Web Development For Accessibility

Dickson Tan

25 Jun 2020

  • What is web accessibility?
  • Why?
  • WCAG
  • Semantic HTML
  • Aria: when HTML alone isn’t enough
  • Keyboard testing
  • Automated Testing
  • Evaluate third-party dependencies


Web accessibility is:

  • design that works for everyone
  • regardless of the hardware and software they use to access your site


  • Forms that work well with autocomplete, keyboard and password managers
  • Captions / transcripts
  • Works with user’s preferred software, screen readers, magnifiers, voice dictation etc
  • Reader mode
  • Search engines
  • Phone assistants
  • Responsive design

WCAG v2.1

  • 13 guidelines for making websites accessible
  • Principles:
    1. Perceivable
    2. Operable
    3. Understandable
    4. Robust
  • 3 conformance levels: A, AA and AAA. Aim for AA

Semantic HTML

  • The foundation of accessibility
  • Use HTML elements for what they represent, not how they render
  • Often under appreciated

Native Elements When Possible

  • Examples:
    • <button>
    • <a>
    • <select>
    • <datalist>
    • <details> and <summary>
  • 🙅 Avoid:
    • <div> + JavaScript to replicate lost functionality


  • ✔ hierarchical structure for search engines and screen readers
  • <h1> through <h6>
    • <h1>: main content
    • <h2>: subsections
    • <h3>: sub-subsections
  • 🙅 Avoid:
    • Skipping levels (h1> then <h4>)
    • Headings just for formatting and pseudo-headings
  • Visualize heading structure: a11y-outline extension

Programatically Label Form Elements

  • For touchscreen usage, password managers, voice dictation and screen reader users
<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname">
  First name:
  <input type="text" name="firstname">

HTML5 Sectioning Elements

  • Adds structural info that makes sense non-visually
  • ✔ Use these below instead of <div class="...">
  • Visualize section structure: a11y-outline extension
    <!-- logo, title etc -->
     <!-- navigation links here -->
    <!-- main site contents -->
    <!-- copyright and legal info -->

<table> For Tabular Content

  • For rapid navigation by screen reader users and easier scraping / parsing
  • ✔ Use for tabular data and info spread across 2 axes
  • 🙅 Avoid:
    • Abuseing tables for layout purposes (especially common in emails)
    • Table nesting
    • Pseudo-tables (faked via CSS)
    • Separate tables for column headers and row content

ARIA: When HTML Isn’t Enough

  • A set of standardized aria-* attributes to convey additional information that can’t be expressed in HTML alone
  • Used for making widgets accessible such as accordians, tab panels etc
  • Examples:
    • aria-current has no HTML equivalent
    • Implementing disclosures with ARIA

Testing With A Keyboard

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

Automated Testing

  • Finds low-hanging fruit, about 40% of issues
  • Not a substitute for actual tests with users
  • Highly recommend integrating this into CI / CD pipeline or your IDE
  • TODO: insert example of a eslint jsx-a11y lint

End-user Testing

  • Include users of various devices in user research
  • Screen reader testing

Evaluate Third-Party Dependencies

  • Inaccessible dependencies are very difficult to replace or fix later on
  • Always verify accessibility claims
  • Look through issues to see if reports of accessibility bugs are resolved timely

Key Takeaways

  • The web was always designed to be accessible
  • Semantic HTML is the foundation of accessibility
  • 🏋 Call to action:
    1. Start looking out for good HTML usage in code reviews
    2. Progressively implement automated accessibility testing in CI / CD pipelines to help with this
    3. Start testing features with a keyboard while implementing them