#techInColor 2017: Practical Web Accessibility Testing
•
3 gostaram•550 visualizações
From my 2017 #techInColor lightning talk for Philly Tech Week. Summary ======= Thinking about accessibility in every step of your process ensures legal compliance but helps create a well-designed, more inclusive product that reaches a broader range of people. Testing your site or application for common accessibility user experience problems helps reduce barriers between you and your intended audience. Watch a recorded screencast of this presentation on YouTube (10m 6s): https://youtu.be/0uoH66mnqNw
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a #techInColor 2017: Practical Web Accessibility Testing
Semelhante a #techInColor 2017: Practical Web Accessibility Testing (20)
Último
Último (20)
#techInColor 2017: Practical Web Accessibility Testing
- 1. Practical Web Accessibility Testing May 2, 2017 #techInColor 2017
- 2. PRACTICAL WEB ACCESSIBILITY TESTING 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 People who want to design better experiences People interested in including everyone Those interested in starting a11y testing or advocacy in their organization
- 3. Overview Why should we start accessibility testing? Who are we testing for? What are some tools we can use? What are some top concerns? What else can we do?
- 4. Why Do We Want to Do A11y Testing? Practical Web Accessibility Testing
- 5. Why Do We Want to Do A11y Testing? Prevent legal action Better code and technology Reach more customers It’s the right thing to do
- 6. The Audience Practical Web Accessibility Testing
- 7. The Needs of Our Audience Visual Auditory Motor and Mobility Cognitive
- 8. The Tools Practical Web Accessibility Testing
- 9. Manual Screen Reader Testing Practical Web Accessibility Testing The Tools 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) NVDA (NonVisual Desktop Access) (with Firefox) JAWS Screen Reader (with IE, Edge incompatible) VoiceOver (primarily iOS, also available on macOS) TalkBack (Android) Switch Access AbleNet Switches (such as the Blue2) iOS Switch Control Android Switch Access
- 10. The Concerns Practical Web Accessibility Testing
- 11. Keyboard Navigation Practical Web Accessibility Testing The Concerns 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 “Skip to”/in-page links Single page application routing Alternatives to Multimedia Closed Captioning Video Descriptions ALT attributes for images Transcriptions
- 12. What Else? Practical Web Accessibility Testing
- 13. Developers Practical Web Accessibility Testing What Else Can We Do?* Product Make accessibility a business case and priority Require accessibility in your company’s definition of “Done” Design/UX Include people with disabilities in personas Annotate wireframes Consider accessibility and AT when designing Clarify requirements Include accessibility from the beginning Use automated testing tools QA Test with keyboard Test with AT and also use them Write accessibility test cases Use testing tools Research Look at accessibility history in the organization and make recommendations Conduct user testing with real people *Credit Marcy Sutton, Sr. FE Engineer at Deque
- 14. In Conclusion Empathize with others Consider who we might be forgetting Look into available tools Research and evaluate high priority concerns Get everyone involved
- 15. As designers, we disable people when we don’t get it right. “ -Jamie Knight Senior Accessibility Specialist at BBC
- 16. Thank You
Notas do Editor
- Welcome to Practical Web Accessibility Testing
- 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.
- 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.
- 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.
- 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. Conveying Information This will be HTML 101 but 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 can’t take credit for this slide. The credit belongs to Marcy Sutton, Senior Frontend Engineer at Deque. The following are different roles and what the people in those roles can do to help champion accessibility. 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 get down to the testing phase. Also, where possible, try to involve native users of assistive technology.
- 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...