[Draft] Analysis for "Accessibility Support Database"
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 email@example.com (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.
See also these resources developed as proof-of-concept during the development of WCAG 2.0:
- [Experimental] Collaborative Database of Information on Assistive Technology and User Agent Support for Uses of Technologies
- Reports on Accessibility Support for Ways of Using Various Web Technologies
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.
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.
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;
- 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;
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
- W3C Conformance Test Framework ; see also W3C Web Testing Interest Group
- WCAG 2.0 Test Samples Repository; see also WCAG 2.0 Test Samples Development Task Force (TSD TF)
- BenToWeb WCAG 2.0 Test Suites ; see also BenToWeb Project
- [Experimental] Collaborative Database of Information on Assistive Technology and User Agent Support for Uses of Technologies ; see also Reports on Accessibility Support for Ways of Using Various Web Technologies and WCAG 2.0 Techniques
Test files that implement specific accessibility features (following the WCAG 2.0 Techniques ) 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).
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 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.
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.
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 , 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 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.
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 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.
Users can select any sub-set of test files by WCAG 2.0 Techniques 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.
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.
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 . 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.
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.
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.
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.
Important: see related Resources.
Simple rating schemes will be used to avoid misinterpretations of the values and to reduce the impact of potential subjectivity. For example, "yes/no" ratings for questions such as "Do you agree with the test results" could be significantly more effective than, say, rating the use of test files on a scale from 1-5. Raters could also have a comment field to further explain the rationale for their ratings. This could be particularly useful where there are conflicting results.
Apache with TomCat, to run Java servlets. MySQL or any other relational database.
Optional LDAP module will be used to authenticate users.
JQuery will be used for dynamic front-end.
Java Persistency layer will be used (part of JDK).