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.

1. accessible
names
What are
and why should you care?

2. Before learning about accessible
names, we need to cover three
other topics:

3. Accessibility APIs
The DOM
The accessibility tree

4. I’ll give a brief overview of these
topics, then dive into accessible
names.

5. Accessibility APIs

6. Application Programming Interfaces

7. APIs are software intermediaries
that allow two or more applications
to talk to each other.

8. For example, Twitter has an API that
allows developers to pull live
conversations from Twitter to their
own website or app.

9. What about Accessibility APIs?

10. These APIs communicate
information about the user
interface from the browser to
assistive technologies.

11. Browser Accessibility
API
Assistive
Technology
Diagram showing the relationship between browsers, Accessibility APIs and Assistive Technologies

12. Accessibility APIs expose
information about objects within
the UI to assistive technologies.

13. This information includes:

14. 1. The object’s role.

15. 2. The object’s name and
description.

16. 3. The object’s property.

17. 4. The object’s current state.

18. There are a wide range of
Accessibility APIs in use, including:

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. The DOM

21. Document Object Model

22. The DOM is an interface that treats
XML or HTML documents as tree
structures.

23. Each branch of the tree ends in a
node, and each node contains
objects.

24. You can see the DOM tree in most
modern browsers by choosing the
“Inspect Element” functionality.

25. Diagram showing Chrome’s DOM, via the “Inspect Element” function

26. Accessibility Tree

27. Browsers use the DOM tree to
create a second tree, called the
accessibility tree.

28. This accessibility tree is a
simplified version of the DOM
tree.

29. DOM
Tree
Accessibility
Tree
Diagram showing the relationship between the DOM and the Accessibility Tree

30. The accessibility tree is exposed to
assistive technologies via the
Accessibility API.

31. DOM
Tree
Accessibility
Tree
Accessibility
API
Assistive
Technology
Diagram showing the relationship between the DOM, Accessibility Tree, Accessibility APIs and Assistive Technologies

32. The accessibility tree contains only
“accessible objects”.

33. These are nodes that can receive
focus, or have states, properties
or events.

34. All other DOM nodes (that do not
have states, properties or events)
are not presented in the
accessibility tree.

35. For example, a section within the
DOM tree could be:

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. Depending on the browser, the
accessibility tree might only
present the following:

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. Each browser could potentially
present a slightly different
accessibility tree.

40. The accessibility tree can be viewed
in a range of different ways,
including directly within the browser.

41. Using Chrome’s Developer Tools,
via the “Accessibility” Tab.

42. Diagram showing Chrome’s Accessibility Tab

43. Using Firefox’s Developer Tools,
via the “Accessibility” Tab.

44. Diagram showing Firefox’s Accessibility Tab

45. Putting them all
together

46. Let's look at an example of the
Accessibility API, the DOM and
accessibility tree in action.

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. 1. When the user types in a URL
and hits “ENTER”, an HTTP
request is sent by the browser.

49. 2. The resulting HTML is delivered
to the browser.

50. 3. The browser creates a DOM tree.

51. 4. The browser also creates an
accessibility tree.

52. 5. The screen reader user can then
navigate the web application,
accessing the accessibility tree via
the Accessibility API.

53. 6. When the user focuses on the
button, it is exposed via the
accessibility tree and announced to
the screen reader user.

54. “Save, Button”

55. 7. When the user activates the
button, the assistive technology
relays the action back to the app via
the Accessibility API.

56. 8. The web application then
interprets the action appropriately
in the context of the original UI.

57. The key question is: “How did the
browser know to announce the
button as ‘Save’”?

58. That’s where accessible names
come into play.

59. Accessible names

60. All accessible objects in the
accessibility tree should have
meaningful, accessible names.

61. These names are used by assistive
technologies to identify the object.

62. You can see the name assigned to
accessible objects by viewing the
accessibility tree.

63. In the following example, a
<button> element has a text value
of “Save”.

64. <button>Save</button>

65. Using Chrome’s accessibility tree,
we can see that the computed
accessible name for the <button>
is “Save”.

66. Screenshot showing Computed Properties, Name: “Save”

67. How do browsers know how to
define the accessible name for
each object?

68. They use the W3C specification
“Accessible Name and
Description Computation”.
https://www.w3.org/TR/accname-1.1/

69. This specification describes how
browsers determine the names
and descriptions of accessible
objects.

70. The specification allows browsers to
create a name for each object as a
text string.

71. Stepping through the
Computation

72. We’re now going to go through the
steps of the “Accessible Name
and Description Computation”.

73. This is an extremely simplified
version of the steps. Otherwise
we’d be here all day.

74. Step A.

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. The following example has an
<input> with a <label> nearby.

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. <label>Street Address</label>
<input type="text">
Accessible name=""

79. Step B.

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. In the following example an
<input> element has an aria-
labelledby attribute with two
space-separated values, A and B.

82. <input type="text" aria-labelledby="a b">

83. Within the document there are two
elements with ID values of A and B.

84. <input type="text" aria-labelledby="a b">
<p id="a">Help text</p>
<p id="b">Error message</p>

85. The contents of these elements
becomes the accessible name for
the <input>.

86. The accessible name is computed
based on the order the ID contents
are defined within the aria-
labelledby attribute.

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. Step C.

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. In the following example, the
<button> element has an aria-
label, which becomes the
accessible name.

91. <button aria-label="Close modal">X</button>
Accessible name="Close modal"

92. Step D.

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. In the following example, the
<label> is explicitly associated
with the <input> using matching
FOR and ID values.

95. This means that the <label>
element provides a text alternative
for the <input> that can be used as
an accessible name.

96. <label for="suburb">Your suburb</label>
<input id="suburb" type="text">
Accessible name="Your suburb"

97. In the following example, the <img>
includes an alt attribute that
contains a text string.

98. This means that the alt attribute
provides a text alternative for the
<img> that can be used as an
accessible name.

99. <img alt="Round ball" src="ball.png">
Accessible name="Round ball"

100. The title attribute is a special
case.

101. This attribute is considered
problematic and should be
avoided.
https://developer.paciellogroup.com/blog/2013/01/using-the-
html-title-attribute-updated/

102. In reality, the title attribute is
meant to be used as descriptive
text, rather than an accessible
name.

103. It is only promoted to an accessible
name in situations where there is no
other accessible name that can
be computed.

104. In the following example, the <img>
has no alt attribute. However, a
title attribute is present.

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. <img title="Another ball" src="ball.png">
Accessible name="Another ball"

107. If both alt and title attributes are
present, the alt attribute will
always be used as the text
alternative for an <img>.

108. In the following example, the <img>
has both alt and title attributes.

109. The alt attribute’s text alternative
is used as the accessible name.

110. <img alt="Round ball" title="Another ball"
src="ball.png">
Accessible name="Round Ball"

111. Step E.

112. We’ll skip over Step E to avoid
complexity.

113. Step F.

114. “ Otherwise, if the current node's role allows
name from content… return the
accumulated text.*
(* Extremely simplified version)

115. Some ARIA role attributes allow
“Name from content”.

116. This means that the text within
these elements becomes the
accessible name.

117. The full list of “Roles Supporting
Name from Content”:
https://www.w3.org/TR/wai-aria/#namefromcontent

118. In the following example, an
element has been given a role of
button and therefore can produce
an accessible name.

119. <div role="button">Help</div>
Accessible name="Help"

120. Step G.

121. “ Otherwise, if the current node is a Text
node, return its textual contents.

122. In the following example, the link
text is the accessible name.

123. <a href="#">Hello world</a>
Accessible name="Hello world"

124. The order

125. These steps are applied in priority
order from highest to lowest.

126. A and BUTTON elements

127. In the case of <a> and <button>
elements, and elements with a role
of button or link, this would
mean:

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. What happens if you apply multiple
name options to an object?

130. Let’s look at a series of weird
examples.

131. <button aria-labelledby="red" aria-label="Blue"
title="Pink">Green</button>
<p id="red">Red</p>
Accessible name="red"

132. This can be seen when viewing the
accessibility tree in Chrome.

134. <button aria-label="Blue" title="Pink">Green</
button>
Accessible name="Blue"

135. <button title="Pink">Green</button>
Accessible name="Green"

136. <button title="Pink"></button>
Accessible name="Pink"

137. IMG elements

138. In the case of <img> elements, this
would mean:

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

140. INPUT, SELECT and
TEXTAREA elements

141. In the case of most of the common
<input> elements, <select> and
<textarea> elements, this would
mean:

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

143. Fixing some poor
examples

144. Let's look at some examples of
where the accessible names could
be improved.

145. Buttons

146. In the following example a
<button> element uses only an
icon for content.

147. This means that it has no text
string that can be used as an
accessible name.

148. <button>
<i class="fa fa-trash"></i>
</button>
Accessible name=""

149. One solution would be to use an
aria-label to provide an
accessible name.

150. <button aria-label="Delete item">
<i class="fa fa-trash"></i>
</button>
Accessible name="Delete item"

151. Links

152. In the following example, a link
contains the text “More”.

153. <a href="#">More</a>
Accessible name="More"

154. While there is an accessible name
present, it does not provide any
context for assistive technologies.

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

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

157. <a href="#" aria-label="More about fruit">More</a>
Accessible name="More about fruit"

158. Alternatively, additional content
could be presented to screen
readers only, to provide additional
context.

159. <a href="#">More<span class="sr-only"> about fruit</
span></a>
Accessible name="More about fruit"

160. Placeholder

161. In the following example, the
placeholder is used to provide a
label for an <input>.

162. <input placeholder="Search" type="text">

163. Even though the placeholder
attribute can be treated as an
accessible name, it is not an
acceptable alternative to a
<label> element.

164. The HTML5 specification states that
the placeholder attribute should
not be used as an alternative to a
<label>.

165. The placeholder also has a range
of accessibility issues.

166. By default, the placeholder lacks
sufficient colour contrast.

167. The placeholder value
disappears as soon as users start
typing, which can cause issues for
some cognitively impaired users.

168. If you don’t want to display a label,
an aria-label could be used to
provide an accessible name.

169. <input aria-label="Search" type="text">
Accessible name="Search"

170. Or, a hidden <label> could be
used. This means it would be
available to screen readers only
but not presented on-screen.

171. <label for="search" class="sr-only">Search</label>
<input id="search" type="text">
Accessible name="Search"

172. These three examples show that
there are ways to provide
meaningful accessible names,
without affecting how the objects
are displayed.

173. Conclusion

174. By including meaningful accessible
names for all accessible objects,
you can provide a better
experience for everyone!

175. Thank you.