Mike Mai’s Web Accessibility Manual

§Principles

1. Honest

   Constantly keep yourself honest. There are 1.3 billion people with significant disabilities in the world. Never use accessibility overlay or widget solutions to shove dirt under the couch. Fix accessibility issues in the foundation, whether that be the HTML, the visual design, or the company culture.

2. Usable

   There are more than a dozen screen readers and other assistive technologies. Mouse and keyboard are not the only input devices. Your website should be friendly to a wide range of users: screen reader users, screen magnifier users, text-to-speech users, etc.

3. Efficient

   Consider this: 42 million Americans don’t have high-speed internet according to NPR. Do you really need to build every website with whatever heavy JS-framework-of-the-week? Why not build with just lean and mean HTML? Which leads to the final principle…

4. Semantic

   95.9% of the top million websites have detectable accessibility issues as of 2024, most of the issues are related to bad HTML structure. Well-crafted visual hierarchy also needs well-crafted meaningful code. Don’t neglect what’s under the hood.

§Mindset

• Accessibility is not more expensive

  You know what is expensive? Fixing the mountain of tech debts from poorly written HTML and paying the lawyer fees and fines on ADA lawsuits. Also, 69% of disabled customers will leave a website if it is not accessible. Be proactive and shift left, that’s the way to reduce costs and increase revenues.

• Accessibility is not ugly design

  Why should I make the design ugly only to make it better for a small number of users? You wouldn’t say that publicly so don’t say that in design meetings. If you design by the numbers, disabled people will always lose because they are the minority. Besides, there are many ways to design, it is your job to make something beautiful and usable.

• Accessibility is not extra code

  A huge benefit of writing semantic HTML is less code! HTML tags provide screen reader announcements out of the box. Don’t reinvent the wheel and build something custom with unnecessary layers of markup plus extra JavaScript just to do the job of a simple HTML tag.

• Accessibility is a basic human right

  I am a privileged person, and you might be as well, but not everyone is so lucky. The Human Rights Act Article 14 states that all of us, no matter who we are, enjoy the same human rights and should have equal access to them. Do our best to remove as many barriers as possible.

§Process

1. Define

   Accessibility needs a seat at the table. It is never going to work without manager buy-ins. Teach empathy and encourage everyone to do the right thing. Define requirements from top to bottom.

2. Build

   Design and development needs a lot of attention to details. Creatives should create extensive accessibility annotations for dev hand-offs and engineers should learn the correct technical techniques to bring accessible designs to life.

3. QA

   QA engineers not only need to be able to perform visual regression, cross browser, and screen reader tests, they also need to know how to code. It is just as important to spot bad code—especially bad HTML—and recommend accessible fixes.

4. Educate

   Continuous education is crucial to implementing an accessible and inclusive company culture. Run empathy workshops, creative workshops, and technical workshops periodically to remind people why accessibility is important.

§Testing

• Windows

  Primary screen reader and browser combinations are:

  • Chrome/Firefox/Edge + JAWS
  • Chrome/Firefox/Edge + NVDA
  • Edge + Narrator

• Android

  Primary screen reader and browser combination is Chrome + TalkBack.

• MacOS

  Primary screen reader and browser combination is Safari + VoiceOver.

• iOS

  Primary screen reader and browser combination is Safari + VoiceOver.

• & more

  The primary combinations are meant to highlight the most commonly used ones—the ones that you must test first and foremost. There are certainly more combinations and you should always cross browser test and screen reader test. Also consider other types of assistive tech such as switch device, flexible braille display, voice control, and more.

• Further reading

  • An Introduction to Screen Readers
  • Mobile Accessibility 101: Mobile Screen Readers
  • How to Use Assistive Technology to Comply with Section 508

§Checklists

• Design

  Here are some basic things to check in a design file:

  1. Layouts and page designs are responsive and fit within a 320px viewport without any loss of content and functionality, and it does not create unexpected bi-directional scrolling.
  2. Contrasting color pairs—foreground and background—should meet WCAG 2.1 Level AA. 4.5:1 for text elements and 3:1 for non-text elements.
  3. Essential interactive elements should have a technical click target size of 44px, even if the element is not visually 44px in height.
  4. Accessible names for semantic elements—links, buttons, images, headings, etc.—help screen reader users gain context of the particular element. If an element is lacking a visual text label, make sure to annotate.
  5. Semantic headings help define the information hierarchy of a particular web page and allow screen reader users to jump from heading to heading to explore sections of the web page. Annotate each heading in the design with the proper heading tag—h1 to h6.
  6. Landmarks are defined regions of a particular web page. They help to communicate page structure and allow screen reader users to quickly navigate between sections. Annotate each section of the layout as a landmark.
  7. Provide alt text for informative images.

  For complex interactive UIs that require it depends nuanced answers, consult an expert. Web-A11y Slack is a great place to start.

• Code

  First things first, let’s cover the most mundane things:

  1. Let links navigate only.
  2. Let buttons perform functions only.
  3. Do not use aria unless necessary.
  4. Do not use title attribute.
  5. Do not skip heading levels.
  6. Use proper landmarks.
  7. Add caption to videos.
  8. Add alt text to images.
  9. Add empty alt text to decorative images.
  10. Ensure users can operate with keyboard only.
  11. Use aria-live to announce dynamic changes.
  12. Use semantic table for tabular content.
  13. Match tab order with visual order.

  Secondly, there are many existing checklists created by engineers more seasoned than me, I recommend checking out some of the best ones I have read:

  • The A11y Project Checklist (web)
  • The T-Mobile Checklist (web, iOS, & Android)
  • The Va11ydette Checklist (web, iOS, & Android)

§Playlist