Is Screen Reader Testing Enough

CSUN, March 2014
Is Screen Reader Testing Enough?
© 2014 Interactive Accessibility

Why Accessibility?
•
•
•
•
•
•
Meet the needs of people with disabilities
Right thing to do
Organizations / governments require accessibility
Legal compliance
Good PR
Access to talent
© 2014 Interactive Accessibility 2

End goal is to make products
usable for people

And That Includes People with Disabilities
•
•
•
•
•
Blind
Low vision
Deaf and hard of hearing
Mobility impairments
Cognitive impairments
Who are your
users?

But, what does that mean?

People with Disabilities Use Tools
•
–
–
–
–
–
•
–
–
–
–
–
Hardware
Switches
Refreshable Braille
Alternative keyboards
Trackballs
Eye tracking
Software
Screen readers – JAWS, Window Eyes, NVDA, VoiceOver, System
Access, Talkback
Screen magnifiers – ZoomText, MAGic
Dragon Naturally Speaking
Learning/Literacy software – Kurzweil, Read & Write Gold, Natural Reader,
Wynn
OS settings
Assistive Technology
(AT)
Tools that people with
disabilities use to access
digital communications

Key Questions
Compatibility testing with AT can be challenging!
1. Is it enough to test with only screen readers?
2. What is a good testing strategy?

Accessibility Dependencies
Assistive
Technology
Browsers
Accessibility
APIs
Code /
Platform
• Many factors that impact the end user experience

So testing with one screen
reader may not be enough…

Poll – What is your test matrix?
Active Participation! Let’s talk!
•
•
•
•
How many of you test with assistive technology?
How many test with:
–
–
–
–
–
–
–
–
–
Only screen readers?
More than one screen reader?
Screen magnifiers?
Dragon Naturally Speaking
Other AT?
How many test with more than one browser?
IE, Firefox, Chrome, Safari, Other?
What about different versions of the browsers and AT?
Latest versions only?
2 versions back?
More versions?

Test Strategy
Conformance to the
WCAG 2.0 Success Criteria
Make sure the product is
accessibility supported
Offer accommodations

Conformance Testing
•
•
•
Meet WCAG 2.0 success criteria
–
•
•
–
–
–
–
Conformance level: A, AA, AAA
Full pages
Complete processes
Follow techniques and best practices (but not required)
Use automated tools and favelets to check for
compliance
Use a screen reader during testing
Dynamic content
Page interaction
Reading order

The Challenge
No one says…
What to test
or how much
is enough
© 2014 Interactive Accessibility
13

WCAG 2.0 Accessibility Supported
•
•
–
–
W3C WCAG 2.0 doesn’t specify how much / how many /
which AT a technology must support to be “accessibility
supported”
Accessibility supported means:
Content is defined in a way that makes it possible for AT &
user agents (e.g. browsers) to successfully present the
content’s information to the user
AT/user agents can understand and use the information (e.g.
text alternatives)
For more, see http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

Section 508 Functional Performance Criteria
•
–
–
–
–
–
•
First, the paraphrased definition (§ 1194.31)
Mode of operation & information retrieval not requiring vision, or
AT support for blind/low vision
Mode not requiring better than 20/70 vision, or AT support for
visually impaired
When audio is important, a mode for enhanced audio or support
for hearing AT
Mode not requiring speech or support for AT
Mode not requiring fine motor control or
simultaneous actions - that works with limited
reach & strength
But what does this mean in practice?

Combinations – oh the math…
The number of combinations can be daunting and
infeasible
•
•
•
•
Operating systems
Devices / platforms
Browsers
Assistive technology
Each has multiple versions!

Factors in Determining What to Support
•
•
•
•
Support varies by environment and by language
New technology is often unsupported in older AT
Support for a single AT is usually insufficient
Support by affordable AT is often poor
So what should we design for?
What should we test?

Defining Test Suite
•
•
Product requirements
–
–
–
–
–
What operating system(s) does the product run on?
Which browsers does the product support?
Who is the target audience?
Assistive technology requirements
What does the assistive technology support?
What combinations are used by most users?

Approach to Testing
•
•
Start testing with screen reader
–
–
–
–
Determine what issues need to be fixed
Document accessibility support
Expand testing scope after issues have been fixed
Fixing issues found in screen reader testing will increase
likelihood that it will work better in other AT
Screen reader testing will catch most issues

Assistive Technology Checklists
•
•
•
•
•
•
Screen Reader Testing
Screen Magnifier Testing
Keyboard Testing
Dragon Naturally Speaking Testing
No Sound Testing
Text-to-Speech (Learning/Literacy
Software)
http://www.interactiveaccessibility.com/downlo
ad-assistive-technology-testing-checklists

Challenges Testing with Assistive Technology
•
–
–
•
•
Determining the issue can be difficult
Is the problem in the code?
Is the problem in the browser or assistive
technology?
Fixing the issue in the code cause
issues in other assistive technology
New versions of browsers and assistive
technology can introduce new issues

Fixing Issues
•
–
–
•
–
–
Determine the severity of the issue
Where does the issue occur?
Will the issue prevent a user from accessing or interacting
with the product?
Submit bugs to AT and user agents
Accessibility bugs will not get fixed unless we report issues
Send examples where possible

Conclusions
•
•
•
Accessibility support should be defined
for each product
Start small then expand to other AT
Provide a way for users to submit
feedback

Questions
Kathy Wahlbin
kathyw@ia11y.com
Slides: http://www.slideshare.net/kwahlbin

Are your sites accessible?Thank you!

Is Screen Reader Testing Enough

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to Is Screen Reader Testing Enough

Similar to Is Screen Reader Testing Enough (20)

Recently uploaded

Recently uploaded (20)

Is Screen Reader Testing Enough