loading...

7 Must Haves for Web Accessible HTML in Your Site ❤️️ [Template]

njericooper profile image Njeri Cooper ・6 min read

Lots of developers are building their own personal blogs, brands, and working on side projects. What better way to strengthen development skills than incorporating the best web accessibility practices into each web app? At the time of writing, these are some of the best ways to make a site accessible to the visually and physically impaired:

1. Aria Roles, States, and Properties

ARIA stands for accessible rich internet applications. These applications are a list of attributes that communicate with a subset of the DOM called the accessibility tree. The accessibility tree is a more simplified rendering of a website. Some may call this the "shadow DOM". This version is readable by screen readers and focusable for keyboard users.

Assigning the correct role property to an HTML tag lets ARIA file its intended function. It's important to not use abstract terms when defining roles. There are a few types of roles that serve the purpose of structuring a site for the DOM and the accessibility tree. The types of roles and a few examples of them are:

  • Landmarks

    • Navigation
    • Search
    • Banner
    • Main
  • Widgets

    • menuitem
    • tab
    • textbox
  • Document Structure

    • article
    • img
    • row
    • toolbar

An alphabetical list of all ARIA roles and their definitions can be found in section 5.4 of The Roles Model by w3. Below is an example of what appropriate roles would look like for a nav bar.

<nav role="navigation">

    <ul role="menu">

        <li>

        <a href="" role="menuitem">Home</a>

        </li>

        <li>

        <a href="" role="menuitem">About</a>

        </li>

        <li>

        <a href="" role="menuitem">Contact</a>

        </li>

    </ul>

</nav>

In addition to ARIA roles, there are states and properties which have values that give HTML tags characteristics. These values can be a boolean, number, token, etc., and globally define elements on the DOM. For example, a menuitem widget can have the state of "hidden" that is changed on hover. A use case for this may be a dropdown menu that becomes visible when focused on with a mouse or keyboard selection. Here's what would be placed inside of the html tag

aria-hidden="true"

Another ARIA attribute that may be used in a nav bar is aria-owns. To let the DOM now that the menu item has a parent child relationship with the menu items nested under it.

<nav role="navigation">

    <ul role="menu">

        <li>

            <a href="" role="menuitem">Home</a>

        </li>

        <li aria-owns="child-item">

            <a href="" role="menuitem">About</a>

        </li>

            <ul id="child-item">

                <li>

                    <a href="" role="menuitem">My Mission</a>

                </li>

                <li>

                    <a href="" role="menuitem">Portfolio</a>

                </li>

            </ul>

        <li>

            <a href="" role="menuitem">Contact</a>

        </li>

    </ul>

</nav>

Assigning ownership would help to set the DOM and accessibility tree structure. This is useful in the event that some of the HTML becomes unordered.

Here's a list of all official aria states and properties.

2. Semantics

One of the dangers of ARIA is that developers can make the whole accessibility thing a catch 22.

Sometimes, we create elements on a website just to get it up and working. The thought of completing a project with urgency is appealing. Doing this results in poorly written code that just "works". It will boost user experience if the HTML tags correspond with its intended function. The most common example of what I mean is using a span, div, or text element as a button instead of using the button tag. This is a misuse that overrides the accessibility definitions already in place. To quote Steve Faulkner "No ARIA is better than Bad ARIA".

3. Alt Text

Alt text is short for alternative text. The alternative text is not visible to the user, but holds information about its link or image. It can be a description or an attribute. It is available to screen readers and search engines to index images and links.

On my website, I add alt text with my name, what I do, and image descriptions.

4. Media with Lazy Loading

Lazy loading is a native feature in the Google Chrome browser. It allows for images to be loaded only when you look at them. This is awesome because images and videos don't pre-load and down the page’s speed. To use the lazy loading feature use this code in image HTML tags:

loading="lazy"

There is Javascript that adds cross-browser support. To learn more about lazy loading for other browsers, check out this article by Addy Osmani.

5. Sections

Implementing sections into a website helps to separate the different types of content. Sections could be landmark tags like search, side bars, main content. Section tags let assistive technologies know that the developer is making a "region" on a page. On my website, I use it to make "about me" separate from "what I do". The structure looks like this:

<div role="main">
<section class="section section-1" id="who" >
  <div class="who" >
    <h2 class="title">Who TF is Coop?</h2>
    <p>Demo Text</p>
  </div>
</section>
<section class="section section-2" >
  <div class="what" >
    <h2 class="title">What</h2>
  </div>
</section>

To learn more about the region role and how it's used and classified by ARIA, check out this MDN page.

6. Tab Index

Some web users navigate a website by only using a keyboard. Up and down arrows scroll, the tab key focuses on links, buttons, and selectable page elements and the enter key selects. Modern browsers have keyboard focus built in. If a web browser cannot detect the portions on a website that should be clicked on or hovered over, use tabindex. Tabindex sets an order or hierarchy to selectable items on a page. The default value is 0. This means that everything is equally important and will be ordered from left to right for rows, then up and down for side menus or columns. Change the value of tab index to match the page's layout and ensure for the easiest navigation

7. Inclusive Design

I've learned that the best way to make sure a website is accessible is to use all the features. Try turning on voice over, screen readers, or using your keyboard to get around your website. Being aware is the only way that we as humans can make sure our web apps are accessible to everyone.

Full Homepage Code Template

<!--begin nav bar-->
  <nav id="nav" class="nav" role="navigation" >
    <ul class="navbar" role="menu">
      <li>
        <a href="#home" role="menuitem" alt="home" tabindex="0">Home</a>
      </li>
      <li>
        <a href="#who" role="menuitem" alt="Who is Njeri Cooper?" tabindex="1">Who</a>
      </li>
      <li>
        <a href="#what" role="menuitem" alt="What does Njeri Cooper Do?" tabindex="2">What</a>
    </li>
    <li>
      <a href="#contact" role="menuitem" alt="Contact Njeri Cooper" tabindex="3">Contact</a>
    </li>
  </ul>
</nav>
<!--begin main content section-->
<div role="main">
<section class="section section-1" id="who" >
  <div class="who" >
    <h2 class="title">Who TF is Coop?</h2>
    <p>Njeri Cooper is a front end web and iOS developer. Lorem Khaled Ipsum is a major key to success.</p>
    <p>They don’t want us to win. I’m giving you cloth talk, cloth. Special cloth alert, cut from a special cloth.</p>
  </div>
</section>
<section class="section section-2" id="what" background="https://vignette.wikia.nocookie.net/steven-universe/images/e/ed/Steven_the_Swordfighter_Cloud_Temple_Background.jpg/" loading="lazy" alt="Cloud Temple Image From Steven Universe">
  <div class="what">
    <h2 class="title">What</h2>
    <div class="links" id="contact">
      <a href="http://github.com/njericooper" alt="Njeri's Github" tabindex="4">git</a>
      <a href="https://dev.to/njericooper" alt="Njeri's tech blog" tabindex="5">dev to</a>
      <a href="https://twitter.com/njericooper" class="last" alt="Njeri's Twitter" tabindex="6">twitter</a>
    </div>
  </div>
</section>
</div> <!--end main content section-->
<div class="email-container">
  <div class="email_container">
      <form id="singular-form" role="form">
          <button class="shown" type="button" id="trigger" role="button" tabindex="7">Notify me</button>
          <div id="input-container">
              <input type="text" placeholder="E-mail">
              <button type="button" role="button" tabindex="8">Send</button>
          </div>
          <div id="success">Thank you!</div>
      </form>
  </div>            
<!--Footer-->
<footer class="footer" role="contentinfo">
    <p>©2019 OG Codes</p>
</footer> 

Njeri Cooper

Njeri uses the web to educate, innovate, and create. Read her authentic student to freelance dev story. Feel free to send Njeri a message here.

Twitter | | Pinterest | | Instagram

Posted on by:

njericooper profile

Njeri Cooper

@njericooper

I do lit wavy tech things. I like avocados and alkaline water.

Discussion

markdown guide
 

Hi, Njeri, I'd like to challenge a couple of the examples you've shared here.

  • You've used the role attribute in a lot of places where it is inferred -- for the nav, button and form elements; see, for example, MDN:

Using the <nav> element will automatically communicate a section has a role of navigation. Developers should always prefer using the correct semantic HTML element over using ARIA.

If there's more than one nav element on your page, it can be helpful to add an aria-label to distinguish them. But, just like the tweet you included from Steve Faulkner said, no ARIA is actually better than bad/unnecessary ARIA markup.

  • role="menu" isn't ideal or recommended for site navigation; see details here.

  • Any mention of tabindex should make clear which elements already receive focus (ie, <a href="#" tabindex="0"> is not necessary) and that declaring a value positive tabindex on any item can result in needing to set tabindex values throughout your layout, which is a headache.

  • Also, the code example under #5 "Sections" is missing the closing </div> -- though, if you're using role="main", maybe a main element would be better than a div?

I took a stab at commenting and updating your CodePen here. There's a lot of outdated and confusing info about accessible markup online, so I hope this doesn't discourage you -- keep exploring and learning 😁

 

Certainly! I love feedback. What would be the best way to tab through dropdown menus or adding non-visible options to skip tabbing through some sections of a site (in the event that there is a long sidebar)? I have a few buttons that I'm adding and want to make sure that safari knows that they are tabbable. I read a posts like this that made me want to ensure that all browsers index every button, every time.

Wrapping all content in a main tag would be more optimal. I'm going to implement the edits you made. Thanks so much for taking the time to do that.

My email form is animated with CSS (accessible CSS and javascript coming in pt 2). It looks a little weird in plain HTML, email form animation here.

Yes, there's so much old web accessibility content out there. It was really hard to find things that are relevant. While doing research on the subject, it seemed as if the topic had become a forgotten folklore of the web. Are there any other resources or lists where I can get more up to date accessibility practices?

 

Not the OP, but I think I might be able to answer a few of your questions there.

For dropdown menus, there are a few ways to satisfy accessibility according to the standards in WCAG 2, but I typically like "Approach 2" on the W3C page on Fly-out menus. This method ensures that keyboards and screen readers get the advantage of a mouse user by being able to jump past content that is irrelevant to them and then choose when to expand the menu.

As for your question on making sure elements are tabbable, there are a number of elements that inherently are tabbable, no additional code required. Key examples are <a> (assuming it has an href attribute), <button>, <input>, <select> and <textarea>. All browsers do this automatically.

It is generally never recommended to use tabindex unless you are using the -1 value to remove an element from the natural tabbing order (or creating a target for tabbing), or the 0 value to give an element tab focus that does not normally receive it. The order of tab focus is predetermined by the order in the DOM (therefore, the way to make your site accessible for tab order is to make sure the order of elements in code is the same order you expect a user to read the content).

If you want up to date information on accessibility practices, I would definitely use the W3C Web Accessibility Initiative resource and I'd also highly recommend WebAIM as well.

Thanks for writing this article as well, spreading the word about accessibility is definitely important, especially as it becomes more of a requirement for many organizations.

Thank you, @sg667 . I will make sure to check out W3C's accessibility page.

 

I shared your article here t.me/theprogrammersclub and check out the group if you haven't already!

 

I checked it out and it’s awesome 😎 Thanks for sharing 🙌🏽 What is the goal for your channel?

 

To bring more equality between male and female programmers/developers, most of us in the tech world underestimated the female programmers/developers and the great job they created. I'm speaking for myself as a male, I believe that Men should appreciate the hard work that the women put into this tech world, and actually, give them some credits and treat them as it should be. I see so many women online have to hide their identity just for their work or courses to be accepted by the majority of people without questioning their gender and ability/knowledge/skills. That's why I'm trying to share more contents that are made by women instead of men in my channel to bring more awareness to the community.

Doing the lords work (I respect what you’re doing). I’ll download Telegram and join the channel ✊🏾

 

Great work. While people think that you have to don't have to use certain things due to redundancy, I would say that you actually do depending on the users, the tech and the legal team. For instance, although nav works for pages rendered in most settings for screen readers, it didn't work for our team onsite for our AMP pages inexplicably so we had to use the navigation role as well. It was also coming from the legal team the the role had to be in there to meet the prerequisite for the audit team. Better safe than sorry I always say.