MozFest 2018 · Victor, Katherine, Dafydd & Guerman
A copy of all the slides, notes and resources can be found on this GitHub repository. The following slides have 3 keyboard exercises/examples, and two for screen readers.
Inclusive Components is a blog detailing step-by-step how to make components accessible
The new Chrome DevTools now have an Accessibility tab to inspect how nodes are seen in the accessibility tree
Keyboard: making custom elements accessible
The button below is implemented using a div. At the moment you cannot focus on it with a keyboard: try using the tabindex attribute to make it gain focus. This will not be enough: you need to add a new event handler in JS.
Exercise time! Recreate the demo above, but this time we want different interactions on click and on keyboard. Create a function called makeBoxSmaller() by copying the function above and changing the + to a -, and copy the event listener to use a keydown event instead of mousedown.
Keyboard: moving focus programmatically
Use the element.focus() method to force moving to a certain point. Calling .focus(), with no arguments, moves the focus to a specific element, just as if the user tabbed onto it.
Being able to set focus programmatically can have bad consequences for accessibility: it breaks predictability for keyboard and screen reader users, particularly when it is not expected. It can be a breach of SC 3.2.1 On Focus (opens in new window) or 3.2.2 On Input (opens in new window) because it changes context when the user does not expected.
However, when used wisely it can be useful! A common example is a modal dialog. Let's see that on the next page…
Screen readers: well-connected labels
Use the label element with a for attribute that references the id of the field.
You can test whether they are correctly linked by just clicking on the label: it should focus the field!
After ARIA: you can also go further and associate that hint text using aria-describedby. This attribute is placed on the field and not the label!
Keyboard + ARIA: modal dialogs
The following is an inaccessible modal dialog: the focus is not moved, the background receives focus with a screen reader and a keyboard. There is also no label on the close button.
The following is a correctly implemented, accessible dialog:
ARIA: giving states
Sometimes, native HTML elements won't cut it, because of complex interactions or implementations. Examples that you will have encountered include accordions: the expanded or collapsed state needs to be communicated non-visually, and this can be achieved using aria-expanded. Text that changes elsewhere on the page needs to be announced, with aria-live. Tabs can be made accessible as such by using role="tab" and aria-selected, despite not having any native element for them in HTML.
Here's an example of an accordion button. Sometime ARIA elements need to remain the same and are set in HTML only, but sometimes they need to be changed in JS for it to make sense:
Have a look at the code and now try to make the toggle button below accessible. At the moment, screen reader users do not know whether it is pressed or not; there is only a visual cue. Hint: use aria-pressed.
The full reference for aria-pressed can be found in the ARIA spec (but as you will see it is very verbose!).