It’s always better to bake in accessibility from the very beginning of your project than tack it on after the fact. Making accessibility decisions up front in your web app can save your users a lot of frustration and save you a lot of development time. But how do you know what to bake in, how to mix it all together, and whether you’re doing it right?
In this talk we’ll look at the key ingredients of web accessibility — including semantic HTML, mindful color palettes, keyboard interactivity, and a dash of ARIA — and discuss some tried-and-true recipes for accessible web development. We’ll also knead through technically challenging accessibility feats like complex interactive widgets and drag-and-drop to achieve more inclusive interaction patterns. With these techniques in your back pocket, making an accessible website will be a piece of cake.
Accessibility is about making products, services and spaces that everyone can use and enjoy in all contexts, regardless of their abilities.
We tend to think about things in four dimensions: visual, motor, auditory, cognitive. This includes situational and temporary disabilities – someone in a loud bar has the same problems hearing their phone as someone who is hearing impaired. Trying to use a system in a language you don’t know is a cognitive problem.
We should consider everyone’s experiences from the start and not try to tack on accessibility at the end… it should be baked in, not added on. You can’t add the blueberries to a blueberry muffin after you bake them! If you cram blueberries into a baked muffin, you end up with a mess.
The web is full of buttonish things, where people create a clickable div and have to cram in lots of extra markup to make it work like a button. Just use the button in the first place!
Quick introduction of the Great British Bake Off, a show where amateur bakers compete in a range of challenges (signature, technical and showstopper) to be the best baker. But they are really competing with themselves rather than each other, it’s a quite charming show.
So we will be doing the Great Accessibility Bake Off, considering a set of users with different needs – mouse, touch screen, braille input, voice control, laptop, single-button clicker.
Main ingredients of an accessible UI:
- semantic HTML
- a dash of ARIA
- alt attrs
- names for all interactive items
- sufficient text contrast
- mouse/keyboard parity
Semantic HTML is the foundation of accessibility. If you just send your users divs, spans and as, you really aren’t giving them anything meaningful.
As we move into web apps, plain HTML doesn’t handle 100% of the complex interactions we now have. That’s where ARIA comes in – it helps you describe rich interactions. ARIA lets you communicate role, state and properties to assistive tech when HTML alone won’t suffice. The first rule of ARIA is don’t use it if you don’t have to. Think of it like cinnamon – it’s good, but not if you try to eat a whole spoonful!
Alternative text is the next piece. Images with contextual content should have the text you’d want in a text-only version of the page (alt=”Home”), for decorative images include an empty alt (alt=””) or apply aria-hidden=”true”.
Criteria for the accessibility bake off:
- Does it look amazing?
- Does it function as expected?
- Did you over/under-engineer it?
Test everything with…
- screen readers – beware that specific combinations make a big differences
- grayscale mode
- real users!
Signature challenge: make an accessible form
(on the show this is making a simple thing really well)
Simple subscribe: text input, email input (required), checkbox, button. You need:
- visible focus indicators
- label associated with its input with the for attr
- placeholders are not labels! they are low-contrast, they look like the field has been pre-filled, they disappear when you start typing (puts a lot of cognitive load on people, and most screen readers don’t make it available after you start typing)
- associate error messages with aria-describedby linked to the input by ID
- put an icon on the error as well as changing the colour, so people in grayscale mode see something
Technical challenge: accessible tree view (file system)
(on the show, this is a challenge where contestants get a recipe with pieces of information missing; so they need to fill in some blanks to create the final product)
Tree views really don’t have markup for this, but ARIA has a tree view! W3 provides a lot of recipes, including this: http://www.w3.org/TR/wai-aria-practices#TreeView
You can still hit bugs though; and now you have to determine where the problem lies –
- your code
- the browser
- the screen reader
This can be hard to debug. Good resources:
- whoseline.a11yideas.com/bugs.html tells you where to log bugs for a11y issues
- web-a11y.herokuapp.com very active slack community
When Dropbox followed the W3’s recipe, it worked everywhere except Safari+Voiceover – the arrow keys were not reading things out. They did a lot of reading and found each item needed an aria-label.
Showstopper challenge: drag’n’drop
(on the show, the Showstopper is the grandest piece – a huge and extravagant creation)
Drag and Drop is really challenging. It has a huge amount of things going on. Thankfully it’s not really that hard, if you simply think of it as a way to move something.
Drag and drop patterns usually fall into one of three patterns:
- drag something into a bucket (file uploads, kanban boards)
- rearranging lists (ranking something)
- move an element on a canvas (less common on the web, but likely to happen more in future)
Kanban board: focus the card, press space/enter to open a menu that lets you choose which column to move the card into.
ARIA 1.1 has deprecated aria-grabbed and aria-dropeffect… although don’t worry too much as they’ll probably keep working. It seems the ARIA authors are hoping to rely on the native drag and drop API
Good article: sitepoint.com/accessible-drag-drop
Dropbox also gives users an alternative interface, where they click “move” and simply choose the new location in a modal.
For positioning on a canvas you can use arrow keys, or provide inputs for x/y coordinates.
Give people choice and flexibility. They will pick the method that works for them.
So is this all great?
We need to talk to our users and find out if they are happy. Test and review. Ask people who really use this whether it’s working for them.
- Lots of apps use custom keystrokes as keyboard shortcuts – how do these work with assistive tech, if at all?
- works well but be consistent with general conventions
- Is there a caniuse for ARIA?
- not yet… would be wonderful if there was, there are some resources for specific attributes
- If you have images with a lot of technical content, eg. a graph – what’s the best way to label that?
- there is a longdesc but there is a lot of politics around… (Adem says regardless of debate, “it works!”)
- you can also just link to (or reveal) a transcript, which is great because anyone can read it and it’s searchable
- Do you think we are doing enough to tell people that accessibility options are available… are there any good resources that we can provide?
- no, in general we are not. There’s a lot of discussion in game accessibility about this… xbox team have done a lot of work on a11y and also put out information promoting that. Other teams do the work but don’t promote it.