a11y

[Addy Osmani]

Over on Polymer, we've recently started looking at how we can make our elements more a11y friendly. I know that Brick are really interested in exploring this too and I think it would help everyone to have some a11y custom element examples that don't necessarily use a library.

We're hoping to share a doc with some of our ideas on how one might tackle a11y for WCs in the next week or two, but in case anyone else is trying this out, you might find this new Shadow-DOM enabled version of the Accessibility DevTools useful as a linter.

High-level goals:

• Anyone using custom elements get the same accessibility experience as authors using native elements
• Authors working on custom elements have examples for creating that accessibility experience

Some notes from Alice Boxhall, one of our resident a11y wizards:

• Since native elements have built-in keyboard interaction you'll want to add keyboard interaction to custom elements too. I added notes to how I did this for a Polymer-based carousel.
• Make sure focus is always visible. If you're overriding an outline style make sure you add a :focus style too
• Passing the accessibility audit with the DevTools extension listed above doesn't mean you're 100% accessible. You will want to test with a screenreader or at least the Mac VoiceOver feature (F5 to enable/disable - Ctrol + Alt + to move through the page).
• Use tabIndex=0. Try to avoid tabIndex > 0. This tabs through everything with tabIndex > 0 first and then everything with tabIndex == 0. tabIndex < 0 implies that it's focusable.
• We're still trying to figure out how touch targets factor into a custom elements accessibility story. 

[Rob Dodson]

This is awesome, nice work Addy!