Skip to main content
Design system

Accessibility Checklist

Overview of considerations, not comprehensive

Table of Contents

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 accessibility@washpost.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
    Press the tab key (setup needed if using Firefox and Safari) and shift + tab to 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 (caps lock + U with 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 h2 to h4, don't use h2 as a subhead of an h3, etc.).

  • Confirm page landmarks are present and have correct content
    Are the base page landmarks (main, nav, header, footer) present? If there is complementary page content like a sidebar or right rail, is it in an aside tag? Are the landmarks accessible with a screen reader? They should contain the right content to help screen readers scan the page quickly.

2. Multimedia

  • 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 or 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 is readable and in plain language
    Text should be no smaller than 12px and written in plain language wherever possible. Is there any jargon or use of idioms? These should be avoided.

  • 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, dir="rtl.

  • 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?

4. Color

  • 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.

  • Confirm black text is never on a pure white background
    Black text on a pure white background causes eye strain among many users. See our guidance for avoiding eye strain.

  • 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.

Edit this page on GitHub.
CommunityXTwittergithubGithubyoutubeYoutube