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.
2. "It can be difficult to know where to start,
and more difficult to know where to stop."
- Chetan Bakhru @cbakhru
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/
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. 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!
11. Support for additional combinations will
likely impact effort, cost & timelines
Development QA
Customer/user
support teams
Project
delivery
timelines
Tools &
training
12. Levels of support
• Full
• Reduced
• Targeted
• On Demand
• None (at this time)
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. 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
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. 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. iOS 9 adoption – almost overnight
https://mixpanel.com/trends/#report/ios_9
20. Android adoption – a different story
https://mixpanel.com/trends/#report/android_os_adoption
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
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
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. 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. Each organization or team needs
to make its own call on what is
the right baseline.