EU Flag Seventh Framework Programme logo

[Draft] Analysis for "Accessibility Support Database"

Page Contents

Introduction
General Description
Functional Requirements
Interface Requirements
Technical Requirements

Introduction

Conceptual Draft: $Date: 2012/04/16 07:31:58 $
Status: This document is an in-progress draft and should not be referenced or quoted under any circumstances. Please send comments to wai-eo-editors@w3.org (a publicly archived list).

This is a requirements analyis for a W3C/WAI Accessibility Support Database. It is developed as part of the WAI-ACT Project.

General Description

See also these resources developed as proof-of-concept during the development of WCAG 2.0:

Purpose

To provide a comprehensive, public repository of information on accessibility support in web technologies. The repository will employ collaborative tools that facilitate public input and contribution, to continually expand the repository with updated and new information on accessibility support in web technologies.

Objective

To guide the selection of technologies during the development of accessible websites and web applications. For instance, to help select web technologies that provide support for captions, keyboard support, and support for text alternatives for images with certain combinations of browsers and assistive technologies.

Audience

Primary target audience includes:

Web developers and accessibility evaluators wanting to know how particular accessibility features are supported in specific web technologies;
Web accessibility experts and technology developers wanting to publicly document information about accessibility support in specific situations;

Other audiences includes:

Browser, assisitive technology, and other web technology developers wanting to know how well their products support specific accessibility features;

Scenarios

A web developer wants to know in which combinations of web browsers and assistive technologies a specific WAI-ARIA property is supported, for a specific web technology such as HTML;
A web accessibility consultant wants to know how consistently a specific WCAG 2.0 Technique is supported across most web browsers and/or assistive technologies;
A web accessibility evaluator wants to know if a specific WCAG 2.0 Technique is supported in particular combinations of web browsers and assistive technologies;
A web browser and/or assistive technology developer wants to know if a specific WCAG 2.0 Technique is supported in a particular version of their products;

Challenges

Some of the main challenges of this work include:

Motivating users to run the test files and provide test results
Motivating experts to provide and review test files and results
Highlighting the state of vetting and the currency information
Versioning test files and keeping up with specification updates

Resources

Functional Requirements

Test files that implement specific accessibility features (following the WCAG 2.0 Techniques different format ) are provided for anyone to browse. Users of the repository run these test files (usually a selected sub-set of test files) using different combinations of web browsers and assistive technologies. Users can contribute the outcomes (test results) of these test runs into the repository to extend the data in the repository. Users can also contribute test files, and they can rate test files and test results contributed by others.

All contributed test files, test results, and ratings are provided through an interactive web interface. The level of confidence in test files and test results (ratings) is prominently displayed to avoid misguidance. In particular, test files with conflicting test results are prominently indicated to caution users and to encourage further investigation into the reasons of these conflicting test results (such as bugs or required settings in browsers and assistive technologies).

Authenticating Users

Users do not need any authentication to browse through the test files, test results, ratings, and profiles of registered. Users need to login using a W3C User Account different format to contribute test files, test results, and ratings. Users can login or create an account at any time without interrupting the current task. For example, users do not need to re-run test files to contribute the results, if they were not logged in before running them.

Super Users

There are users with additional previliges such as approving contributed test files, and removing test files, test results, ratings, and if needed also users. The interface for these super-users needs to be determined.

Browsing Repository Data

Users can browser through the test files, test results, ratings, and registered user profiles (without need for authentication). Users can select any sub-set of test files by browser, assistive technology, web technology, and WCAG 2.0 Techniques different format , and view reports of the corresponding test results. Reports provide higher-level aggregation of the test results (such as percentage of positive ratings for a particular combination of test files, web browsers, and assistive technologies, and users can drill down into further details to view specific test results. See more information about the test result reports.

User Profiles

User profiles show the number of test files, test results, and ratings that the user provided, to help indicate the contribution of a particular person. The profile also provides links to get to the individual test files, test results, and ratings provided by the user.

Contributing Test Files

Logged-in users can contribute test files and test results. The interface for providing test files helps users in creating metadata such as to which WCAG 2.0 Techniques different format and web technologies the test files correspond to. It also allows users to upload a batch of test files with the corresponding metadata (for power-users). Test files are pre-parsed and pre-checked by the application but need final authorization by super users to avoid spam and misuse of the system. Users can revoke any of the test files they have contributed at any time.

Contributing Test Results

Users can select any sub-set of test files by WCAG 2.0 Techniques different format and web technologies, and run through the selected test files using their own browsers and assistive technologies. A report of the test run is presented to the user at the end of this process. In addition, logged-in users can choose to contribute the test results into the repository. In this case the users are asked to confirm and complete the information about the web browser and any assistive technology they were using during the test run, as well as any comments such as specific settings they used. Users can revoke any of the test results that they have contributed at any time.

Rating Repository Data

Logged-in users can rate test files and test results provided by others (but not their own). The rating scheme is used to indicate the quality of the contributed test files and agreement with the contributed test results. These ratings are clearly highlighted in the test results and aggregated reports to indicate the level of confidence one can have in the information provided. Users can revoke any of the ratings that they have contributed at any time.

Terminology

Test Files

Test files are minimal but complete samples of code that demonstrate conformance or non-conformance to a particular feature of a specification. In the context of this work, test files are code samples that demonstrate implementation or non-implementation of a specific WCAG 2.0 Technique different format . These files also include metadata about the WCAG 2.0 Technique , web technologies, and other relevant information about the test context.

Most of the test files are expected to need manual intervention, including steps that need to be carried out by humans. For example, a test may request the human to confirm if a WAI-ARIA property was relayed to the platform API (using corresponding system tools) or if particular information was rendered by a screen reader.

Important: see related Resources.

Interface Design Requirements

A clear and easy-to-use interface are provided for the target audience. Particularly information about the currency and reliability of the displayed data will be highlighted prominently. For example, indicators such as the number of reviews, the date of the test file, the date of the latest review, and others will be clearly highlighted to avoid misunderstanding about the state of the data.

Filtering and Selection

Users can search for the data (test results from test files) according to many use-cases. For example, users may need to search for data matching:

One or more WCAG 2.0 Technique
One or more combinations of platforms, browsers, and assistive technologies, including specific versions of any of these
One or more web technologies such as HTML, CSS, etc.

Design mechanisms to reduce complexity of the user interface will used to accomplish this requirement. For example, techniques, tools, and technologies could be grouped by default in Success Criteria and major version numbers, but allow users to specify specific versions if needed.

Test Result Reports

The results from filtering and selection will be aggregated according to logical grouping (such as Success Criteria, major version numbers, etc.) to provide overview on the results. Users can expand information and drill deeper into the results as needed (progressive disclosure). Users can drill down all the way to the indiividual reviews provided by others.

The state of the results will be clearly highlighted to ensure transparency and appropriate expectation. For example, indicators such as the number of reviews, the date of the test file, the date of the latest review, and others will be clearly highlighted. In particular, it will be clear to the user where there are conflicting test results so that users are aware and can explore these conflicts.

All reports, test results, reviews, and other resources will have URIs that can be linked to from outside the system. This allows people to specifically point to and reference data points.