Rapid Introduction to Web Accessibility

Editor's Notes

• #2: 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.
• #3: 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.
• #4: What is web accessibility?
• #5: 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).
• #6: 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.
• #7: 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.
• #8: Why should we prioritize web accessibility?
• #9: 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.
• #10: How do we know we're making things accessible?
• #11: 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.
• #12: 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
• #13: 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.
• #14: 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.
• #15: 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.
• #16: 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.
• #17: 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.
• #18: 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.
• #19: 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.
• #20: 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.
• #21: 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?
• #22: 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.
• #23: 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*.
• #24: 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.
• #25: Here's my contact information--feel free to reach out with questions or just to say hello! Thank you all for joining me.