Accessibility testing during the web development lifecycle

In building an accessible website, accessibility needs to be considered at all key stages of the web development lifecycle.

We have developed a suite of activities to ensure that accessibility issues are identified early, and your site is as accessible as possible at launch.

Test from the start – not just at the end

We are happy to work with you for all or a selection of the activities that you need.

Stage 1: Planning

Request for Quote and/or Tender consultation

This work includes writing the accessibility requirements content for RFQs or Tenders for the development of your website. Once RFQs or Tenders have been received, we will assess the responses to gauge the accessibility knowledge of each applicant, providing you with a recommendation.

Stage 2: Analysis

Functional Specification and/or Requirements document review

A review of the functional specifications and/or requirements will identify early the presence of any issues that may cause accessibility problems with the site. This document will be reviewed and re-drafted with comments for your review. This is a collaborative work, with time allocated to discuss our recommendation and provide explanations.

Content Management System accessibility review

This is a high-level accessibility analysis of a CMS product against the W3C Authoring Tool Accessibility Guidelines Version 2.0 (ATAG2), Level AA.

We are able to perform an accessibility audit on:

  • the generated output of the CMS content, and/or
  • the accessibility of a particular CMS interface.

This is particularly useful if you are:

  • reviewing/comparing the accessibility of one or more CMS’s to use for your new website, or
  • determining the accessibility issues with your current CMS.

Web Publishing Guide review (optional)

As part of your commitment to maintaining the accessibility of your website, we are able to review your web publishing guidelines.

The purpose of this review is to ensure the importance of accessibility is highlighted, and accessibility standards for content publishing are clearly outlined for your developers and content authors.

The benefits include, but are not limited to:

  • outlining a consistent approach to accessibility, and
  • reducing the risk of publishing non-accessible content (especially during staff changes).

This document will be reviewed and re-drafted with comments for your review. This is a collaborative work with time allocated to discuss our recommendation and provide explanations.

If you do not have a Web Publishing Guide, we are able to draft this for you.

Stage 3: Design

Wireframes and/or visual design review

Once your wireframes and/or visual designs are complete, we will review them against the design success criteria of the Web Content Accessibility Guidelines, Version 2.0. The results of our testing will be provided with recommendations and comments for your review.

Stage 4: Development

Template evaluation

Once your templates have been developed, we will test them against the relevant success criteria of the Web Content Accessibility Guidelines, Version 2.0. This includes site-wide templates, homepage and specific content type templates such as form, video, slideshows, image gallery, maps, etc. The results of our testing will be provided with recommendations and comments for your review.

Training of staff (optional)

After discussions with you, we can help you determine if your developers and/or content authors need customised accessibility training.

Stage 5: Testing

Post-launch final testing and evaluation

Once your website has been launched, we will systematically test your website using manual inspection and our unique automated testing tool, OzART (AccessibilityOz Reporting Tool). Testing is against the Web Content Accessibility Guidelines, Version 2.0, and errors are compiled into a final audit report.

Final audit report

The accessibility report includes the findings of the audit; it is comprised of the following information:

  • Success Criterion that the error applies to,
  • Level (A or AA),
  • Occurrence: whether the error was found in the template or content,
  • Impact: the actual impact on people with disabilities,
  • Error description,
  • Example, including URL, screenshot of the error and relevant code, and
  • Solution to the error.

Presentation of audit findings

At the conclusion of the audit a walkthrough will be held for the Web Manager, developers and content authors. This session will walk through the audit report, providing an opportunity for people to ask questions arising from their audit.

Stage 6: Maintenance

Help desk hours for implementation issues

While your developers and content authors are making the fixes recommended from the final testing audit and user testing, we will be available to answer any questions you have.

Urgent support requests are responded to within 4 hours. Standard support requests are responded to within 2 business days.

Please contact us to discuss your requirements.