Xcodes accessibility inspector has long been thought of as only an 'automated' issue tool. This thought has led to its full potential never being fully met by developers and testers. So if it's more than just automated issues, then what should users be doing with it to catch more accessibility bugs? Let's dive right in.

Simple Testing List

Keeping it simple, there are 3 main categories of tests you can do to ensure you are getting the most out of the accessibility inspector:

• Action Name/Role
• App Navigation (Screen reader light)
• Dynamic Type (Font size increase)

Setup Before We Begin

To access the XCode accessibility inspector, you must have Xcode open and then go to Xcode > Developer tools > Accessibility Inspector.

Once open, it may default you to the "Audit" function of the application. You need to navigate to the "Inspection" tab and ensure your screen looks like the one shown below in the image. If it does, you are ready to test!

Action Name/Role

Automated checks can only tell if an action has a label or has a trait, but what it cannot do is tell you if the label or the trait actually describes the purpose of the action!

Action Test 1: Proper Label

Once the action item is selected (highlighted) in the inspector, ensure the label properly describes the action item. For example, if the button is a "Search" icon, the label should be "Search" NOT "IC Search, icon".

The label also MUST NOT include the trait in the label. Using the search example above, we would not want it to read as "Search, button". As it would actually read, "Search button, button".

Action Test 2: Proper Trait

Once the action item is selected (highlighted) in the inspector, ensure the trait for the action properly correlates to the expected action.

One prime example, buttons vs links. A button should keep you within the application while a link should take you to a WebView or out of the application.

Action Test 3: Over-riding Label

The final test, check that the label that is set does not override the visible text. Overriding visible text can make it confusing mainly for voice control users. Who can use "show text" to be able to tap a button.

For example, if the login button on your app visibly says login but the accessibilityLabel for it says "login to your application" it may not function with voice control.

App Navigation (Screen reader light)

Accessibility inspector comes with a screen reader built in (similar to that of Voice Over) that allows you to hear and navigate the application as a screen reader user would! The advantage of this, is not all iOS developers have access to physical phones to test with VoiceOver!

Navigation Test 1: Accessibility focus order

Pressing the "Play" button on the Navigation group, let the navigator go through one by one of each item in the application and highlight each item.

As long as the accessibility focus order goes from left to right in a concise and simple order that matches that of the visual order, then you are good! If it jumps and skips around the view while using it, then you have focus order issues.

Navigation Test 2: Proper grouping

Using the Navigation section, use the arrows right and left to navigate each item one by one in the view. While doing this, look for groups of content that could easily be put together.

The example image below shows a card component that can have the name, image, and description grouped as one, and then the "Add to Cart" button as the next accessibility focus stop. However, in this case they are all individual accessibility focus stops.

Dynamic Type (Font size increase)

The final test is for dynamic type! Which is a very simple test to ensure that your application properly is using dynamic type in your mobile application and the text resizes!

Different than the other tests, you will have to navigation in the top right to the "Settings" (the third button to the right). Once there, you will notice a number of different accessibility settings. Go to the bottom and select "Dynamic type".

Once you do that, simply move the slider up and ensure that the text does not do the following:

• Overlap over other text
• Addition of trailing ...
• Overflow its container and get cutoff

In Summary

Accessibility inspector is much more than just automation. Using these simple tests in daily development and QA, can help ensure that your application goes beyond the basics of automation and does more to ensure its accessibility!