Testing native apps for accessibility

We can test your native app’s accessibility using W3C standards-based testing and the Native App Mobile Accessibility Testing Methodology.

Request a native app 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 ICT Accessibility Testing Symposium’s Native App Guidelines to ensure that your native app fis 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. 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

Testing against Native App Testing Methodology

AccessibilityOz has developed a methodology for evaluating the accessibility of native apps. There is some correlation between native app issues and WCAG2 issues; however, native apps are not specifically covered by WCAG2. For example, although WCAG2 requires native apps 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 native apps; however, the accessibility industry believes it does not go far enough – which is why they developed the Native App 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 also test with a range of assistive technologies and features, including (but not limited to):

  • iOS VoiceOver
  • Android TalkBack
  • iOS Larger Text and Bold
  • Android Increase Font Size and Increase Display Size
  • iOS Voice Control
  • iOS Zoom
  • Android Magnification
Request a native app 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 native app
  • 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 screen name and screenshot of the error
  • Solution to the error.

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 (if relevant)
  • Solution to the error
Request a native app accessibility audit quote.