DEV Community

Cover image for Debunking the Myths of the iOS Accessibility Inspector
Mark Steadman
Mark Steadman

Posted on

Debunking the Myths of the iOS Accessibility Inspector

One of the most commonly overlooked tools in iOS development is the XCode accessibility inspector. The inspector is a free tool that comes with XCode that you can use to help test your application for accessibility issues. Over the years however, the tool has gotten a bad reputation for being unreliable and only being an "automated" checker.

While some of the functional issues with tool are completely valid, the tool itself is so much more than just automated audits. Lets dive into some of the big myths about the iOS accessibility inspector and debunk them!

Myth 1: "Only Automation"

While it is true that the inspector has an audit function that runs automated tests, the myth that it ONLY does this is false. There are two big features that developers miss in the tool, the ability to manually inspect each element and screen reader navigation!

Manual Inspection

You can access each individual element on the screen by using the "Inspection" tab. Once you target your application you want to test using the target button, you can use the arrows under "navigation" to go through each item in the screen one by one.

For each element that is highlighted, the following information will show:

  • Label
  • Value
  • Traits
  • Identifier
  • Hint
  • User Input Labels

You can now see the accessibility tree information for that element! Not only that, you can also do simple manual checks to go beyond automation.

For example, in the image below, currently focused is a search icon in an application, and that icon button has a label of "ic search" with a trait of 'button'. Automated checks would say this is fine since it has a label, however the label itself is not sufficient as it does not properly describe its purpose and contains partial image name. This is the true power of the manual inspector!

The accessibility tree inspector

Screen Reader Navigation

One of the more unique features of the "Inspection" portion of this tool is the ability for it to read out the content of the view. Using the "navigation" section, you can simply hit the 'play' button and it will read out all the content within the view with a screen reader.

You may be thinking to yourself, "Well what is the benefit here if I can just fire up voiceover and do the same?". If a developer is using this tool and doesn't have access to a physical device and only an emulator, then this can be a subtle substitute for screen reader testing! It also shows all the information for each element just like above, so developers can learn why something may not be announcing properly.

Myth 2: Automated Checks Lack

A true statement when it comes to automated accessibility, is that it will NOT get you to 100% of all issues. However, that doesn't mean that automation can't get you started down a path to make your content accessible.

The accessibility inspector has been thought to have "only having 3 checks" for accessibility, touch target sizes, dynamic type and contrast. The truth is, there are 7 automated issues it checks for:

  • Element Description
  • Contrast
  • Hit Region
  • Element Detection
  • Clipped Text
  • Traits
  • Dynamic Type

Most development teams don't know where to start when it comes to making their applications accessible. These simple checks can help them get started down that path and can begin to ensure accessible practices while developing.

Automated audit result example that includes touch target size issues, dynamic type and element missing description

Myth 3: No Reporting

One of the bigger reasons teams choose not to use the accessibility inspector is "it doesn't have the ability to export a report". That is true no longer! The accessibility inspector does have the ability to export the automated checks to a report!

Within the inspector, if you go "File > Save audit report as.." you will be able to save an HTML file version of the report with screen shots and all!

This can help development teams with:

  • Definition of done
  • Automated monitoring of applications
  • Reporting of bugs

Example report showcasing the screen shots at the top, and the issues at the bottom

Myth 4: Only Works with Simulator

Accessibility inspector does not only work with the simulator! Yes, you read this correctly. You do not need direct access to the code or the simulator to run the accessibility inspector against your application!

You can plug-in your iPhone, pick an application and start inspecting it using the "Inspection" tab or run an automated audit it right away!

In Summary

Accessibility Inspector gets a bad reputation for only being single use case tool. The fact is, it has so many more features to help development teams make their applications accessible. Using this tool daily in development can help build a culture that makes accessible applications from the start!

Top comments (0)