Accessibility Checklist

February 19, 2020

The web should be accessible to everyone regardless of their location or ability. Almost one billion people worldwide have a disability, and we’re failing them. We have to commit to doing better. In 2018, disability lawsuits more than tripled to 2,258 in the US. I am not a lawyer and do not claim any of the steps below will prevent you from getting sued for an inaccessible site. This is a list that I’ve used to show “best-effort” toward making what I build accessible for all.

Accessibility is Good Business

From a business perspective, it makes sense to design for accessibility. Why? Accessible websites are automatically SEO friendly (think: alt tags), reach more customers, are generally faster, and showcase best practices. Most of all, accessibility inherently brings usability. It’s a win-win for UX designers.

At BL3NDlabs (where I’m of Head of Design), I wrote this checklist to ensure consistency in our design and build process. These steps work with typical assistive tools including speech recognition, screen readers, and magnifiers.

We’ve written similar checklists for SEO, Content Strategy, User Research, overall Product Design, and Development. We clone these templates and save individual projects as child pages in our wiki. During project scoping, it’s the New Business Team’s and Project/Product Managers’ job to define accessibility requirements.

🔥Tip: make sure your team has an identified owner to document and share accessibility requirements.

Sorry, this list is not a silver bullet or a one-and-done tool. Accessibility takes thoughtful upfront work and consistent monitoring.

The Standards

First, let’s start with a quick background. The World Wide Web Consortium (W3C) “is an international community that develops open standards to ensure the long-term growth of the Web.” The W3C develops Web Content Accessibility Guidelines (WCAG), covering a wide range of recommendations for making Web content more accessible.

WCAG 2.0 and WCAG 2.1 are the current “referenceable” standards. They have 10+ guidelines organized under four principles: perceivable, operable, understandable, and robust. For each, there are success tests at three levels: A, AA, and AAA. A has the least visual impact on design, where AAA significantly impacts design (for example, contrast constraints). If our client doesn’t have a benchmark, then we use WCAG AA as a default.

That’s a lot of versions and letters. At first, accessibility looks daunting. The WCAG realized this (I think), so they wrote this summary.





Guidelines for Designers

Most designers want to know exactly how requirements like this might constrain them. Everyone wants to do the right thing, but it can easily be overwhelming with the number of resources out there. This documentation helps clarify expectations for my team. After all, designing for accessibility is not that hard. (H/T to the talented Pablo Stanley.)

Accessibility is not a feature.
Ethan Marcotte (wrote the book on responsive web design)

ABC = Accessible Brand Colors
A beautiful Accessible Brand Color breakdown from Use All 5.


  1. Make text color contrast enough from its background. Ask for Contrast App (Mac App) or Stark. I like Stark since we can use it for our Sketch and Figma projects as a plugin rather than run a separate app. The Contrast App works well since you can test any application since it’s at the OS level.
  2. Use accessible color tools when developing palettes like Colorable, Color Review, Colorsafe, or Use All 5. Document them in your Design System.
  3. Don’t use color alone to identify information. Use patterns for color differentiation. Consider a color-blind mode toggle.
Colorable Accessible Color Tool
Colorable’s accessible color tool is a fun experiment.


  1. Design w/ focus states.
  2. Use instructions and labels with form fields. Make sure they don’t disappear when the user starts to input text.
  3. Write relevant alt text (per any SEO requirements) for non-text content for screen readers.
  4. Use correct markup for content.
  5. Enable keyboard navigation. Can your user at least tab through?
  6. Allow for font resizing.
  7. Avoid using layout tables.
  8. Use stylesheets and div tags for visual layout.
  9. Use basic header information for data tables (the <th></th> element).
  10. Use linearized data tables for complex data.
  11. Ensure videos have supporting text transcripts and follow modern video best practices for accessibility.
Contrast Checker from Stark
The contrast checker from Stark.

Wistia Accessible Player
Wistia launched a robust player with an accessibility checklist.

Process, Process, Process

Remember, we make no guarantees that the client will not be sued. This “best-effort” process will differ if you’re starting from scratch vs. fixing an existing site. Either way, this is a continuous process that can be managed as part of maintenance activities over time to prevent accessibility emergencies due to lawsuit filings.

Existing Sites

If you’re undertaking an accessibility review of an existing site, first gauge the LOE (level of effort). Once you do that, you will need to assess and prioritize enhancements. You can use Chrome extensions aXe Coconut, Google WAVE, or similar.

Sample aXe Instructions:

  1. Install aXe Coconut in-browser.
  2. Go to View > Developer > Developer Tools
  3. Select the aXe tab.
  4. Make sure the site you’re analyzing is loaded in Chrome. Click the “Analyze” button
  5. You’ll be presented with a list of items to adjust and a severity weighting.
  6. Add each item to a Google Sheet.
  7. Weigh each item according to severity as the highest value to the business.
  8. Weigh each item according to design/dev lift.
  9. Sort by highest value to the business, lowest LOE in design/dev.
  10. Build tickets into your roadmap as an Accessibility theme.
  11. Set a timer or create another project to repeat the cycle during development and post-launch.
aXe Results
A screenshot from aXe Coconut for my website. These tools can pull false positives, so it’s good to select “this is not an issue” if it truly isn’t an issue. I have other issues I need to review with the team at Webflow.

New Project Process Checklist

Designers: I’ve...

  • Checked there is enough contrast between text and its background color, everywhere
  • Paired values of colors together (not only hues) to increase contrast
  • Created and documented accessible color palettes in the design system
  • Checked that I didn’t indicate important information using color alone
  • Designed focus states to help users navigate and understand where they are on site
  • Designed forms with labels that don’t disappear
  • Wrote/used good alt text for images
  • Been as consistent and clear as possible in layout and copy
  • Used descriptive links/buttons
  • Made sure I did not convey important information through images, color, or sensory characteristics alone
  • Checked that accessibility testing is planned and will contribute to testing during Design QA
  • If an experience could not be made accessible, created another route for users to get that information (example: highly interactive feature translated to a script)

Engineers: I’ve...

  • Used the correct HTML element for content
  • Made sure the build supports keyboard navigation
  • Used HTML landmarks
  • Implemented good alt text for images
  • Made sure to use focus states to help users navigate and understand where they are
  • Reviewed the design spec to help users understand inputs, and help them avoid and correct mistakes
  • Used ARIA attributes when applicable
  • Given users a way to skip top-level navigation to access the main content
  • Made links descriptive
  • Avoided images and iconography in pseudo-elements
  • Made SVGs accessible to assistive technology
  • Hidden decorative elements from screen readers
  • Created alternate routes for users to access information
  • Made links should be visually identifiable and have clear :focus and :active states
  • Check that the HTML document has a language attribute

Quality Assurance: I’ve...

  • Run through each page with the WAVE/aXe Chrome Extension, notified my PM of any issues
  • Made sure users can navigate through content using their keyboard
  • Checked that users can navigate content using a screen reader and tested with one
  • Checked that the general architecture and hierarchy of the content should make sense
  • Reviewed charts and images for alt-text so that users with screen readers or users on a slow connection will still be able to understand the images
  • Ensured decorative images are not visible to screen readers

Project/Product Managers: I’ve...

  • Familiarized myself with the work associated with making content accessible
  • Reviewed videos for the need for text transcripts
  • Built-in time for accessibility during project planning and sprint planning
  • Praised efforts to increase accessibility
  • Been an advocate for accessibility
  • Managed and enforced this list

More Favorite Accessibility Resources

I plan to keep this post updated as I improve this process. Subscribe in the footer below for updates...



Lead Image: Ishan @seefromthesky on Unsplash.

Do you have a team in need of design leadership?

Let’s chat.

get in touch