Accessibility lessons from running clinics

motion-induced nausea - those full-screen background images…

temporary - at work, can’t use sound or headphones

alternative inputs - trackballs, sticks

magnification

… so you want to learn to use a screen reader, do you want to learn every form of

don’t outsmart yourself

a developer

and then screen-readers differ

don’t assume that developing for screen readers is the hardest problem, and that solving it will solve all your problems.

  1. Developing for neurodiversity is the hardest problem.
  2. Solving one problem does not automatically solve them all.

If you insist on learning a screen reader… Learn the screen reader you have in your pocket– android app store; built in on iOS

Using something like

keyboard traps - some so bad, have had to close the browser and restart computer to get out of them

ARIA abuse

Accessible Rich Internet Applications

specification for how developer can pass extra information to assistive technologies using the assistive API built into most devices.

Validate your web sites. Not every validation error is an accessibility issue, but some, including duplicate IDs, is a problem.

Out of sight, out of mind– don’t create separate content for screenreaders. Sometimes you have to, and when you do, make sure you don’t forget about it.

Every a tag needs an href or an id or both– or don’t use an a tag.

For tabindex, use only 0 or -1. Never use a positive integer.

-1 is something that needs to be focusable programmatically but should not be in tab order.

The first rule of ARIA: Don’t use ARIA. It’s in the spec! That’s the first rule: use native elements when they have the semantics. And don’t use an ARIA role that conflicts with the native element’s semantics.

You should never be using role=button. Don’t say span role=“button”, use the <button> tag.

tablist, tabpanel, tab - in 13 years of clinics we’ve seen one implementation that didn’t have problems

role=alert, role=dialog, can all interrupt

How can aria-label not be useful? If it’s not visible on screen, or conflicts with what’s on screen, you can really mess things up for people who are both hearing and seeing the screen.

Just don’t use: menu, menubar, menuitem, toolbar – these aren’t for site navigation, that’s what nav is for. A list of destinations in navigation. A list of preferences, actions might be an ARIA menu.

Don’t ever use ‘application’ - you have taken away all the 4,000 keystrokes that the assistive technology is able to interpret, and telling the browser to send everything directly to your site. Only seen it used correctly once– for a Python IDE used through a browser.

keyboard testing - unplug everything and use keys only

Ensure you can:

Automated tools to help test this

Drupal 8 + nightwatch + axeJS library - can run it in your JavaScript test suites. Won’t catch everything but will quickly catch glaring errors.

Test your interface with real people; this is what we do in a clinic. Developers and designers finally see someone using their site with assistive technology and there’s a lightbulb.

standards keep evolving

webex team will keep our checklist updated

but ultimately: it’s accessible if people can use it

Notes from presentation by:

Caroline Boyden UC Berkeley https://2018.badcamp.org/session/accessibility-201-tales-front-end

Button can be activated with enter or spacebar. Links can only be activated with enter.

So buttons should look like buttons, and links should not look like buttons.

WhatSock - http://whatsock.com/ - blind developer created a library of accessible patterns, including drag-and-drop, which is quite difficult.

Most people will try esc to close a modal; it should also have a close button you can tab to.

https://webaccess.berkeley.edu/evaluating/self-assessment/diy-accessibility-checklists