Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Accessibility Support Baseline: Balancing User Needs Against Test Effort

2,536 views

Published on

A guided conversation about the accessibility support baseline and an opportunity to find out what others are supporting and to share thoughts and experiences. The support baseline is the term WCAG uses for the set of user technologies that an application is expected to work with, specifically the combinations of assistive technology (AT), operating system (OS) and where relevant browser and device. WCAG doesn’t define what needs to be in the baseline because it depends on your users, and on the technologies available to them.

Is testing only one combination for web and one for mobile sufficient? Changes in desktop screen reader usage, mobile fragmentation, and frequent updates to OS and AT may mean that it isn’t. But there are hundreds if not thousands of potential combinations. How do we balance support for these combinations against testing effort?

We will discuss:
• Who or what does a baseline impact?
• Variables to account for in a baseline
• Effort and costs
• Assistive Technology usage data
• Organizational challenges to supporting AT
• Sample web and mobile support baselines.

Published in: Technology

Accessibility Support Baseline: Balancing User Needs Against Test Effort

  1. 1. THE ACCESSIBILITY SUPPORT BASELINE Aidan Tierney @AidanA11y CSUN March 25, 2016
  2. 2. "It can be difficult to know where to start, and more difficult to know where to stop." - Chetan Bakhru @cbakhru
  3. 3. Accessibility Support Baseline "the minimum set of combinations of operating systems, web browsers, assistive technologies, and other user agents that the website is expected to work with" Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 http://www.w3.org/TR/WCAG-EM/
  4. 4. Examples of 'combinations' Windows 10, IE 11, Jaws 16, Android 5.1.1, TalkBack 4.2, Nexus 6 iOS 9.2.x, Safari, VoiceOver, iPad Air 2
  5. 5. Balancing… User needs & EXPECTATIONS Effort to develop, test & SUPPORT
  6. 6. Lip service Insincere support or respect expressed but not put into practice.
  7. 7. Support Anticipating and addressing user needs & expectations
  8. 8. Evidence of support for AT • We could speak to the person reporting the issue and not say something embarrassing like "what's JAWS?" • We have knowledge of the AT and ability to use it on a device to replicate an issue within a day or two • We have already tested the app with the AT • We can investigate or fix the issue • We have licensing, firewall clearance, and basic training in place for this AT
  9. 9. Assistive Technology (AT) Version # E.g. JAWS 17, NVDA 2016.1 Operating System (OS) Version # E.g. Windows 10, OSX 10.11, iOS 8.4 Browser Version # E.g. IE 11, Chrome 49 Device Mostly for mobile E.g. iPhone 6 Plus, Samsung Galaxy S6, iPad Air 2 Things to account for in baseline And users of course!
  10. 10. Tens or even hundreds of possible combinations
  11. 11. Support for additional combinations will likely impact effort, cost & timelines Development QA Customer/user support teams Project delivery timelines Tools & training
  12. 12. Levels of support • Full • Reduced • Targeted • On Demand • None (at this time)
  13. 13. Support level before & after launch - May not need to be the same • QA before launch • Customer support • E.g. Projects tests with JAWS 17 but will support customers on JAWS 15, 16 also
  14. 14. Level Before launch: QA & Dev After launch: User –reported issues Full QA tests all screens and user flows QA validates & Dev addresses all issues Reduced Scope defined by project Factors to consider: core functionality, templates QA validates & Dev addresses all issues Targeted QA tests only specific content related to known differences for a particular combination Only used before launch. On Demand No QA activity before launch QA validates all issues. Remedial action taken by Dev only where code does not conform to WCAG and where feasible. None No QA activity prior to release. No QA or Dev activity, but Customer Service does support user. Levels of Support Defined 14
  15. 15. WCAG & the baseline It SHOULD work It DOES work
  16. 16. Accessibility Support Baseline MOBILE APPS
  17. 17. OS OS Version Assistive Technolog y (AT) Device Level of Test/ QA Level of user support iOS Latest major version VoiceOver Late- model Full Full Android Latest major version with > 10% share TalkBack Late- model, minimal bloatware Full Full Mobile App Baseline - Basics
  18. 18. OS OS Version AT Device Level of Test/ QA Level of user support iOS iOS 9.x VoiceOver iPhone 6 Full Full Android Android 5.x TalkBack Nexus 6 Full Full Mobile App Baseline – Basics w. specific versions iOS versions stats: https://developer.apple.com/support/app-store/ Android version stats: https://developer.android.com/about/dashboards/index.html
  19. 19. iOS 9 adoption – almost overnight https://mixpanel.com/trends/#report/ios_9
  20. 20. Android adoption – a different story https://mixpanel.com/trends/#report/android_os_adoption
  21. 21. OS OS Version AT Device Level of Test/QA Level of user support iOS Latest major version VO Late-model Full Full iOS Prior major version VO Different, late-model Reduced Full iOS All other versions the app supports None None None On Demand iOS Future version, if expected soon after launch VO Late-model Reduced Full Android Latest major version with > 10% share TB Late-model, minimal bloatware Full Full Android Prior Android version TB Most popular Android device (if known) Reduced Full Android Other versions None None None None Mobile App Baseline - Generic
  22. 22. Accessibility Support Baseline WEB/DESKTOP
  23. 23. OS AT/ mode Browser Level of Test/QA Level of user support Windows JAWS (n-1) IE 11 Full? Full? Windows JAWS (n, n- 2) IE 11 None On Demand Windows NVDA FF (latest) Full? Full? Windows WindowEyes ZoomText? Other AT? OSX VoiceOver Safari Web/Desktop Baseline – fill in the blanks
  24. 24. MOBILE WEB & RESPONSIVE WEB
  25. 25. Responsive web • Browser based • Smartphone, Tablet, Desktop • Breakpoints: – May be more than 3 – Portrait vs. Landscape – Interface components change – Include targeted testing for changes
  26. 26. OS OS Version AT Browser Device Level of Test/QA Level of user support iOS iOS 9.2.x VO Safari Late-model iPad –landscape view Full Full iOS iOS 9.2.x VO Safari Late-model iPad –portrait view Targeted Full iOS Other versions site supports VO Safari Late-model None On Demand Android Android 5.1.x TB Chrome? Firefox? Nexus 10 – landscape view Full Full Android Android 5.1.x TB Chrome? Firefox? Nexus 10 portrait view Targeted Full Android Other versions site supports TB Any Late-model None On Demand Responsive Web for Tablet Baseline - Specific
  27. 27. Each organization or team needs to make its own call on what is the right baseline.
  28. 28. THE ACCESSIBILITY SUPPORT BASELINE Aidan Tierney @AidanA11y CSUN March 25, 2016

×