For the past 5 years I have worked on projects that have needed to meet some kid of accessibility standards (Sec508 several years ago; now WCAG 2.0 A/AA). I have collected a few simple ways that any dev can start to keep in mind while developing new UIs that I thought I'd share.
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:
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.
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
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 has three values,
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:
- Axe browser extension - This one adds a tab to your browser devtools.
- 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 covers A LOT.
There's a checklist created by the A11y Project.