A presentation at role=drinks in June 2018 in Amsterdam, Netherlands by bruce lawson
@brucel AOM-nom-nom!
@brucel
@brucel Wix • enable navigation by keyboard • provide Screen Reader compatibility • build infrastructure for accessibility development and testing.
@brucel “Perfect is the enemy of Good”
110
million
@brucel Stylable is a CSS preprocessor for styling components with typed CSS.
@brucel Photo: F. Antolín Hernandez
@brucel “HTML 4.0 developments inspired by concerns for accessibility include the requirement that alternate text accompany an image included via the IMG element.
@brucel HTML Design Principles Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential.
This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided.
HTML Design Principles - https://www.w3.org/TR/html-design-principles/
@brucel Ajax / “Web 2.0” By decoupling the data interchange layer from the presentation layer , Ajax allows for Web pages, and by extension Web applications, to change content dynamically without the need to reload the entire page .
@brucel WAI ARIA WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state. WAI-ARIA describes new navigation techniques to mark regions and common Web structures as menus, primary content, secondary content, banner information, and other types of Web structures.
@brucel ARIA landmark roles role="contentinfo", "main", "banner" ...
Built-in beats bolt-on
@brucel Photo: Brittany Shaw
@brucel ARIA isn’t a magic bullet You still need to
• maintain state and value
• make sure things are keyboard-focusable
• listen for keypresses
• deal with live regions
@brucel Web Components
@brucel Web Components WTF? Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps .
https://www.webcomponents.org/introduction
@brucel JavaScript frameworks
@brucel Custom elements <lovely-button>Click me!</lovely-button>
@brucel .. or semantically neutral
https://www.flickr.com/photos/dannynorton/186795352/
@brucel accessibility object model F Delventhal https://www.flickr.com/photos/krossbow/10324856173/
AccessibilityObjectModel
@brucel Current gaps • Leaky abstractions
• IDrefs
• No way to capture input events from Assistive Technology
• Every accessible node requires a DOM element.
• No introspection
@brucel Eric Hunt https://en.wikipedia.org/wiki/Brussels_sprout#/media/ File:Brussels_sprout_closeup.jpg
@brucel Sprouting ARIA attributes <custom-slider
"0"
"5"
"3"
</custom-slider>
<custom-slider
"slider"
@brucel Phase 1 of AOM
"checkbox"
“true"
Receive promotional offers
"checkbox" ;
el . accessibleNode . checked
=
true ;
@brucel Cleaner code <custom-checkbox
checked
Receive promotional offers </custom-checkbox>
@brucel AOM vs ARIA • While AOM and ARIA both affect the computed accessible properties of a node, and have the same vocabulary, they are separate interfaces.
• They don’t reflect each other.
• If an AOM Accessible Property and the corresponding ARIA attribute have different values, the AOM property takes precedence.
IDrefs
@brucel IDs in HTML associate
"firstname"
First name:
<input
aria-activedescendant indicates a descendant that's focused in a composite control like a list box.
"listbox"
"item1"
"option"
Item 1
"item2"
Item 2
"item3"
Item 3
@brucel Impossible across components <custom-listbox>
<custom-option
Item 1 </custom-option>
Item 2 </custom-option>
Item 3 </custom-option>
comboBox.shadowRoot.querySelector(
comboBox.querySelector(
optionList.accessibleNode;
AT input events
@brucel Accessible Actions • Accessible Actions gives web developers a mechanism to listen for accessible actions directly, by adding event listeners on an AccessibleNode .
• This is analogous to listening for user interaction events on a DOM node, except that the interaction event arrives via an assistive technology API, so it is directed to the accessible node first.
AOM phases
@brucel Phase 1 Modifying Accessible Properties, will allow setting accessible properties for a DOM element, including accessible relationships.
@brucel Phase 2 Accessible Actions, will allow reacting to user actions from assistive technology.
@brucel Phase 3
Virtual Accessibility Nodes, will allow the creation of accessibility nodes which are not associated with DOM elements.
@brucel Phase 4 Computed Accessibility Tree, will allow reading the computed accessible properties for accessibility nodes, whether associated with DOM elements or virtual, and walking the computed accessibility tree.
@brucel Why is Phase 4 last? “the accessibility tree is not standardized between browsers: Each implements accessibility tree computation slightly differently. In order for this API to be useful, it needs to work consistently across browsers
We want to take the appropriate time to ensure we can agree on the details for how the tree should be computed and represented”.
@brucel Users users users! “Compared to the previous three phases, accessing the computed accessibility tree will have the least direct impact on users ”
@brucel Priority of Constituencies In case of conflict, consider users over authors over implementors over specifiers over theoretical purity .
Crowd image!!
@brucel Priority of Constituencies
Thank you thank you thank you to Alice Boxhall (@sundress)
Thank YOU! xxx @brucel
View AOM-nom-nom on Notist.
Dismiss
A brief overview of the forthcoming Accessibility Object Model