How to Use Accessibility Inspector for iOS Apps

Why Accessibility Matters in iOS Apps?

iOS applications are used by 28.54% of all mobile users. This is a large chunk of the 7 billion people who use a mobile phone. When the application has such high potential with a vast audience, it is the responsibility of developers and testers to build an inclusive application that everyone, with or without a disability, can use.

In addition, the more people use the application, the more beneficial it is for the business. The app can generate more data and earn more revenue if in-app purchases are allowed (a good example of this is eCommerce applications). Brands that provide accessible iOS apps also enjoy positive word of mouth amongst the users.

Moreover, legal complaints against organizations are on the rise today due to inaccessibility of the mobile applications. Several organizations and individuals have started to step up to make the application world inclusive for all. Legal cases end up in court or settlement, both of which are expensive affairs. Instead, this money can be put into hiring additional resources and making the iOS app accessible for all.

What Is an Accessibility Inspector?

Accessibility Inspector is a tool developed by Apple to debug accessibility issues. It can be used for macOS and iOS applications and even for apps that will run on Apple watches.

With Accessibility Inspector, accessibility issues can be identified using the following two scenarios:

• Issues in the core elements (its code, behavior, styling, etc.).
• Issues in navigating from one element to another (such as scrolling, pop-ups, dropdowns, etc).

Accessibility Inspector With Reset Accessibility Settings​​

Both of these areas are worked upon by analyzing the code associated with each element, a process facilitated by the inspector. However, to ease things out, the Accessibility Inspector can provide suggestions for improvement in the iOS apps for issues such as inverted colors and contrast issues.

Shortcomings of Accessibility Inspector

Accessibility Inspector is a great tool for inspecting accessibility issues and is one step towards an inclusive app world. However, there are some shortcomings of this tool that need to be kept in mind.

• Need for operating systems: Accessibility Inspector is available only on macOS, which limits its use for developers who might be working on other platforms or need cross-platform accessibility testing.

For people using Windows or Linux, procuring new Mac systems for everyone or installing virtual systems (which is not recommended due to false performance metrics) is a huge monetary and time investment.

• Absence of real devices: Accessibility Inspector uses Xcode, which uses simulators to run the application on Apple devices. Simulators are never a good idea, especially for iOS-based applications, due to memory shortage and movable devices (which raises issues like network lags).

They also provide incorrect metrics for vital parameters like network response time, load time, etc. It can create a false illusion of how the application works, which will come back to the team sooner than expected from the end-user.

• Need for physical devices: The Accessibility Inspector will require a device connected to the system in case real devices are used. However, the tester may require hundreds of devices with different specifications while performing cross-platform and cross-browser testing at scale. They will also require constant maintenance and upgrades.

Buying all the devices is a heavy dent in the balance sheet of the organization considering this is a recurring cost. In such a scenario, the team can leverage cloud-based AI testing platforms like TestMu AI, which offers a device farm of 5000+ latest and legacy iOS devices where you can test and debug your apps.

• Limited resource: Accessibility Inspector runs on limited resources provided by the host system, which in turn could be running on its share of resources in the case of virtual machines. Having limited resources that are shared by multiple applications can produce false timings.

For instance, an assistive device may start the reading process with a little delay. It is better to choose an option where resources are fast and not limited for smoother testing.

Best Practices for iOS Accessibility Testing

Apart from the predefined settings in the Accessibility Inspector, the tester should also consider other accessibility attributes that must be taken care of while performing mobile accessibility testing of iOS apps:

• Contrast: The WCAG guideline defines the contrast ratio to be at least 7:1 in stricter terms, but 4.5:1 is also acceptable. Below these limits, the elements become inaccessible to people with disabilities.

The more the contrast ratio, the better it is to distinguish between the elements and the more comfortably a viewer can view those elements together. The maximum contrast value of 21:1 is reached by complementary colors like black and white. The tester can use an online contrast checker to view the contrast values before settling on the colors.

• Media elements: While text elements can be read aloud by assistive devices, there is no way to know what video is played and what the subject is saying in it. The same is the case with image and audio elements (for people with hearing disabilities).

Therefore, it is important to pay special attention to media elements for accessibility issues while developing and testing the iOS application. The most common solution to this problem is to provide alt text for images to get the reference of the image and for video to give the transcript of the video being played.

• Logical segment division: It is recommended to divide the text into logical sections with appropriate headings. The headings, when read aloud, give the user context about the text that follows and also provide a logical path to remember the content, which is not possible in single long passages with multiple contexts.

Animations: Animations and any other type of transitions can make people uncomfortable who struggle with visual impairments. It is important to include the query prefers-reduced-motion, which helps the application understand whether the user has turned on the settings to minimize non-essential animation. In such a case, we can reduce animations on demand rather than for everyone all the time.

• Use descriptive links: A web page will contain a lot of links with redirection to the same website pages or third-party websites. While people without any disabilities can open the link and retrace it if it is irrelevant, people with visual impairment will not get the context if the link is not embedded in the correct word. Therefore, it’s important to use descriptive links that an impaired user can easily understand.

Conclusion

As a user without any impairments, it is easier to forget the features and requirements a mobile application should possess to make the lives of all people easier regardless of their abilities. However, a developer and a tester cannot think this way.

Building an application for iOS, which more than 1 billion people use, is a task that requires technical skills and responsible ethics. For this, the most sought-after solution out there is the Accessibility Inspector. It provides pre-built options to quickly inspect how the application looks when accessibility settings are turned on, or the user is using some assistive device.

Conclusion