The following checklist is derived from the much more detailed WCAG guidelines. This does not cover every possible accessibility issue but aims to cover the most prominent varieties. It’s meant to be an entry-level guide. For help with any part of the guide, or to request an addition to any of our docs, contact email@example.com. We can also share copies of this checklist as .md files upon request.
Important: Repeat all steps below on all screen sizes (mobile, tablet, desktop) to better evaluate accessibility across devices.
Many of the checklist items link out to more detailed instructions from our accessibility docs on how to test.
We provide a 5-minute video tutorial going through a portion of the checklist.
Thanks for incorporating accessibility considerations into your work!
1. Screen reader & keyboard controls
It might seem complicated, but this testing often takes only a minute or two! Use the links below and reach out with any questions.
Navigate content with keyboard only
tabkey (setup needed if using Firefox and Safari) and
tabto cycle forward and backward through the buttons, links, hoverable elements and any others the user should be able to interact with, ensuring (a) they each receive appropriate focus styles and (b) they are clickable with the enter key (links and buttons) and/or space key (buttons). Each time you press
tab, you should see something change on the page. If not, there is a missing focus style or tab index issue. See the full list of keyboard controls for details on other behavior, like what arrow keys and escape should do.
Test with screen reader linearly
Using a screen reader (guidance on using screen readers), navigate the page from top to bottom. You can click with your mouse to position the screen reader, which is helpful for testing specific parts of a page. Ensure all visible text is read aloud with correct pronunciation and in a sensible order.
Test with screen reader rotor
Open the screen reader rotor (
Uwith VoiceOver) and ensure all links, buttons and other elements have appropriate names. Interactive elements should not have generic names like "click here." You should be able to understand what each link or button does from the rotor menu without other context from the page.
Confirm heading order is correct
Check the page headers using a screen reader. Does the heading order make sense? There should be only one
h1, the page title. From there, headings should be ordered strictly by page hierarchy (don't jump from
h4, don't use
h2as a subhead of an
Confirm page landmarks are present and have correct content
Are the base page landmarks (
footer) present? If there is complementary page content like a sidebar or right rail, is it in an
asidetag? Are the landmarks accessible with a screen reader? They should contain the right content to help screen readers scan the page quickly.
Ensure all images have alt text
Follow the guidance for writing alt text. If an image is purely decorative, make sure it still has
alt=""present in the HTML. Similarly, videos and gifs should have text descriptions for screen reader users.
Test with reduced motion settings turned on
Turn on reduced motion, and ensure all non-essential animation and other moving content is eliminated upon page refresh. If not, then you should use the prefers-reduced-motion media query to modify behavior accordingly.
Hide useless content from screen readers
Just as you would put alt="" for purely decorative images to hide them from screen readers, you should add aria-hidden="true" for content on the page that is not screen reader friendly. An example might be an election map full of svgs and labels, etc. You can include a table version of the data or some other alternative for accessibility, and then hide the map with aria-hidden.
Avoid auto-playing audio and video
Never auto-play audio. Auto-playing video, animations and other graphics (including gifs) are strongly discouraged. Ensure all audio and video instances have an accessible pause, stop or hide button.
Eliminate rapidly flashing content
Videos, gifs and animations must not include any instances of flashing or blinking more than 3 times within any one second, as this is a seizure risk.
Provide captions and transcripts
Anywhere there is audio, there should be a transcript provided. Videos with audio should include captions in addition to transcripts. Both should include words spoken AND any other meaningful sounds from the audio (such as a sigh or laugh in conversation, or the chopping of a knife in cooking) as well.
3. Text, labels & zoom settings
Ensure text decoration is not needed to understand meaning
Do you use underlined text (example) or struck-through text (
example)? Text decorations like these are often not recognized by screen readers and are often confusing to other users, too, so they are generally not recommended. If you do use text decoration to convey meaning, then you must also provide other ways for users to understand the meaning of decorated text.
Ensure non-English content is labeled as such
Content in non-English languages, such as Arabic or Spanish, must have the lang="CODE" attribute set, where CODE is the language code e.g. “ar” for Arabic or “es” for Spanish. There’s a list of language codes. This is essential for non-English text to be read correctly by screen readers. Additionally, Arabic and some other languages are read right-to-left. In those cases, we need to set an additional attribute in the HTML,
Clearly label interactive content
Meaning of icons, buttons and other elements should be explicitly conveyed via text whenever possible. In all cases, interactive elements should have appropriate aria-labels. See our guidance on labeling for screen reader users. Avoid user prompts or notices that disappear automatically. If the content includes a form, make sure that clear prompts and error messages are provided. See our guidance on forms.
Change page zoom level and browser zoom settings
Set page zoom to 200% (on a Mac, press
command +to zoom in). Does text scale correctly? Is it still readable (no overflow, overlap, etc.)? Then, Restore the page zoom to 100% and increase the font size in your browser settings to 200%. Does text scale correctly? Is it still readable?
Confirm white text is never on a pure black background
White text on a pure black background causes a fuzziness known as halation for many users with astigmatism. See our guidance for avoiding halation.
Ensure color contrast meets the WCAG AA standard
All color combinations, especially for text and interactive elements, must meet at least the AA (preferably AAA) color contrast standard using the WebAIM tool.
Check contrast for common forms of colorblindness
Ensure color combinations meet the AA color contrast standard for colorblind users among at least the three most common forms of colorblindness.
View the page in dark and light mode
Dark mode and light mode should both be supported. Does the page change to light or dark mode automatically per browser settings? Does the page pass color contrast thresholds in both modes? And does everything change color correctly upon toggling to light or dark? Are all links, buttons, fonts, etc. on the page still visible?
5. Automated testing (will not catch most issues)
If you are a developer, read our documentation on automated testing for info about adding automated checks to your code.
Run the WAVE tests
Install the WAVE Chrome extension and then use it on the page (guide to using WAVE). The tool is great for beginners, as it allows you to learn about different types of issues by clicking interactive labels that appear on the page. Fix any issues that are flagged.