Building Accessible Web Experiences: A Checklist for Frontend Developers

Contents

1. Benefits of accessible web
2. Accessibility checklist
3. Useful tools

Benefits of accessible web

Around 16% of world population have some kind of disability, however only 3% of the web is accessible to people with disabilities. Not only we should strive to accommodate to this part of population, but accessible web can be very helpful for people without disabilities as well. Consider older people, people with slow internet connection, or people with situational immobility - broken arm, etc.

Its time we bring accessible web to light and we, as a frontend engineers, are the people who can take proactive action to do that.

Accessibility checklist

Let's dive into most common and important accessibility checkpoints and their implementations.

Keyboard Interaction

1. Interactive elements should receive keyboard focus. Buttons, clickable cards, checkboxes, tabs, etc. should be highlighted when using keyboard navigation. Add tabindex to allow element to be focusable with the Tab key and don't forget about adding CSS styles for :hover, :focus and :active.
2. Anchor tags with no href should receive keyboard focus. This rule is almost the same as above except for anchor elements <a>. Depending on the browser, you can find that anchor can be selected with keyboard even without tabindex, however those without href cannot. Add tabindex to all anchors.
3. Tooltip should receive keyboard focus. Tooltips often provide additional information that is usually accessible when mouse is hovered over component. We need to make sure tooltip is shown when anchor element is in focus as well.

Landmarks

1. Landmark regions should be clearly defined. Webpage should be divided into separate landmark regions, each with a defined role. Identify webpage's logical structure, assign and label the areas.
2. Page structure should be marked up semantically. Related to above, use main, nav, footer, header, section, aside to mark up the webpage.

Document Structure

1. Tables should have table headers. Don't forget to add th tags to tables.
2. Form fields and visual labels should be associated. Add aria-label or aria-labelby to input element.
3. Error messages should be associated with input fields. Input error message should be associated with their controls. Add aria-describedby to error message or area-label if its show in the label.
4. Headings should be marked up semantically. Make use of heading tags starting from h1 and make sure that they're positioned in order of importance. Avoid putting h3 in <nav> and h1 below in <main>, for example.
5. Heading levels should not be skipped. Related to above, do not put <h3> semantically directly under <h1>
6. Lists should be marked up semantically. This includes ordered, unordered and description lists.

Avoid:

<ul>
    <div>One</div>
    <div>Two</div>
    <div>Three</div>
</ul>       

Better:

<ul>
    <li>One</li>
    <li>Two</li>
    <li>Three</li>
</ul>       

Readability

1. Regular text should have sufficient contrast. Don't put red text on a green background! Use sufficient contrast between text and background colours to make content readable for individuals with low vision or colour blindness.
2. Dynamic text resize should be supported. When user sets font size to 200% in their browser settings, webpage fonts should scale automatically, without loss of content or functionality. Avoid hardcoded size units such as px and use em or % instead.

Skip Navigation Links

1. There should be keyboard functional link to skip repeated block of content. Add "skip to content" or similar links that allow users to bypass repetitive elements, e.g. navigation menus and go directly to the main content. This is will be of great benefit to screen reader users.

Element Relationships

1. Radio groups should be associated with legend. Make sure to indicate that what property radio buttons control by wrapping them in <fieldset>.
2. Checkboxes should be associated with their group level. Similar rule applies for the checkboxes.

Indicators

1. Links should visually or programmatically indicate that they open in a new window. Adding target="blank" to anchor tag is helpful but it's even better to add a small arrow icon or image to the link.
2. Mandatory fields should be clearly marked. Usually an asterisk * is used to indicate required field.

States and Properties

1. Pages should have descriptive titles. Make use of <title> tag. Not just for accessibility reasons, its one of the key tools to improve your SEO.
2. iFrames should have descriptive titles. iFrame is basically a page within a page, same rule applies for it too.
3. <html> tag should have lang attribute. It helps screen readers to use correct pronunciation. If parts of your website use different languages, add lang attribute to respective elements as well.
4. Roles: ARIA roles define the type of element and its purpose. Roles can be used to indicate whether an element is a button, link, menu, dialog, or other interactive components. For example, role="button" can be added to a <div> element to convey that it functions as a button.
5. Labels. Interactive elements should have accessible name inside aria-label
6. Element semantics should not be inappropriately suppressed with aria-hidden. Avoid hiding elements from accessibility tree; If required, use CSS styles to make element invisible by changing opacity or visibility.
7. Images should have alt attribute. Have you ever been stuck with slow connection and faced a white square wonder what's that supposed to be? Add an alt attribute so the images could be easily identified by text readers.

Useful tools

Going through all those checkpoints might be overwhelming, and indeed, the larger your webpage or application is, the more effort it will take to find and address them.

There are, luckily excellent tools that can jumpstart the process.

• WAVE: A free online tool that provides visual feedback about the accessibility of your web content, highlighting potential issues and offering suggestions for improvement.
• axe DevTools: An accessibility testing extension for Google Chrome and Firefox that can be used directly within the browser's developer tools.
• Pa11y: An open-source automated accessibility testing tool that you can run from the command line or integrate into your CI/CD pipeline.
• Lighthouse Accessibility Audit: Excellent for a quick accessibility insight, Lighthouse is available with Google Chrome dev tools and checks highlight opportunities to improve the accessibility of your web app.

Remember that automated tools are valuable for identifying many common accessibility issues, but manual testing is often necessary to fully understand and address the user experience for people with disabilities. A combination of automated and manual testing, along with a commitment to ongoing accessibility, is key to maintaining an accessible web presence.

Happy coding!

Original post

Comments

[Cezary Tomczyk]

All of the tools mentioned are great. However, there are challenges that aren't covered, like support for single page applications, dynamic changes, or testing accessibility in a real user environment.

It is worth mentioning that Lighthouse uses Axe, but not all the rules are there. I guess someone in Google wanted to strip out the rules to the bare minimum, but that misguides whoever uses Lighthouse to the point that says "Your page is accessible", which may not be true.

A bonus of making a site accessible is that SEO will benefit from it. For example, when you add an alternative description to the image, the search engine will understand and process it. Or your site uses semantic HTML, which search engines can process in a much more efficient way to understand the meaning of the content.

[Kate]

Excellent points, thank you!
I've tried to focus on code improvements one can single-handedly apply to webpage/app however there's always a bigger picture to keep in mind of course, such as accessibility testing, integrating those tests in CI/CD and testing in real user environment like you mentioned.

[Cezary Tomczyk]

@snoblomma

integrating those tests in CI/CD

I think writing E2E tests (or the like) isn't the future for accessibility. The reason is that the engineers are spending too much time gathering the required user flows for testing as well as writing tests themselves.

In my opinion (hence I invented a solution to audit accessibility and more on the client side), a much better way is to hook automated audits within your app. That way, you could have your accessibility rules run always on the whole app and on all software development stages, including production. Thoughts on that are very welcome.

[John P. Rouillard]

Kate is that braille keyboard in your cover image? I checked the alt text for the image but it doesn't really describe the image.

[Kate]

Yes! This the braile display in the image (not my photo)
unsplash.com/photos/9xxNZCJZ8bA