Is Testing With A Screen Reader Enough?

CSUN, March 2014

Is Screen Reader Testing Enough?

© 2014 Interactive Accessibility

Why Accessibility?

••••••

Meet the needs of people with disabilitiesRight thing to doOrganizations / governments require accessibilityLegal complianceGood PRAccess to talent

© 2014 Interactive Accessibility 2

End goal is to make products usable for people


And That Includes People with Disabilities

•••••

Blind Low visionDeaf and hard of hearingMobility impairmentsCognitive impairments

Who are your users?


But, what does that mean?


People with Disabilities Use Tools

•–––––

•–

–––

–

HardwareSwitchesRefreshable BrailleAlternative keyboardsTrackballsEye tracking

SoftwareScreen readers – JAWS, Window Eyes, NVDA, VoiceOver, System Access, TalkbackScreen magnifiers – ZoomText, MAGicDragon Naturally SpeakingLearning/Literacy software – Kurzweil, Read & Write Gold, Natural Reader, WynnOS 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

APIsCode /

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 SpeakingOther 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 theWCAG 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, AAAFull pagesComplete processes

Follow techniques and best practices (but not required)Use automated tools and favelets to check for complianceUse a screen reader during testing

Dynamic contentPage interactionReading order


The Challenge

No one says…What to test

or how much is enough


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 userAT/user agents can understand and use the information (e.g. text alternatives)

For more, see http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html


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 visionMode not requiring better than 20/70 vision, or AT support for visually impairedWhen audio is important, a mode for enhanced audio or support for hearing ATMode not requiring speech or support for ATMode 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 systemsDevices / platformsBrowsersAssistive technology

Each has multiple versions!


Factors in Determining What to Support

••••

Support varies by environment and by languageNew technology is often unsupported in older ATSupport for a single AT is usually insufficientSupport 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 requirementsWhat 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 fixedDocument accessibility support

Expand testing scope after issues have been fixedFixing issues found in screen reader testing will increase likelihood that it will work better in other ATScreen reader testing will catch most issues


Assistive Technology Checklists

••••••

Screen Reader TestingScreen Magnifier TestingKeyboard TestingDragon Naturally Speaking TestingNo Sound TestingText-to-Speech (Learning/Literacy Software)

http://www.interactiveaccessibility.com/download-assistive-technology-testing-checklists


http://www.interactiveaccessibility.com/download-assistive-technology-testing-checklists

Challenges Testing with Assistive Technology

•––

•

•

Determining the issue can be difficultIs 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 technologyNew versions of browsers and assistive technology can introduce new issues


Fixing Issues

•––

•––

Determine the severity of the issueWhere does the issue occur?Will the issue prevent a user from accessing or interacting with the product?

Submit bugs to AT and user agentsAccessibility bugs will not get fixed unless we report issuesSend examples where possible


Conclusions

•

••

Accessibility support should be defined for each productStart small then expand to other ATProvide a way for users to submit feedback


Questions

Kathy [email protected]

Slides: http://www.slideshare.net/kwahlbin


mailto:[email protected]

http://www.slideshare.net/kwahlbin

Are your sites accessible?Thank you!

Is Testing With A Screen Reader Enough?

Technology

Transcript of Is Testing With A Screen Reader Enough?