Becoming an accessibility-focused developer

A presentation at Edinburgh React Meetup in February 2020 in Edinburgh, UK by Suzanne Aitchison

Becoming an accessibility-focused developer — Becoming an accessibility-focused developer
Suzanne Aitchison twitter: @s_aitchison

Accessibility is everyone’s responsibility — Accessibility is everyone’s responsibility
including everyone in your organisation

Accessibility needs to be considered at every stage of the product development lifecycle — Accessibility needs to be considered at every stage of the product development lifecycle
but that is a lot of people for you to convince

We work in imperfect organisations — We work in imperfect organisations
You will hear some very bad takes, like:
“accessibility isn’t part of MVP”

We work in imperfect organisations — We work in imperfect organisations
“just put a ticket in the backlog”

We work in imperfect organisations — We work in imperfect organisations
“we don’t have any disabled users”
These are very common comments, unfortunately and also very ableist. It’s a privilege to be able to be so dismissive about accessibility.

Our sphere of control — Our sphere of control
But we do have control over our small piece of the puzzle: the implementation i.e. our daily development work.
The focus of the talk is what you can do yourself to learn more about accessibility and start making positive changes in your code

Habits to build — Habits to build
detect common issues
boost with some quick-win refactoring
learn by finding bugs in the browser

add accessibility linting with eslint-plugin-jsx-a11y — add accessibility linting with eslint-plugin-jsx-a11y
add accessibility linting with the NPM package eslint-plugin-jsx-a11y

jsx-a11y — jsx-a11y
catch common errors, e.g:
• meaningful alt text on images • association of labels with inputs • no non-interactive elements with click listeners

jsx-a11y example — jsx-a11y example
image of example jsx-a11y lint output

Commit to 2 key pieces of refactoring — Commit to 2 key pieces of refactoring
Before you push code to review, try to get in the habit of reviewing these two aspects, for some quick accessibility boosts

Replace divs with semantic alternatives

Why not a div? — Why not a div?
Authors are strongly encouraged to view the <div> element as an element of last resort, for when no other element is suitable - W3C

Landmarks — Landmarks
Some of your divs can be replaced by landmarks. Using landmarks correctly allows screen reader users to find and skip to relevant content more easily

Landmarks - HTML sectioning elements — Landmarks - HTML sectioning elements
<header> <footer> <nav> <main> <aside> <section>

Header — Header
<header> = banner landmark
only one at the top level of your structure

Footer — Footer
<footer> = contentinfo landmark
only one at the top level of your structure

Nav — Nav
<nav> = navigation landmark
wrap lists of links
can have more than one nav, but if you do, give a label to each so a user can find which one they are looking for

Main — Main
<main> = main landmark
only one
contains the main content of your page

Aside — Aside
<aside> = complementary landmark
Outside of the main content, but contains complementary information, e.g. lists of useful links or resources, “other stories related to this..”

Section — Section
<section> = region landmark (only if labelled/titled)
Only a landmark if labelled

Lists — Lists
ensure lists are marked up using <ul> and <li> to give screen reader users context

Lists — Lists
if you used .map() to create a set of elements for display, they should probably be <li> elements and displayed in a list

Audit your headings

Why audit your headings — Why audit your headings
68.8% of respondents said their first action on a web page is to navigate by heading levels - WebAIM 2019 screen reader user survey

Headings navigation example — Headings navigation example
example of heading levels surfaced by the VoiceOver rotor

Headings when there's none in the design — Headings when there's none in the design
an invisible heading is better than no headings at all

Visually hidden CSS — Visually hidden CSS
CSS that can be used to hide elements visually

Heading levels - structure, not style — Heading levels - structure, not style
think of heading levels in terms of structure, not style

Heading structure - example 1 — Heading structure - example 1
heading structure • Find a pet for adoption <h1> • Meet our dogs <h2> • Meet our cats <h2> • New arrivals! <h2> =😸+🐶+?

Heading structure - example 2 — Heading structure - example 2
• Find a pet for adoption <h1> • Meet our dogs <h2> • Meet our cats <h2> • New arrivals! <h3> =😸

Rules for headings — Rules for headings
only one <h1> per page
only increase by one level at a time

Verify your code in the browser — Verify your code in the browser
verify your code in the browser with an accessibility checker, e.g. axe or wave

Axe/Wave — Axe/Wave
axe / wave catch common errors, e.g: • colour contrast • heading levels skipped • duplicate or missing landmarks

Example Axe output — Example Axe output
example axe extension output showing accessibility errors

Check your work is operable by keyboard alone

Keyboard operability — Keyboard operability
• verify you can tab to every interactive element (shift + tab to go backwards) • check the current focus is clearly visible • ensure the tab order is logical • test interacting with elements

Check your code works for screen reader users

How often should we check with a screen reader? — How often should we check with a screen reader?
a reasonable minimum: if you used an aria attribute, you should check your code with a screen reader
aria attributes can override other semantics in the HTML
if you use aria attributes but don’t check with a screen reader - how are you checking your code works?
websites with higher use of aria, have higher incidences of accessibility failings

Screen reader / browser combos — Screen reader / browser combos
• Windows: NVDA + Firefox • MacOS: VoiceOver + Safari
Based on user behaviour reported in the WebAIM 2019 Screen Reader User Survey

Key screen reader skills - switch on/off — Key screen reader skills - switch on/off
• switch on and off: ⌘ + F5

Key screen reader skills - read parts of page — Key screen reader skills - read parts of page
• switch on and off • read parts of the page: ctrl +⌥ + right/left arrow

Key screen reader skills - interact with items — Key screen reader skills - interact with items
• switch on and off • read parts of the page • interact with items: ctrl +⌥ + spacebar

Your new pre-push checklist

Pre-push checklist — Pre-push checklist
✅ refactor for semantics & heading structure ✅ verify in axe/wave ✅ check with keyboard ✅ check with screen reader *

Further reading — Further reading
slides + resource links bit.ly/a11y-focused-developer Up Your A11y: upyoura11y.com

Suzanne Aitchison
@aitchiss

1 / 47

Resources

The following resources were mentioned during the presentation or are useful additional information.

Up Your A11y

Resources and tutorials for creating accessible web experiences, including some React-specific content
npm eslint-jsx-a11y-plugin

Add to your eslint setup to lint for common accessibility issues
Stop using so many divs! An intro to semantic HTML

Blog post detailing the benefits of semantic HTML, and where you might be able to transform your divs to something more meaninful
W3: HTML Sectioning Elements

A short guide to the HTML sectioning elements and the landmarks they map to
Axe Browser Extension (Chrome)

To help identify issues with your code in the browser
How should keyboard navigation work in web applications?

More detail about how keyboard navigation should work in your web apps
Getting Started with VoiceOver on Mac

Some tips on how to set up your Mac and Safari to start using VoiceOver
WebAIM: Getting Started with VoiceOver

Quick-start guide for MacOS’s default screen reader
WebAIM: Getting Started with NVDA

Quick-start guide for using the NVDA screen reader (for Windows users)
WAI-ARIA Authoring Practices

An extensive set of ‘how-to’ guides for creating accessible standard web components