Detailed Audits

A third type of web accessibility audit is a Detailed Audit. This type of audit is conducted on a particular feature of a website or on a particular process. All aspects of the accessibility of the feature or process are examined.

Purpose of Audit

Detailed Audits may be part of a series of audits that include a Template and General Audit or they may be conducted on their own. A Detailed Audit may be conducted on a standalone web application as a whole, where a vendor or developer wishes to certify the accessibility of their product. Alternatively, a Detailed Audit may be conducted on a particular collection of pages that serve a particular purpose within a site.

Process of Audit

The procedure for conducting a Detailed Audit is much like that of a Template or General Audit, with the added review of the process or transition elements of the process associated with a feature or application.

A Detailed Audit begins by identifying all pages or screens associated with the feature(s) to be reviewed. Think of this collection of pages as representing a path through the site a visitor might take to reach an ultimate destination. For example, consider a shopping cart application used within a larger community website. The community site may include a registration screen, a login screen, a user home page, and the cart itself may include a product selection page, an invoice page, a checkout page, and a credit card submission page, among others. All of these pages together represent a process that must be accessible as a whole before the cart application can be judged conformant.

Each page of the process of making a purchase with the cart application is reviewed independently and as part of the whole process. Individual pages are evaluated much like a content page would be assessed in a General Audit. For example, can a screen reader user easily navigate through a collection of products and make a selection from the product page?

It is also important to evaluate the transitions between screens in the process of making a purchase. For example, if a user wants to find out more details about a product and opens a details window, once the user has finished with the details window and closes it, are they able to easily find their way back to their position in the products page from which the details were opened? Or, after making a selection from the product screen and being directed to the checkout screen, is there sufficient feedback provided to indicate the product selection was successful, without having to spend too much time searching through the content of the checkout screen to make that determination? These types of accessibility issues are part of the process, rather than part of the content. Both content and process need to be considered as a whole in a Detailed Audit.

Time Required for Audit

The scope of a Detailed Audit can vary quite significantly from audit to audit. Assessing the accessibility of a whole web application, for instance, can take weeks or more to complete. When estimating the time required to complete a Detailed Audit, a strategy similar to the sampling process in a General Audit is helpful. Create a list of each of the pages or screens to be reviewed, do some initial informal review to get a sense of the level of accessibility and the complexity of the elements to be reviewed. Come up with a base time-per-page and multiply that by the number of pages to be assessed to estimate the effort required for the audit.

Conformance Considerations

When conducting Detailed Audits of web applications, it is important to note a software version number in the report. A Detailed Audit will only apply to a specific version of the software or to a specific feature on a website on a particular date. Because software and websites change over time, it is only appropriate to assign conformance on a particular “date identified” snapshot of the features or functionality being reviewed.