Skip to content

Instantly share code, notes, and snippets.

@svinkle

svinkle/a11y.md

Last active December 28, 2015 23:48
Show Gist options
  • Save svinkle/99e72d083b3cfe7636cd to your computer and use it in GitHub Desktop.
Save svinkle/99e72d083b3cfe7636cd to your computer and use it in GitHub Desktop.
Download ZIP
a11y
Raw
a11y.md

a11y

The following covers developing for accessibility and keyboard/screen reader users. There is much, much more to making everything accessible for all people. More to be added soon.

Screen reader A11Y from a development perspective

“WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.” - https://www.w3.org/WAI/intro/aria

The first rule of using ARIA is not to use it. Only use it if absolutely necessary. It at all possible, use native HTML elements. Native controls have keyboard interactions and accessibility baked in from the start. Using these will save lots of time and make for way less code, making your application smaller and more manageable.

Test with a keyboard

Test UI and components using a keyboard only. Can everything be reached just by using a keyboard? Can you see where you are on the page? If you can’t tell where the browser cursor currently is on screen, chances are there is some CSS removing the outline property on the element’s focus state. Try to add outline back in the styles, or be creative and create your own focus styles!

Test with a Screen Reader

Test UI and components using a screen reader. Hit Cmd+F5 to turn on VoiceOver, the screen reader built in to Mac OS X. Start tabbing around, navigate using just a keyboard, and see if things are announced in a way that make sense. When focusable elements receive focus they are announced with the element type and label. For example, a link with the text “Save”, will be announced as, “link, Save”. A text input control with a label of “First name” will be announced as “First name, edit text.” If something doesn’t sound quite right, check the HTML document source. Chances are something is missing or the incorrect HTML element has been implemented.

Common screen reader + browser testing combinations:

  • JAWS + IE, Firefox
  • NVDA + IE, Firefox
  • VoiceOver + Safari, Chrome
  • VoiceOver (iOS) + Safari
  • Chromevox + Chrome
  • Orca + Firefox
  • Talkback + Chrome, Firefox

Like rendering differences and bugs between browsers, screen readers also vary in how they announce page elements. Sometimes one will announce (or not announce at all) an element as one thing, and something else in another. When this happens, it’s best to read through the ARIA docs and try to find a property or state value that works well across all screen readers.

Custom Controls

If there are custom controls in place, such as UI Popover, these may require some extra Javascript in order to add event listeners for specific keypresses and setting ARIA roles, properties, and states. When working with custom controls, look to the W3 ARIA Design Patterns (http://www.w3.org/TR/wai-aria-practices/#aria_ex) documentation page on how keyboard interaction should be implemented and which ARIA roles/properties need to be applied.

Focus Management

Just as important as elements being described correctly is the concept of focus management. This includes moving the browser cursor to specific elements after an action has taken place. This helps keyboard user experience and attempts to alleviate frustration. Ex., when closing a modal window, focus should return to the element which invoked the modal window to open. This way the user may continue through the document from the point where they launched the modal window.

Screen Reader software:

Resources:

Articles:

Video:

Patterns:

Tools:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment