View source for Feature requirements for Interactive Guide to Assist Managing Web Accessibility Evaluations

Related page: [[WCAG-EM Report Tool Comments]]

The Interactive Guide to Assist Managing Web Accessibility Evaluations (Project name: WCAG-Reporter) will guide web accessibility evaluators through the process of evaluating a website using [http://www.w3.org/TR/WCAG-EM/ WCAG-EM] with WCAG 2.0. WCAG-Reporter will take evaluators through the steps of WCAG-EM, giving them instructions on what to do and feedback about their approach. After completing the process, WCAG-Reporter creates an HTML report of the evaluation, to be shared with the commissioner of the evaluation. Evaluation data can be exported and imported, allowing users to save the data locally and potentially integrate their own tools with WCAG-Reporter.

The requirements described on this page are part of the deliverable for the WAI-Act project. For details, see: http://www.w3.org/WAI/ACT/deliverables

== Project resources ==
* [https://github.com/w3c/wcag-em-report-tool/issues/milestones Project milestones] What to expect from the project in the coming months
* [https://github.com/w3c/wcag-em-report-tool/issues Issues list] Use this page for feature requests. They should be flagged as 'Enhancement'.
* [http://w3c.github.io/wcag-em-report-tool/dist/ Most recent project build]


== Target Audience ==
This project is mainly focused at web accessibility evaluators. These are people with medium to advanced knowledge of web technologies. They will have at least a basic understanding of Web Accessibility and WCAG 2.0 in particular. The primary focus of the project will be on evaluators with a beginner's understanding of WCAG and WCAG-EM. Reporter will do this by guiding them through the process of evaluating and giving them appropriate instructions when they need it. It should also have easy access relevant documentation.

A secondary group are experienced web accessibility evaluators. These evaluators have greatly varying approaches and procedures which they use to come to their end results. WCAG-Reporter should therefore not enforce one method of evaluating or of reporting, but leave this open to the evaluators. For the beginning evaluators, it is important that these features come with instructions. This enables them to decide what methods of evaluation and reporting work best for their situation.

== Requirements ==
This means that the tool '''must''':

# Provide a step by step guide through WCAG-EM. 
# Provide direct access to W3C documentation, relevant to the current step in the evaluation
# Contain form fields in which users can record:
## The scope of the evaluated website
## The sample of web pages or web page states
## The results of each evaluated success criterion (pass, fail, not present)
## Name/Type of report
## Version number
## Name of the evaluator
## Name of the evaluation commissioner
## Date for the evaluation (completion date or duration period)
## A free form text description of the accessibility problem
# Provide the user with an HTML report of the evaluation. This report must:
## Contain all the information listed in WCAG-EM Step 5
## Be downloadable so that users can host the report on their website.
# Be globalized so that the tool can be configured to:
## Use different languages, with English as it's default
## Use different date formats, with YYYY-MM-DD as the default.
# Have separate documentation of the entire system
# Conform to WCAG 2.0 level AA
# conform to ATAG 2.0


The tool also '''should''':

# Be hosted on GitHub as an open source project, so that it can be extended by other developers.
# Allow users to enter the optional features for the evaluation report as described in WCAG-EM step 5.
# Allow different work flows in the evaluations:
## Open sample pages in new tabs, as a batch or individually
## Allow marking success criteria as 'completed'
## Allow marking sampled pages as 'completed'
## Allow hiding of 'completed' pages and criteria 
# Function mostly on client side technologies, to reduce impact on the server and make installation easier.  
# At any point during the evaluation be able to export the data to a JSON file.
# Open an evaluation using a JSON file containing previously exported data
# Help the user keep track of their progress in the evaluation
# Allow the user to revise information after it was entered.
# Have an About page; indicating how to use the tool and the report

The tool '''could''':

# Be extendible, so that plugins can be created that add features to this, such as test for additional requirements or opening sample pages which automatically could start a plugin.
# Function on both desktop, tablet and mobile devices.
# Allow evaluators to identify when content was not present on a page.
# Allow evaluators to link a single accessibility problem to multiple success criteria.
# Be easily installed on a server, by:
## Allow loading and saving it's data through a RESTful API
## Auto-save the content
# Track meta data of the report, including who created a certain issue and at which time.
# Use the import function to merge multiple evaluation sources into a single evaluation


The tool '''will not''':  (For all of these features, plugins could be developed later or by third party developers)

# Generate reports when the evaluator did not complete all the required steps or indicate all success criteria (or all sample pages) as completed.
# Have a fully formed style, as the app should be integrated in a pre-existing web site from which it will take it's style
# Store evaluations on the W3C site or be linked to W3C accounts
# Allow customization of the report
# Import or export data in XML EARL
# Contain assistance for evaluation of individual success criteria or sample pages
# Be able to poll a server for new information about the evaluation that might have been provided through other tools.