Web Development For Accessibility

Dickson Tan

14 Jul 2020

Overview

  • What is web accessibility?
  • Why?
  • WCAG
  • Semantic HTML
  • Keyboard testing
  • Automated Testing
  • Evaluate third-party dependencies

What?

Web accessibility is:

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

Why?

  • 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
  • Starting point: only tells you when something’s terribly wrong. AAA != good experience

Semantic HTML

  • Using HTML elements for what they represent, not how they render
  • Foundation of accessibility
  • Often under appreciated

Native Elements When Possible

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

Headings

  • ✔ 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

HTML5 Sectioning Elements

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

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">
<label>
  First name:
  <input type="text" name="firstname">
</label>

<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

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

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

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

End-user Testing

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

Evaluate Dependencies

  • Inaccessible third-party 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

  • Accessibility was baked into the design of the web
  • Semantic HTML is the foundation of accessibility
  • 🏋 Call to action:
    1. Start looking out for correct 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

Additional Resources

See the article this presentation was based on for links to more resources.

// reveal.js plugins