Download as PDF, PPTX
![“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/](https://image.slidesharecdn.com/2016-05-19-id24-v2-160519065306/85/Building-Accessible-Web-Components-22-320.jpg)
Uploaded byRuss Weakley
Building Accessible Web Components
This document discusses best practices for making web components more accessible, particularly focusing on the proper use of ARIA attributes to avoid redundancy and verbosity. It outlines various methods for providing additional context for assistive technologies (AT) users, informing them effectively without overwhelming them with information. Additionally, it addresses challenges with dynamic content, error messages in forms, and modal usability, proposing solutions to enhance accessibility for all users.
More Related Content
Similar to Building Accessible Web Components
Building Accessible Web Components
- 1.
- 2. Who the hell is this guy?
- 3.
- 4. Designing & developing UI Patternlibraries for applications Working with developers to build accessible applications Passions:
- 5. This talk? Somethings you can do to make applications more accessible.
- 6.
- 7. Over the lastfew years there has been a growing trend to include ARIA attributes in all sorts of areas in applications.
- 8. Unfortunately, ARIA attributes canbe misused, and this can lead to all sorts of problems for AT users.
- 9.
- 10. This is whereARIA is used to provide additional context for assistive technologies, but the native elements already have accessibility APIs available.
- 11. <label for="a" aria-‐label="Add your email"> Add your email </label> <input type="text" name="a" id="a">
- 12. <button type="submit" role="button"> Submit </button>
- 13. This can leadto problems such as form controls being announced more than once.
- 14. Problem 2: Overlyverbose
- 15. This is whereARIA attributes and additional hidden information is used extensively across an application.
- 16. This can sometimeslead to excessive amounts of information being presented to AT users.
- 17.
- 18. This is wheredevelopers have copied and pasted components, often from existing pattern libraries, without understanding how the ARIA attributes work.
- 19. This can leadto problems such as aria-labels pointing to non- existent ID attributes, so the ARIA does not work.
- 20.
- 21. The simplest guidelineis not to use ARIA unless you really need to.
- 22. “If you canuse 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/
- 23. Where possible, test applicationsyourself using a variety of ATs.
- 24. This should includeall major screen readers in different browsers. And don’t forget to test with keyboard only!
- 25. If possible, workwith a range of real AT users and get their input/feedback. Make sure your audience selection includes different levels of skill.
- 26.
- 27.
- 28. There may betimes when you want to provide additional information to a link or a button to provide extra context for screen reader users.
- 29.
- 30. This “Purchase” linkmay be acceptable for sighted users who can see the link in context and do not require additional information.
- 31. However, screen readerusers may navigate to this link and hear the word “Purchase” without any additional context.
- 32. For these usersonly, we could provide additional information to the link:
- 33. “Purchase Don Quixoteby Miguel De Cervantes”
- 34. Similarly, there maybe times when you want to provide additional information on a button.
- 35.
- 36. “Close and returnto Account details”
- 37. Solutions for adding contextto links
- 38. There are arange of different methods we could use, such as:
- 39. <a href="#" title="Purchase Don Quixote by Miguel De Cervantes"> Purchase </a>
- 40.
- 41. <a href="#" aria-‐label="Purchase Don Quixote by Miguel De Cervantes"> Purchase </a>
- 42.
- 43. <a href="#" aria-‐labelledby="info1"> Purchase </a> <p id="info1" class="hidden"> Don Quixote by Miguel De Cervantes </p>
- 44.
- 45. <a href="#" aria-‐describedby="info1"> Purchase </a> <p id="info1" class="hidden"> Purchase Don Quixote by Miguel De Cervantes </p>
- 46.
- 47. <a href="#"> Purchase <span class="hidden">Purchase Don Quixote by Miguel De Cervantes</span> </a>
- 48.
- 49. The most robustsolution involves using hidden content.
- 50. More information at“Adding information to links”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/05-adding- to-links.html
- 51. Solutions for adding contextto buttons
- 52. There are arange of different methods we could use, such as:
- 53. <button title="and return to Account details"> Close </button>
- 54.
- 55. <button aria-‐label="Close and return to Account details"> Close </button>
- 56.
- 57. <a href="#" aria-‐labelledby="info1"> Close </a> <p id="info1" class="hidden"> and return to Account details </p>
- 58.
- 59. <button aria-‐describedby="info1"> Close </button> <p id="info1" class="hidden"> and return to Account details </p>
- 60.
- 61. <button> Close <span class="hidden"> and return to Account details</span> </button>
- 62.
- 63. The most stablechoices are using aria-label or hidden content.
- 64. More information at“Adding information to buttons”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/06-adding- to-buttons.html
- 65.
- 66. Providing additional contentto screen readers should be used with care.
- 67. If too muchadditional information is provided, it can make web pages or web applications too verbose and hard to use.
- 68.
- 69.
- 70. There may betimes when you want to provide different content for screen readers to the content that is displayed on- screen - for links and buttons.
- 71.
- 72. For example, “AED”may be acceptable for sighted users but may not make sense for screen reader users - especially when out of context.
- 73. In certain situation,you may want to announce different information to screen reader users.
- 74. “United Arab EmiratesDirham $10,640.00”
- 75. Similarly, there maybe times when you want to provide different content for screen readers for buttons.
- 76.
- 77. “Close and returnto Account details”
- 78. A solution for differentcontent for links
- 79. <a href="#"> <span aria-‐hidden="true"> AED </span> <span class="sr-‐only"> United Arab Emirates Dirham </span> </a>
- 80.
- 81. More information at“Display A, announce B - link content”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/03-different- content-link.html
- 82. A solution for differentcontent for buttons
- 83. <button type="button" aria-‐label="Close and return to account details"> x </button>
- 84.
- 85. More information at“Display A, announce B - button content”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/04-different- content-button.html
- 86.
- 87. Providing different contentto screen readers should be used with care.
- 88. In some situations,providing different information could potentially confuse Assistive Technology users.
- 89.
- 90.
- 91. Well done! Yourchanges have been saved
- 92. Adding content afterthe initial page has loaded can cause potential issues for screen readers.
- 93. Problem 1: 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.
- 94. Problem 2: Screen readerscan 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.
- 95.
- 96. The aria-live attributeallows us to notify screen readers when content is updated in specific areas of a page.
- 97. We can applythe aria-live attribute to any HTML element.
- 98.
- 99. If we thenuse JavaScript to inject/hide/show content within this element, screen readers will be made aware of any DOM changes within that element.
- 100. The aria-live attributecan be used for any page regions that are likely to get updates after the initial page is loaded.
- 101. Success alerts! Yourchanges are saved Info alerts! Some info to be aware of Warning alerts! Something has changed Error alerts! Fix the error and try again
- 104.
- 105. There are threepossible values for aria-live: “off”, “polite” and “assertive”.
- 106.
- 107. Assistive Technologies should notannounce updates unless the assistive technology is currently focused on that region.
- 108. Should be usedfor information that is not critical for users to know about immediately.
- 109.
- 110. Assistive Technologies should announceupdates at the next graceful opportunity (e.g. end of current sentence).
- 111. Should be usedfor warning notifications that users may need to know.
- 112.
- 113. Assistive Technologies should announceupdates immediately.
- 114. Should only beused if the interruption is imperative for users to know immediately such as error alerts.
- 115. Unfortunately, aria- live=“assertive” isnot well supported at this point, so the “polite” value may be preferred. http://maxdesign.com.au/jobs/sample-accessibility/10-notifications/ index.html
- 116.
- 117. aria-relevant This attribute givesa hint about what types of changes are relevant and should be announced by Assistive Technologies.
- 118. <!-‐-‐ Insertion of nodes into the live region should be considered relevant -‐-‐> <div aria-‐relevant="additions"> </div>
- 119. <!-‐-‐ Deletion of nodes should be considered relevant -‐-‐> <div aria-‐relevant="removals"> </div>
- 120. <!-‐-‐ Changes to the textual content of existing nodes should be considered relevant -‐-‐> <div aria-‐relevant="text"> </div>
- 121. <!-‐-‐ All changed nodes should be considered relevant -‐-‐> <div aria-‐relevant="all"> </div>
- 122. The default behaviouris equivalent to “additions text”.
- 123. aria-relevant values of “removals”or “all” should be used sparingly.
- 124.
- 125. role=“alert” Defines a messagewith important information.
- 126.
- 127. Elements with therole=“alert” have an implicit aria-live value of “assertive”.
- 128.
- 129. We’re going tolook at two different aspects of client-side form validation.
- 130. 1. Form controlvalidation Individual form fields are validated as the user moves focus out of the form control.
- 131. 2. On-submit formvalidation The entire form is validated as the user submits the form - before the script sends the form to the server.
- 132.
- 133. Problem 1: Form ControlError messages only appears after a control has lost focus. For this reason, it is not immediately presented to screen reader users.
- 134. Screen reader usersoften have to travel back through the form to try and find invalid form controls. If invalid form controls are not effectively flagged, users may not be able to find them.
- 135. Problem 2: Screen readerusers are often not informed that the overall form contains errors.
- 136. In the worstcases, focus remains on the form submit button, even after the form has been found to be invalid, and screen reader users have no idea why the form won’t submit.
- 137. A solution for form control validation
- 138. 1. When aform control is defined as invalid, the control and associated label should be “flagged” so that users can be made aware that there is an error.
- 139. 2. Flagging formcontrols and associated labels should not use colour alone to signify errors.
- 140. 3. An errormessage should be displayed in close proximity to the relevant form control.
- 141. Error: The phonenumber must include a 10 digit number Phone
- 142. 4. The errormessage should be informative - it should provide information that will help users fill in the field correctly.
- 143. 5. The errormessage should be programmatically associated with the form control.
- 144. This means thatthe error message should be announced along with the relevant label information.
- 145. There are arange of different methods to programmatically associate error messages with form controls.
- 146. The simplest isto place the error message content inside the label.
- 147. <div> <label for="email"> Email <input type="email" id="email"> <span class="error">Error</span> </label> </div>
- 148. A solution for on-submit formvalidation
- 149. If there areone or more form validation errors:
- 150. 1. An errormessage should appear at the top of the form alerting users that there are errors.
- 151. 2. Focus mustbe taken to the error message as soon as the user has attempted to submit for form.
- 152. 3. The errormessage should list all errors.
- 153. 4. Each errorshould ideally be a link that takes the user to the relevant form control.
- 154. The form hastwo errors that must be completed before it can be submitted. 1. Error: You must include your first name 2. Error: Email address must include an "@" symbol
- 155. Optionally, error messagescan be placed inside a hide/show function that allows users to choose whether they see the list of errors or not.
- 156. The form hastwo errors that must be completed before it can be submitted. View all errors
- 157.
- 158. The error messagecontainer can exist on the page, even when non-active. However, it should not contain any content until triggered.
- 159. This container shouldbe set with role=“alert”. This is used to communicate important information.
- 160. <div class="error-‐message-‐container" role="alert"> </div>
- 161. Optionally, the aria-live attributecan added with a value of “assertive” or “polite”.
- 162. <div class="error-‐message-‐container" role="alert" aria-‐live="polite"> </div>
- 163. This container canbe set with tabindex value of “-1” so that it will not receive focus.
- 164. <div class="error-‐message-‐container" role="alert" aria-‐live="polite" tabindex="-‐1"> </div>
- 165. When the errormessage needs to be displayed (i.e. the user has attempted to submit the form with invalid form controls) some changes need to occur dynamically.
- 166. If present, thetabindex attribute value needs to be changed from “-1” to “0” so that the element will appear in normal tab order.
- 167. <div class="error-‐message-‐container" role="alert" aria-‐live="polite" tabindex="0"> </div>
- 168. The container canbe given a label so that it is announced to screen reader users.
- 169. <div class="error-‐message-‐container" role="alert" aria-‐live="polite" tabindex="0" aria-‐label="Form Errors"> </div>
- 170.
- 171.
- 172. Problem 1: Keyboard-only usersare often able to TAB outside of the modal window while the modal is still active. This can be very confusing and disconcerting.
- 173. Problem 2: Screen readerusers are sometimes not informed that an action will trigger a modal.
- 174. Problem 3: Screen readerusers are sometimes not made aware of the purpose of the modal or what actions they need to perform within the modal.
- 175. Problem 4: Screen readerusers are sometimes sent to the top of the parent page after a modal window has been closed. This can be confusing.
- 176.
- 177. When a modalis not in use, we need to hide it so that is not seen by sighted users or announced to Screen Readers.
- 178. <div style="display:none"> ... </div>
- 179. When a modalwindow is triggered, we need to change the value.
- 180. <div style="display:block"> ... </div>
- 181. When the modalwindow becomes active, all other content should be hidden from Assistive Technologies.
- 182. <!-‐-‐ all other content -‐-‐> <div aria-‐hidden="true"> ... </div> <!-‐-‐ modal window -‐-‐> <div style="display:block"> ... </div>
- 183. We need toset the initial focus to the modal window element itself rather than elements inside the modal.
- 184.
- 185.
- 186. This is importantbecause we are going to give the modal a label.
- 187. If we setfocus on an element inside the window, the label will not be announced to Assistive Technologies.
- 188. We need toinform screen reader users that this modal window is a “modal dialog”.
- 189. <div style="display:block" role="dialog"> ... </div>
- 190. We need toprovide a label for the modal dialog, so Assistive Technologies can announce its purpose.
- 191. <div style="display:block" role="dialog" aria-‐labelledby="modal-‐label"> <h1 id="modal-‐label">Choose account</h1> </div>
- 192. In some circumstances,we may need to provide a more detailed description of the purpose of the modal dialog.
- 193. <div style="display:block" role="dialog" aria-‐labelledby="modal-‐label" aria-‐describedby="modal-‐description"> <h1 id="modal-‐label">Choose account</h1> <p id="modal-‐description"> Description here </p> </div>
- 194.
- 195.
- 196.
- 197.
- 198.
- 199.
- 200.
- 201.
- 202.
- 203.
- 204.
- 205.
- 206.
- 207.
- 208.
- 209.
- 210.
- 211.
- 212.
- 213.
- 214.
- 215.
- 216. Option 1 -apples ARROW
- 217. Option 2 -pears ARROW
- 218. Option 3 -bananas ARROW
- 219.
- 220. Adding meaning to importantactions
- 221. For some importantactions inside the modal window, Assistive Technologies should be given additional information to let them know what will happen.
- 222. As screen readerusers are submitting form data, they should be informed that:
- 223. 1. They willbe taken back to the parent page.
- 224. 2. Where thisdata will be submitted when they return to the parent page.
- 225. ENTER “Submit and returnto bank balance information. Your data will be added to the Balance table”
- 226. As screen readerusers focus on the “Close” function, they should be informed that closing will take them back to the parent page.
- 227. ENTER “Leave form andreturn to bank balance information”
- 228.
- 229. When the modalwindow is closed, if users are being taken back to the parent page:
- 230. 1. Focus shouldbe placed on the relevant component of the parent page. The most common practice is to move focus back to the element that invoked the dialog.
- 231. The user shouldnot be thrown back to the top of the parent page unless there is a good reason!
- 232. 2. The usershould be informed where they are and what change has occurred.
- 233.
- 234. Lorem ipsum dolorsit amet consect etuer adipi scing elit sed diam nonummy nibh euismod tinunt ut laoreet dolore magna aliquam erat volut. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip vel eum iriure dolor in hendrerit in vulputate. Accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat. Heading here Another thing here Add your bank balance Another heading $1,200.34 Focus “Bank balance $1200.34 added to bank information table”
- 235. PART 7 Where tostart?
- 236. When is thebest time to focus on accessibility?
- 237. The best timeto focus on accessibility is right at the beginning of development process, when creating the individual components in your pattern library.
- 238. Quick steps youcan do yourself
- 239. Don’t be overwhelmed.Look for quick wins. You’ll be surprised what you can do without too much effort.
- 240. Test with keyboard-only andmake changes as needed. (Make sure you also check for visible focus). 1
- 241. /* avoid this! */ :focus { outline: none; }
- 242. Test with accessibility checkingtools and make changes as needed.2
- 243. Tenon https://tenon.io/ Web Accessibility Toolbar https://www.paciellogroup.com/resources/wat/ AccessibilityViewer https://www.paciellogroup.com/resources/aviewer Colour Contrast Analyser https://www.paciellogroup.com/resources/contrastanalyser/
- 244. Accessibility Evaluation Toolbar1.5.7.1.1 https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation- toolb/ WAVE http://wave.webaim.org/ Total Validator http://www.totalvalidator.com/ CynthisSays http://www.cynthiasays.com/
- 245. Test with oneor more screen readers and make changes as needed.3
- 246.
- 247. Get expert assistanceand conduct a formal accessibility audit of your website or web application and action as needed. 4
- 248. Russ Weakley Max Design Site:maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley
- 249.
- 250.
- 251. Some developers useCSS button classes that allow them to make any element appear like a button, even if it is a link.
- 252. This is alink This is a button
- 253. <a class="btn btn-‐default" href="#" role="button"> Button using a link </a> <button class="btn btn-‐default" type="button"> Button using a button </button>
- 254. The problem withthis is that it can lead to some confusion about when to use a link or a button.
- 255. When the incorrectelement is used, this can confuse Assistive Technology users who expect links and buttons to behave in specific ways.
- 256.
- 257. Use a linkwhen you want to send the user to a new location - like a different page.
- 258. Use a buttonwhen you want the user to perform some sort of action - like click a button, submit a form, open an accordion.