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.

Thanks for incorporating accessibility considerations into your work!

Automated testing

• Run the axe DevTools tests
  You can install the axe DevTools Chrome Extension and then use it on the page (guide to using axe DevTools). Fix any issues that are flagged.

• Run the WAVE tests
  You can install the WAVE Chrome extension and then use it on the page (guide to using WAVE) to check for any other auto-detectable issues.

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.

• Hide certain 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 of this might be an election map full of svgs and labels, etc. Ideally, you’d include a table version of the data for accessibility and just 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.

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?

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?

Screen reader & keyboard controls

• Navigate content with keyboard only
  Using your keyboard only, tab through the buttons, links, hoverable elements and any others the user should be able to interact with, ensuring that (a) they each receive appropriate focus styles and (b) that they are clickable with the enter key (links and buttons) and/or space key (buttons). Each time you press the tab key, you should see something change on the page. If not, there is a missing focus style or tab index issue.

• Test with screen reader linearly
  Using a screen reader, navigate the page from top to bottom. Ensure all visible text is read aloud in a sensible order.

• Test with screen reader rotor
  Open the screen reader rotor 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 the 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.