Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

What are accessible names and why should you care?

609 Aufrufe

Veröffentlicht am

This presentation will look at accessible names, how they are exposed in the browsers accessibility tree, and their importance to assistive technologies. There will be a deep dive into simple examples, advanced examples using ARIA, and an overview of the W3C's Accessible Name and Description Computation.

Veröffentlicht in: Bildung
  • Excellent presentation Russ! Very well explained.
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

What are accessible names and why should you care?

  1. 1. accessible
 names What are and why should you care?
  2. 2. Before learning about accessible names, we need to cover three other topics:
  3. 3. Accessibility APIs The DOM The accessibility tree
  4. 4. I’ll give a brief overview of these topics, then dive into accessible names.
  5. 5. Accessibility APIs
  6. 6. Application Programming Interfaces
  7. 7. APIs are software intermediaries that allow two or more applications to talk to each other.
  8. 8. For example, Twitter has an API that allows developers to pull live conversations from Twitter to their own website or app.
  9. 9. What about Accessibility APIs?
  10. 10. These APIs communicate information about the user interface from the browser to assistive technologies.
  11. 11. Browser Accessibility API Assistive Technology Diagram showing the relationship between browsers, Accessibility APIs and Assistive Technologies
  12. 12. Accessibility APIs expose information about objects within the UI to assistive technologies.
  13. 13. This information includes:
  14. 14. 1. The object’s role.
  15. 15. 2. The object’s name and description.
  16. 16. 3. The object’s property.
  17. 17. 4. The object’s current state.
  18. 18. There are a wide range of Accessibility APIs in use, including:
  19. 19. • MSAA: Microsoft Active Accessibility • UI-AUTOMATION: Microsoft User Interface Automation • UIA-EXPRESS: MSAA with UIA Express • AXAPI: Mac OS X Accessibility Protocol • ATK: Linux/Unix Accessibility Toolkit • AT-SPI: Assistive Technology Service Provider Interface • IAccessible2: IAccessible2
  20. 20. The DOM
  21. 21. Document Object Model
  22. 22. The DOM is an interface that treats XML or HTML documents as tree structures.
  23. 23. Each branch of the tree ends in a node, and each node contains objects.
  24. 24. You can see the DOM tree in most modern browsers by choosing the “Inspect Element” functionality.
  25. 25. Diagram showing Chrome’s DOM, via the “Inspect Element” function
  26. 26. Accessibility Tree
  27. 27. Browsers use the DOM tree to
 create a second tree, called the accessibility tree.
  28. 28. This accessibility tree is a simplified version of the DOM tree.
  29. 29. DOM Tree Accessibility Tree Diagram showing the relationship between the DOM and the Accessibility Tree
  30. 30. The accessibility tree is exposed to assistive technologies via the Accessibility API.
  31. 31. DOM Tree Accessibility Tree Accessibility API Assistive Technology Diagram showing the relationship between the DOM, Accessibility Tree, Accessibility APIs and Assistive Technologies
  32. 32. The accessibility tree contains only “accessible objects”.
  33. 33. These are nodes that can receive focus, or have states, properties or events.
  34. 34. All other DOM nodes (that do not have states, properties or events) are not presented in the accessibility tree.
  35. 35. For example, a section within the DOM tree could be:
  36. 36. <div class="container"> <form action="#"> <div class="form-container"> <label for="name">Name</label> <input id="name" type="text"> </div> <div class="form-container"> <button type="submit">Submit</button> </div> </form> </div>
  37. 37. Depending on the browser, the accessibility tree might only present the following:
  38. 38. <div class="container"> <form action="#"> <div class="form-container"> <label for="name">Name</label> <input id="name" type="text"> </div> <div class="form-container"> <button type="submit">Submit</button> </div> </form> </div>
  39. 39. Each browser could potentially present a slightly different accessibility tree.
  40. 40. The accessibility tree can be viewed in a range of different ways, including directly within the browser.
  41. 41. Using Chrome’s Developer Tools, via the “Accessibility” Tab.
  42. 42. Diagram showing Chrome’s Accessibility Tab
  43. 43. Using Firefox’s Developer Tools, via the “Accessibility” Tab.
  44. 44. Diagram showing Firefox’s Accessibility Tab
  45. 45. Putting them all together
  46. 46. Let's look at an example of the Accessibility API, the DOM and accessibility tree in action.
  47. 47. In the following example, we’ll go through the steps of a screen reader user going to a web application, navigating the application and then activating a button.
  48. 48. 1. When the user types in a URL and hits “ENTER”, an HTTP request is sent by the browser.
  49. 49. 2. The resulting HTML is delivered to the browser.
  50. 50. 3. The browser creates a DOM tree.
  51. 51. 4. The browser also creates an accessibility tree.
  52. 52. 5. The screen reader user can then navigate the web application, accessing the accessibility tree via the Accessibility API.
  53. 53. 6. When the user focuses on the button, it is exposed via the accessibility tree and announced to the screen reader user.
  54. 54. “Save, Button”
  55. 55. 7. When the user activates the button, the assistive technology relays the action back to the app via the Accessibility API.
  56. 56. 8. The web application then interprets the action appropriately in the context of the original UI.
  57. 57. The key question is: “How did the browser know to announce the button as ‘Save’”?
  58. 58. That’s where accessible names come into play.
  59. 59. Accessible names
  60. 60. All accessible objects in the accessibility tree should have meaningful, accessible names.
  61. 61. These names are used by assistive technologies to identify the object.
  62. 62. You can see the name assigned to accessible objects by viewing the accessibility tree.
  63. 63. In the following example, a <button> element has a text value of “Save”.
  64. 64. <button>Save</button>
  65. 65. Using Chrome’s accessibility tree, we can see that the computed accessible name for the <button> is “Save”.
  66. 66. Screenshot showing Computed Properties, Name: “Save”
  67. 67. How do browsers know how to define the accessible name for each object?
  68. 68. They use the W3C specification “Accessible Name and Description Computation”. https://www.w3.org/TR/accname-1.1/
  69. 69. This specification describes how browsers determine the names and descriptions of accessible objects.
  70. 70. The specification allows browsers to create a name for each object as a text string.
  71. 71. Stepping through the Computation
  72. 72. We’re now going to go through the steps of the “Accessible Name and Description Computation”.
  73. 73. This is an extremely simplified version of the steps. Otherwise we’d be here all day.
  74. 74. Step A.
  75. 75. “ If the current node is hidden and is not directly referenced by aria-labelledby, aria-describedby, <label> or attribute, return the empty string.
  76. 76. The following example has an <input> with a <label> nearby.
  77. 77. However, the elements are not explicitly associated using matching FOR and ID values, and therefore the <input> returns an empty string for the accessible name.
  78. 78. <label>Street Address</label> <input type="text"> Accessible name=""
  79. 79. Step B.
  80. 80. “ Otherwise, if computing a name, and the current node has an aria-labelledby attribute that contains at least one valid IDREF, process its IDREFs in the order they occur.
  81. 81. In the following example an <input> element has an aria- labelledby attribute with two space-separated values, A and B.
  82. 82. <input type="text" aria-labelledby="a b">
  83. 83. Within the document there are two elements with ID values of A and B.
  84. 84. <input type="text" aria-labelledby="a b"> <p id="a">Help text</p> <p id="b">Error message</p>
  85. 85. The contents of these elements becomes the accessible name for the <input>.
  86. 86. The accessible name is computed based on the order the ID contents are defined within the aria- labelledby attribute.
  87. 87. <input type="text" aria-labelledby="a b"> <p id="a">Help text</p> <p id="b">Error message</p> Accessible name="Help text Error message"
  88. 88. Step C.
  89. 89. “ Otherwise, if computing a name, and if the current node has an aria-label attribute whose value is not the empty string, return the value of aria-label.
  90. 90. In the following example, the <button> element has an aria- label, which becomes the accessible name.
  91. 91. <button aria-label="Close modal">X</button> Accessible name="Close modal"
  92. 92. Step D.
  93. 93. “ Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string, unless the element is marked as presentational role="presentation" or role="none".
  94. 94. In the following example, the <label> is explicitly associated with the <input> using matching FOR and ID values.
  95. 95. This means that the <label> element provides a text alternative for the <input> that can be used as an accessible name.
  96. 96. <label for="suburb">Your suburb</label> <input id="suburb" type="text"> Accessible name="Your suburb"
  97. 97. In the following example, the <img> includes an alt attribute that contains a text string.
  98. 98. This means that the alt attribute provides a text alternative for the <img> that can be used as an accessible name.
  99. 99. <img alt="Round ball" src="ball.png"> Accessible name="Round ball"
  100. 100. The title attribute is a special case.
  101. 101. This attribute is considered problematic and should be avoided. https://developer.paciellogroup.com/blog/2013/01/using-the- html-title-attribute-updated/
  102. 102. In reality, the title attribute is meant to be used as descriptive text, rather than an accessible name.
  103. 103. It is only promoted to an accessible name in situations where there is no other accessible name that can be computed.
  104. 104. In the following example, the <img> has no alt attribute. However, a title attribute is present.
  105. 105. As there is no alt attribute present, the title attribute provides a text alternative for the <img> that can be used as an accessible name.
  106. 106. <img title="Another ball" src="ball.png"> Accessible name="Another ball"
  107. 107. If both alt and title attributes are present, the alt attribute will always be used as the text alternative for an <img>.
  108. 108. In the following example, the <img> has both alt and title attributes.
  109. 109. The alt attribute’s text alternative is used as the accessible name.
  110. 110. <img alt="Round ball" title="Another ball" src="ball.png"> Accessible name="Round Ball"
  111. 111. Step E.
  112. 112. We’ll skip over Step E to avoid complexity.
  113. 113. Step F.
  114. 114. “ Otherwise, if the current node's role allows name from content… return the accumulated text.* (* Extremely simplified version)
  115. 115. Some ARIA role attributes allow “Name from content”.
  116. 116. This means that the text within these elements becomes the accessible name.
  117. 117. The full list of “Roles Supporting Name from Content”: https://www.w3.org/TR/wai-aria/#namefromcontent
  118. 118. In the following example, an element has been given a role of button and therefore can produce an accessible name.
  119. 119. <div role="button">Help</div> Accessible name="Help"
  120. 120. Step G.
  121. 121. “ Otherwise, if the current node is a Text node, return its textual contents.
  122. 122. In the following example, the link text is the accessible name.
  123. 123. <a href="#">Hello world</a> Accessible name="Hello world"
  124. 124. The order
  125. 125. These steps are applied in priority order from highest to lowest.
  126. 126. A and BUTTON elements
  127. 127. In the case of <a> and <button> elements, and elements with a role of button or link, this would mean:
  128. 128. 1. Use aria-labelledby 2. Otherwise, use aria-label 3. Otherwise, use element’s subtree 4. Otherwise, use title 5. If none of the above yield a usable text string, there is no accessible name
  129. 129. What happens if you apply multiple name options to an object?
  130. 130. Let’s look at a series of weird examples.
  131. 131. <button aria-labelledby="red" aria-label="Blue" title="Pink">Green</button> <p id="red">Red</p> Accessible name="red"
  132. 132. This can be seen when viewing the accessibility tree in Chrome.
  133. 133. <button aria-label="Blue" title="Pink">Green</ button> Accessible name="Blue"
  134. 134. <button title="Pink">Green</button> Accessible name="Green"
  135. 135. <button title="Pink"></button> Accessible name="Pink"
  136. 136. IMG elements
  137. 137. In the case of <img> elements, this would mean:
  138. 138. 1. Use aria-labelledby 2. Otherwise, use aria-label 3. Otherwise, use alt 4. Otherwise, use title 5. If none of the above yield a usable text string, there is no accessible name.
  139. 139. INPUT, SELECT and TEXTAREA elements
  140. 140. In the case of most of the common <input> elements, <select> and <textarea> elements, this would mean:
  141. 141. 1. Use aria-labelledby 2. Otherwise, use aria-label 3. Otherwise, use associated <label> element(s) 4. Otherwise, use title 5. Otherwise, use placeholder 6. If none of the above yield a usable text string, there is no accessible name.
  142. 142. Fixing some poor examples
  143. 143. Let's look at some examples of where the accessible names could be improved.
  144. 144. Buttons
  145. 145. In the following example a <button> element uses only an icon for content.
  146. 146. This means that it has no text string that can be used as an accessible name.
  147. 147. <button> <i class="fa fa-trash"></i> </button> Accessible name=""
  148. 148. One solution would be to use an aria-label to provide an accessible name.
  149. 149. <button aria-label="Delete item"> <i class="fa fa-trash"></i> </button> Accessible name="Delete item"
  150. 150. Links
  151. 151. In the following example, a link contains the text “More”.
  152. 152. <a href="#">More</a> Accessible name="More"
  153. 153. While there is an accessible name present, it does not provide any context for assistive technologies.
  154. 154. Depending on the circumstances, this link would probably fail “Success Criterion 2.4.4 Link Purpose”. https://www.w3.org/TR/WCAG21/#link-purpose-in-context
  155. 155. If the designer/developer did not want a more descriptive link text to be displayed, an aria-label could be used to provide additional context.
  156. 156. <a href="#" aria-label="More about fruit">More</a> Accessible name="More about fruit"
  157. 157. Alternatively, additional content could be presented to screen readers only, to provide additional context.
  158. 158. <a href="#">More<span class="sr-only"> about fruit</ span></a> Accessible name="More about fruit"
  159. 159. Placeholder
  160. 160. In the following example, the placeholder is used to provide a label for an <input>.
  161. 161. <input placeholder="Search" type="text">
  162. 162. Even though the placeholder attribute can be treated as an accessible name, it is not an acceptable alternative to a <label> element.
  163. 163. The HTML5 specification states that the placeholder attribute should not be used as an alternative to a <label>.
  164. 164. The placeholder also has a range of accessibility issues.
  165. 165. By default, the placeholder lacks sufficient colour contrast.
  166. 166. The placeholder value disappears as soon as users start typing, which can cause issues for some cognitively impaired users.
  167. 167. If you don’t want to display a label, an aria-label could be used to provide an accessible name.
  168. 168. <input aria-label="Search" type="text"> Accessible name="Search"
  169. 169. Or, a hidden <label> could be used. This means it would be available to screen readers only but not presented on-screen.
  170. 170. <label for="search" class="sr-only">Search</label> <input id="search" type="text"> Accessible name="Search"
  171. 171. These three examples show that there are ways to provide meaningful accessible names, without affecting how the objects are displayed.
  172. 172. Conclusion
  173. 173. By including meaningful accessible names for all accessible objects, you can provide a better experience for everyone!
  174. 174. Thank you.

×