At ngEurope, Marcy Sutton’s session on accessibility was one of the sessions I looked forward to most. Accessibility is something we often forget. While screenreaders and other tools are becoming increasingly sophisticated, so are our websites and applications. And it’s worth it to invest some time in accessibility, because everyone should be able to use the web.

So here’s a quick recap of what was covered.

Accessibility (or a11y, with 11 referring to the 11 omitted letters) starts with using semantic elements. With HTML5, we have lots of new elements that communicate something meaningful about their contents: article, aside, etc.

If you’re using javascript, and have elements that are only there for your javascript code, add the attribute tabindex=”-1″ to make it accessible for javascript, but not for the keyboard.

The ARIA-attributes are for screenreaders, magnifiers, etc. Agnular provides the ng-aria directive for this. There also decent documentation on accessibility and AngularJS. ngAria hooks into ngModel and dynamically adds ARIA attributes where needed.

But there’s more:

Roles communicate what an element does:

<div role="img"...>

States:

<md-input-group aria-disabled="true">

This can be used because this is a custom element and the disabled property is only available on certain elements.

The application role disables a screenreader’s virtual cursor. Don’t do this on the entire body, only on things that mimic for example desktop widgets. A user won’t be able to navigate in this element anymore. This is an example of the application role:

<div role="application">

Think about enabling keyboard access.

<div ng-click="sorryKeyboard()"></div> // this won't work
<button ng-click="better()"></button> // this is better
<md-button ng-click="better()" ng-keypress="better()"></md-button> // if you must use a custom element

Be sure to test your site with the keyboard. Does it work? Are all elements accessible via the keyboard and can everything be controlled/clicked/toggled/…? Does it work pleasantly or do you find yourself having to press tab too much to navigate?

Don’t forget ‘:focus’ to let the user know where the focus is at the moment.

Marcy contributed accessibility improvements to Angular Material. For example, for Material Checkbox, it will add a role, but also a label, based on the text it finds. What’s more, there’s code to warn the developer that it can’t find a label.

Some tools for accessibility:

• The ARIA specification* ngAria
• Marcy’s blog post on how she audits a website for accessiblity
• Chrome Accessibility Dev Tools
• WebAIM Screen Reader Survey
• Color Contrast Checker This was most definitely the most interesting talk of ngEurope to me. Just because it connects our technical world with something we don’t often come into contact with. What’s more, it’s something of an overlap with my wife’s world (speech therapy/remedial teaching), where dyslexic people could also greatly benefit from. If we’re serious about the web and connecting all people in the world, accessibility is something we shouldn’t forget.