Scenarios for the Guidance on the development of web accessibility evaluation tools

AERT in requirement capture

Accessibility-Me (Acme) is a consultancy firm with a relevant expertise and track record in web accessibility evaluation and the development of accessible web applications. Another company, a gigantic web provider called HuGh, has contracted Acme the development of a tool that integrates within HuGh Content Management System (CMS) and deals with the semi-automatic evaluation and repair of content generated by its users (who are not accessibility savvy at all).

Ann is an Acme system analyst who has the relevant know-how to deal with an accessibility-related project, but which has always dealt with evaluation tools as a user, never having developed one herself. Fortunately, she may count with the previous experience of the industry, condensed in a set of techniques called AERT (Guidance on the development of web accessibility evaluation tools): she may rely on some orientations regarding what is expected from evaluation tools, what functionalities they usually provide, and how they are supported. AERT itself is not enough to specify the whole set of requirements of an accessibility evaluation tool, as they need to be tailored to the specific needs of the client which commissioned its development, and the context where it is going to be used. Thus, Ann will use AERT as an input to the requirement capture activities, together with other sources such as the current architecture of HuGh systems and processes wherein the tool must integrate, or her own experience as a web accessibility evaluator.

Ann might follow different development processes, but in this specific case she chose to follow the Unified Software Development Process [USDP], a standardized software development process model which defines several artifacts. Ann will integrate inputs from AERT into these artifacts:

• A domain model that captures those concepts and relations most relevant to the tool (acting as a kind of extended glossary). AERT already describes the different concepts that an accessibility evaluation tool usually needs to deal with, always focusing on the relation with the tool, but Ann will need to adapt it to make them match HuGh procedures.
• A business model that defines how the evaluation tool fits into the different steps of an accessibility evaluation workflow. AERT does not define the evaluation workflow (elsewhere described in WAI documents), but it describes the role of evaluation tools in this workflow. Notwithstanding, some of the steps described by AERT need to be put into the context of HuGh scenario. For instance, preference to automatic repair will be given when possible, in order to limit the cognitive overload of tool users. Or some steps will be filtered out, as HuGh cannot rely on the tool users having any previous accessibility training.

AERT in system specification and architecture

Marc is a system architect working for the IT department of a medium sized company, which need to introduce accessibility evaluation functions in their own intranet content generation tools. Marc is familiar with software specification techinques, but not so acquainted with the accessibility domain. He will use AERT as an input to generate the tool specification, given that it defines desirable, expected or simply typical features of evaluation tools.

AERT defines different profiles for different kinds of evaluation tools, each defining a set of feature lists typical for each kind. Marc will choose the AERT profile that best fits the needs his company, and draw inspiration from it to get a requirement list and a set of use cases. Best practices defined by AERT will be chosen and added to the list of features. Possibly, Marc will prioritize a required subset of features and use cases, while leaving others as optionally supported. Later, he will check against AERT that his specification is complete and consistent.

He will wireframe user-interface prototypes that provide a sensory representation for the different actors that will use the tool, and which serve as a tangible, shared artifact he can present to the stakeholders. In this protoype, the AERT may serve as background on the different ways the results of accessibility tests may be presented.

Of course AERT does not prescribe how an accessibility tool should look, but it just defines what it is supposed to achieve, giving a broad range of options. Marc will thus define the specific tool features and use cases in accordance with the needs of its company, and will possibly need to neatly cooperate with final users and business units.