Simplifying the Web Accessibility Test LabMitchell Evan and Kevin Chao

JPMorgan Chase

#csun14 #ATtestlabsnipurl.com/ATtestlab

For details in the slide notes, download the PowerPoint

With limited resources, how do we support limitless diversity of AT users?

• What we’re doing today• What we can do better

Two requests

1. Challenge your own assumptions.

2. Challenge me. How can we keep improving?

Simplify.

Simple for an organization

=

Simple for a customer (client, etc.)

=

It takes a lot of work to make it simple.

Browser RecommendationsWe have detected that you are using a browser which is not compatible with our application. Our application requires that you use Internet Explorer version 8.0 or greater

Nice and simple for the organization!

BYOD:

Bring Your Own Device

BYOC:

Bring Your Own

Combo

hardware + browser + assistive tech

BYOB

What goes into the combos?• Desktop and mobile operating systems (OS)• Browsers• AT software and hardware -- for vision, learning, and mobility• Versions• Configurations

Potential combos

Windows: 1200Mac: 150Linux: 10

iOS: 12Android: 5000Symbian: 4

Conclusion: Give up.

Thank you.

Mitchell Evan @MitchellREvanKevin Chao @KevinChao89

Just kidding!

Diverse people use diverse technology

Diversity matters.

Simulate diversity

>

You can’t test all combos...

...but consider all of the potential combos, when you plan your testing.

You get to choose.

The WCAG Working group and the W3C do not specify which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported.

Web standards are essential……but you still have to test.•Make sure it’s usable•For WCAG conformance, it must work in AT.

Only accessibility-supported ways of using technologies can be relied upon for conformance. -- WCAG 2.0 (normative)

Principles

Quiz: What does “A 11 Y” stand for?

1) Accessibility

2) Affordability

Financial barriers

Support by just one assistive technology (for a given disability) would not usually be enough, especially if most users who need it in order to access content do not have and cannot afford that assistive technology.

Principles

1. Make it affordable.2. Support every disability group.3. Include a free AT for each disability group.4. Focus on popular, capable combos.5. Browser versions: use the same list as the rest

of your organization.6. AT versions: Current minus 2 versions? Or

current minus x years?

Put the principles into practice

Principles

Matrix

Efficiencies

Choose your Big Matrix

• Chop out combos that are irrelevant for your organization.• Expect customers to upgrade.• Define “incapable” combos closer to the cutting edge.

Survey: what do you use for testing?

Org Test Suite or Support PrincipleYahoo! NVDA, FF on PC; VO & Saf on

Mac; VO & Saf on iOS;TalkBack & FF on Android. Spot check JAWS; Chrome Android. Latest versions.

Affordable

Intuit JAWS + IE, older and newer versions. NVDA lastest version. Firefox, Chrome, Safari latest versions.

Capable: needs to work with ARIA.

UC Berkeley

Internal: latest versions only Providing AT directly to community

Survey: what do you use for testing?

Org Test Suite or Support PrincipleBank A Desktop screen readers, iOS,

mobile keyboardsCapable: work reasonably well with ARIA

Bank B Desktop screen readers (first round plus spot check), iOS, Android

Capable: work with older versions

publisher Screen readers (vision and dyslexia use cases), screen magnifiers, switch access, voice control, literacy aids, browser settings

Support many groups

Which of these organizations did it the right way?

Answer: All of the above

Prevent bugs in the first place• Train your managers, designers, and developers• Write standards-based code.

Efficiencies

Pure time savings• Test UI components at the framework level.• Phase your testing.• Test two configurations a the same time.• Write custom-scripted automated tests.

Efficiencies

Lower priority of some combos• Assume similar combos will give similar results; concentrate on combos that are more different from each other.• Bookend strategy: skip the middle version.

Efficiencies

Accept some defects• Embrace “graded AT support”• If you write “good code” and it fails in one AT: “not my problem”

Efficiencies

Reduce scope of testing• Deep test your framework. Anything that’s not framework, test more lightly.• With each release, rotate which combos you test with.

Efficiencies

Reduce more drastically• Test the Accessibility API directly• Heuristic evaluation• Trust what you read on the web.• Let your customers test for you

Efficiencies

Talk to your customers

• On your accessibility page, be straightforward about what you do and don’t support.

• If you offer live customer support, make sure they are trained.

Listen to your customers

• Online feedback form• Customers submit issues directly to an issue

tracking system

Future efficiency: Element-Level Support

One way for authors to locate uses of a technology that are accessibility supported would be to consult compilations of uses that are documented to be accessibility supported.– WCAG “accessibility supported”

Another explosion!

• 107 HTML elements• 61 ARIA roles• 35 ARIA states and properties• 50 JavaScript interactions (estimate)

Crowdsourced element testing

Envision the result

Crowdsource element

testing

Publish known issues

Fix the frameworks

Fix the Internet

Users find what we missed

Fix the AT, browser, or

OS

It’s starting now• TPG Bug Bash: Tonight 5:30-6:30, Suite 3233 Harbor Tower• Saturday hack-a-thon: Launch the Open Accessibility Testing initiative

DiscussionHow can we simplify, yet test well?How do we advance quality and affordability?

#ATtestlabsnipurl.com/ATtestlab

Mitchell Evan @MitchellREvanKevin Chao @KevinChao89