Not Just For PWDs

• Accessibility features are often thought of as an edge case because it only affects people with disabilities (PWDs)
• Many accessibility features benefit everyone:
  • Meeting contrast guidelines
  • Dark mode
  • Responsive design
  • Semantic HTML
  • Subtitles / Transcripts
• Useful for all, essential for some

Accessibility From The Start

• Building accessibility is much easier if done right from the start
• Examples:
  • Design that doesn’t require a mouse hover to reveal information
  • Using semantic HTML
  • Choosing a third-party component library with accessible components

The Cost Of Retrofitting Accessibility

• Not factoring in accessibility requirements and retrofitting it later is a form of tech debt which compounds over time
• Its much easier to use an accessible calendar component from the start vs having to replace an existing one later on
• Prioritizing accessibility features accordingly

Native Elements

• Use native widgets whenever possible
• For HTML, this means using elements for what they represent, not how they render
• Foundation of accessibility
• Refer to this article for more details

Evaluate Third-party Dependencies

• Inaccessible third-party dependencies are very difficult to replace or fix later on
• Examples of accessible React components: Reach UI, Headless UI, Radix Primitives, React ARIA
• Always verify accessibility claims
• Look through GitHub issues to see if reports of accessibility bugs are resolved timely

Automated Accessibility Testing

• Finds low-hanging fruit, about 40% of issues
• Not a substitute for testing with actual users
• Highly recommend integrating this into CI / CD pipeline or your IDE

Here’s what an eslint-plugin-jsx-a11y warning looks like.

<a href="#" className="brand-blue" onClick={printOverlay}>
  print this page or save as PDF
</a>

error  Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md

Testing With A Keyboard

• One of the most important aspects of web accessibility
• 🔎 Watch out for:
  • Focus order
  • Visible focus outline
  • Widgets fully interactable by keyboard
  • Controls appearing on hover only

End-user Testing

• Include different personas at the design stage
• Include users with different access needs in user research because nothing beats lived experience
  • Better yet if you hire them as part of the team

VS Code

• I’ve used VS Code since 2017 and in that time, have submitted almost 40 accessibility-related bugs / feature requests
• For critical accessibility-related bugs, I’ve seen releases delayed or fixes pushed within a few days
• Most accessible development environment by far