Web Accessibility 101: a DIY starting point for finding and fixing website accessibility problems

1. Web Accessibility 101:a DIY starting point for finding and fixing website accessibility problems Heidi Koester, Ph.D. hhk@kpronline.com Koester Performance Research, Ann Arbor, MI https://kpronline.com

2. Overview Intro to web accessibility A recipe for evaluating web accessibility Fixing web accessibility issues Focus on KPR’s websites as examples Principles and techniques you can use on your own websites or to advocate for improved accessibility in your own organization

3. Quick definition of web accessibility • Ensures that your website is available to everyone • All users can understand the content and navigate the site • Regardless of: • Disability (short- or long-term) • Age • Environment/setting

4. Examples of web accessibility needs • Is blind • Has low vision • (or is older, or doesn’t have their glasses, or is in bright sunlight, or…) • Has problems with hearing • (or can’t listen to sound at work) • Has challenges with reading • (or is a non-native speaker) • Has problems with mouse or keyboard • (or has a preference) Allow all users to understand the content and navigate the site, including someone who:

5. WCAG 2.0 Framework Web Content Accessibility Guidelines The 4 POUR principles: Perceivable: Available to the senses (vision and hearing primarily) through the browser or AT such as screen readers, screen enlargers, etc. Operable: Users can interact with all controls and interactive elements using either the mouse, keyboard, or an assistive device. Understandable: Content is clear and unambiguous. Robust: Many ways to access the content.

6. WCAG 2.0 Framework • Operationalize the principles into specific guidelines • Level A • Level AA • Level AAA • Focus today will be on Level A but same approach applies to all levels. • Achieving Level AA is typical standard for Section 508 and other government regulations.

7. Case Study Websites • kpronline.com • Main KPR website • Regular pages • WordPress blog • Ecommerce pages

8. Case Study Websites kpronline.com/atnode • AT-node • Web application • Search text entry data • Search forms • Dynamic results pages

9. Case Study • We developed a recipe to check for accessibility problems • Applied the recipe to each of the two websites • Fixed problems that we found • Spoiler alert: • Found 386 a11y problems. Yikes! • Fixed almost 90% of them

10. Challenges in web accessibility • Have you experienced similar challenges? • What questions do you have at this point?

11. Overview Intro to web accessibility A recipe for evaluating web accessibility Fixing web accessibility issues How we defined the recipe How we used it How you can use it

12. Goals for the recipe Test for compliance with WCAG 2.0 Level A Cover all content in the website Can be followed by an undergraduate with no particular training in accessibility Caveat: this is a starting point. Not a substitute for testing by experienced testers using assistive technologies or a complete analysis by accessibility consulting firm. More of a prerequisite for same.

13. Resources used WCAG itself is interesting but pretty opaque, so: https://www.wuhcag.com - clear description of each guideline https://www.dhs.state.il.us/accessibility/references/web-accessibility-quick-test-checklist.html - simple quick test procedures Found these later: https://a11yproject.com/checklist/ https://alistapart.com/article/diy-web-accessibility-blueprint/

14. Tools (ingredients) needed • Automated testing • https://validator.w3.org/unicorn/ • https://wave.webaim.org/ • Manual testing • VoiceOver (or other screen-reader) • Screen-reader cheatsheet (https://webaim.org/articles/voiceover/) • Our spiffy template for rating each guideline (https://tinyurl.com/kpr-a11y-template)

15. Overall approach • Quick Check of the Home page • Get the lay of the land • See what you’re in for • Detailed Testing of each guideline • On each webpage • Dig in broader and deeper • Gives an error count to measure your progress

16. 3-step Home Quick Check • Run Home page through WAVE • Any errors? • View it in grayscale • Look for contrast and color-coding issues • Read the page with a screen-reader • Does all content get covered in a reasonable sequence?

17. Quick Check Step 1 - WAVE • 2 Errors and 0 Contrast Errors –not too bad so far… Styles tab is the regular view with stylesheet active

18. Quick Check Step 1 - WAVE No Styles tab disables the stylesheet – check the structure and sequence

19. Quick Check Step 1 - WAVE • 14 Contrast Errors on AT-node home page… Contrast tab focuses on visual contrast errors

20. Quick Check Step 1 - WAVE zapier.com example WAVE shows the colors used and contrast ratio, for every contrast error Try different colors to see what works Also gives a window to the underlying code Gray-on-white very common error Orange also tough

21. WAVE Contrast Errors: Caveat • WAVE is awesome but can’t do everything • Can’t detect contrast errors for these items: • Button text within <button> elements • Hover states of elements • Text within images

22. Quick Check Step 2 - Grayscale • Look for color-coding issues (conveying content only through color) as well as contrast (esp for things that WAVE can’t auto-detect) E.g., on the Mac: System Preferences/Accessibility/Display/Use Grayscale

23. Quick Check Step 3 - Screenreader These can be tricky to use. I need a cheatsheet. https://webaim.org/articles/voiceover/ Try live demo with kpronline.com Sequence: does it speak in appropriate order Coverage: does it speak all the content on the page? Images: does the alt text make sense?

24. Questions at this point? • Have you used any of these tools? • Other approaches that you find helpful?

25. Overall approach • Quick Check of the Home page • Get the lay of the land • See what you’re in for • Detailed Testing of each guideline • On each webpage • Dig in broader and deeper • Gives an error count to measure your progress

26. Testing Template Rows: guidelines/rubrics. Cols: webpages Public at https://tinyurl.com/kpr-a11y-template

27. W3C validator https://validator.w3.org/unicorn/ Checks the validity and structure of the HTML and CSS code for the webpage https://validator.w3.org/nu for just HTML Invalid code might render OK for you, but confuse assistive technologies, or fail on other browsers. So check it!

29. Testing Template “Training” Template gives specific criteria for pass/fail for each guideline. But read wuhcag.com description of each guideline before starting to understand bigger picture https://www.wuhcag.com/wcag-checklist/

30. Results from the 2 KPR websites • For kpronline.com, 90 of the errors are from 2 ecommerce pages. • Pretty important pages, but not ones that we directly control… 39 pages tested

31. 17 error types Can’t use the order form without mouse Some links inaccessible by keyboard Poor user experience (at best) for low contrast content Poor UX with video captions

32. Order page problems: “Edit text, blank” I have to fill out the form, but I have no idea what each field is. Country is required, but I can’t get there I need to use a P.O., but I can’t get there

33. Questions at this point?

34. Overview Intro to web accessibility A recipe for evaluating web accessibility Fixing web accessibility issues This isn’t primarily a coding workshop But want to give some perspective on fixing a11y errors

35. Web coding 101? Simplest case: these are all text files that you have direct access to But HTML might be generated by server-side tech like PHP The CSS might be provided by a framework like a WordPress theme or Bootstrap

36. Fixing contrast errors • MailChimp subscribe button • Default styling fails (not found by WAVE 😳) • MailChimp has its own CSS file, but we can override it in our own stylesheet: footer #mc_embed_signup .button{ background-color: #767676; } • The key is the #mc_embed_signup id

37. Enhancing video captions • Use YouTube to host videos • Its automatic captioning works very well for narrated videos like ours • Edit the automatic captions within YouTube – easy! • A good student or volunteer project, if you produce a lot of videos.

38. Links skipped with keyboard navigation • Huh? How could that be? Shouldn’t that “just work”? • Ah, the old <a onclick> gotcha pattern… • Fix by using <button> markup instead of <a onclick>

39. Announcing button text changes • Show/Hide button from previous example • Use aria attributes to tell screen readers what to say “Show how to, collapsed, button” Click “Hide how to, expanded, button”

40. Fix the Share-it e-commerce problems • Keyboard navigation: change a setting buried somewhere in Share-it. Tab Mandatory Fields Only was set to No by default. Luckily, Yes fixed it. Hallelujah! • Dig into the Share-it templates to add screen reader support • Add accessible labels to all fields • aria-labels for available <input> elements or “for” attributes for labels • Quite a bit of work for this part, but: • Keyboard navigation is now possible • Screen reading of the order page is now much enhanced

41. Before and After for the 2 KPR websites • For kpronline, 46 of the remaining errors are from 2 ecommerce pages, but UX is definitely better. • Other remaining errors are relatively low impact: • we don’t yet provide full transcripts for audio, missing form labels for spam prevention fields that a user never interacts with, etc. 39 pages tested

42. Thanks for coming! For more… • See kpronline.com/blog for details about this accessibility work and related topics • Presentation available at kpronline.com/pubs • Hands-free Mice: What’s currently available and how to make the “right” choice • Thursday 10:45 –12:15pm Room 206B • Happy to discuss your accessibility project with you! • Contact: Heidi Koester, hhk@kpronline.com, https://kpronline.com