Whether people were born with different needs or are experiencing a disability due to location, health, or equipment, everyone should have equal access while exploring the Web. Building a website with respect and attention given to disability and accessibility is not a nice gesture, but rather functions to include everyone, and the variety of needs that we all require as we navigate different spaces and phases of life. 

Providing effective accessibility is how we put more good into the world. When we build better, we welcome more people, and when we keep the abilities of all users in mind, we create better experiences. To help everyone, Anchor & Alpine has created this accessibility checklist.

Colors & Fonts

  • Colors pass accessibility tests — 4.5 to 1 contrast. See Figma Plugins ›
  • Fonts pass accessibility tests — at least 14px at smallest, but we recommend 16-18px. 
  • Text is able to be resized 200% without the site losing cohesiveness. 
  • Text is generally left-aligned for English websites, don’t use justified text. 
  • Color (or other sensory descriptors) is not the only way to convey information. 
  • Links are recognizable as links. 

Images

  • Image descriptions—called alt tags—are in place.
  • Text is not used in images if possible.
    This is good for accessibility and also supports multi-lingual websites and apps. 

Audio & Video 

  • Audio and video have pause, stop, and mute. 
  • Audio and video have closed captioning for hearing impaired people. 
  • Flashing elements should not flash more than 3x/second. 

Buttons

  • Buttons use the <button> element. 
  • Buttons are labeled clearly.
    e.g. use terms like ‘Download PDF’ and not ‘click here’.
  • Icon-only buttons have a <title> set to explain the functionality.
    e.g. a search icon would have the title ‘Search’ set for screen readers. 
  • Mobile tap areas are at least 44px—this is the size of a fingerprint. 

Forms

  • Form fields are marked as either ‘Optional’ or ‘Required’
    Interesting note: When we worked with     Optimizing Autism, they asked that we go with the ‘Optional’ note instead of the ‘Required’, stating a research-backed opinion that these users prefer the flag for what is optional instead of what is required.  
  • Error messages are graceful and include help to complete the task. 
  • Focus states are clear so the user knows where they are. 
  • Items are not named with sensory characteristics.
    e.g. ‘click the red button’ wouldn’t work, but you can say ‘click the cancel button’. 
  • The correct keyboard is selected on inputs.
    e.g. the number keyboard on mobile for phone numbers. The options are text input, number input, telephone number, search bar, email, and date. 

SEO & Code

  • Correct, semantic HTML is in place.
    e.g.  <nav>, <table>, <h1>, <button>, etc. 
  • Only one H1 is used per page.
  • Subheadings are used correctly and in order.
    More information: Headings should not be used for typographic elements that aren’t headings, for example, a rubric should not be set in an H4 or H5 — anything that doesn’t have enough content under it to read as a heading shouldn’t use heading tags. 
  • Pages are well organized and still read and function correctly if the CSS is removed. 
  • Titles are less than 55-characters. 
  • Breadcrumbs are present on Resource Centers and other nested content.
  • Tab order is correct and users can navigate a website using the keyboard only. 
  • The language attribute is set correctly in the HTML.
  • ARIA roles and labels are set where appropriate.
  • Don’t disable anything that impairs assistive technology—this includes zoom levels, CSS overrides and screen reader access. 

Tools & Checklists

Further reading about Accessibility

Do you want to build accessible websites and product user interfaces (UI)?

We do too! Let’s build something for everyone, together.

Contact Anchor & Alpine

Photo by Kelly Sikkema on Unsplash