Rapid Introduction to Web Accessibility
•Télécharger en tant que PPTX, PDF•
0 j'aime•83 vues
Presented by: Michael Head, Slalom, Inc Presented at All Things Open 2020 Abstract: Web accessibility is a growing topic of interest among many practitioners in software development, from designers to product managers to developers. If you're not familiar with the topic it can be overwhelming at first. This talk serves as a crash course into web accessibility to help people get a grasp on the topic overall and figure out where they can go to learn more. It's useful for designers, developers, product managers, or anyone else involved in product development. Come learn about why accessibility is important, what all those acronyms mean (WCAG, ATAG, WAI-ARIA, oh my!), and about some of the tools of the trade.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Rapid Introduction to Web Accessibility
Similaire à Rapid Introduction to Web Accessibility (20)
Plus de All Things Open
Plus de All Things Open (20)
Dernier
Dernier (20)
Rapid Introduction to Web Accessibility
- 1. Rapid Introduction to Web Accessibility Michael Head Solution Architect - Slalom All Things Open 2020
- 2. Topics • Defining web accessibility • Assistive Technologies (AT) • Prioritizing • Measuring • Building • Learn more Rapid Intro to Web Accessibility - ATO 2020 1
- 3. Defining What is web accessibility? Rapid Intro to Web Accessibility - ATO 2020 2
- 4. Web Accessibility “Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.”1 Or: Make user interfaces usable for the widest possible combination of users and contexts as is feasible Pictured right: disability on a spectrum2 Rapid Intro to Web Accessibility - ATO 2020 3
- 5. Can you see this on your screen? Can you see this on your screen? Can you see this on your screen? Rapid Intro to Web Accessibility - ATO 2020 4 What's easiest to see?
- 6. Assistive Technologies Just a few of the many types of assistive technologies available: • Screen readers • Text to speech software for users with visual impairments • Examples: VoiceOver on macOS, Narrator on Windows, JAWS, braille keyboards • Speech-to-text software • For hearing impairments • Sip-and-puff switch • For motor control impairments • Animation blockers • For cognitive impairments (e.g. epilepsy) Rapid Intro to Web Accessibility - ATO 2020 5
- 7. Prioritizing Why should we prioritize web accessibility? Rapid Intro to Web Accessibility - ATO 2020 6
- 8. Prioritizing Why should we care about web accessibility? Rapid Intro to Web Accessibility - ATO 2020 7 Minimize risk • Section 508 of the ADA • Target paid $6 million in settlements to National Federation of the Blind3 Business reach • 2.9 million people in the US have low vision4 • Up to 8 percent of men and 0.5 percent of women with Northern European ancestry have red- green colorblindness5 Ethical standards • Some people think it’s just the right thing to do
- 9. Measuring How do we know we're making things accessible? Rapid Intro to Web Accessibility - ATO 2020 8
- 10. Measuring Now that we care, how do we get it right? Rapid Intro to Web Accessibility - ATO 2020 9 WCAG Web Content Accessibility Guidelines: • Guidelines for web content in “sites” or “applications” • Applies to desktop, tablet, and mobile interfaces • Latest version is 2.1 • Version 2.2 is in the works ATAG Authoring Tool Accessibility Guidelines: • Guidelines for making authoring tools more accessible, such as WSYWIG editors, content management systems, or other software that generates websites or content • It has two concerns: making an authoring tool itself accessible as well as the content that tool creates • Latest version is 2.0
- 11. POUR Rapid Intro to Web Accessibility - ATO 2020 10 WCAG principles fall in 4 categories identified by the acronym POUR. https://www.w3.org/WAI/WCAG21/quickref/ Understandable “Information and the operation of the user interface must be understandable.” Robust “Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.” Perceivable “Information and user interface components must be presentable to users in ways they can perceive.” Operable “User interface components and navigation must be operable.”
- 12. Perceivable Rapid Intro to Web Accessibility - ATO 2020 11 First name Last name City Not perceivable <img src="/images/city-required.jpg" alt="" />
- 13. Operable Rapid Intro to Web Accessibility - ATO 2020 12 Not operable <div class=“button”>Save</div>
- 14. Understandable Rapid Intro to Web Accessibility - ATO 2020 13 Not understandable The error when submitting a form is not identified. Users won’t understand what the error is. Error First name Last name City
- 15. Rapid Intro to Web Accessibility - ATO 2020 14 Not robust <ul> <div>Item 1</div> <div>Item 2</div> <div>Item 3</div> </ul> Not robust because this is invalid HTML and screen readers may not recognize this as a list. Robust
- 16. WCAG Four high-level principles, many granular guidelines. Compliance with WCAG is measured in levels A, AA, AAA. Some guidelines inside 1. Perceivable > 1.4 Distinguishable: • 1.4.1 Use of Color – Level A • Color is not the only means of conveying information • 1.4.3 Contrast (minimum) - Level AA • Text and images of text have a contrast ratio of at least 4.5:1 (dependent on text size) • 1.4.6 Contrast (enhanced) – Level AAA • Text and images of text have a contrast ratio of at least 7:1 (dependent on text size) Rapid Intro to Web Accessibility - ATO 2020 15
- 17. 1.4.1 Use of Color – Level A Rapid Intro to Web Accessibility - ATO 2020 16 First name Last name Nickname City First name Last name Nickname (optional) City Failed Level A Passed Level A
- 18. 1.4.3 Contrast (minimum) - Level AA Rapid Intro to Web Accessibility - ATO 2020 17 Failed Level AA Passed Level AA This text is less than 24px font size and has a contrast ratio of 2.84:1 This text is less than 24px font size, but has a contrast ratio of 5.74:1
- 19. 1.4.6 Contrast (enhanced) – Level AAA Rapid Intro to Web Accessibility - ATO 2020 18 Failed Level AAA Passed Level AAA This text is less than 24px font size and has a contrast ratio of 5.74:1 This text is less than 24px font size, but has a contrast ratio of 12.63:1
- 20. Building Rapid Intro to Web Accessibility - ATO 2020 19 How do we build accessible web interfaces?
- 21. WAI-ARIA Rapid Intro to Web Accessibility - ATO 2020 20 Web Accessibility Initiative–Accessible Rich Internet Applications is a set of web standards around building accessible web applications. Overview: https://www.w3.org/WAI/standards-guidelines/aria/ Authoring practices: https://www.w3.org/TR/wai-aria-practices/ Some tips when working with ARIA: • First rule of ARIA: if you can avoid using it, do so. • Browsers come with built-in UI controls that are more accessible than most things developers build—build and use custom controls with caution.
- 22. Tools Rapid Intro to Web Accessibility - ATO 2020 21 Browser built-in tools • Chrome, Edge, and Firefox all have built- in tools for viewing the accessibility tree or running an audit Design tools • Stark (getstark.co) for Sketch • Color contrast checkers • https://webaim.org/resources/contrastchecker/ • https://developer.paciellogroup.com/resources/co ntrastanalyser/ Browser extensions • Accessibility Insights: https://accessibilityinsights.io • WAVE: https://wave.webaim.org/extension/ Development tools • axe: https://www.deque.com/axe/ • axe: an open-source accessibility rule set for automated accessibility validation6 • Web Hint: https://webhint.io/
- 23. Learning more Rapid Intro to Web Accessibility - ATO 2020 22 Why stop learning at a single PowerPoint presentation? • International Association of Accessibility Professionals: https://www.accessibilityassociation.org/ • Deque University: https://dequeuniversity.com/ • WCAG: https://www.w3.org/WAI/standards-guidelines/wcag/ • ATAG: https://www.w3.org/WAI/standards-guidelines/atag/ • WebAIM: https://webaim.org • Section 508 Testing: https://www.dhs.gov/508-testing
- 24. Thanks! Feel free to contact me: Twitter: @michaelehead LinkedIn: michaelehead Rapid Intro to Web Accessibility - ATO 2020 23
- 25. References • Cover Photo by Ivana Cajina on Unsplash • Voiceover icon from https://support.apple.com/accessibility/tv • JAWS icon from https://www.freedomscientific.com/products/software/jaws/ • Braille screen reader image from Photo by Sigmund on Unsplash • Icons made by Freepik from Flaticon Rapid Intro to Web Accessibility - ATO 2020 24
- 26. Sources 1. https://www.w3.org/WAI/fundamentals/accessibility-intro/#what 2. https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-4417-8f28- d60703d672ed/inclusive_toolkit_manual_final.pdf 3. https://arstechnica.com/uncategorized/2008/08/target-to-pay-6-million-to-settle-site- accessibility-suit/ 4. https://www.flickr.com/photos/nationaleyeinstitute/14931304207/in/album- 72157646733299877/ 5. https://nei.nih.gov/health/color_blindness/facts_about 6. https://dequeuniversity.com/rules/axe/ Rapid Intro to Web Accessibility - ATO 2020 25
Notes de l'éditeur
- Hi everybody! Thanks for coming to this rapid introduction to web accessibility. My name is Michael Head; I’m a solution architect at a consulting company named Slalom. I am a certified web accessibility specialist and trusted tester. Trusted tester is an accessibility certification the US Federal government provides. Since this is a short session, we’ll jump right in.
- Here’s what we’ll be discussing today. We’ll define web accessibility, go over some assistive technology, then cover prioritizing, measuring, and building accessible interfaces. I doubt we’ll have time for Q&A, so my contact information will be posted in the chat for you to get in touch after the session if you’d like to talk further.
- What is web accessibility?
- Here is one definition for web accessibility…I’ve provided my own take on it because I think it deserves to be broadened—if we only focus on making things “work” for folks with disabilities, we’re missing an opportunity to integrate accessibility into user experience design and development. It’s best to treat this as a new of way of thinking about design and development, not just a checkbox to tick at the end of a project. Graphic on the right from Microsoft Inclusive Design Toolkit “Usability”: ISO 9241 (https://www.w3.org/2002/Talks/0104-usabilityprocess/slide3-0.html) Let’s look at a real world example that we may not think of in terms of accessibility (next slide).
- Most people can probably read the top line. Can folks read that second or third line? If you have glasses or contacts and you took them out, could you read the same lines then? If you couldn't, would you be considered “disabled”? Aren’t glasses and contacts “assistive technology”? Here’s an example where we have to consider font size and color contrast for the sake of legibility. But the context also matters—on a larger screen or printed out, this may be perfectly legible, but viewing in a poorly lit room may make it hard to read. Plus, your own eyesight matters. So, again, usability within a particular context. In this case, these lines get progressively "worse" with regards to accessibility compliance as you go from top to bottom. First line passes AAA for any font size. Second line has to be "large text" (bold and greater than 18.5px) just to pass AA, fails for "regular text". Last line fails AA for contrast at all font sizes. And we'll get more into what compliance means later.
- What does accessibility look like from the users’ perspective? Well, it often includes the use of assistive technologies—software or hardware that improves the experience of users with disabilities. Here is a very short list of assistive technologies that users might use to overcome a challenge with using user interfaces. This is a very short list to give some examples—there are many, many other kinds of software and hardware out there. Screen readers are possibly the most well known in the web community and are the most prevalent. Most major operating systems ship with some form of screen reader, like VoiceOver on macOS or Narrator on Windows. Then there are standalone applications like JAWS (the blue icon with the shark ion the right) and NVDA. In the bottom right of the screen, there is a hardware version of a screen reader called a braille reader.
- Why should we prioritize web accessibility?
- Why should we care that this kind of work gets prioritized alongside other work? There are a few reasons to prioritize it listed here. One reason is to minimize or mitigate risk. For example, Section 508 of the Americans with Disabilities Act states “that Federal agencies' electronic and information technology is accessible to people with disabilities, including employees and members of the public.“ So, building accessible interfaces ensures we minimize the risk of lawsuits, such as the one Target faced, and lost, to the National Federation of the Blind for their website not being usable with screen readers. However! I do not believe in lawsuit-driven-development, so let’s look at some other reasons we might prioritize it. One is business reach: limiting the usability of your software limits the reach of it and therefore your business. Looking at just these *2* stats shows how far reaching disabilities can be; and these are very limited stats in themselves, being US-centric and even focused on ancestry. Finally, there is the stance that it is the “right” thing to do based on ethical and professional standards. That’s a tricky stance, given it has real impact on budgets, timelines, and so on, but I think the wider design and development community is going to continue to make it a higher priority by default in the future so hopefully it becomes a “given”. I see the topic as akin to ”security” in software systems—slowly becoming more and more of a default instead of an after-thought.
- How do we know we're making things accessible?
- There are two sets of guidelines a designer or developer can use in order to determine either how they should build a new user interface or evaluate what they have built for an existing interface. We’ll spend more time on WCAG, the web content accessibility guidelines, as these apply to the widest range of web apps. ATAG, the authoring tool accessibility guidelines applies to a specific class of web apps: those apps that build web content, such as content management systems, HTML editors, or other back-office kinds of tools.
- WCAG guidelines (which is one of those acronyms folks say like “PIN number”) fall in 4 categories that have the nifty acronym of POUR. This link to the “quickref” is a good overview of how the principles and guidelines fit together. We’ll go over each principle individually. Perceivable, Operable, Understandable, and Robust
- Perceivable: information must be perceivable by the user; for example, an image that is crucial to filling out a form that doesn’t have alternative text provided means folks using screen readers will never get the content needed to fill out the form; that content is not perceivable to them. Here's a contrived example where the text "city is required" is in an image so screen reader users will never get that information before filling out the form. They may fill out the form and leave that field out, then receive an error, get frustrated, and ultimately bail on the form.
- Operable: interactive elements have to be operable by the user; for example, here we have a button that is made from a <div> element. By default, when you roll your own UI elements, you have to code all the stuff that normal HTML elements give you for free--keyboard focus, handling clicks, keypresses, etc. In this case, by default this button doesn’t receive focus from a keyboard so users that use only keyboards can’t activate it; it’s effectively inoperable to them.
- Understandable: information and operation of the interface has to be understandable to users; for example, if a form doesn’t identify which fields are in error when a user submits the form, users won’t understand what is wrong or what needs to be fixed. In this example, they have to guess what is in error.
- Robust: content must be robust enough to work with a wide variety of user agents; for example, without the correct semantics in markup some screen readers don’t know how to “read” the content; Here we have some invalid markup that represents a list, but using divs instead of list items.
- POUR represents the high-level principles. In each of those principles, we have many granular guidelines. We can’t go into every guidelines now, but we’ll look at some examples for the guidelines “distinguishable” inside of “perceivable”. Compliance with WCAG is measured in levels A, AA, AAA. Each guidelines is also associated with a particular level. Here is a guideline from each level. We’ll walk through these with passing and failing examples for each. Most organizations strive for adhering to level AA.
- Here we see two versions of a form with some fields, one of which is marked as optional through the color green. The label Nickname is optional but on the left hand side only color has been used to designate that. On the right, the word “optional” is provided to ensure that color alone is not the only means of conveying that information to a user. This ensures colorblind users can perceive that information.
- Here we're looking at some example text with different colors. The contrast minimum guideline requires a contrast ratio of at least 4.5:1.
- Here’s the same text as the previous slide that passed AA, but would fail AAA because the contrast enhanced guideline requires a contrast ratio of at least 7:1.
- Now we know what web accessibility is, we know why we want to build it into our applications, and we have an idea of how to measure it so we know we're doing it right. Now, how to actually build it?
- There are two topics I’ll cover in the build it section: ARIA and testing tools. Instead of copying and pasting a bunch of content from W3 specs, here are links for folks to review on their own. WAI-ARIA is a set of standards we can use for building accessible web applications. It lets us code our interfaces for use by screen readers and other assistive technologies. Note, though, that one of its own recommendations is that if you can avoid using it, do so. Again, many things work in browser "out of the box", so to speak, so be careful if you start building your own stuff that might not be compliant by default.
- Before, during, and after development we'll want to test for adherence to the WCAG guidelines. There are many accessibility tools available to do that. This slide shows some categories with names and links to a few out there. Some of these are for manual evaluations, like color contrast checkers, while others allow for some automated evaluations, like Web Hint and Accessibility Insights. Browsers even come with built-in tools these days for doing things like running an audit or viewing the accessibility properties of elements. Axe is an accessibility rule set that you can put into your CI/CD pipeline to evaluate components or pages before letting something go to production. Note: automated testing can only get you so far, some folks even say only about 30% there (https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/), so manual evaluation is a *must*.
- Why stop at a single PowerPoint presentation? There are many resources out there and these are just few. Hopefully this presentation provided you with a little bit of knowledge to build on.
- Here's my contact information--feel free to reach out with questions or just to say hello! Thank you all for joining me.