This document presents an example of a scenario where the Techniques for Automated and Semi-Automated Evaluation Tools ([TASAET]) are used in the development process of an accessibility evaluation tool. It parts from the supposition that TASAET have already been published, and they are employed to support the development of a new tool.
The scenario describes a sequence of activities, where different workers intervene to eventually create a software product (the evaluation tool). It draws upon the different roles assumed by workers in the Unified Software Development Process [USDP]: the scenario shows how TASAET are used by these workers in the different phases of the development process. The different software artifacts herein exemplified respond to the terminology used in Object-Oriented Design. However, all these choices are just to be taken as concrete examples that allow substantiating the scenario, so as to ease understanding how TASAET may be used. They should not be considered the only option: instead of a sequential process, feedback loops and iterations may also be introduced; instead of the Unified Process, other methodologies such as Scrum, etc. may be taken as reference; instead of Object-Oriented Design, other paradigms such as procedural, aspect-oriented, or declarative programming may be followed in the design and implementation.
Besides, the scenario is bound to a specific evaluation tool to be used in a specific context (evaluation of user-generated content in a large web portal), but we understand of course TASAET will be used for other kinds of tools that may follow other exploitation models.
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. They have recently embarked upon expanding their services, by dealing with the adaptation and customization of Content Management Systems (CMS) that foster the creation of accessible contents by external content creators (who are not necessarily accessibility experts).
Leveraging that business line, Acme has been recently hired as the provider of accessibility services by HuGh, a gigantic web provider that mostly serves user-generated contents (UGC). HuGh wants its users to generate accessible contents, so that its platform can reach a larger audience base and comply with accessibility regulations. Given that its users have limited external motivations to ensure the accessibility of the contents they generate, and they may lack the necessary training to do that, HuGh wants to achieve this with a minimal user intervention and without introducing any significant friction in the content creation process. With that goal, HuGh has contracted Acme the development of a tool that deals with the semi-automatic evaluation and repair of User-Generated Contents hosted by HuGh.
Acme has the relevant know-how to deal with an accessibility-related project, and they also have software engineers who may deal with the development of a production-grade software product, to be integrated within HuGh systems. However, this is the first time they tackle the development of their own accessibility evaluation tool. Fortunately, they may count with the previous experience of the industry, condensed in a set of techniques called TASAET. Although Acme will still need to put remarkable efforts into the development process, they may rely on some orientations regarding what is expected of evaluation tools, what functionalities they usually provide, and how they are supported. Thus, Acme will mainly use TASAET as an input to the requirement capture and specification activities.
Acme starts the project by involving a system analyst (or an analyst team) in charge of creating a first version of the tool requirements. The system analyst first needs to compile a domain model that captures the most relevant concepts related to the tool and their relations (acting as a kind of extended glossary) and a business model that captures the processes the tool will support. For both models, the system analyst will take a threefold input:
TASAET describes the different concepts that an accessibility evaluation tool usually needs to deal with (e.g. success criteria, automatic technique, evaluator, report, etc., etc.), always focusing on the relation with the tool (e.g. it gets a success criteria as an input, which is specified by a set of tests, each applying one or more techniques...) These concepts will be part of the domain model, together with the concepts taken from the specific HuGh activities, and sometimes collapsed with them (e.g. a web content in the accessibility domain can be mapped to a blog post or a picture in HuGh domain, an evaluator can be collapsed with HuGh content creator, etc.)
TASAET describes as well how the accessibility evaluation tool fits into the different steps of an accessibility evaluation workflow, elsewhere defined. These steps will become part of the business model, together and into the context of HuGh activities. Some of the steps described by TASAET simply do not apply in this scenario, as HuGh does not rely on the tool users having any previous accessibility training. Others will need to be filtered in order to take into account the specificity of the scenario, e.g. giving preference to automatic repair when possible, in order to limit the cognitive overload of tool users. That is just one reason why other inputs are needed: TASAET itself is not enough to specify the 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.
In TASAET, Acme system analyst may find pointers to external documents as well, that serve as background information on the domain of accessibility (e.g. WCAG 2.0 documents), a global workflow of accessibility evaluation (WCAG-EM), and accessibility-compliant authoring systems (ATAG); but Acme team will seldom need them, given their previous familiarity with web accessibility.
Departing from the domain and business models, the system analyst will provide a specification in the form of a list features the tool is expected to provide and a set of use cases that represent the behavior the tool is expected to support. The analyst will be helped by other workers, such as a system architect or a specifier, who may be familiar with software specification tecniques, but not so acquainted with the accessibility domain.
Again, TASAET will be used as an input, given that it defines desirable, expected or simply typical features of evaluation tools. The system analyst will choose the TASAET profile that best fits the needs of HuGh tool in order to use it as an inspiration for the tool feature list and the use case list, and will check against TASAET that the specification is complete and consistent. Best practices defined by TASAET will be chosen and added to the list of features.
Of course TASAET 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. The analyst will thus define the specific tool features and use cases in accordance with HuGh needs, and will possibly need to neatly cooperate with members of HuGh technology and business units. Possibly, the architect will prioritize a required subset of features and use cases, while leaving others as optionally supported.
A user-interface designer will support the specification by designing mockup 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 among the teams of HuGh and Acme so that they can agree and discuss based on a tangible presentation. The prototype is not focused on the physical aspects (look-and-feel), but on the logical ones (information architecture). As that, TASAET may serve as background on the different ways the results of accessibility tests may be presented.
Acme team mainly uses TASAET in the requirement capture and specification activities. After them, all the relevant contents from TASAET are already taken into account an integrated in the project documentation. Nonetheless, they may still refer to the original techniques in case they want to contrast anything.
Besides, TASAET will still prove useful for some analysis, design and implementation tasks.
TASAET is written from the perspective of web accessibility community, and thus it uses the language and terminology from that community, as contrasted with the usual way of expressing within HuGh industry. It is typical that the system specification is translated during the analysis phase into an internal system view that employs the developer's language. Hence TASAET may be used as a reference framework for accessibility-oriented terms.