Becoming an accessibility-focused developer

Slide 1

Becoming an accessibility-focused developer

Suzanne Aitchison twitter: @s_aitchison

Slide 2

Accessibility is everyone’s responsibility

including everyone in your organisation

Slide 3

Accessibility needs to be considered at every stage of the product development lifecycle

but that is a lot of people for you to convince

Slide 4

We work in imperfect organisations

You will hear some very bad takes, like:

“accessibility isn’t part of MVP”

Slide 5

We work in imperfect organisations

“just put a ticket in the backlog”

Slide 6

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.

Slide 7

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

Slide 8

Habits to build

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

Slide 9

add accessibility linting with eslint-plugin-jsx-a11y

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

Slide 10

jsx-a11y

catch common errors, e.g:

• meaningful alt text on images • association of labels with inputs • no non-interactive elements with click listeners

Slide 11

jsx-a11y example

image of example jsx-a11y lint output

Slide 12

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

Slide 13

Replace divs with semantic alternatives

Slide 14

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

Slide 15

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

Slide 16

Landmarks - HTML sectioning elements

Slide 17

Header

<header> = banner landmark

only one at the top level of your structure

Slide 18

Footer

<footer> = contentinfo landmark

only one at the top level of your structure

Slide 19

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

Slide 20

Main

<main> = main landmark

only one
contains the main content of your page

Slide 21

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..”

Slide 22

Section

<section> = region landmark (only if labelled/titled)

Only a landmark if labelled

Slide 23

Lists

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

Slide 24

Lists

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

Slide 25

Audit your headings

Slide 26

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

Slide 27

Headings navigation example

example of heading levels surfaced by the VoiceOver rotor

Slide 28

Headings when there's none in the design

an invisible heading is better than no headings at all

Slide 29

Visually hidden CSS

CSS that can be used to hide elements visually

Slide 30

Heading levels - structure, not style

think of heading levels in terms of structure, not style

Slide 31

Heading structure - example 1

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

Slide 32

Heading structure - example 2

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

Slide 33

Rules for headings

only one <h1> per page
only increase by one level at a time

Slide 34

Verify your code in the browser

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

Slide 35

Axe/Wave

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

Slide 36

Example Axe output

example axe extension output showing accessibility errors

Slide 37

Check your work is operable by keyboard alone

Slide 38

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

Slide 39

Check your code works for screen reader users

Slide 40

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