Note: if you are using Firefox on macOS, in order to work with the examples in this page, you need to go to System Preferences -> Keyboard -> Shortcuts and tick Use keyboard navigation to move focus between controls. MacOS does not make this obvious for some reason.

Quick tips on boosting accessibility of your web page
In this blog post, I want to share my learnings after working on an accessible UI component library for over a year. Our team was fortunate to include an accessibility expert who helped set a high bar for accessibility.

The goal of any frontend website or application should be to make it usable by as broad of an audience as possible, including people with disabilities.

In an article by the World Health Organization, in 2021 over 1 billion people lived with some form of disability.

A total of $13 trillion is estimated to be controlled by people who have those with disabilities either in their family or in their circle of friends:
https://www.rod-group.com/sites/default/files/2020%20Annual%20Report%20-%20The%20Global%20Economics%20of%20Disability.pdf

The number of federal lawsuits for inaccessible websites has also steadily increased:
https://www.adatitleiii.com/2021/04/federal-website-accessibility-lawsuits-increased-in-2020-despite-mid-year-pandemic-lull/

Why be accessible:

• Attract more users
• Improve Lighthouse metrics
• Don’t get sued

A set of guidelines called WCAG (Web Content Accessibility Guidelines) are usually used to ensure accessibility compliance. This blog post will touch upon a number of most common WCAG violations.

Always add labels to inputs

Inputs should always have text associated with them explaining what the input value used for. If a label is missing, then, when focusing with a screen reader, the user will not know what the input is used for. Placeholder text cannot be used as a replacement for labels because its purpose is to show an example of a valid value. Moreover, placeholder text does not have broad support across screen readers, as noted by Web Accessibility Initiative (WAI).

<label for="html">HTML</label>
<input id="html">

Always show focus

WCAG Success Criteria 2.4.7
A web application should be entirely navigable using a keyboard. One way of doing so is by hitting the Tab key to focus across different elements of the page. When navigating like this, a clear indication of focus must be shown to indicate which element is currently focused. Not doing so affects the keyboard usability of the website.

Move focus sequentially (left-to-right, top-to-down)

WCAG Success Criteria 2.4.3
Related to making focus visible, focus should also traverse the page sequentially in a way that makes sense. In most cases, this will mean that pressing Tab moves focus left-to-right, top-to-bottom. This violation is often made by using the CSS float property which ignores the ordinary flow of the page. A common way of fixing this is switching from float to flexbox with justify-content: right.

Note that if the website is provided in a language read right-to-left, such as Arabic, then focus should move right-to-left accordingly. To see an example of this, visit this Syrian government page.

Avoid color-alone failure

Color alone cannot be used to convey information. An example of this failure would be displaying a set of badges (say a gold, silver and bronze medal) with the expectation that the user will make out the difference. Color is a stylistical CSS value which is not conveyed to a screen reader user, therefore when navigating across the badges, the user will not be able to identify which badge is gold, silver or bronze. The easiest way to avoid this failure is to ensure labels exist for the given elements. These can be visual or hidden using aria-label.

Keep sufficient contrast between text and background

WCAG Success Criteria 1.4.3
The color between text and the background must be of a sufficient contrast in order to ensure easy readability. While there are different levels of compliance to this rule, a contrast ratio of 4.5:1 is a good start that will cover most use cases. A handy way to inspect for errors in the WebAIM contrast checker. To find out more about the different levels of compliance, see the WAI page for WCAG conformance.

Do not conflict links with buttons

It is important to differentiate between the semantic meaning of links and buttons:
Links are used to navigate to a different page.
Buttons are used to trigger an action on the current page.

A common source of confusion for screen reader users is when the two elements are used interchangeably. Using a button to open an external link in a new tab is one of the most common violations of this rule.

Use modal dialogs for required input (with trapping and returning focus)

Disclosures: pop-ups that add additional information without affecting the user tab-flow.
Dialogs: pop-ups that trap user focus and force the user to perform an action.

When opening a modal that acts as a dialog, focus must be placed inside of the modal.
When closing the modal, focus must be placed back on the trigger button.

Use semantic HTML whenever possible

Make use of , , and elements to indicate the key parts of your page. If you don’t make use of these landmarks, then screen reader users may lose critical context about the section of the website they are currently on. The key advantage of using semantic HTML is that screen readers can provide quick navigation across the key landmarks of the page. To learn more, see this page for navigating landmarks with Voiceover on MacOS, and this page for using NVDA Browse Mode for Windows.

Use sufficiently large touch targets

WCAG Success Criteria 2.5.5
Use touch targets of at least 44 by 44 pixels for all interactive elements. This is especially relevant for mobile devices which have a smaller viewport. Failure on this criteria can cause frustration for mobile users and fingers are a less accurate method of input compared to a mouse.

Add a skip-to-main-content link

If your webpage has a lot of links on top, screen reader users are forced to tab through all of them before getting to the main content of the page. A handy fix for this is to provide a link that skips to the main content of the page. The link is ordinarily hidden with CSS and made visible when focusing. Clicking on the link puts focus on the main contents of the page, saving the user the hassle of tabbing.