Yesterday I had the pleasure of presenting at the 2nd MakingWeb conference in Norway, I talked about web components.
Web Component Accessibility
The key points I attempted to convey during the presentation:
An accessible, usable UI is a MUST
UI accessibility is not an accessory, a ‘nice to have’. If a UI is not accessible it’s incomplete, substandard, half baked – a neckbeard UI
There are no new demons
There is nothing inherent within web components as a technology that makes it harder to build usable and accessible UI’s
The challenges remain the same
The challenges with web components are pretty much the same as what we have dealt with for years with HTML/JavaScript custom controls
Build accessibility in from the start
- Create custom elements by extending native HTML elements, wherever practical, as you will then get much of the accessibility for free.
- When creating custom element attributes pair them with ARIA attributes wherever the semantics align.
- Use standardized, defined interaction patterns for custom controls.
- Refer to the ARIA Design patterns
Related reading
- Web Components punch list
- Usability and accessibility opportunities in a web component world
- Some stuff that doesn’t work between the DOM and Shadow DOM
- Accessible Web Components – Part 1
- What ARIA does not do
- Using the tabindex attribute
- Building an Accessible Disclosure Button – using Web Components
- Notes on notes (of smart people) about web components
- HTML5 accessibility implementation support in browsers
- HTML5Accessibility.com
- Using ARIA in HTML
- Using ARIA to enhance SVG accessibility
- The HTML5 Document Outline
- HTML heading custom element on github
