Web Accessibility Live London, Feb 2018

Slide 1

Slide 1 text

@brucel The Future of Accessibility Web Accessibility Live, 8 February 2018 1

Slide 2

Slide 2 text

@brucel Who? • Multiple Sclerosis owner • Ex-Deputy CTO, Opera Software • BS8878 committee member • co-editor HTML5.3 spec at W3C • Co-author “Introducing HTML5”, “Web Accessibility: Web Standards and Regulatory Compliance”

Slide 3

Slide 3 text

@brucel

Slide 4

Slide 4 text

@brucel https://voice.mozilla.org/

Slide 5

Slide 5 text

@brucel https://code.facebook.com/posts/457605107772545/under-the-hood-building- accessibility-tools-for-the-visually-impaired-on-facebook/

Slide 6

Slide 6 text

@brucel Automated lip-reading “The Google DeepMind project ran research on over 100, 000 natural sentences, taken from videos from the BBC. These videos had a wide range of languages, speech rates, accents, variations in lighting and head positions. …experts interpreted about 12.4% of the content, AI successfully interpreted 46.8%” - Denis Boudreau “Five Ways in Which Artiﬁcial Intelligence Changes the Face of Web Accessibility”

Slide 7

Slide 7 text

@brucel Photo: Robert Nelson

Slide 8

Slide 8 text

@brucel Smart Cities Fibercool - https://www.ﬂickr.com/photos/hgoye/2422963135/

Slide 9

Slide 9 text

@brucel icon: Becris https://thenounproject.com/term/smart-city/1271139/

Slide 10

Slide 10 text

@brucel Smart cities • London: SCOOT optimises traﬃc lights • Barcelona: emergency vehicles routing • Amsterdam: street lighting based on pedestrian numbers • Singapore - smart health care • Santa Cruz - directing police resources • Shwetank Dixit: What do we mean by accessible smart cities? http://blog.barrierbreak.com/2017/05/02/what-do-we- mean-by-accessible-smart-cities/

Slide 11

Slide 11 text

@brucel

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

@brucel Wix • enable navigation by keyboard • provide Screen Reader compatibility • build infrastructure for accessibility development and testing.

Slide 14

Slide 14 text

@brucel

Slide 15

Slide 15 text

@brucel

Slide 16

Slide 16 text

@brucel 110 million

Slide 17

Slide 17 text

@brucel Stylable is a CSS preprocessor for styling components with typed CSS.

Slide 18

Slide 18 text

@brucel Photo: F. Antolín Hernandez

Slide 19

Slide 19 text

@brucel

Slide 20

Slide 20 text

@brucel

Slide 21

Slide 21 text

@brucel

Slide 22

Slide 22 text

@brucel “HTML 4.0 developments inspired by concerns for accessibility include the requirement that alternate text accompany an image included via the IMG element.

Slide 23

Slide 23 text

@brucel

Slide 24

Slide 24 text

@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/

Slide 25

Slide 25 text

@brucel

Slide 26

Slide 26 text

@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.

Slide 27

Slide 27 text

@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.

Slide 28

Slide 28 text

@brucel ARIA landmark roles role="contentinfo", "main", "banner" ...

Slide 29

Slide 29 text

Built-in beats bolt-on

Slide 30

Slide 30 text

@brucel

Slide 31

Slide 31 text

@brucel

Slide 32

Slide 32 text

@brucel Photo: Brittany Shaw

Slide 33

Slide 33 text

@brucel

Slide 34

Slide 34 text

@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

Slide 35

Slide 35 text

@brucel Web Components

Slide 36

Slide 36 text

@brucel

Slide 37

Slide 37 text

@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

Slide 38

Slide 38 text

@brucel JavaScript frameworks

Slide 39

Slide 39 text

@brucel Custom elements Click me!

Slide 40

Slide 40 text

@brucel .. or semantically neutral

Click me!

Slide 41

Slide 41 text

@brucel dannynorton - https://www.ﬂickr.com/photos/dannynorton/186795352/

Slide 42

Slide 42 text

@brucel accessibility object model F Delventhal https://www.ﬂickr.com/photos/krossbow/10324856173/

Slide 43

Slide 43 text

@brucel wicg.github.io/aom/spec/ • Alexander Surkov, Mozilla • Alice Boxhall, Google • Dominic Mazzoni, Google • James Craig, Apple --enable-blink-features=AccessibilityObjectModel

Slide 44

Slide 44 text

@brucel Current gaps • Leaky abstractions • IDrefs • No way to capture input events from Assistive Technology • Every accessible node requires a DOM element. • No introspection

Slide 45

Slide 45 text

@brucel

Slide 46

Slide 46 text

@brucel Eric Hunt https://en.wikipedia.org/wiki/Brussels_sprout#/media/ File:Brussels_sprout_closeup.jpg

Slide 47

Slide 47 text

@brucel Sprouting ARIA attributes

Slide 48

Slide 48 text

@brucel Phase 1 of AOM

Receive promotional offers

can be replaced by: el.accessibleNode.role = "checkbox"; el.accessibleNode.checked = true;

Slide 49

Slide 49 text

@brucel Cleaner code Receive promotional offers

Slide 50

Slide 50 text

@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.

Slide 51

Slide 51 text

IDrefs

Slide 52

Slide 52 text

@brucel IDs in HTML associate

First name:

aria-activedescendant indicates a descendant that's focused in a composite control like a list box.

Item 1

Item 2

Item 3

Slide 53

Slide 53 text

@brucel Impossible across components Item 1 Item 2 Item 3

Slide 54

Slide 54 text

@brucel New! Improved! AOM! const input = comboBox.shadowRoot.querySelector(“input"); const optionList = comboBox.querySelector("custom-optionlist"); input.accessibleNode.activeDescendant = optionList.accessibleNode;

Slide 55

Slide 55 text

AT input events

Slide 56

Slide 56 text

@brucel

Slide 57

Slide 57 text

@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 ﬁrst.

Slide 58

Slide 58 text

AOM phases

Slide 59

Slide 59 text

@brucel Phase 1 • Modifying Accessible Properties, will allow setting accessible properties for a DOM element, including accessible relationships.

Slide 60

Slide 60 text

@brucel Phase 2 • Accessible Actions, will allow reacting to user actions from assistive technology.

Slide 61

Slide 61 text

@brucel Phase 3 • Virtual Accessibility Nodes, will allow the creation of accessibility nodes which are not associated with DOM elements.

Slide 62

Slide 62 text

@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.

Slide 63

Slide 63 text

@brucel Why is Phase 4 last? “the accessibility tree is not standardized between browsers: Each implements accessibility tree computation slightly diﬀerently. 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”.

Slide 64

Slide 64 text

@brucel Users users users! “Compared to the previous three phases, accessing the computed accessibility tree will have the least direct impact on users”

Slide 65

Slide 65 text

@brucel Priority of Constituencies In case of conﬂict, consider users over authors over implementors over speciﬁers over theoretical purity. HTML Design Principles - https://www.w3.org/TR/html-design-principles/

Slide 66

Slide 66 text

Crowd image!!

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

Thanks to Alice Boxhall (@sundress), Denis Boudreau (@dboudreau), Shwetank Dixit (@shwetank).

Slide 69

Slide 69 text

Thank YOU! xxx @brucel