Discussion on how the Accessibility API and the DOM communicate in web browsers

1. AIMEE MAREE FORSSTROM
AIMEEMAREE.COM
ACCESSIBILITY
API 101
DOM and
Accessibility API
Communication

2. Sometime back in the 90s
The Web Browser was born and with that the Document
Object Model
The Browser was built to read Web Documents, or as we
came to know them Web Pages
Document Object Model is the programming interface
between Web Scripts and the Web Browser on end device
DOM represents the document and its order of elements in a
logical tree, each branch contains a node and each node
contains objects
2

3. 3

4. The Accessibility API was born
Shortly after the DOM came along the Accessibility API was
born
The Accessibility API gave us the greatest advancement we
have seen to enable Screen Readers and other assistive
technologies to be able to read a web page like it would a word
document
4

5. 5

6. Where are we now?
Ever since the 90s we have had both Operating system and
Browser Accessibility API
There is a direct mapping between HTML elements and
operating system elements
So now this means that the iPhone and your MacBook will
bot h have an operating system A11y API and the Browser
Accessibility API, creating a somewhat seamless
experience
6

7. Accessibility Stack
ASSISTIVE TECHNOLOGY
OS A11Y API
BROWSER
OPERATING SYSTEM
7
DOM A11Y API

8. The Accessibility API and the Browser
Alot of accessibility work is done for you by the browser
Browser also handles keyboard focus, so it knows for example
that you can hit an enter key on an element because it knows
its a link and it you will want to click
There is a direct mapping between the OS Accessibility API
and the Browser Accessibility API
8

9. HOW DOES IT ALL WORK
YOU ASK?
Presenter
9

10. Browser Accessibility Access
ASSISTIVE
TECHNOLOGY
Role: Button
Name: Submit
State: Focus
10
BROWSE
R A11Y
API
X
Tabs to Form
Submit
Submit
Focus
Clickable

11. Javascript libraries, CSS, image files sent from the web
server are processed in the BROWSER turned into tokens
interpreted by DOM to build the Accessibility Tree
HTML is rendered in the BROWSER to the end
device and interpreted by assistive technologies
HTML
Scripts to Tokens to Information
11

12. <img src =“australian_flag.jpg”
alt=“Australian Indigenous Flag”>
Painted into the visual UI on the Browser
Transformed into accessibility tree
Role: Image
Name: Australian Indigenous Flag
Clients Browser Assistive Technology
Accessibility API
DOM
12

13. Common Language
ACCESSIBILITY
API
Name = Search
Value = (none)
Role = Button
State = default, focusable
Description = “Search this Site”
Aria-live = “polite”
13

15. Role
Declares element type used to identify the purpose and
mapped to values in the accessibility API
Exposes a set of known actions to tools based on implied
behaviour of the role, example: role=“search”
Can define what behaviour to use when certain states or
properties with default values are not provided
<input type=“checkbox” id=“happy" checked>
<label for=“happy”>Accessibility makes me happy</label>
15

16. Name
Provides an accessible name for the element
Can come from various areas of an element
For example: The form label tag becomes the accessible name
for the associated form field object
For image the alt tag provides the accessible name
<input type=“checkbox” id=“happy" checked>
<label for=“happy”>Accessibility makes me happy</label>
16

17. State
Conveys the current state of the element
Dynamic property expressing characteristics of an object that
may change in response to an action [user or script]
Represent associated data or user interaction
States declare interactions and grouped by Widget types, Live
region, drag and drop
<input type=“checkbox” id=“happy" checked>
<label for=“happy”>Code 2017 makes me happy</label>
17

18. Its Magic
By using Native HTML elements you are already informing
the Accessibility API about their Name, Role and State
This is what we mean by “Let the Browser do the Work”
If your not using Native Elements you MUST state their
Name, Role and State
Native Elements are semantic and pass information to the
DOM and Accessibility API
Span and Div are not semantic Accessibility API will ignore
18

19. 19
DOM Accessibility API
Accessibility API is a trimmed
subset of the DOM

20. 20
DOM Accessibility API
Semantic Native Elements are declared by the
Browser Non Semantic Elements are ignored
H1 H1
span
H2 H2
Button
Input
Button
Input

21. How is the Accessibility API created?
21
ACCESSIBILITY
APIDOM
HTML
DOM parses the markup code and creates a Tree of
Nodes representing the hierarchy of the document
DOM takes Name, Role, State tokens and build
the Accessibility Tree

22. Where Java Script fits in
22
ACCESSIBILIT
Y API
DOM
HTML
JavaScript can access and modify the DOM directly
JavaScript can not access the Accessibility API
JAVASCRIPT

23. Where Aria Comes in
23
ACCESSIBILITY
APIDOM
HTML
Accessibility API can only be modified by ARIA
JavaScript can not access the Accessibility API
JAVASCRIPT ARIA

24. How we manipulate the a11y Tree
24
ACCESSIBILITY
APIDOM
HTML
DOM is built from HTML and includes the information from the Aria
Tags in the accessibility tree
We place ARIA tags on HTML elements and we can use JavaScript
to modify the Aria Tags on HTML elements
JAVASCRIP
T
ARIA
Accessibility Tree now includes the information from Aria Tags

25. The pieces of the puzzle and where they belong
25
ACCESSIBILITY
APIDOMHTML
CSS
ASSISTIVE
TECHNOLOGY
BROWSER
JAVASCRIPT
ARIA TAGS

26. What does this all mean?
JavaScript can manipulate the DOM tree but not the A11Y tree
We use JavaScript to add AriaTags to HTML elements so the DOM can
produce the A11y tree with this information included
When we use Native Elements the Browser does most of the work for
us
When we create our own components we need to inform the DOM of
Role, Name, State so thew A11y tree will be aware of them
AFICIONADO.TEC
H
26

27. SO WHERE DOES THIS
LEAVE US THEN?
Audience
27

28. Accessibility Mechanics
Accessibility API
Role
‣ Navigational landmarks
‣ Assest Types
‣ Widget Types
‣ States and Properties
‣ Widgets
‣ Form
‣ Dynamic
‣ Value
DOM-implied hierarchy
State and Property Events
User Agent
Browser DOM
JavaScript
‣ Acts as the Controller
‣ Manipulates DOM
tokens
‣ Event-driven
‣ Can produce new
widget/s
Assistive
Technology
Interprets the HTML
output from the browser
Reads the information
presented in the HTML
and uses the HTML
elements found to
understand the type of
information presented
DATA
DOCUMENT
ELEMENT
UI
28

29. Passing Through the Stack
ASSISTIVE
TECHNOLOGY
ACCESSIBILITY API
JS
29
DOM
BROWSER
HTML / CSS / ARIA

30. Accessibility Mechanics Takeaway
Native HTML Elements first
Test your site with keyboard access only
Provide accessible names and descriptions, give images alt-
tags, assign labels to forms, make sure links actually provide
information about what the link is and not click or read more
Communicate State
Check your DOM output
Check your Accessibility API tree output
30

31. To Aria or Not to Aria?
Aria is aimed at Screen Readers, other assistive technologies will
rely on Native HTML
All Screen Readers will read Aria tags
Overuse of Aria can break the Accessibility API and/or cause an
unexpected outcome
Each Browser extends the DOM in its own unique way
When thinking of Accessibility think Native Elements and that way
the browser does most of the work for us
31

32. GO FORTH AND MAKE
THE WEB MORE
ACCESSIBLE…
The Presenter
32