Blog Post

For the past 5 years I have worked on projects that have needed to meet some kind of accessibility standards (Sec508 several years ago; now WCAG 2.0 A/AA). In that time, I have learned a few simple ways that any dev can start to keep in mind while working on web UIs.

Write Semantic HTML

So, I see far too many div's these days - but fortunately, this is the easiest place to start.

Example: If it reads like a list (perhaps iterating over an array using the map method), you should likely use the tag or role:ul, ol or role=list (read more). I am not particularly a fan of using the role for this example but maybe you can't change the HTML for some reason and can only append attributes to existing elements. It's definitely better than nothing.

Review the list of HTML elements - read through their descriptions and swap out your div tags today. Structural/semantic HTML is THE starting point for accessibility because assistive devices rely on the DOM.

Write your HTML first - this makes you think about the structure from the start.

Test your semantic HTML by disabling CSS - does your content still look organized and read as you intend it to?

• Firefox: View > Page Style > No Style

• IE 11: View > Style > No Style

• Chrome: Use a browser extension like Wave; toggle "Styles" off

*React tip: you can use Fragments to help group your content without adding extra nodes to the DOM.

Tab around

Test your web page without a mouse. Users should be able to access all the interactive elements you need them to by using their keyboard. Interactive elements such as input fields and buttons will receive focus by default. Other elements such as divs usually don't need to be interacted with. However, if you need to bring focus or have a non-interactive element be tabbale, you may consider adding the tabindex attribute to your element or using focus() in your JS.

The order in which your items are accessibile depends on the DOM order. You can change the order using tabindex.

Be considerate with dynamic content

Aside from using the focus method to set focus to elements manually, you can also ensure your dynamic content makes use of roles such as status and the aria-live attribute.

The aria-live attribute has three values, polite, assertive, or off (off is the default.) An example would be if you have a list of items that can be filtered by the user. The container for that list should have aria-live="polite" so that when the list items update based on the filter, the update is announced when the user pauses. I personally haven't really felt the need to set it to assertive since that interrupts all other announcements.

Similarily, you have roles like status which works like a "polite" live region and alert which works like an "assertive" live region. For example, the status role could be used to notify a user that a change has been saved. You may use the alert role is used to announce critical information such as an error that needs immediate attention.

Use browser tools and extensions

Most browsers now have Accessibility tools built right into their devtools. They can show you the color contrast, tab order or check for other common issues. There are two extensions/add-ons that I've enjoyed using in my development flow that tell you how to fix issues as well:

1. Axe browser extension - This one adds a tab to your browser devtools.
2. WAVE - This tool renders on the left side of your browser.

---

Stuff to check out

For much more in-depth explanations and examples, this W3C document which covers guidance for common design patterns including examples.

There's a checklist created by the A11y Project.