A Primer on Web Accessibility for Teams
•Download as PPTX, PDF•
3 likes•324 views
This document provides an overview of web accessibility for teams. It discusses why accessibility is important, who the target audience is for accessible websites, common accessibility concerns, and how different roles can get involved in improving accessibility. The primer covers topics such as assistive technology, labeling elements, color contrast, tab order, focus management, ARIA attributes, and tools for testing accessibility. It emphasizes designing with accessibility in mind from the start and using native HTML elements which have built-in accessibility features rather than custom elements.
Recommended
More Related Content
What's hot
Similar to A Primer on Web Accessibility for Teams
Similar to A Primer on Web Accessibility for Teams (20)
Recently uploaded
Recently uploaded (20)
A Primer on Web Accessibility for Teams
- 1. A Primer on Web Accessibility for Teams June 6, 2017 Code for Philly
- 2. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Introduction About Me UI Developer at Think Company User Acceptance Tester at Comcast (Left: photo of me with long hair, caption: UX; Right: photo of me with fresh haircut, caption: UI) Who Is This Talk For Web professionals Those who want to design better experiences People interested in including everyone Organizations interested in accessibility advocacy, design, development and testing
- 3. Overview Why accessibility? Who is our audience? What are some common concerns? How do we get involved?
- 4. Why accessibility? A Primer on Web Accessibility for Teams
- 5. Why accessibility? Prevent legal action Better code and technology Reach more customers It’s the right thing to do
- 6. Who is our audience? A Primer on Web Accessibility for Teams
- 7. Who is our audience? Visual Auditory Motor and Mobility Cognitive
- 8. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS
- 9. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Assistive Technology
- 10. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Assistive Technology, Continued
- 12. What are some common concerns? A Primer on Web Accessibility for Teams
- 13. Keyboard Navigation A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Common Concerns in Web Accessiblity Conveying Information Proper HTML form elements and labels Logical heading structure Unlabeled elements in native applications Use of Color Use of only color to convey information Sufficient color contrast No keyboard support Focus management Visual focus indicator or focus ring “Skip to”/in-page links Single page application routing Alternatives to Multimedia Closed Captioning Video Descriptions ALT attributes for images Transcriptions
- 14. How do we get involved? A Primer on Web Accessibility for Teams
- 15. How do we get involved? Business Design/UX Developers QA Testers
- 16. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS How do we get involved? Business Make accessibility a business case and priority Make sure everyone gets accessibility training Require accessibility in your company’s definition of “Done” Look at accessibility history in the organization and make recommendations Conduct user testing with real people/evaluate product with user studies Develop internal accessibility standards Design/UX Identify critical/secondary user journeys to help scope accessibility work Consider accessibility and assistive technology when designing Include people with disabilities in personas Annotate wireframes with accessible labels/announcements Think about multiple ways to interact with UI and convey information Ensure proper color contrast Define a logical tab order Include visual focus ring in guidelines
- 17. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS How do we get involved? Development Include accessibility from the beginning Develop according to latest web standards and use native elements Implement logical tab order Manage focus properly, ensure visibility Ensure and apply keyboard support Use ARIA roles and attributes as needed Properly label elements Use automated testing tools, help QA QA Test with keyboard Test and use assistive technology Write accessibility test cases Use testing tools
- 18. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Web Content Accessibility Guidelines (WCAG) The WCAG documents explain how to make web content more accessible to people with disabilities. Web "content" generally refers to the information in a web page or web application, including: natural information such as text, images, and sounds code or markup that defines structure, presentation, etc.
- 19. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Who WCAG is for? WCAG is primarily intended for: Web content developers (page authors, site designers, etc.) Web authoring tool developers Web accessibility evaluation tool developers Others who want or need a standard for web accessibility, including for mobile accessibility Related resources are intended to meet the needs of many different people, including policy makers, managers, researchers, and others. WCAG is a technical standard, not an introduction to accessibility.
- 20. Proper Color Contrast WCAG 2.0 level AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text. Level AAA requires a contrast ratio of 7:1 for normal text and 4.5:1 for large text. Large text is defined as 14 point (typically 18.66px) and bold or larger, or 18 point (typically 24px) or larger. Be careful of: thin text, translucent UI A PRIMER ON WEB ACCESSIBILITY FOR TEAMS
- 21. Proper Color Contrast WCAG 2.0 level AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text. Level AAA requires a contrast ratio of 7:1 for normal text and 4.5:1 for large text. Large text is defined as 14 point (typically 18.66px) and bold or larger, or 18 point (typically 24px) or larger. Be careful of: thin text, translucent UI A PRIMER ON WEB ACCESSIBILITY FOR TEAMS
- 22. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Tab Order
- 23. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Managing Focus
- 24. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Managing Focus
- 25. Visual Focus or Focus Rings outline: none; A PRIMER ON WEB ACCESSIBILITY FOR TEAMS
- 26. Focus Ring Examples A PRIMER ON WEB ACCESSIBILITY FOR TEAMS
- 27. Focus Ring Examples A PRIMER ON WEB ACCESSIBILITY FOR TEAMS
- 28. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS WAI-ARIA Web Accessibility Initiative Accessible Rich Internet Applications Use sparingly For retrofitting old code When HTML isn’t enough
- 29. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Common ARIA Examples role=”dialog” Defines understanding, helps user know context, screen readers behaves accordingly. aria-hidden=”true” Hide content from screen readers, similar to display: none; but only hides from screen reader. aria-describedby=”errorMsg” Used to indicate the IDs of the element that describe the object. Useful for errors. aria-expanded=”true” Announces the expanded or collapsed state. Useful for accordions and other expandable content.
- 30. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Advanced ARIA Patterns The following patterns would involve the use of JavaScript and knowledge of appropriate ARIA tags to use. Lots more at the WAI-ARIA Authoring Practices Guide. (They list a bunch of UI patterns and the expected keyboard support.) Carousels Dropdowns (aka Combo Boxes) Mobile menu drawers Single page application announcements Custom web components Date pickers Modals Modal windows Tooltips Chat windows Loading messages and toasts Media players Autocomplete/type ahead
- 31. There is very literally, the <label> element. Control must be a child of <label> or targeted by an IDRef using the label’s for=”” attribute. Only works with native form elements. (Which is why it’s always helpful to use native elements.) How to Label Elements: <label> A PRIMER ON WEB ACCESSIBILITY FOR TEAMS <label> First name: <input type="text" /> </label> A screen reader would say, “First name, edit text”
- 32. aria-label attribute A string to be used as the accessible label. Overrides any other native labeling mechanism. How to Label Elements: aria-label A PRIMER ON WEB ACCESSIBILITY FOR TEAMS <button id=”hamburger” aria-label=”Main Menu”> </button> A screen reader would say, “Main menu, button”
- 33. aria-labelledby A reference to an element (or elements) which will act as an accessible label. Overrides any other labeling mechanism including aria-label. How to Label Elements: aria-labelledby A PRIMER ON WEB ACCESSIBILITY FOR TEAMS <h2 id=”lbl”>Triple Play Offers</h2> <button id=”btn” aria-labelledby=”lbl btn”> Shop Now </button> A screen reader would say, “Triple Play Offers, Shop Now, Button”
- 34. Off screen text is tried and true, sometimes necessary. What do I mean by offscreen? How to Label Elements: Off Screen Text A PRIMER ON WEB ACCESSIBILITY FOR TEAMS A screen reader would say, “Change location, button” “Location” is visibly using this CSS: position: absolute!important; display: block; visibility: visible; overflow: hidden; width: .063rem; height: .063rem; margin: -.063rem; border: 0; padding: 0; clip: rect(0 0 0 0);
- 35. ALT tags are also tried and true, but they need to be used effectively. Don’t simply duplicate text that’s already on screen, a screen reader user would hear it twice. How to Label Elements: Image ALT Tags A PRIMER ON WEB ACCESSIBILITY FOR TEAMS mY SiTe iS aCesSibLe I uSeD aLt TaGs <img src=”spongebob.jpg” alt=”mY SiTe iS aCesSibLe I uSeD aLt TaGs” /> <h2>mY SiTe iS aCesSibLe I uSeD aLt TaGs</h2> A screen reader would say, “graphic, mY SiTe iS aCesSibLe I uSeD aLt TaGs” “mY SiTe iS aCesSibLe I uSeD aLt TaGs, heading level 2”
- 36. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Just Use Native Elements It’s best to use native input types such as button, checkbox, radio and other native elements such as select rather than create your own. Why? Natively focusable, great keyboard support, custom controls need work to bring them up to parity. <ul> and <li> vs. <select> and <option>
- 37. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Just Use Native Elements, The Curious Case of Buttons <div class=”menu-btn”></div> By default: Non-focusable/tabbable No keyboard support for activation Does not announce properly to screen reader
- 38. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Just Use Native Elements, The Curious Case of Buttons <button class=”menu-btn”></button> By default: Still styleable with CSS Focusable, tabbable Full keyboard support, Spacebar/Enter Announces properly to screen reader as “button” Click handler activation, Spacebar/Enter run click handler
- 39. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Just Use Native Elements, Continued In your designs, consider using pre-existing HTML elements and patterns instead of creating interactions that will be really odd for assistive tech to use. It’s sometimes unavoidable but if you’re in the position of having to build it, do the best you can and consider the impact assistive technology. Examples: Dropdowns whose options have checkboxes Tooltips with actionable elements (not a tooltip anymore) Checkboxes that expand and collapse content
- 40. Manual Screen Reader Testing A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Tools for Testing and Development Online Checkers and APIs W3C Validator WebAIM WAVE (Web A11y Evaluation Tool) Tenon Deque aXe (Browser Extension) Readable.io and Juicy Studio: Readability Test Color Contrast Checkers WebAIM: Color Contrast Checker Colour Contrast Analyser (CCA) by Paciello Group Contrast Ratio by Lea Verou Color Contrast Analyzer (Chrome Extension) Contrast Ratio Checker (Chrome Extension) Contrast Grid NVDA (NonVisual Desktop Access) (with Firefox) JAWS Screen Reader (with IE, Edge incompatible) VoiceOver (primarily iOS, also available on macOS) TalkBack (Android) (Don’t use ChromeVox) Switch Access AbleNet Switches (such as the Blue2) iOS Switch Control Android Switch Access
- 41. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Color Contrast Tool Examples: Color Contrast Analyzer
- 42. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Color Contrast Tool Examples: CCA by The Paciello Group
- 43. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Color Contrast Tool Examples: Contrast Ratio by Lea Verou
- 44. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Color Contrast Tool Examples: Contrast Grid by Eight Shapes
- 45. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Training Resources Web Accessibility by Google Udacity Course (FREE two week course): https://www.udacity.com/course/web- accessibility--ud891 Google Web Fundamentals https://developers.google.com/web/fundamentals/accessibility/ Material Design: Accessibility Guidelines https://material.io/guidelines/usability/accessibility.html WebAIM Checklist http://webaim.org/standards/wcag/checklist Vox Media Accessibility Guidelines http://accessibility.voxmedia.com/ WAI-ARIA Authoring Practices https://www.w3.org/TR/wai-aria-practices-1.1/ Comcast Accessible Code Library http://haltersweb.github.io/Accessibility/
- 46. In Conclusion Empathize with others Consider who we might be forgetting Look into available tools Research and evaluate high priority concerns Get everyone involved
- 47. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Upcoming Events June 9, 2017 - Inclusive Design 24 (#ID24) - http://www.inclusivedesign24.org June 18, 2017 - LipSync Buildathon at NextFab - https://nextfab.com/event/lipsync-buildathon June 29, 2017 - DesignBrew: UX & Color Blindness - https://www.meetup.com/DesignBrew Follow the Following Accessibility at Google, Amazon, Microsoft Accessibility companies such as Paciello Group, Deque Systems, SSB BART Group (Level Access), Tenon, AbleGamers, Knowibility, NV Access, Freedom Scientific Conferences such as CSUNATC, AccessU, M-Enabling Local organizations Deaf Hearing Communication Center, Philly Accessibility Forum Hashtags: #GAAD, #a11y, #accessibility, #WCAG, #techInColor, #SoEveryoneCanGame Join the Web a11y Slack! http://web-a11y.slack.com
- 48. As designers, we disable people when we don’t get it right. “ -Jamie Knight Senior Accessibility Specialist at BBC
- 49. Thank You @mikeyil / @thinkcompany / @codeforphilly
- 50. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Screen Reader Demo: Setup In mobile Safari or Chrome, navigate to: www.bbc.com
- 51. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Screen Reader Demo: Setup Android Turn on TalkBack: Settings > Accessibility > TalkBack > Toggle On For Samsung users without TalkBack installed: Settings > Accessibility > Vision > Voice Assistant > Toggle On Pause TalkBack at any time by holding both Volume keys at the same time. iOS Turn on VoiceOver: Settings > General > Accessibility > VoiceOver > Toggle On Turn on Accessibility Shortcut: Settings > General > Accessibility > Accessibility Shortcut OR Just ask Siri to turn it on VoiceOver
- 52. A PRIMER ON WEB ACCESSIBILITY FOR TEAMS Screen Reader Demo: Navigating and Activating Mobile screen readers provide spoken feedback for the user interface. This allows the visually impaired to use a smartphone or tablet without any tactile feedback. There are two primary ways of moving around: “Swiping” or “Flicking” (Quick horizontal motion) Explore by Touch (Press and drag finger across screen) What normally would’ve been a single tab before is now: A double tap!
Editor's Notes
- A Primer on Web Accessibility for Teams Just to preface, I’m about to cover *a lot* of information, so feel free to break things up a bit by asking me questions. For the most part though, many of the deeper topics I’ll be re-visiting several times this evening. When I’m finished giving you all this information, I’ll show you how to use mobile screen readers, VoiceOver for iOS and TalkBack or Voice Assistant for Android. I’m opting to go with mobile this time around since I’m guessing almost everyone should have a smartphone and there’s way less setup time involved. And yes, I will be posting these slides online at the conclusion of tonight’s event.
- I’m Mikey Ilagan, I’m a UI Developer at Think Company but every day you’ll find me at Comcast on the Accessibility team where I perform User Acceptance testing across a very wide range of products and services. I got involved with accessibility from years of dev experience and a commitment to web standards, especially at Comcast where I was doing frontend for two years before my current role. This talk is aimed toward web professionals, anyone who wants to design better experiences that truly include everyone. My goal is that you’ll be able to walk away with a better perspective and might want to advocate for accessibility in your organization.
- You’re likely to hear about preventing legal action. Unfortunately, the fear of legal consequence and the price tag associated with it is what usually motivates people to get started. It’s cheaper to avoid legal trouble now, rather than settle in court later while still having to fix it anyway. You can make the case for better code and technology as part of a redesign, re-platform or handling existing tech debt. Since so much accessibility depends on clean, semantic frontend code to begin with you can even make the case for performance optimization or even SEO. In 2015 Cornell reported that the overall percentage of people in the U.S. with disabilities was 12.6%. That means nearly 40 million people of roughly 317.5 million individuals in the United States reported one or more disabilities. They deserve to be engaged as your customers or userbase just like anybody else. Here’s my favorite point: It’s the right thing to do. Ensuring accessibility gives us the ability to reach a broader, more diverse audience. Being mindful of this audience allows us to create a better, more holistic user experience and improve our goodwill for our fellow humans. We should be do good, for the sake of being good. How can we call ourselves designers if we aren’t really designing for everyone?
- Like many organizations, when we test and talk about accessibility we consider the following groups. Visual: This would include people with all forms of color blindness and visual impairments. These folks might have difficulty with certain color combinations or depend on screen magnification software and/or screen readers. Auditory: Individuals who are deaf or hard of hearing would have difficulty with information presented without text, such as videos without closed captioning. In most broadcast cases, Closed Captioning would enforced by law. Available transcriptions for audio content such as podcasts not only make it accessible to the deaf but also allow those with cognitive disabilities to review more easily or even have your content indexed by search engines. Motor/Mobility: People with difficulty or inability to use hands for any reason, loss or lack of fine muscle control would be categorized under mobility considerations. Some depend on switch access (more on that later) to replace the need to use a keyboard or a mouse. In the advent of voice recognition, you’ll even encounter people using software such as Dragon NaturallySpeaking. Cognitive: People with cognitive disabilities of various origins, affecting memory, attention, problem-solving and logic need to be accounted for. This includes developmental disabilities, learning disabilities, dyslexia, ADHD and more.
- A couple real-world examples of impairments from Google. Consider the fact that people are often impaired in several ways. I heard someone recently express it in the sense that we’re all temporarily abled. With luck, we’ll all grow old but along the way, we’ll need some help to keep up.
- These are examples of some assistive technology. So many people are keyboard-only users so interfaces really need to work without the aid of using a mouse. In the next photo we see a person using a screen reader to aid their access. On the bottom row we have a braille display, these provide Bluetooth connectivity with pretty much every kind of computing device. They allows a person to interpret digital interfaces as braille. They can read and write in braille with this device. The last photo shows an example of the rotor in iOS as part of VoiceOver. The “rotor” is a kind of context menu that gives users more options when accessibility features such as VoiceOver are turned on.
- In these photos we have people using different forms of AT meant to aid motor impairment. A woman using what’s known as a sip-and-puff switch. It’s essentially a joystick-like mouse meant for your mouth, blowing into it activates the left click and sipping or sucking activates the right click. It can be activated with very little effort. The two gentlemen in the middle are able-bodied but they created a LipSync as part of Comcast’s Lab Week. A LipSync is a sip and puff switch designed and invented by a company in Canada but intended to be extremely low cost. Most of the parts are 3D printed and all-in the device is under $400 which is roughly a tenth of what it would normally cost. The last person in this row is likely using an Eye Gaze communication device which tracks and interprets eye movements. At a previous Comcast Lab Week we’ve got some remote control software working with a similar eye tracking device. If you come visit the Comcast Accessibility Lab you can demo it. On the bottom row, it might be tough to see, but this person is using dictation software. So he’s able to interact with interfaces using voice commands. This last device is one that I’ve brought with me today. It’s a Blue2 Switch from AbleNet. We use these for testing over at Comcast. This Switch is for “Next” and the other one is to “Activate”, the Switch Access feature in iOS does the rest of the work. However, it can also be used as an extender or hub for other switches. I’ll allow the video on the next slide to show how that works.
- In the time I’ve been doing accessibility testing, I’ve started to look at frontend development a whole new way. Here’s a few of the recurring issues or concerns that I come across often. And it’s totally okay if you don’t know what some, any or even what most of this means. I’ll be covering how our roles affect the following common problems. Most of these topics will be covered again in following slides, for anything I’ve highlighted will be covered in more detail later on. Conveying Information Ultimately, when we craft an experience we’re conveying information somehow. When we think about today’s frontend engineering landscape the use of frameworks, libraries and accruing tech debt, clean markup can be lost pretty quickly. You’ll want to make sure your HTML forms are properly labeled and you’re using the right elements at all times. Additionally, you’ll want to follow a logical, descending heading structure. Assistive tech users--screen reader users especially--navigate by heading. Moving on to speak for native applications for a second, unlabeled elements are very frustrating. Any icons or buttons without visual text should have it audibly available for VoiceOver or TalkBack. Keyboard Navigation If you can’t use your interface without using a mouse, seriously reconsider. A design that is keyboard-navigable benefits screen readers users, Switch Device users and just about anybody. You’ll want to trap keyboard focus within dialog menus, manage it for when toggling expandable content, etc. There’s the visual focus indicator, which by default is the CSS :outline property, by itself it’s a huge concern and something completely forgotten or completely misunderstood. Other considerations include in-page “skip to” links and similarly, single page app routing since single page apps confuse screen readers. Use of Color Many web accessibility issues are solely frontend issues. Color, however, is probably the number one issue I run across and it’s something that’s entirely up to design to solve. Make sure you are using more than color alone to convey information, such as in graphs. Don’t forget about adequate color contrast. That’ll benefit people born with low visual acuity, people losing it due to age or even people with displays that lack contrast. Alternatives to Multimedia Much of this depends on where you’re sourcing your content but if you’re producing content for the web please consider closed captioning for people with hearing disabilities and video descriptions for people with visual impairment. Are you using a lot of image tags? Please give them an ALT attribute and don’t make it simply duplicate text that’s already accompanying the photo. It should be descriptive. And as previously stated, transcriptions make your audio content such as podcasts accessible to those with hearing impairment but also indexable by search engine.
- I’m going to take an informal poll by show of hands. Feel free to raise your hands for as many of these as you want. By show of hands, how many people here fall into the Business side of projects? To me, that means you’re a product manager, product owner, project manager or scrum master. Do you do research as part of your job? How many of you are designers? Either visual or UX. Who in the room would consider themselves a developer or engineer? We should all be performing quality assurance testing as we all should be mindful of accessibility but who in the room primarily does testing? Here’s a fun question: Who here designs for or works on accessibility or make sure accessibility is accounted for in their organization? All your hands should be going up. On the following slides, I’ll be discussing how all of you will be able to think about or be mindful of accessibility in your given role.
- Everyone from product to developers, design/UX, QA and even researchers should be involved with accessibility. The more mindful we are of accessibility the more value we can derive when we’re getting ready to test and ship a product. Also, where possible, try to involve native assistive technology users in your process. They’re really the experts in this. Business Accessibility should be a foundational consideration in what you’re doing. Make it a priority. Think about it from the beginning and you’ll have less problems down the road. Make sure everyone gets accessibility training. There’s a ton of technical documentation out there, companies offer training for small and large organizations, find local meetups and informative sessions like this one. Require accessibility in your company’s definition of “Done”. We’re running into this quite often right now when working with vendors, they’ll come back and say “We didn’t know this had to be 508 compliant, etc.” While I get their point, working in the space that I do, it’s almost like saying, “We didn’t know this had to work!” Internally and externally, you can look at the history of your organization or one that you’re doing work for and make recommendations based on what they’ve done. As with anything else, you can focus on areas to improve. Find real people to test your products with, when your product is done, have real users evaluate it and incorporate their feedback in successive iterations. Develop internal accessibility standards. While there’s guidelines out there for legal, you’ll want to create more specific internal standards and probably UI and design patterns to go along with it. Design/UX As UX, you’re probably already identifying the critical and secondary user journeys you want people to take. These should be the same basis in which you prioritize your accessibility work. Consider the most important things you want people to accomplish and ensure everyone is able to take that journey. This next point might be tough since there is A LOT of assistive technology out there but realize there is no middle or average user. Many people approach technology in more ways than you’re probably considering, but think about including different types of people as you design your experience. How many people in here know somebody with a disability? How many people do you run into on a daily or weekly basis that might have difficulty using your product? Include them in your personas. As a designer we’d always talk about designing experiences easy enough for our grandparents to use but often we’d forget that our grandparents have very low vision due to common acute glaucoma. Or, we want to design for the up-and-coming digital native generation so let’s say one of them has low reading comprehension or ADHD because these people are out there but I feel so rarely considered when we’re designing. At Comcast, we’re starting to do a lot of the following. We’re building a lot of native apps in which iconography is heavily used. Take the TV remote app for example, you’ll want to provide an audible label so that a user knows a “heart icon” will bring them to their favorites. Consider multiple ways to interact and understand the content with a site. For example, it’s probably poor practice to handle form validation by simply turning text and input borders red. A person with colorblindness is very likely to miss that. A screen reader user will definitely miss that. And on another but related note, consider multiple ways to achieve the same function. For example, if you’re depending on most of your users navigating through your app using some sort of internal, fancy, auto-completing super site search, still have every option available through conventional means. Complicated search interfaces are very difficult to perfect. Another great example is Drag-and-Drop. There has to be another way to complete that same action.
- On to... Developers Everyone should be thinking about accessibility from the beginning, especially developers. As stated, it’s easier to implement accessibility earlier on than retrofit it later on. As developers, we’re the chief implementers. We’re creating the components and reusable patterns that’ll live throughout an entire application. And they could live there for a long while. We should be developing according to the latest web standards, as I said before, so much about assistive technology depends on clean, frontend code. Please use native elements, some of the biggest challenges users have are when they encounter a series of list items in an unordered list, simulating but not quite fulfilling everything that a native dropdown element can achieve. Be mindful of the differences of links and buttons, use either one of them for their appropriate function. For all the headaches you’ll encounter, it’s definitely not worth applying clickEvents to elements such as divs, spans, buttons, etc. You and your designer should’ve already had conversations on logical tab order. It’s your job to implement it while taking other considerations into account. Manage focus properly, ensure that it is visible. I’ll elaborate on this further. Related to the previous point, I can’t stress enough how keyboard support is critical. Use ARIA roles and attributes as needed. ARIA isn’t necessary to make a site accessible, but sometimes it is necessary to make older sites accessible or new sites with complicated UI patterns. Properly label all elements so screen reader users know what they’re interacting with, but use easy to understand language. I’ve been asked at least twice in the past year what a “hamburger menu” or “hamburger button” is. When you’re using text in your code, realize that a screen reader is going to catch it and repeat it verbatim. Lastly, use automated testing tools and help QA to implement and use them. QA Testers Use your keyboard. Just your keyboard. See how well you can interact with the site or application. Test and use assistive technology. Screen readers such as NVDA for the Windows Desktop and mobile screen readers make it easier than ever to access and use. Write accessibility test cases, as I mentioned earlier in our personas, people with disabilities are out there and we need to consider them in the same regard that we’ve always considered every else. Lastly, use testing tools. There’s a bunch of automated and manual options.
- This is how WCAG 2.0 defines and requires color contrast standards on the web. Any questions?
- This group of what we refer to as “offer cards” at Comcast was an interesting exercise in focus management and implementing a logical tab order. It started as everything but logical however. Due to a couple competing requests from UX, dev opted for using flexbox and flexbox ordering to get the presentation just right. Originally these three dark boxes were the only thing shown, then you’d hit a button and it would expand the lower halves for all three. This created a couple issues with the flow. I’ve drawn up some arrows to show what the tab order used to do originally. That’s pretty annoying right? Now when tabbing everything flows down vertically, keeping you you contained tabbing through the elements within that order before moving onto the next one. That makes more sense.
- Managing focus is a deep topic. What we have here is an example of tabs that change an area of content, simple enough, right? However, there’s something a little different about these tabs. Both visually and in the DOM, or the code they’re at the bottom. This will prove problematic for people using assistive technology. First off, a person using a screen reader simply won’t know anything has changed unless you show them. You need to bring their keyboard focus to the start of the content that’s changed and they’ll read down from there.
- Overlays are another area in which focus management is essential. What did the designers intend on this situation? Visually, it’s pretty clear what’s in focus, the overlay in the foreground is front and center. It’s bright and it’s clear we need to activate one of these buttons or hit either the close or cancel button. The content for this overlay is likely injected into this page, usually the very bottom but sometimes the top. What makes modals tricky UI for screen reader users is that sometimes they’re unaware they’ve even shown up on the page. We could’ve activated this modal from one of the “Add to Cart” buttons on the page but the screen reader is very true to the code. What we call the focus or keyboard focus is likely to remain at the point of origin until we re-orient it within the modal--which for many reasons such as through use of frameworks or libraries--live far away in the code from that “Add to Cart” button.
- At an assistive technology conference earlier this year I sat in a presentation where the consultant who was presenting said he’d make a lot less money if people stopped doing this. And it’s true. There seems to be a lot of confusion as to the purpose of the outline. I’ve seen designers and non-designers alike refer to it as “an ugly blue outline”. While it might ugly sometimes, we’re far better off being judicious about where we turn it off versus applying it to a global stylesheet and turning it off throughout our entire site. That’s a big problem. Keyboard users depend on this visual focus indicator or focus ring for context.
- Here are two examples of focus indicators. Deque Systems is a well known company in the accessibility space, they create software, provide training, etc. Obviously they have very noticeable focus indicators on their website. Simply Accessible has a bit of a different approach. “Our work” would be the current page. “Articles” surrounded in a darker blue is what you see upon tab stops. Both of these work. The problem is when we don’t see anything at all.
- Here are two more examples. On top we’ve got XFINITY xFi, which similar to Simply Accessible, they’ve defined separate “current” versus “focus” styles. That makes sense to do based on your design. Another thing they’ve chosen to do is standardize their focus ring across platforms. Here they’ve chosen a dotted line, which you’d see in Firefox and IE. In Chrome, and I think Safari, you’ll see a glowing blue outline. GOV.UK has an obvious implementation similar to Deque.
- Label element Aria-label Aria-labelledby Off screen text ALT tags
- Label element Aria-label Aria-labelledby Off screen text ALT tags
- Label element Aria-label Aria-labelledby Off screen text ALT tags
- Label element Aria-label Aria-labelledby Off screen text ALT tags
- Label element Aria-label Aria-labelledby Off screen text ALT tags
- Using dropdowns as an example, as a compromise, it would be acceptable to use <ul> and <li> as a replacement for <select> and <option>. The <ul> and <li> would have to be hidden from the screen reader as they would use the <select> and <option> elements that still need to be in the DOM. In turn, the <select> and <option> would have to be hidden from the sighted user so that use the stylized <ul> and <li> which still need to be keyboard accessible. Still need to solve for people using dictation software. Not sure of the answer to that.
- Use the proper element. Take advantage of HTML. Use a button. It’s styleable. It’s focusable/tabbable. A side benefit of the button element is that if you add a click handler to it in JavaScript, it has a thing called synthetic click activation, using spacebar and enter will run your click handler. A div and span cannot do this out of the box, you’ll have to listen for the keyboard event, check the key type, etc. Using the button element just gives this to you.
- For day to day web accessibility testing of sites and native apps, I use a combination of mostly free tools and services for desktop and mobile. Online Checkers and APIs As I previously mentioned, since so much about web accessibility depends on clean semantic markup starting with something like the W3C Validator would be a good starting point. If your code validates, chances are it’ll be mostly accessible, at least from a compliance standpoint. WebAIM WAVE, Tenon, Deque aXe are similar in the respect that they have online validators to use through a web interface as well as APIs to tap into. They’re testing against rules more specific to the WCAG (Web Content Accessibility Guidelines) though. Readable and Readability Test I put here not because they validate code but they score your copywriting’s complexity. That’ll help guide you to aim for a reading level accessible to your audience. Manual Screen Reader Testing I could do an hour long session on just how to use any one of these but this is what we’re currently testing for in priority order. NVDA and JAWS on PC Desktop, VoiceOver for iOS and TalkBack for Android. They all essentially do the same thing which is interpret your markup in a text-based, audible way for users with low vision or blindness. When using them however, we get more into the Accessibility UX side of things. Color Contrast Checkers These all essentially do the same thing but just have different ways of doing it. These are online checkers, native desktop apps and Chrome extensions. Simply put, they output a contrast ratio value based on WCAG 2.0. A being the least strict and AAA being the most strict. At Comcast and most places, we’re testing to pass WCAG 2.0 AA standards. Switch Access If you want to obtain the actual hardware to do switch testing instead of approximating the experience with a standard computer keyboard, you can purchase a switch device. Even without purchasing one however, you can browse the software settings in both iOS and Android to get an idea of how a user would pair one of these input devices and use it to navigate an interface.
- This is the Color Contrast Analyzer Chrome Extension. In my opinion what it lacks in detail it makes up for in making a statement. What it does is highlight all the identifiable borders in white and mutes everything else in a black overlay. This way, we can really see what passes adequate color contrast ratio. This is an example from my.xfinity.com.
- This is probably my favorite tool, it’s a native application for macOS or Windows from the Paciello Group. I like it because it has an eyedropper you can use throughout the OS, it appropriately pulls the hex values or allows you to enter your own and if you’re testing to reach a standard such as WCAG 2.0 AA which we follow at Comcast… it interprets the rule right here.
- I mentioned earlier to keep an eye out for opacity changes. This tool is similar to other except it also allows entry of rgba or hsla color values.
- This is the Contrast Grid by Eightshapes. It’s best for testing multiple color combinations at once. Once again, it outputs the WCAG pass/fail and for you. Really great for testing a whole color library.
- In conclusion, let’s empathize with other people who have different experiences. Let’s consider who we might be forgetting and how they interact with technology. Look into the tools that are available. I’m sure there are way more out there than what I covered today. Research and evaluate high priority concerns, like anything else you’re likely to uncover a wide range of issues and you can prioritize and tackle them much like anything else. Get everyone involved, as mentioned, your process will be a lot more successful if you can get ahead of your testing.
- I leave you with some closing thoughts...