W4A 2010 Education Tool to Support the Educational Process Chris Bailey

Christopher BaileyDr. Elaine Pearson

Teesside University

c.p.bailey@tees.ac.uk

An Educational Tool to Support the Accessibility Evaluation Process

Main Issues

• Guide novice auditors through an evaluation, raise awareness of accessibility.

• Compile a detailed list of checks based on testing for well known accessibility principles

• Support a contextual approach to evaluation.

• Our students need support with accessibility:

– Little existing knowledge of accessibility– Develop live websites for specific audiences– Accessibility personally a low priority– Limited access to disabled end users– Limited access to expert reviewers

Functionality (1)

• The tool lists accessibility checks based on three evaluation contexts:

– User Group– Site Features– Check Categories

• For each check, the tool:

– States the impact the issue has on users– Provides instructions on how to perform each check – Assists auditor in interpreting result of any

automated check– Includes a video ‘how to’ walkthrough

Functionality (2)

• Auditor records results of checks as they progress.

• Print a template, or completed evaluation report.

• Supports multiple users

• Supports multiple site evaluations.

• User can save/retrieve evaluations.

Evaluate by User Group• Auditor views prioritised checks for one user group

• Compare different requirements of two user groups.

• Importance of check is dynamic:

– Critical Checks: Complete barrier, significant annoyance to user.

– Important Checks: Noticeable annoyance or inconvenience

• Allows auditor to see commonalities, but also identify exceptions.

• Utilises the full database of checks, supporting the concept of universal accessibility

• Checks are grouped to make process simpler and intuitive

– Design Checks: overall visual design, e.g.: colour contrast– User Checks: testing with a human element, e.g.: keyboard

accessibility, image text alternatives– Structural Checks: structure of web pages, e.g.: semantic HTML– Technical Checks: coding elements, e.g.: valid mark-up,

metadata– Core Checks: Overall accessibility of site, e.g.: site map,

accessibility statement

• Considers roles in web development team

Evaluate by Check Categories

Evaluate by Site Features

• Auditor selects elements of their site they wish to check, e.g.: data tables, forms.

• Auditor selects content features of their website, e.g.: video files.

• Checks are tailored to content of website:

– Prioritises relevant checks– Streamlines process– Increases relevance– Eliminates redundancy.

Future Work• “Dogfooding” – Create accessible RIA

• Further development of tool over next 2-3 months.

• Used for teaching Post Graduate students.

• Expanded to include checks for other contexts, e.g.: WCAG 2.0, Mobile Devices, RIAs.

• Test the performance of the tool:

– Is it effective?– Are results consistent?– Compare with existing evaluation methods.

Christopher BaileyDr. Elaine Pearson

Teesside University

c.p.bailey@tees.ac.uk

An Educational Tool to Support the Accessibility Evaluation Process

AEA Interface (1)

• Example comparison of high priority checks for Dyslexia and Screen Reader User groups.

AEA Interface (2)

• For each check the following information is provided:

– Why the check is necessary– Step by step instructions on how to carry out the check– A video walkthrough

AEA Interface (3)

• The AEA contains an integrated reporting mechanism so the auditor can record their results as they complete an evaluation.