Accessibility is for everyone.

What if the work really did only impact those with disabilities? What if the work was only for those who are blind or deaf? What if the work were only so that one person could use their iPhone? I should hope we’d be doing it anyway.[7]

Getting Started

Learn about some quick ways you can make your website more accessible on[38,39].

Use this checklist to ensure you are doing your best to meet accessibility requirements. Consult best practices[5] for those with low-bandwidth internet.


There needs to be a contrast of at LEAST 4.5:1 between the background and foreground of colors for readability.

In WCAG 2, contrast is a measure of the difference in perceived "luminance" or brightness between two colors (the phrase "color contrast" is never used). This brightness difference is expressed as a ratio ranging from 1:1 (e.g. white on white) to 21:1 (e.g., black on a white).

Alt Text, Titles, and Captions in HTML[11-14, 35-37]

Alternative (Alt) Text is meant to convey the “why” of the image as it relates to the content of a document or webpage.[11]

  • Add alt text to all non-decorative images.
  • Keep it short and descriptive, like a tweet.
  • Don’t include “image of” or “photo of”.
  • Leave alt text blank if the image is purely decorative
  • It's not necessary to add text in the Title field.

Accessibility and HTML Elements

You can go a long way by just using the correct semantic elements. If it's a link, use an a tag, if it's a form, use the form tag, etc.

Tab Order

Only interactive elements should be tabbable! Tab is a special key used with screen readers, it should not be used for everything.

The tab order is set by how they show up in the DOM. If you want users to be able to tab through something in a certain order, you should put the elements in the HTML in that order. The keyboard focus should also visually make sense. When looking at the page as a user, does tabbing through make sense, or is it jumping around in unexpected ways?

You can set the tabindex attribute on an element if you must, but it is strongly discouraged and should be avoided if at all possible.

tabindex Ordering[32]

tabindex with values of 0 and -1 are special cases:

tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source.

A negative value (the exact negative value doesn't actually matter, usually tabindex="-1") means that the element is not reachable via sequential keyboard navigation. tabindex="-1" may be useful for elements that should not be navigated to directly using the Tab key, but need to have keyboard focus set to them. Examples include an off-screen modal window that should be focused when it comes into view, or a form submission error message that should be immediately focused when an errant form is submitted.

tabindex should be equal to or less than zero, NEVER above.

Warning: You are recommended to only use 0 and -1 as tabindex values. Avoid using tabindex values greater than 0 and CSS properties that can change the order of focusable HTML elements (Ordering flex items). Doing so makes it difficult for people who rely on using keyboard for navigation or assistive technology to navigate and operate page content. Instead, write the document with the elements in a logical sequence.

Elements with tabindex="-1" can still be focused on using Javascript via .focus(), but again this should be avoided if at all possible.

Interactive Elements

The browser will handle the user interaction natively and assistive tech will give special options for interactive elements.

Often time, people use divs and spans to build custom buttons and things. They will not be focusable by default or interactive in the way that assistive tech users expect! This must be added manually via giving a tabindex[32], having a proper role, and adding event handlers for their equivalent keyboard interactions.


SPAs made with a framework like React put out standard HTML and thus should follow the same rules of accessibility for static sites. Be careful that you are using semantically correct HTML whenever possible and giving correct aria attributes when necessary.

Focus and Title

In traditional/static websites, when moving to a different page (for instance, after following a link or submitting a form):

If you have a single page application, these must be done explicitly, as dynamic content is being added/removed dynamically and no "new page" is being moved to in the eyes of the browser. When moving to a new page, you should ensure that:

Custom Components

If you are building custom components for the web, follow the ARIA Authoring Practices Guide[x] to make sure you are giving all users everything they need.


  10. Make your website accessible and look ok
  21. Best practices for making things work on older browsers
  22. Atlassian Design's Accessibility Guides
  23. Accessible contrast finder
  24. ARIA Spec for the Uninitiated, video
  25. W3C HTML Validator
  26. Derek Featherstone on LinkedIn, and his homepage
  27. Accessible Frontend Components
  28. Understanding the Four Principles of Accessibility
  29. The 7 Principles of Universal Design
  30. Chrome Axe DevTools
  31. WebAIM's Guide to Conforming to WCAG2, successor to Section 508
  32. tabindex
  33. Focusability and tabbability of all elements
  34. ARIA Authoring Practices Guide
  35. Axess Lab | Alt-texts: The Ultimate Guide
  36. Considerations when writing alt text | by Scott Vinkle | Shopify UX
  37. WebAIM: Alternative Text
  38. Common accessibility issues that you can fix today |
  39. More common accessibility issues that you can fix today |
  40. A New Day: Making a Better Calendar - 24 Accessibility
Incoming Links

Last modified: 202304260456