Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

aria-live: the good, the bad and the ugly

12,168 views

Published on

Almost all web sites and web applications today are heavily reliant on JavaScript to provide rich interactions for the user. But how can we make these interactions accessible for assistive technologies such as screen readers? The answer is WAI-ARIA – and in many cases, the aria-live property. The presentation will explore the use of WAI-ARIA and the aria-live property to alert screen readers to changes in the DOM. The presentation will also look at support for aria-live across various screen readers and how the property can be most effectively used today.

Published in: Software, Education
  • did you noticed any difference with chrome when adding or omitting aria-atomic="true" (false by default)?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Great preso and handy test results, thank you! Note that with aria-live, screen reader users may be notified of the update, but if it may not be noticed by sighted folks—especially users with low vision. Managing focus to the updated area or adding a visual cue (like a yellow fade) are quite valuable techniques for sighted users.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

aria-live: the good, the bad and the ugly

  1. 1. aria-live the good the bad the ugly
  2. 2. What’s the problem?
  3. 3. Generally speaking, HTML has a very limited set of interface controls and interactions.
  4. 4. As the demand for rich interactions has increased, JavaScript has become our saviour!
  5. 5. JavaScript provides us with many things including:
  6. 6. dynamic interactions: such as drag and drop, resizing, hide and show, open and shut, switch views etc.
  7. 7. widgets and components: such as modals, in-page tabs, date pickers, page loaders, sliders etc.
  8. 8. However, many of dynamic interactions and widgets are problematic for Assistive Technologies.
  9. 9. Assistive Technologies may not be aware of content that has been updated after the initial page has loaded.
  10. 10. Many widgets are not accessible for keyboard-only users.
  11. 11. ARIA to the rescue!
  12. 12. WAI: Web Accessibility Initiative ARIA: Accessible Rich Internet Applications
  13. 13. WAI-ARIA allows us to use HTML attributes to define the role, states and properties of specific HTML elements.
  14. 14. what is it? Is it a widget (menu, slider, progress bar etc.) or an important type of element (heading, region, table, form etc.) role
  15. 15. what is the current state of the widget? Is it checked, disabled etc. state
  16. 16. what are the properties of the widget? Does it have live regions, does it have relationships with other elements, etc? properties
  17. 17. ARIA also provides keyboard navigation methods for the web objects and events. keyboard navigation
  18. 18. An ARIA process?
  19. 19. Things to avoid
  20. 20. Don’t use ARIA unless you really need to.
  21. 21. “If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.” Steve Faulkner: http://www.paciellogroup.com/blog/2014/10/aria-in-html-there-goes-the- neighborhood/
  22. 22. Where possible, use correct semantic HTML elements. Don’t use ARIA as a quick-fix.
  23. 23. <!-­‐-­‐  avoid  this  if  possible  -­‐-­‐>   <span  role="button">...</span>   <!-­‐-­‐  this  is  preferred  -­‐-­‐>   <button  type="button">...</button>
  24. 24. If you must use aria
  25. 25. 1. Alert users to the widget or elements role (button, checkbox etc).
  26. 26. 2. Alert users to the properties and relationships of the element (disabled, required, other labels etc).
  27. 27. 3. Alert users to the original state of the element (checked, unchecked etc).
  28. 28. 4. Alert users to changes in state of the element (now checked etc)
  29. 29. 5. Make sure widgets are keyboard accessible (including predictable focus).
  30. 30. What is aria-live?
  31. 31. Let’s look at a simple scenario…
  32. 32. In a web application, you want a simple notification to appear at the top of the page when a user completes a task.
  33. 33. Well done! Your changes have been saved
  34. 34. This dynamically inserted notification can cause two problems for screen readers.
  35. 35. Screen readers “buffer” pages as they are loaded. Any content that is added after this time many not be picked up by the screen reader. problem 1:
  36. 36. Screen readers can only focus on one part of the page at a time. If something changes on another area of the page, screen readers may not pick this up. problem 2:
  37. 37. The aria-live attribute allows us to notify screen readers when content is updated in specific areas of a page.
  38. 38. How is aria-live applied?
  39. 39. We can apply the aria-live attribute to any HTML element.
  40. 40. <div  aria-­‐live="polite">       </div>
  41. 41. If we then use JavaScript to inject/hide/show content within this element screen readers will be made aware of any DOM changes within that element.
  42. 42. <div  aria-­‐live="polite">     <!-­‐-­‐  Dynamic  content  -­‐-­‐>       </div>
  43. 43. There are three possible values for aria-live:
  44. 44. off
  45. 45. <div  aria-­‐live="off">   </div>
  46. 46. Assistive technologies should not announce updates unless the assistive technology is currently focused on that region. aria-live=“off”
  47. 47. Can be used for information that is not critical for users to know about immediately. aria-live=“off”
  48. 48. polite
  49. 49. <div  aria-­‐live="polite">   </div>
  50. 50. Assistive technologies should announce updates at the next graceful opportunity (eg end of current sentence). aria-live=“polite”
  51. 51. Can be used for warning notifications that users may need to know. aria-live=“polite”
  52. 52. assertive
  53. 53. <div  aria-­‐live="assertive">   </div>
  54. 54. Assistive technologies should announce updates immediately. aria-live=“assertive”
  55. 55. Should only be used if the interruption is imperative for users to know immediately such as error alerts. aria-live=“assertive”
  56. 56. Where can we use aria-live?
  57. 57. The aria-live attribute can be used for any page regions that are likely to get updates after the initial page is loaded.
  58. 58. Success alerts! Your changes are saved Info alerts! Some info to be aware of Warning alerts! Something has changed Error alerts! Fix the error and try again Alert messages
  59. 59. Dynamic stock info
  60. 60. Dynamic RSS feeds
  61. 61. Date pickers
  62. 62. Sortable tables
  63. 63. Avoid misuse
  64. 64. The aria-live attribute should not be used for dynamic content that is non-critical, or just adds additional “noise” for assistive technologies
  65. 65. Testing aria-live
  66. 66. Working on a recent project with James (Brothercake) Edwards, we needed to test how aria-live performed across different screen readers.
  67. 67. We built different pages for “off”, “polite” and “assertive”. Each page had a message that would automatically be triggered 10 seconds after page load.
  68. 68. This automatic trigger was important as we wanted to observe screen reader behaviour when in the middle of announcing content on a different area of the page.
  69. 69. three tests
  70. 70. Is the newly inserted message announced immediately when triggered - while screen reader is silent? Test 1:
  71. 71. Is the newly inserted message announced immediately when triggered - while screen reader is currently announcing other content? Test 2:
  72. 72. Is the newly inserted message announced when navigated to? Test 3:
  73. 73. browsers / screen readers
  74. 74. IE 11 NVDA 2014.4 and JAWS 16 Chrome 39 NVDA 2014.4 and JAWS 16 Firefox 34 NVDA 2014.4 and JAWS 16 Windows
  75. 75. Chrome 39 VoiceOver Firefox 34 VoiceOver Safari 7 VoiceOver OSX
  76. 76. Results
  77. 77. “off” results
  78. 78. Newly inserted message should not be announced when screen reader is silent. “off” page - test 1
  79. 79. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 1 results
  80. 80. Newly inserted message should not be announced when screen reader is currently announcing other content. “off” page - test 2
  81. 81. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 2 results
  82. 82. Newly inserted message should be announced when navigated to by screen reader. “off” page - test 3
  83. 83. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 3 results
  84. 84. Chrome/NVDA did not announce the message when navigated to. issues
  85. 85. “polite” results
  86. 86. Newly inserted message should be announced when the screen reader is silent. “polite” page - test 1
  87. 87. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 1 results
  88. 88. Chrome/NVDA Chrome/JAWS Firefox/Voiceover did not announce the message when the screen reader was silent. issues
  89. 89. Newly inserted message should not be announced when screen reader is currently announcing other content, but should be announced at the next available pause. “polite” page - test 2
  90. 90. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 2 results
  91. 91. Chrome/NVDA Chrome/JAWS Firefox/Voiceover did not announce the message at the next available pause. issues
  92. 92. Newly inserted message should be announced when navigated to by screen reader. “polite” page - test 3
  93. 93. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 3 results
  94. 94. Chrome/JAWS did not announce the message when navigated to. issues
  95. 95. “assertive” results
  96. 96. Newly inserted message should be announced when screen reader is silent. “assertive” page - test 1
  97. 97. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 1 results
  98. 98. Chrome/NVDA Chrome/JAWS Firefox/Voiceover did not announce the message when the screen reader was silent. issues
  99. 99. Newly inserted message should be announced when screen reader is currently announcing other content. “assertive” page - test 2
  100. 100. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 2 results
  101. 101. IE11/NVDA IE11/JAWS Firefox/NVDA Firefox/JAWS did not announce the message immediately as the message was triggered. They all waited until there was a pause. issue 1
  102. 102. Chrome/NVDA Chrome/JAWS Firefox/Voiceover did not announce the message immediately as the message was triggered or after a pause. issue 2
  103. 103. Newly inserted message should be announced when navigated to by screen reader. “assertive” page - test 3
  104. 104. BROWSER IE 11 (Win) Chrome 39 (Win) Firefox 34 (Win) Chrome 39 (OSX) Firefox 34 (OSX) Safari 7 (OSX) NVDA JAWS VOICE test 3 results
  105. 105. Chrome/JAWS did not announce the message when navigated to. issues
  106. 106. Take-aways
  107. 107. Rather depressingly, aria-live has some support issues.
  108. 108. Currently, “polite” is slightly better supported than “assertive” so it is the preferred option.
  109. 109. <div  aria-­‐live="polite">   </div>
  110. 110. Other attributes
  111. 111. There are also a range of other attributes that can be used associated with live regions, (though their support is sometimes patchy).
  112. 112. aria-atomic
  113. 113. <!-­‐-­‐  true  attribute  -­‐-­‐>   <div     aria-­‐live="off"       aria-­‐atomic="true">   </div>
  114. 114. <!-­‐-­‐  false  attribute  -­‐-­‐>   <div     aria-­‐live="off"       aria-­‐atomic="false">   </div>
  115. 115. Indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria- relevant attribute. aria-atomic
  116. 116. true: Present the region as a whole when changes are detected. false: Present only the changed regions. (default) aria-atomic
  117. 117. aria-relevant
  118. 118. <!-­‐-­‐  all  attribute  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐relevant="all">   </div>  
  119. 119. <!-­‐-­‐  additions  attribute  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐relevant="additions">   </div>  
  120. 120. <!-­‐-­‐  removals  attribute  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐relevant="removals">   </div>
  121. 121. <!-­‐-­‐  text  attribute  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐relevant="text">   </div>  
  122. 122. <!-­‐-­‐  all  attribute  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐relevant="all">   </div>  
  123. 123. <!-­‐-­‐  multiple  attributes  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐relevant="text,  removals">   </div>  
  124. 124. Describe semantically meaningful changes, as opposed to merely presentational ones. aria-relevant
  125. 125. aria-relevant values of “removals” or “all” should be used sparingly. Assistive technologies only need to be informed of important change. aria-relevant
  126. 126. aria-busy
  127. 127. <!-­‐-­‐  true  attribute  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐busy="true">   </div>
  128. 128. <!-­‐-­‐  false  attribute  -­‐-­‐>   <div       aria-­‐live="off"       aria-­‐busy="false">   </div>
  129. 129. Indicates whether an element, and its subtree, are currently being updated. aria-busy
  130. 130. If multiple parts of the same element need to be loaded or modified, they can set aria-busy to “true” during initial load, and then “false” when the last part is loaded. aria-busy
  131. 131. role=alert
  132. 132. <div  role="alert">   </div>
  133. 133. Used to define a message with important, and usually time- sensitive, information. role=alert
  134. 134. The alert role goes on the node containing the alert message. role=alert
  135. 135. Elements with the role=“alert” have an implicit aria-live value of “assertive”, and an implicit aria-atomic value of “true”. role=alert
  136. 136. role=alertdialog
  137. 137. <div  role="alertdialog">   </div>
  138. 138. A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. role=alertdialog
  139. 139. The “alertdialog” role goes on the node containing both the alert message and the rest of the dialog. role=alertdialog
  140. 140. Unlike alert, “alertdialog” can receive a response from the user - such as a “Confirm” or “Save” button. role=alertdialog
  141. 141. Conclusion
  142. 142. The aria-live attribute is a very powerful and effective method of keeping screen readers informed about changes the page.
  143. 143. As with any aria- attributes, you should test heavy before using and use with care!
  144. 144. http://maxdesign.com.au/jobs/ sample-accessibility/10- notifications/index.html Our test results:
  145. 145. @brothercake @russmaxdesign

×