Becoming an accessibility-focused developer

Suzanne Aitchison twitter: @s_aitchison

Accessibility is everyone’s responsibility

including everyone in your organisation

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

You will hear some very bad takes, like:

“accessibility isn’t part of MVP”

We work in imperfect organisations

“just put a ticket in the backlog”

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

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

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 the NPM package eslint-plugin-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

image of example jsx-a11y lint output

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?

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

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

Header

<header> = banner landmark

only one at the top level of your structure

Footer

<footer> = contentinfo landmark

only one at the top level of your structure

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 landmark

only one
contains the main content of your page

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> = region landmark (only if labelled/titled)

Only a landmark if labelled

Lists

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

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

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

example of heading levels surfaced by the VoiceOver rotor

Headings when there's none in the design

an invisible heading is better than no headings at all

Visually hidden CSS

CSS that can be used to hide elements visually

Heading levels - structure, not style

think of heading levels in terms of structure, not style

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

• Find a pet for adoption <h1> • Meet our dogs <h2> • Meet our cats <h2> • New arrivals! <h3> =😸

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 with an accessibility checker, e.g. axe or wave

Axe/Wave

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

Example Axe output

example axe extension output showing accessibility errors

Check your work is operable by keyboard alone

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?

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

• 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

• switch on and off: ⌘ + F5

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

• switch on and off • read parts of the page • interact with items: ctrl +⌥ + spacebar

Your new pre-push checklist

Pre-push checklist

✅ refactor for semantics & heading structure ✅ verify in axe/wave ✅ check with keyboard ✅ check with screen reader *