Testing web sites and applications for accessibility

We test websites, web-based applications and stand-alone applications. We also test native apps: for more information see our Testing Native Apps for Accessibility page.

Our accessibility testing is based on our expert analysis and understanding of WCAG2 and our experience with a wide range of websites, coding styles and content management systems.

Request an accessibility audit quote.

Our Audit Approach

Our audit methodology is rigorous, based on our expert analysis and understanding of WCAG 2.2 accessibility requirements and our experience with a wide range of websites, mobile sites, coding styles and content management systems. We will test online content and functionality in accordance with the W3C’s WCAG 2.2 Level AA and the WAI-ARIA 1.0 techniques for web content. We also test against the ICT Accessibility Testing Symposium’s Mobile Site Guidelines to ensure that your site is fully accessible to people with disabilities on mobile and tablet devices.

What we test

We have distilled WCAG2.2 into 635 different errors across 20 categories. Approximately 325 of our errors are tested using our internal automated testing tool, OzART (however, many of these require further manual testing).

Automated and manual testing

It is important that testing consists of both automated and manual testing. All pages will be tested using OzART, and all locations of errors that can be automatically identified will be provided. Those errors that can’t be automatically identified will be manually tested.

Testing against WCAG2.1 and WCAG2.2

Automated testing of WCAG2.1 requirements, for example 1.4.10 Reflow and 2.1.4 Character Key Shortcuts have been included in the OzART tool since late 2018. Automated testing of WCAG2.2 requirements, for example 3.2.6 Consistent Help and 3.3.7 Redundant Entry have been included in the OzART tool since late 2024.

Testing against Mobile Site Testing Methodology (optional)

AccessibilityOz has developed a methodology for evaluating the accessibility of mobile websites. There is some correlation between mobile site issues and WCAG2 issues; however, mobile sites are not specifically covered by WCAG2. For example, although WCAG2 requires sites to be accessible to the keyboard user, it does not specify that it should also be accessible to the mouse or touchscreen user. WCAG2.1 does address some accessibility errors that occur on mobile; however, the accessibility industry believes it does not go far enough – which is why they developed the Mobile Accessibility Testing Methodology. This was released in 2019, and our CEO Gian Wild was Chair of the Committee. This methodology tests issues such as Zoom features, screen reader accessibility and touch target size (this is in WCAG2 but is relegated to Level AAA).

We test for things like the ability to zoom, functionality in landscape mode, sufficient inactive space between links, sufficient colour contrast and proper labelling of forms and headings. We also connect a keyboard to our devices to ensure that content is keyboard accessible, as there are some people who will not be able to use the touchscreen.

We do not test on mobile emulators – we test on actual devices. We test on the following devices; however, we can test on different devices on request:

  • Google Pixel phone / Samsung phone, Android, Chrome
  • iPhone, iOS, Safari
  • iPad iOS, Safari
  • Android Tablet, Chrome

We also test with a range of assistive technologies and features.

Testing with assistive technologies

Although assistive technology is not strictly necessary to test compliance with WCAG2.2, we always test with assistive technologies. We have a dedicated screen reader specialist who conducts accessibility testing and a full range of screen reader testing (JAWS, VoiceOver, NVDA, TalkBack on Android, VoiceOver on iOS). We also test for keyboard-only usage and increasing text sizes in accordance with WCAG2.2.

Testing social media

In addition to testing the site, AccessibilityOz also tests other content that is referenced in the site and published by the client, such as social media. It is important that social media is accessible as it is ubiquitous and an essential form of communicating with your users. Some of the issues we test for include:

  • Whether contact information has been provided on social media About pages (and whether it is accurate);
  • Whether social media posts contain accessibility features such as alternative text on images, captions for videos and the use of Camel Case;
  • Whether the content of social media posts is replicated on the site.

Testing PDFs and other downloadable documents

In addition to standard HTML testing, AccessibilityOz also tests for non-HTML content, such as PDFs and other downloadable documents. OzART can automatically identify all PDFs and other downloadable documents in your site. With regards to PDFs, OzART can automatically identify if the PDF:

  • Is a scanned PDF
  • Does not have an encoded language
  • Title is missing or illegible
  • Is tagged

Our manual testing also identifies:

  • All instances of other downloadable documents (Word, PowerPoint, MP3s, Excel)
  • Whether these documents are accessible, or whether an alternative has been provided
  • Whether the link text is accurate and identifies the format of the file
  • Whether the presentation of links for downloadable documents is consistent across the site

With regards to PDFs, our manual testing also identifies whether the PDFs on the site are compliant with the W3C PDF Techniques for WCAG2.

Request an accessibility audit quote.

What we provide

Word Accessibility Audit Report

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

  • Executive Summary
  • Background and Methodology
  • Accessibility Compliance of the web site
  • Accessibility principles and solutions for each category

The identified errors are grouped by category (Page titles, Headings, etc), then Impact and have the following information:

  • Error Number, Title and Description
  • Success Criterion that the error applies to (or mobile methodology error)
  • Level (A or AA)
  • Impact: the actual impact on people with disabilities
  • Example, including URL, screenshot of the error and relevant code
  • Solution to the error.
Request a sample Accessibility Audit.

Excel Summary Spreadsheet of WCAG2 errors

An Excel spreadsheet for each site with errors listed with description, solution and WCAG2.1 information.

Q&A session

At the conclusion of the audit, a debriefing session will be held for the Web Manager, Content authors and Developers to discuss the findings of the report. The session usually runs for two hours and gives ample opportunity for people to ask questions arising from the audit.

OzART Web Report (optional)

OzART is AccessibilityOz’ accessibility reporting tool. It provides the errors in the site grouped by category.

Each error has detailed information about the error, and additional functionality capabilities:

  • Instructions on how the error can be tested
  • OzWiki example and reference
  • Information about the error (also in Word and Excel documents)
  • Example of error (also in Word and Excel documents)
  • List of errors found with the following information:
    • Status of Defect which can be edited by developers as they make fixes to the site
    • Screenshot, reference code and additional relevant information
    • Referencing pages which list the URLs (or groups multiple URLs), links to the code of that page and outlines the error on a screenshot of the page
  • Ability to export errors or errors with a particular status to Excel or Jira

OzWiki

We also provide access to OzWiki to assist developers in making fixes. OzWiki is a repository of all accessibility information gathered by AccessibilityOz and enhanced by Gian Wild’s experience with the W3C contributing to WCAG2. OzWiki is aimed at developers, content authors and project managers to assist in understanding accessibility requirements and improving their accessibility knowledge.

AccessibilityOz’s OzWiki has examples of all 635 accessibility errors, broken up into categories (audio, images, content, forms, etc.).

Each error has the following information:

  • Topic (Alternative, Keyboard, Design, etc.)
  • WCAG2 Success Criterion
  • WCAG2 Level
  • WCAG2 Technique
  • Impact on people with disabilities
  • Error description
  • Incorrect example, with screenshot and code
  • Solution to the error
Request an accessibility audit quote.