Accessibility Challenges and Tool Features: An IBM Web Developer Perspective

IBM Research: Accessibility Tools

Accessibility Challenges andTool Features: An IBM Web

Developer Perspective

Shari Trewin,Brian Cragun*, Cal Swart,

Jonathan Brezin, John RichardsIBM Research / *IBM HumanAbility & Accessibility Center


Web Content Evolution


IBM Human Ability andAccessibility Center

• Tools, techniques and training• Unified technology-specific checklists• Test processes• Compliance tracking


Developer Survey

49 RIA developers from Rational, Lotus, Cognos, Websphere, Tivoli

11

15 111

1

2

8


Expertise

• 7.3 yrs Web development experience• 4.1 yrs RIA/DHTML experience

AccessibilityExpert

Novice

Intermediate


Tools Used

AutomatedTestTool

AssistiveTechnology

62% 16%11%

8%

None


Information on Requirements

• 68% used IBM’s CI162 checklists andguidelines,

• 35% referred to W3C Web pages describingaccessibility standards, and

• 14% reported using accessibility informationfound via Google searches.

Other external sites included the Section 508standards, Java and Dojo documentation.


Main Browser for Development

Firefox

Firefox& IE

IEMulti


Creating an Accessible Product

12%Understandingrequirements

21%Making time/prioritizing

27%Findingworkarounds

30%Using the testtools

30%DesignCited byDifficult aspects

12%False positives9%Cross-browser

support

12%Setup18%Retrofitting

21%Technologyworkarounds

30%Testing

Citedby

Time consumingaspects


Limiting Factors

• 78% wanted to do more on accessibilitybut were limited by:– Lack of time (48%)– Limitations in the technology (30%)– Lack of knowledge (15%)– Budget (15%)– Conflicts with other requirements (11%)


Testing is Still Too Hard

“Running [assistivetechnology] and [test tool]took the most time. Anycoding done foraccessibility was morestraightforward than usingthe tools.”


Trouble Using AT

Assistive Technology

Web App

Browser

“The screen reader behavior wasnot entirely well-defined andsometimes inconsistent. Forexample, there were instanceswhere it read twice and sometimesdid not read at all (withoutapparent reason).”


AT

AppBrowser

Hard to Pinpoint Problems

Templates3rd party

components

Widgets

Application state

User-generated content

Technologies

“we don’t even knowif it is the browser,Flash, or it is thetechnology that weare using is havingthe problem”


Accessibility is a MovingTarget

“[test tool and assistive technology] don't always work as wellas they should. [assistive technology] does not yet take intoaccount all the latest WAI-ARIA roles and specifications thatwe must follow. It can also be buggy and read things offincorrectly. [test tool] reports errors that are sometimesambiguous and/or unnecessary.”


What Do Developers Want?

Suggested features:– List of automatically detected problems– Explanation of each problem observed– Ability to pinpoint errors– Visualization of experience of user with a disability– Tight integration with development environment– Checklist of manual checks– Example solutions– Ability to automatically test all possible states– Ability to run a predefined interaction sequence– Indication of problem severity


Tool Features


Tool Features

Score is a weighted sum of positive

responses


Tool Features

Most valued features: list of automatically

detected problems and explanation


Tool Features

Experts gave higheroverall ratings


Tool Features

Accessibility experts valued visualization,

others less so


Tool Features

Integration with development environment

not a priority


Other Suggestions

“would like a tool that would suggest addingARIA roles and appropriate properties to htmltags inside of [development environment]”

“I would like to see a mapping tool that wouldmap out your site based on the navigation ofa person using accessibility tools. So wewould check what they are reading and if theyget where they need.”


Caveats

• Small sample• Not a representative sample

– of RIA developers, or IBMers• Accessibility expertise was self-reported• Under-reporting of information-finding

problems


Accessibility Test Tools

• Developers want– more usable tools– list of problems and GOOD explanation– avoid false positives– ability to pinpoint errors– more automation

• … not dynamic support features?


Visualize User Experience

“ … more useful than a product that tries to magically find problems.”“… needs to be easy though. If this is extremely difficult to configure

or perform most individuals won't do it or will perform the test toolate.”

0

5

10

15

no maybe yes important essential

Value of this feature

Nu

mb

er

of

rep

on

se

s

expert

intermediate

novice


Enhance Understanding

Suggest logical sequence of steps

Highlight problems

Shows user’s view

Describes what to check

Offers solutions


Accessibility Infrastructure

• Workarounds are a major source of difficulty• Conforming to a standard should be sufficient• Need to work towards consistent, complete

cross-browser implementations of standards• Invest in accessible widget libraries and

platforms


Main Findings

Tools are essential, but …– startup cost for testing is significant– Problem understanding is vital– false positives are a big problem– can’t pinpoint source of the problem


Research Topics

• Greater automation of accessibility tests• Ways to develop expertise through

using the tools• Predict/simulate how assistive

technologies will behave• Simple visualizations• Investigate false positives

Accessibility Challenges and Tool Features: An IBM Web Developer Perspective

Technology

accessibility toolstrouble

accessibility toolsexpertise

accessibility toolscreating

accessibility toolswhat

accessibility toolsinformation

accessibility toolstesting

noneibm research

john richardsibm research