accessibility testing in the real world angela m. hooker @accessforall angelahooker.com accessing...

Accessibility Testingin the Real World

Angela M. Hooker@AccessForAll

angelahooker.com

Accessing Higher Ground – #AHG11November 2011

2Accessibility Testing in the Real World / @AccessForAll

Real world fact:What is accessibility testing about?

It’s about the people!

• The goal of every web project is to provide access to information

• We’re testing to uncover issues that would bar people from that information

• Find out the needs of your current audience• Learn about the needs of all users to broaden your

audience– People who are abled– People with different abilities:

• Aging: http://www.w3.org/WAI/posts/2009/older-users-online

• Cognitive: http://webaim.org/articles/cognitive/• Auditory: http://webaim.org/articles/auditory/• Motor: http://webaim.org/articles/motor/• Visual: http://webaim.org/articles/visual/

• Learn how people with different abilities use the web: http://www.w3.org/WAI/intro/people-use-web/Overview.html

What is the desired outcome from accessibility testing?

Provide equivalent access

• Make sure that people—no matter what their abilities are—can use your site/app/project

• The equivalent functionality should provide your users the same information

The ideal process—your goal(simplified for thispresentation)

Your goal: The ideal process

• Plan/gather requirements with the decision makers, stakeholders, designers, developers, content providers

• Help determine your users’ top tasks• Review the information architecture • Analyze the resulting wireframes• Conduct paper prototype (wireframes) user testing• Test the color scheme• Assess the design mockups

• Review the final written content• Conduct more informal user testing (test the

mockups, writing, information architecture)• Review the templates (including ARIA);

validate/remediate the (semantic) code– Just because your code validates doesn’t mean your

project is accessible—validate anyway!– Just because your site doesn’t validate doesn’t mean it’s

inaccessible—validate anyway!• Review the style sheets; validate/remediate the styles

• Test with automated accessibility tools• Review the scripting (JavaScript, AJAX, jQuery,

YUI, whatever); add more ARIA, if needed• Test again with automated tools• Test with assistive technologies• Test on mobile devices and e-readers• Test with real people, including several people

with different disability types• Continue to improve and test after the launch

The real world …

(The phone rings, but it’s drowned out by Angela’s sweet snoring. The caller mumbles, “I knew it. I got her voice mail.”)

“Hi, Angela! It’s Devin. Look, I’m sorry to call you so early this morning. I didn’t even think I’d be up at 6:30 AM, but, uh, that’s how I roll. Heh heh heh (awkward silence).

“Yeah, so, we just wrapped up the banking app last night. Oh, wait; I forgot to tell you that we were working on this app. Well, anyway, I wanted to give you a shout out so you can finish your testing by 11 this morning, and by noon we can fix any of those crazy issues you always find. And that means we can launch the app by about 1 PM, once we give the press office the word.

“So, uh, gimme a call when you’re coherent [yeah, right], and I’ll send you the test server log in. Thanks, Angela! Oh, and the sooner you can get that report to me, the better. I’ve told Hank [Angela’s supervisor] about this, so he’s expecting that report, too (fake laugh). Later, Ange!”

Be ready for that scenario—it’s going to happen.

The real world …

• That’s a typical day for many of us—despite the fact that we know, and tell others, that accessibility reviews and testing can’t wait

• I’ve also heard: “I’m not even an accessibility person. They just added this to my job, and I don’t know what to do!”

The real world: Why?

• Last minute requests for testing come because of:– Urgent projects– Politics and power plays– Being constrained by technologies used by your

organization– Poor planning by project managers– Not understanding accessibility:

• “It’s expensive”• “It’s time consuming”

The real world: What to do?

• When you can’t fix everything NOW, repair items that will make the biggest impact– Testing and remediating these few items can make

a big impact on accessibility without having to rebuild your site immediately:• Structure: <h1> … <h6> headings• Navigable items: the dotted outline appears• All non-text elements: alternative text• Forms: label tags, fieldsets/legends, error messages• Text and graphical elements: color contrast

The real world: What to do?

• Determine other manageable tests and fixes– Identify the critical issues that cannot wait– See Dennis Lembree’s “25 Ways to Make Your Website

Accessible”: http://weba.im/25axs– See Todd Kloots’s “Easy Fixes to Common Accessibility

Problems”: http://weba.im/CommonAccessFixes– Prioritize your testing and remediation by

–Essential functionality–Your users’ top tasks–The most used pages–Critical information

Creating a “new reality”(fixing the real world process)

Building this new process is not going to happen overnight … but it will ensure that your future project testing will go faster

Just like you’ll prioritize the real world fixes, prioritize the steps for your new plan

Be empowered

• Be ruthless, zealous, and thorough in your testing

• Be ready for backlash– People won’t want to hear comments they

perceive as critical of their work• Your work can protect you and your

organization from negative repercussions resulting from accessibility problems

Don’t be an island

• Get everyone involved– Make everyone responsible for a piece of the

accessibility pie– This will change the mindset right away—people

will realize that implementing and testing for accessibility shouldn’t be an afterthought

– Accessibility Responsibility Breakdown http://alpha.gcwwwtemplates.tbs-sct.ircan.gc.ca/theme-clf2-nsi2/accessRespBreakdown-eng.html

Influence “the man”

• Get your supervisor’s support• Until decision makers see accessibility as a

priority, you’ll always have a battle– Accessibility in a Suit and Tie

http://thinkvitamin.com/design/accessibility-in-suit-and-tie/

– Resources for Developing a Web Accessibility Business Case for Your Organization http://www.w3.org/WAI/bcase/resources

– Improve Sensitivity Toward People with Disabilities http://www.slideshare.net/srains/top10-reasons?from=ss_embed#text-version

Help your colleagues …

• What can you do to bridge the gap between people, departments, and philosophies?– Sometimes an accessibility consultant has to be a

counselor, evangelist, educator, and a maverick (among other roles)

– Make sure you’re not being a nag– Give your colleagues useful information and

solutions—not headaches

Help your colleagues …

– Stand against any existing “us versus them” vibe– Create a “no shame; no blame” atmosphere– Make sharing your testing results a time to

educate—don't make “Devin” feel like an idiot

Develop a policy and process

• Write an in-house policy (not an accessibility statement that your users see)– Developing Organizational Policies on Web

Accessibility http://www.w3.org/WAI/impl/pol

Develop a policy and process

• Develop (and iterate) your process—one that fits accessibility throughout every project’s life cycle– You’ll save money from not making costly

accessibility fixes later– Having a solid process will fight the “accessibility is

time consuming” myth– Just Ask: Integrating Accessibility Throughout

Design http://www.uiaccess.com/accessucd/

Build a code library

• Focus on developing reusable solutions for your developers: build it once; use it again; accessibility tweaks will be minimal

• Use code generators (see the tools at Accessify http://accessify.com/tools-and-wizards/)

Refer to personas

• Take advantage of user personas– Aids in remembering all users throughout the

process– Personas of Persons with Disabilities

http://curbcut.net/accessibility/personas-of-persons-with-disabilities/

– Accessibility in User-Centered Design: Personas http://uiaccess.com/accessucd/personas.html

– Dive into Accessibility: Introduction (see “Character Sketches”) http://www.buurenvan.nl/helptools/accessweb/Dive%20Into%20Accessibility/introduction.html

Use a checklist, but …

• Checklists versus usability and access:– Use a checklist when testing, so you don’t forget

anything– Remember: You can satisfy every requirement and

still have accessibility problems– Don’t lose sight of your project being usable and

the ability to access your information and complete tasks

Select the proper tools

• No one tool can adequately test your project—also review everything manually– See “The Importance of Human Evaluation”

http://webaim.org/articles/process/human• Make the most of the free tools

• Issues to consider when selecting a tool:– How much time do you have to learn the tool?– What type of error reporting do you need

(detailed output or a tool that flags errors on screen)?

– Do you need a tool that automates repairs?– Do you have large projects with frequently

updated pages?

• Issues to consider when selecting a tool:– Do you have static pages?– How many people will update your content?– Are there demos (online or in-person events)

available for the tool?– Can you use an evaluation version before you

purchase the tool?– Do you know what functionality you need in the

product?

• An enterprise tool will work well for:– A large organization that has several sites or a

large site• The free tools will work well for:– An organization that uses a template-based

system

Test with real people, too!

• Testing with people with disabilities will help you find errors that you may miss

• Recruit people with different disability types• Go to Twitter and other social media outlets• Ask your friends and family

Test with real people, too!

• Recruiting Participants http://dev.opera.com/articles/view/26-accessibility-testing/#recruitingtesters

• Screening Participants http://uiaccess.com/accessucd/ut_ppt-screen.html

Don’t forget: evaluate written content

• Oft forgotten part of accessibility testing• If you’re not well-versed in– Editorial principles– Plain language– Understanding the impact of cognitive disabilities– Low-language proficiency– Low-literacy– Non-native language speakers… then have someone else review your content from these viewpoints

Document your testing

• Write testing scenarios, based on the standards– Pre-determine what satisfies conformance

• Track issues and fixes• Use logs• Prepare your logs with fine details• Keep these logs forever– Depending upon your work setting, they may save

you later by proving your due diligence

Document your testing

• If you have a vendor perform testing for you, make sure they document their testing and give you raw data as well as detailed reports– Put this in the project contract– Make sure you—not the vendor—are responsible

for determining what testing results satisfies conformance with testing criteria and standards

Maintain and improve your project

• Continue testing—don’t stop because the project ended

• Consider what testing is appropriate given your project’s size, frequency of updates, your workload …

• Have a “hack day” event: Pick one of your projects, invite people inside and outside your organization, and work together to fix its top accessibility problems

Continue to educate …

• Sponsor “brown-bag” events to educate your colleagues, including management– Schedule regular lunch time events, and give

presentations on accessibility topics– Call on other accessibility consultants to speak at

these events

For the decision makers

Decision makers: support your team

• Give your staff freedom– Trust them to do their jobs

• Allow the testers, designers, developers, accessibility consultants, and usability specialists to be involved in the project from conception– Don’t bring them in at the 11th hour—you’ll be wasting

your company’s time and money• Provide training for your employees, and respect

that people learn differently—some enjoy self-study; others may need or want a formal class

Decision makers: support your team

• Give your accessibility team the authority to make decisions and advise your entire team– Don’t create an environment where people are

afraid or powerless to make suggestions, or improve the team’s projects

– Remember, this is for your users and your company’s benefit, which will make you shine

Resources

Resources: standards

• Web Content Accessibility Guidelines (WCAG) 2.0– The Pickards’ WCAG 2.0 Lite (a stripped-down,

easy to read version of WCAG 2.0)• W3C Mobile Web Best Practices

http://www.w3.org/TR/mobile-bp/

Resources: checklists

• WebAIM’s WCAG 2.0 Checklist• Aaron Cannon’s Accessibility Checklist• 3pha’s WCAG 2.0 Quick Reference (This tool

allows one to choose a level of WCAG 2.0 conformance [A, AA, or AAA], and provides the applicable criteria and an explanation of each guideline.)

Resources: tools—reviews

• A Review of Free, Online Accessibility Tools http://webaim.org/articles/freetools/

• iCITA Functional Accessibility Evaluator (review by Joe Dolson) http://www.joedolson.com/articles/2007/11/an-example-of-automated-accessibility-testing/

Resources: tools

• W3C-Web Accessibility Initiative (WAI)– Selecting Web Accessibility Evaluation Tools

http://www.w3.org/WAI/eval/selectingtools.html– Web Accessibility Evaluation Tools

http://www.w3.org/WAI/ER/tools/– Web Design References: Tools

http://www.d.umn.edu/itss/training/online/webdesign/tools.html

Resources: tools—my favorite

• Caveat: These are my favorite, but I use others• Favelets for Checking Web Accessibility

http://jimthatcher.com/favelets/index.htm• Juicy Studio Accessibility Toolbar (Firefox)—

reviews ARIA, data tables, and color contrast https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/

• WebAIM WAVE: Check your page online, by upload, with the WAVE toolbar http://wave.webaim.org/

• Web Developer Toolbar (Firefox and Chrome) http://chrispederick.com/work/web-developer/

• Deque FireEyes (Firefox) http://www.deque.com/products/worldspace-fireeyes

• WebAIM Color Contrast Checker http://webaim.org/resources/contrastchecker

• Accessibility Color Wheel http://gmazzocato.altervista.org/colorwheel/wheel.php

• Wickline Color Blind Web Page Filter http://colorfilter.wickline.org/

• Firebug (if you use FireEyes on the Mac, be sure you have the right version of Firebug) https://addons.mozilla.org/en-US/firefox/addon/firebug/

• Web Accessibility Toolbar (WAT)—IE http://www.paciellogroup.com/resources/wat-ie-about.html

• Trace Photosensitive Epilepsy Analysis Tool (PEAT) –tests flashing content http://trace.wisc.edu/peat/

• My trusty keyboard (yours, too)

Resources: conducting user testing

• Rocket Surgery Made Easy, by Steve Krug• Fast, Good, and Cheap

http://www.useit.com/alertbox/fast-methods.html

• Paper Prototyping http://www.useit.com/alertbox/20030414.html

• Quick and Dirty Remote User Testing http://www.alistapart.com/articles/quick-and-dirty-remote-user-testing/

Resources: glossaries

• Web Accessibility and Development Glossary http://www.joedolson.com/glossary.php

• Glossary of Commonly Used Accessibility Terms http://www.doit.wisc.edu/accessibility/online-course/glossary.htm

Resources: test plans/preparation

• Web Accessibility Initiative (WAI), Evaluating Websites for Accessibility http://www.w3.org/WAI/eval/

• Central Office of Information (COI), Delivering Inclusive Websites http://coi.gov.uk/guidance.php?page=134

• Henny Swan, Establishing a Screen Reader Test Plan http://www.spotlessinteractive.com/articles/accessibility/screen-reader-test-plan.php

• WebAIM, Web Accessibility Gone Wild http://webaim.org/articles/gonewild/

Resources: logs/documentation

• The Pickards’ Accessibility Testing Log http://www.thepickards.co.uk/index.php/200909/accessibility-testing-log/

• Template for Accessibility Evaluation Reports http://www.w3.org/WAI/eval/template

Thank you!

Angela Hooker@AccessForAll

ange@angelahooker.comangelahooker.com

accessibility testing in the real world angela m. hooker @accessforall angelahooker.com accessing...

accessforall slide

launch accessibility

styles accessibility

real people

real world angela

real world thats

real world fact

accessibility reviews

Documents

mary hooker, gesci mary.hooker@gesci.org

h. s. hooker

917-843-5943 jane lee hooker - something...

chapter iv richard hooker

mary hooker

before & after - william hooker

“the hooker” - galfab

lj hooker casino

taylor on hooker

dr. neal h. hooker - john glenn college of public...

hooker, 'systematic realism

hooker v bofa and mers

thomas hooker

lj hooker 2

lj hooker magazine week 44

lj hooker dural & cherrybrook

hooker taxonomy&nomenclature seminarsection1

ux + your team = accessibility! angela m. hooker,...

kb hooker - professional services marketing

accessforall 3.0