Accessibility in Web Development

When we develop a new web application, we often put a lot of work on the design, on making it beautiful and usable. In other words, we want our web app to be effective, efficient, and satisfying for the user. But a lot of times we don’t think about the user experience for people with disabilities, including people with age-related impairments.

Web accessibility (a11y ) means that people with disabilities can perceive, understand, navigate, and interact with websites and tools, and that they can contribute equally without barriers.” (Source: W3C - Web Accessibility Initiative). Our role as frontend and web developers is to create clear interfaces to make people understand and care about data, independently of their disabilities or impairments, but what we, developers, often forget is to ensure that the code we write follows the Web Content Accessibility Guidelines (WCAG), and the only way to achieve that is testing, either manual or automated.

Automated web a11y tests can free up our QA team from manual testing every part of our application…but…they can’t automatically, and magically, make our site accessible. We should use automated a11y tests as one step of a larger testing process. Don’t forget that only 20% to 50% of all accessibility issues can automatically be detected.

Collection of examples: https://codepen.io/collection/XJNepY/
The example code is hosted here: https://github.com/bolonio/testing-web-a11y
---
Adrián Bolonio
https://www.adrianbolonio.com
https://twitter.com/bolonio
https://www.linkedin.com/in/adrianbolonio

Transcript

1. Accessibility in Web Development How web accessibility can make impaired people use your website @bolonio Adrián Bolonio
2. Madrid (Spain) Adrián Bolonio Web Team Lead & Frontend Developer @bolonio #a11y Advocate
3. Accessibility (a11y)
4. Accessibility (a11y) accessibility 11 10 9 8 7 6 5 4 3 2 1 a11y
5. Accessibility (a11y)
6. Accessibility (a11y)
7. Web Accessibility (a11y)
8. Web Accessibility (a11y) You need to click on the button in the top right corner. You need to click on the button with the engine icon.
9. 2018 7.6 billion 1+ billion people live with some form of vision impairment Source: World Health Organisation (October 2018) Web Accessibility (a11y)
10. Developing Web Accessibility How does you website “sound” like?
11. Screen readers are software programs that allow blind or visually impaired users to read the text that is displayed on the computer screen with a speech synthesizer. Voice Over Narrator Orca Screen Readers
12. Defining the correct natural language in an HTML page is very important, because it helps assistive technology (screen readers) to choose the correct voice profile or character set. Language Always use a language attribute on the html element. This is inherited by all other elements, and so will set a default language for the text in the document head element. Note that you should use the html element rather than the body element, since the body element doesn't cover the text inside the document's head element. Demo
13. Image alt Every image must have an alt attribute. This is a requirement of HTML standard (with perhaps a few exceptions in HTML5). Images without an alt attribute are likely inaccessible. In some cases, images may be given an empty or null alt attribute (e.g., alt="").
14. The intent of the tab order is to ensure that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard (tab key). This reduces confusion by letting users form a consistent mental model of the content. Tab Order Demo
15. ARIA Accessible Rich Internet Applications
16. Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make Web content and Web applications (especially those developed with JavaScript) more accessible to people with disabilities. ARIA enables developers to describe their widgets in more detail by adding special attributes to the markup. • ARIA attributes don’t affect anything in the webpage. • Use the correct semantic HTML elements, don’t use it as fixer. • Use aria-* attributes, but test them before using them. Aria (Accessible Rich Internet Applications)
17. Aria Rule #1 Don’t use ARIA, use native HTML instead If you can use a native HTML element 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. If you need a button, use the <button> element. Buttons are: Focusable, Clickable (with mouse and keys), and Screen readers identify them as buttons Source: https://www.w3.org/TR/using-aria/
18. Aria Rule #2 Do not change native semantics, unless you really have to. Source: https://www.w3.org/TR/using-aria/ Most of the HTML elements or attributes convey one or other semantics. We are not supposed to change the native semantics unless it is really essential. An example of this would be if a developer wants to build a heading that is a tab:
19. Aria Rule #3 All interactive ARIA controls must be usable with the keyboard. Source: https://www.w3.org/TR/using-aria/ If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard. All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable. For example, if creating the custom control with role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter and the space key.
20. Aria Rule #4 Do not use role="presentation" or aria- hidden="true" on a focusable element . Source: https://www.w3.org/TR/using-aria/ Using either of these on a focusable element will result in some users focusing on 'nothing'.
21. Aria Rule #5 All interactive elements must have an accessible name. Source: https://www.w3.org/TR/using-aria/ An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value.
22. Don’t use ARIA, use native HTML instead Do not change native semantics, unless you really have to. All interactive ARIA controls must be usable with the keyboard. Do not use role="presentation" or aria-hidden="true" on a focusable element . All interactive elements must have an accessible name. Aria Rules #1 #2 #3 #4 #5
23. Aria-* attributes
24. Aria roles
25. The purpose of this technique is to provide a label for objects that can be read by assistive technology. The aria-label attribute provides the text label for an object, such as a button. When a screen reader encounters the object, the aria-label text is read so that the user will know what it is. <… aria-label=“” /> Demo
26. <button /> Aria Rule #1 - Don’t use ARIA, use native HTML instead If you can use a native HTML element 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. If you need a button, use the <button> element. Buttons are: Focusable, Clickable (with mouse and keys), and Screen readers identify them as buttons Source: https://www.w3.org/TR/using-aria/ Demo
27. It provides visual feedback for links that have "focus" when navigating a web document using the TAB key (or equivalent). This is especially useful for users who can't use a mouse or have a visual impairment. If you remove the outline you are making your site inaccessible for these people. DO NOT DO IT Unless you provide custom styles :focus & :focus-visible Demo
28. Javascript
29. Javascript Demo Usually, screen readers only announce content when an element is focused or the user uses the screen reader’s own navigation commands. Screen reader users must be informed when content changes dynamically, this is done with ARIA Live Regions.
30. Define the correct natural language in an HTML page. Every <img /> must have an alt= attribute, but it needs to be relevant. The tab order of your website must be consistent with the meaning of the content. ARIA - Accessible Rich Internet Applications Use the native HTML elements or attributes, try not to use ARIA. When using aria-* attributes, test it before using them. Use a <button> element if you need a button. Do not delete the focus outline, unless you provide custom styles. Screen reader users must be informed when content changes dynamically, with ARIA Live Regions.
31. https://codepen.io/collection/XJNepY/
32. Developing Web Accessibility https://www.youtube.com/watch?v=yKYA-7tczuk
33. Testing Web Accessibility How to find accessibility vulnerabilities in your website
34. Testing Web Accessibility Source: https://www.smashingmagazine.com/2018/09/importance-manual-accessibility-testing/ Automated a11y tests can free up your QA team from manual testing every part of your application…but…they can’t automatically make your site accessible. Use automated a11y tests as one step of a larger testing process. Don’t forget that only 20% to 50% of all accessibility issues can automatically be detected
35. I’ve created a simple application with 3 tiny components and a bunch of errors in the HTML
36. I’ve created a simple application with 3 tiny components and a bunch of errors in the HTML
37. Testing the code react-axe https://github.com/dequelabs/react-axe eslint-plugin-jsx-a11y https://github.com/evcohen/eslint-plugin-jsx-a11y jest-axe https://github.com/nickcolley/jest-axe
38. react-axe Install it as a dev dependency Call the exported function passing in the React and ReactDOM objects as well as a timing delay in milliseconds that will be observed between each component change and the time A severity level is also assigned for each violation. The possible levels are: • Minor • Moderate • Serious • Critical Results will show in the Chrome DevTools console.
39. eslint-plugin-jsx-a11y Configure the rules you want to use under the rules section in the .eslintrc.json file The linting issues will be displayed directly in the code editor
40. eslint-plugin-jsx-a11y Configure the rules you want to use under the rules section in the .eslintrc.json file The linting issues will be displayed directly in the code editor The linting issues will be displayed in the terminal as well
41. jest-axe Install it as a dev dependency The results of the test will be displayed in the terminal Write an accessibility test using ReactDOMServer to render the html of your application and check for violations
42. Testing the DOM axe-cli https://github.com/dequelabs/axe-cli pa11y http://pa11y.org/ Lighthouse https://developers.google.com/web/tools/lighthouse/
43. axe-cli Install axe-cli globally You can now run the axe command in your CLI, followed by the URL of the page you wish to test
44. pa11y Install pa11y globally You can now run the pa11y command in your CLI, followed by the URL of the page you wish to test
45. pa11y Install pa11y globally You can now run the pa11y command in your CLI, followed by the URL of the page you wish to test You can run the pa11y command in your CLI for localhost as well
46. pa11y-ci By default, Pa11y CI looks for a config file (.json) in the current working directory. Each URL in your config file can be an object and specify pa11y configurations which override the defaults too. Install pa11y-ci globally
47. pa11y-ci By default, Pa11y CI looks for a config file (.json) in the current working directory. Each URL in your config file can be an object and specify pa11y configurations which override the defaults too. Install pa11y-ci globally
48. Lighthouse Install lighthouse globally You can now run the lightouse command in the terminal ( with --view) and it will immediately open the generated html report.
49. Testing the DOM axe-cli Direct link from terminal to documentation at dequeuniversity Main feature pa11y pa11y-ci allows to include several urls with different config options that allows you to perform actions in the website Lighthouse At the end of the analysis, the tools will generate a final report, either HTML or JSON/CSV the can be use for reporting purposes
50. Testing in the browser axe chrome extension https://www.deque.com/axe/ ARC Toolkit https://www.paciellogroup.com/toolkit/ Accessibility Insights WAVE https://wave.webaim.org/ NoCoffee https://accessibilityinsights.io/ https://accessgarage.wordpress.com/
51. axe chrome extension https://www.deque.com/axe/
52. ARC Toolkit https://www.paciellogroup.com/toolkit/
53. Accessibility Insights https://accessibilityinsights.io/
54. WAVE (web accessibility evaluation tool) https://wave.webaim.org/
55. NoCoffee - Vision Simulator https://accessgarage.wordpress.com/
56. react-axe eslint-plugin-jsx-a11y jest-axe axe-cli pa11y Lighthouse axe ARC Toolkit NoCoffee Testing the code Testing the DOM Testing in the browser WAVE Accessibility Insights
57. https://github.com/bolonio/testing-web-a11y
58. Testing Web Accessibility https://www.youtube.com/watch?v=GyXkH5ZmSfk
59. https://speakerdeck.com/bolonio
60. https://www.adrianbolonio.com/
61. https://www.edx.org/course/web-accessibility-introduction Introduction to Web Accessibility
62. “It’s not just about disabled users being able to access your website, it’s about everyone being able to access your website.” Trenton Moss, Owner of Webcredible Consultancy Firm, UK
63. Accessibility is NOT a feature
64. Thanks @bolonio Adrián Bolonio