Case Study: AInspector for Firefox

AInspector, a Firefox browser extension, is the primary accessibility evaluation tool used by web developers, designers, and quality assurance testers at the University of Illinois.

It was first released in September 2014 and about three years later was updated to use the WebExtensions API that was subsequently required by Mozilla. In March 2022, version 2.0 of AInspector was released with significant enhancements, including the ability to export evaluation results in CSV format.

My Role

I was the user interface and interaction designer of the first version of AInspector, working in conjunction with the product manager who is also a developer and accessibility expert. I acted in an advisory capacity for more recent design improvements to AInspector, such as those in version 2.0.

The initial version of AInspector had ambitious goals that were tied to another product, a web application that we had developed a few years earlier named the Functional Accessibility Evaluator (FAE), which uses web spidering to evaluate entire websites.

Much work had gone into FAE (I was the user interface and interaction designer for that product), to the point that we already had developed an information architecture used in structuring the very large dataset of accessibility evaluation results.

AInspector was envisioned as the single-page version of FAE. Because FAE was layered on top of the OpenA11y Evaluation Library, we knew that it would be advantageous if AInspector could also utilize the same library.

However, we also realized that having two separate products that reported or displayed evaluation results in the same format presented a challenge relating to their user interfaces. The labeling of evaluation results in FAE was built into the reporting interface.

AInspector uses the same Evaluation Library as the Functional Accessibility Evaluator, and thus its evaluation results are presented in the same format, using the same terminology and ruleset as FAE.

Question

How to align all of the terminology and labeling of features present in AInspector with those in FAE and keep them in sync?

Options

• Manually and simultaneously make changes in both applications whenever a terminology or feature change occurs in one or the other.
• Create a separate repository where all of the terminology and UI labeling is defined, and then make sure that both applications are kept in sync with it.

Criteria

Based on a 2002 paper, Conceptual models: begin by designing what to design (PDF) by Jeff Johnson and Austin Henderson, I created the Conceptual Model for Web Accessibility Evaluation. I was the author and editor of the conceptual model, but its content is based on extensive input from our multi-organization group whose membership included a number of web accessibility experts.

This conceptual model served as the basis for all terminology, and the organization of evaluation results in all AInspector screens and FAE reports.

Conceptual model for web accessibility evaluation

Wants and needs analysis

Needed to be understandable by, and useful for web developers, designers and website administrators (from very technical to non-technical users).

Multi-level views with progressively more detail; updating the evaluation results data based on browser tab update events

User testing to determine whether various users at different levels of familiarity with the technical details of web accessibility could find what they were looking for.