Download to read offline
![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](https://image.slidesharecdn.com/a11ycampapi-101-191114221928/75/DOM-and-Accessibility-API-Communication-17-2048.jpg)
Uploaded byAimee Maree
DOM and Accessibility API Communication
The document provides an overview of how accessibility is implemented on the web. It discusses: - The origins of the DOM and Accessibility API in the 1990s to provide interfaces for scripts and assistive technologies to interact with web pages. - How the Accessibility API maps HTML elements to operating system elements, allowing for a seamless experience across devices. - The "accessibility stack" with assistive technologies interacting with the OS and browser accessibility APIs to interpret web pages. - How the browser processes HTML, CSS and JavaScript to build the accessibility tree from the DOM, with ARIA roles, properties and states providing additional semantics. - Best practices like using native HTML semantics and communicating state changes
More Related Content
Similar to DOM and Accessibility API Communication
![Accessibility with Joomla [on a budget]](https://cdn.slidesharecdn.com/ss_thumbnails/joomla-accessibility-141123061021-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![Computer Networks 01[1 using all terms].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/computernetworks011-251214040533-327dd9f8-thumbnail.jpg?width=640&height=640&fit=bounds)
DOM and Accessibility API Communication
- 1. AIMEE MAREE FORSSTROM AIMEEMAREE.COM ACCESSIBILITY API101 DOM and Accessibility API Communication
- 2. Sometime back inthe 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.
- 4. The Accessibility APIwas 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.
- 6. Where are wenow? 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 OSA11Y API BROWSER OPERATING SYSTEM 7 DOM A11Y API
- 8. The Accessibility APIand 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 ITALL 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=“AustralianIndigenous 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 typeused 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 accessiblename 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 currentstate 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 usingNative 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 AccessibilityAPI is a trimmed subset of the DOM
- 20. 20 DOM Accessibility API SemanticNative Elements are declared by the Browser Non Semantic Elements are ignored H1 H1 span H2 H2 Button Input Button Input
- 21. How is theAccessibility 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 Scriptfits 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 Comesin 23 ACCESSIBILITY APIDOM HTML Accessibility API can only be modified by ARIA JavaScript can not access the Accessibility API JAVASCRIPT ARIA
- 24. How we manipulatethe 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 ofthe puzzle and where they belong 25 ACCESSIBILITY APIDOMHTML CSS ASSISTIVE TECHNOLOGY BROWSER JAVASCRIPT ARIA TAGS
- 26. What does thisall 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 DOESTHIS 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 theStack ASSISTIVE TECHNOLOGY ACCESSIBILITY API JS 29 DOM BROWSER HTML / CSS / ARIA
- 30. Accessibility Mechanics Takeaway NativeHTML 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 orNot 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 ANDMAKE THE WEB MORE ACCESSIBLE… The Presenter 32
Editor's Notes
- #12 Ok so lets go back to how the myth was created,
- #16 Role tells the browser what the element does, so the browser will tell the screen reader what the element is such as image. HTML landmark roles are an example of this, these are also landmark elements which can be used for navigation and you can move from one to the next like a table of contents for the page Roles are element types and authors MUST NOT change role values over time or with user actions. Authors wishing to change a role MUST do so by deleting the associated element and its children and replacing it with a new element with the appropriate role. Typically, platform accessibility APIs do not provide a vehicle to notify assistive technologies of a role value change, and consequently, assistive technologies may not update their cache with the new role attribute value. This section defines the WAI-ARIA role taxonomy and describes the characteristics and properties of all roles. In order to reflect the content in the DOM, user agents SHOULD map the role attribute to the appropriate value in the implemented accessibility API The role taxonomy uses the following relationships to relate WAI-ARIA roles to each other and to concepts from other specifications, such as HTML and XForms.
- #17 Name, this can come from various areas of an element for an image it will be the alt tag, for a link it will be the link text, or in the case of labels you can use another element to name an element such as form items.
- #18 State, informs that interaction is required before the next step
- #27 HTML output from backend is turned into tokens interpreted via the DOM “Document Object Model” We still need HTML and CSS to layout a webpage Screen Readers and other tools look for HTML native elements JS Frameworks use javascript to inject HTML onto the webpage People like JS Frameworks they are client rendered and render quickly It can depend on the framework? Some frameworks have Aria calls built into their components, some make more use of native elements. So I don't have to worry about HTML then? Well its JS yes, but your still injecting HTML code and that is what needs to be accessible.
- #29 The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means.
- #31 HTML output from backend is turned into tokens interpreted via the DOM “Document Object Model” We still need HTML and CSS to layout a webpage Screen Readers and other tools look for HTML native elements JS Frameworks use javascript to inject HTML onto the webpage People like JS Frameworks they are client rendered and render quickly It can depend on the framework? Some frameworks have Aria calls built into their components, some make more use of native elements. So I don't have to worry about HTML then? Well its JS yes, but your still injecting HTML code and that is what needs to be accessible.
- #32 HTML output from backend is turned into tokens interpreted via the DOM “Document Object Model” We still need HTML and CSS to layout a webpage Screen Readers and other tools look for HTML native elements JS Frameworks use javascript to inject HTML onto the webpage People like JS Frameworks they are client rendered and render quickly It can depend on the framework? Some frameworks have Aria calls built into their components, some make more use of native elements. So I don't have to worry about HTML then? Well its JS yes, but your still injecting HTML code and that is what needs to be accessible.