Considerations Before Conducting an Accessibility Audit…

1. Considerations Before Conducting an Accessibility Audit… Kurt Mattes Senior ICT Accessibility & Customer Success Consultant

6. Color Vision Impairment Dyslexia • Low Vision • Macular Degeneration • Torn Retina • Cataracts • Glaucoma ADHD Parkinson's Traumatic Brain Injury TBI

7. Is ICT Accessibility a Technical Problem? Is the lack of accessibility due to not conforming with the Web Content Accessibility Guidelines (WCAG) Success Criteria? NO! Accessibility is a practical problem with a technical solution

8. Consideration #1 NOT about finding Web Content Accessibility Guidelines (WCAG) bugs IS about finding unnecessary difficulties

9. “Houston, we’ve had a problem”

10. Consideration #2 The problem has most likely sadly had birthdays

11. “Houston, we’ve had a problem” • Pretty sure there is a problem – bugs • There’s evidence – complaints • Something must be done • Sometimes its … YIKES!

12. “Houston, we’ve had a problem” • You know you don’t know what you don’t know • How big is the problem? (wait, how do we measure it?) • Are they nasty bugs – hard to eliminate? • How much effort and time to get rid of them? • Something must be done, but what? • More information needed • Somebody call an expert! (what is it we are asking them to do?) • Google Ahhh…I see, you’ve been reading WCAG

13. (& much more!) Get what you ask for

14. Research… Get what you ask for (& much more!)

15. Plan and budget Looks like classic bug fixing exercise Now know why to call an expert & what to ask for Testing – an Audit With expert’s report they can: Scope remediation project Secure budget Look like a hero Get what you ask for (& much more!)

16. The report (aka OMG!) More than expected • Proves more isn’t always better (caution, does not apply to diamonds) Where to begin? Triage: severity, level of effort Develop strategy Start writing project requirements / plans Get what you ask for (& much more!)

17. Recap Time and $$$ invested Risk exposure – little to no change(perhaps the more important point is - it’s still not accessible) Good news • Now have project requirements / plans, maybe a roadmap too Bad news – outcome short of expectations, much remains to be done Oh, and starting with the next release… Get what you ask for (& much more!)

18. Effective weed whacking - somewhat Classic approach under analysis

19. Common outcomes Effort larger than anticipated Risk reduction? Increased awareness – tends to quickly fade without care and feeding UX slightly better • Poor, cumbersome, confusing experience • Complaints soon return Classic approach under analysis

20. Lessons learned…maybe Include accessibility in project docs • BRD, functional specs • Style guide Start accessibility testing earlier in dev life-cycle Focus on issues with high severity ratings Classic approach under analysis

21. Management sees… Familiar software dev pattern: Classic approach under analysis • Sense of accomplishment • Metrics indicate significant changes made • By the numbers, many bugs fixed • Misleading measure of risk reduction – only 1 issue needed Build > Test > Re-test > Fix

22. Right approach…rarely Effective quick-fix required by legal action (should be questioned) Best as a temporary solution, otherwise High life-time cost Little impact on problem source Ongoing higher level of risk exposure Classic approach under analysis

23. Never ending costly cycle ofremediation Classic approach under analysis

24. What led to this approach? Sense of urgency Appears to be a technical problem Need scope for budget / project planning Known path for finding/fixing technical issues Good research without experienced guidance Classic approach under analysis

25. audit::before { content: “Considerations”; }

26. audit::before { content: “Considerations”; } A problem defined by… • WCAG failures (aka bugs) • No awareness of need • No process or requirement to meet need • Lack of knowledge to design and build inclusive products • People with disabilities cannot use it • But rooted in only 3 of these!

27. Consideration #3 Plan for multiple purposes

28. audit::before { content: “Considerations”; } Objective • Obtain appropriate amount, type, and level of information for short term risk mitigation and guidance of the transition to an inclusive steady state at the lowest possible cost and with the least disruption to daily activities.

29. audit::before { content: “Considerations”; } Measure short term risk exposure • Age of problem • Unknown (end user acceptance, workaround) • Recent addition (last straw) • Complaints • Formal: legal action (fewer options) • Informal: customer feedback, social media chatter

30. audit::before { content: “Considerations”; } Determine organizational risk tolerance • In production now approaches • Stop everything, house is on fire ($$$$) • Time is of the essence management – special remediation project(s) • Correct with intent, during normal course of business • All possible with multiple domains • Determined by exposure + tolerance for each asset • Exposure + tolerance factors also define scope of remediation effort

31. Consideration #4 Use risk exposure & tolerance to inform LOE balance between remediation & prevention

32. audit::before { content: “Considerations”; } Further refine remediation scope: consider the 3 Rs • Retire • Expected shelf life of page/feature/app • Replace • Known redesign or changes in pipeline • Repair • Audit remaining assets from original remediation scope

33. audit::before { content: “Considerations”; } Objective • Obtain appropriate amount, type, and level of information for short term risk mitigation… • What to audit determined by urgency, scope of remediation effort, 3 Rs • Only audit minimum necessary for short term remediation • “… or guidance of the transition to an inclusive steady state…” • 100% of effort prevention focused • Audit to focus/prioritize training and prevention efforts

34. Consideration #5 Is ANY remediation necessary?

35. Consideration #6 Establish process & oversight • Set expectations, provide a rubric to define • Requirements • What will be tested • How it will be tested • To launch or not to launch • Allowable # / type issues • Exception process

36. Consideration #7 Prioritize risk exposure (no legal action) • WCAG Level A & AA Success Criteria • Customer feedback • Top 5 or 10

37. Consideration #8 Major architecture/code base project(s) pending, recently started

38. Consideration #9 3rd party content vetting new vendor & contract renewals

39. Consideration #10 Change the culture! • Audit to fix today and tomorrow • Plan for training based on audit findings • Design it, build it, and test it for inclusivity starting now • Or we’ll have to do this all over again, real soon

40. Thanks for attending! ???