Organising an audit

Specifying an audit

To get the audit that suits your organisation and your website, you need to clearly set out your requirements. Among the factors to consider are:

  • What budget is available; 
  • What wcag accessibility level to audit to;
  • Whether to audit the entire site or a sample of pages;
  • What sampling scheme to use;
  • The need for an implementation plan as output;
  • How to procure the audit.

You will also need a clear statement of the intended functions and purposes of your site. This is important because the auditors will often need to weigh up the relative impact of different accessibility barriers on the overall use of a site - in general, they can only do that if they know what the intended uses are.

The details of the audit specification for inclusion in the request for tender and contract are probably best drafted by someone with technical skills. However, as the manager responsible, you need to be involved.

Taking an informed interest in specifying the audit will help you to get the best results. We recommend that you write the high-level outline of requirements, give it to a web accessibility specialist to draft the technical requirements and then check the final specification. This will:

  • Involve you in the choices being made;
  • Allow you to ensure value for money;
  • Be a first step towards understanding and acting on the finished audit report.

The IT Procurement Toolkit contains additional advice on how to include accessibility as a criterion in request for tenders (rfts).

Accessibility level

While conformance rating double-a under wcag is the minimum required of a public-sector website in Ireland, it represents good value for money to have the audit check the website's conformance rating against  all wcag priority 1, 2 and 3 checkpoints, also called conformance rating triple-a.This will give you an indication of the current level of accessibility of the site and how far it is from reaching conformance with the next accessibility level.

Sample pages or whole site?

The scope of the audit will be affected by several factors, including the budget available. An accessibility audit that reviews every page on a website against every relevant wcag checkpoint is certainly the most thorough audit. It may be feasible only to carry out such an audit on relatively small sites.

With many public sector and commercial sites now running to thousands of pages, a full audit of every page is often not practical.Although some automated web auditing tools can spider an entire site and give some useful information about its accessibility, a certain sample of pages must still be selected for an in-depth audit. It is important that this sample is representative of pages that contain content on the site and of any interactive functionality that the site provides. At the very least the sample should include:

  • Pages most frequently accessed by site users, e.g. homepage, "contact us" page etc; 
  • A variety of page types;
  • Pages with forms or tables;
  • Pages that are generated by the publishing system in response to user input (e.g. search results);
  • Information graphics, such as charts or diagrams;
  • Interactive pages that use scripts or programs to process user input, e.g. forms;
  • Any pages you feel there may be a problem with.

Pages that are generated by a content management system (cms) usually consist of two parts and a template that holds the content and the content that is drawn from a database to populate the template and create the page. When auditing these dynamic pages, it is important that the template and content, as well as the generated page, are audited.

template structure: most websites use some form of template for the header, footer and navigation bars of the site. How these templates are handled depends on the technology used (such as a cms). If an individual or third party is solely responsible for a template, the audit should treat compliance issues relating to templates separately from compliance issues that relate to content. For example, if server side includes are used for a header, the include should be treated as a separate document and checked against the relevant waiwcag checkpoints.

document content: the content of the site can refer to text, images, tables and other elements. Document content refers to information that can typically be edited (and thus fixed) by everyday web editing tools such as wysiwyg editors, cmss and graphics applications.

Before conducting an audit, it is important to confirm what approach is to be undertaken by the auditor. Questions to ask include:

  • If the site uses a cms or technology that uses templates, will templates be audited separately from document content?
  • If not, how will the audit identify instances of non-compliance that occur throughout the site as opposed to unique instances of non-compliance?
  • What approach will be taken by the auditor when testing document content?

Training and on-going support

Building capacity within your organisation around accessibility should be one of the primary goals of your audit.When writing a request for tender (RFT) for auditing services, you should consider requesting additional support from the consultant after the audit is completed, to include:

A presentation by the auditor on the full audit report, including a question and answer session; mentoring and providing additional feedback to staff as they attempt to improve the accessibility of the site to help ensure any changes recommended in the audit report are in line with best practice; training and it may be necessary to carry out some formal classroom-based training in web accessibility for staff to ensure they understand fully the issues raised in the audit report.

Your RFT should also emphasise the need for knowledge transfer to your staff after the audit itself and ask those submitting tenders to specify how this will be achieved.

Writing requests for tenders for audits

Depending on the budget of your web accessibility audit and your organisation's procurement rules, you may need to go to tender for your web accessibility audit. The audit specification is the key component of the rft.

Another important element of the RFT is the qualifications and experience of the successful tenderer. Ensure that you include clear and verifiable requirements for establishing these, such as:

  • Summary of experience of web accessibility auditing;
  • Examples of work in the area;
  • Client references, with names and contact details;
  • Professional qualifications of audit staff;
  • Any specific expertise required to evaluate content on your site that is specialised because of its subject matter, technology or language.

To avoid conflicts of interest, it is advisable that the audit is carried out by a company that is independent of any company that is or has been involved in the development of the website or any its components, such as the cms.

Your RFT will also need to define some other key points, such as the criteria for evaluating tenders. Your technical and procurement staff can probably create the remainder of the rft.

Evaluating tenders or proposals for audit

Evaluation of tenders should follow your normal procurement processes. When you have arrived at a shortlist, it is advisable to contact the referees supplied to confirm key elements of the tenders that form part of your scoring criteria for evaluating tenders.

The it procurement toolkit contains additional advice on how to evaluate accessibility as a criterion in rfts.

Preparing for an audit

Having specified an audit and selected an auditor, it is important to prepare for the audit. The following steps should figure in your preparation:

  • Brief your staff about the audit and its importance to the organisation;
  • Present the audit in a non-threatening way, that it is a valuable chance to improve your website rather than an exercise in blame-attribution;
  • Assign responsibility for audit preparation and liaison with auditors with one member of staff;
  • Assemble all relevant documentation for the auditor;
  • Arrange an initiation session for the audit, well before the audit itself, to ensure that the auditor has all the required information about your site, your organisation and your requirements.