How does your website sound like? [DevFestSiberia2020]

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.

In this talk I would love to show the tools we can use to create more accessible web applications, some good practices when we code a new web application and how to test and audit it in the browser thanks to the integrated developer tools.

Collection of examples: https://codepen.io/collection/XJNepY/
Video of the talk: https://www.youtube.com/watch?v=yKYA-7tczuk

---

My name is Adrián Bolonio. I’m an Engineering Team Lead, Frontend Developer, and Web Accessibility (a11y) advocate. I'm from Spain, but since 2012 I've been living and working in Vienna (Austria). When I’m not at the office I enjoy a good read, working my way through any delicious recipe, and indulging my love for traveling to new places.

You can find my speaker experience in https://www.adrianbolonio.com/talks

You can find me in:
Web: http://adrianbolonio.com/
Twitter: https://twitter.com/bolonio
GitHub: https://github.com/bolonio
Linkedin: https://www.linkedin.com/in/adrianbolonio/

Transcript

1. How does your website “sound” like? How web accessibility can make impaired people use your website @bolonio Adrián Bolonio
2. How does your website “sound” like? How web accessibility can make impaired people use your website @bolonio Adrián Bolonio
3. Madrid (Spain) Adrián Bolonio Engineering Team Lead & Frontend Developer @bolonio #a11y Advocate
4. Accessibility (a11y)
5. Accessibility (a11y) 11 a y
6. Accessibility (a11y) ccessibilit 11 10 9 8 7 6 5 4 3 2 1 a y
7. Accessibility (a11y)
8. Accessibility (a11y)
9. Web Accessibility (a11y)
10. Web Accessibility (a11y) The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services. Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.
11. 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.
12. 2018 7.6 billion 1+ billion people live with some form of vision impairment Source: World Health Organisation (October 2018) Web Accessibility (a11y)
13. Developing Web Accessibility How does you website “sound” like?
14. 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
15. 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.
16. Language Demo
17. 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="").
18. 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
19. ARIA Accessible Rich Internet Applications
20. 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)
21. 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/
22. 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:
23. 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.
24. 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'.
25. 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.
26. 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
27. Aria-* attributes
28. Aria roles
29. 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=“” />
30. <… aria-label=“” /> Demo
31. <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/
32. <button /> Demo
33. 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
34. Javascript
35. Javascript 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.
36. aria live regions Demo
37. 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.
38. https://codepen.io/collection/XJNepY/
39. Testing Web Accessibility How to find accessibility vulnerabilities in your website
40. Testing Web Accessibility https://www.youtube.com/watch?v=1eDCdL-3uI0
41. 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
42. https://www.speakerdeck.com/bolonio
43. https://www.adrianbolonio.com
44. https://www.edx.org/course/web-accessibility-introduction Introduction to Web Accessibility
45. “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
46. Accessibility is NOT a feature
47. Thanks @bolonio Adrián Bolonio
48. Thanks @bolonio Adrián Bolonio