This presentation for AllyCamp 2020, looks at accessible names, how they are exposed in the browsers accessibility tree, and their importance to assistive technologies. There is also 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
A deep dive into

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
simpli
fi
ed 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 di
ff
erent
accessibility tree.

40. The accessibility tree can be viewed
in a range of di
ff
erent 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
de
fi
ne the accessible name for
each object?

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

69. This speci
fi
cation describes how
browsers determine the names
and descriptions of accessible
objects.

70. The speci
fi
cation allows browsers to
create a name for each object as a
text string.

71. The document also determines the
order in which accessible names
are applied.

72. Accessible names are applied in
priority order from highest to
lowest in the following way.

73. A and BUTTON elements

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

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

76. What happens if you apply multiple
name options to an object?

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

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

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

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

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

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

84. IMG elements

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

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

87. INPUT, SELECT and
TEXTAREA elements

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

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

90. Fixing some poor
examples

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

92. Buttons

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

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

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

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

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

98. Links

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

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

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

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

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

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

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

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

107. Placeholder

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

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

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

111. The HTML5 speci
fi
cation states that
the placeholder attribute should
not be used as an alternative to a
<label>.

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

113. By default, the placeholder lacks
su
ffi
cient colour contrast.

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

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

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

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

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

119. These three examples show that
there are ways to provide
meaningful accessible names,
without a
ff
ecting how the objects
are displayed.

120. Conclusion

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

122. Thank you.