Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Show Your Humanity by Making iOS Apps Accessible

DZone's Guide to

Show Your Humanity by Making iOS Apps Accessible

There are features you can use in iOS apps to help with accessibility for disabled or impaired users. Learn about these features and how to implement them.

· Mobile Zone ·
Free Resource

Apple takes accessibility very seriously for all their platforms to make sure all the iOS, macOS, tvOS, and watchOS apps are usable for everyone, including people with disabilities. Every human being is not the same; some people have disabilities like vision impairment, deafness, mental health conditions, or physical disabilities. However, technology has grown so much that people with disabilities can do all sorts of things that other users do. They feel more enabled when technology helps them to make their lives happier. As an iOS application developer, we should also contribute to their lives with little efforts by making iOS apps accessible to everyone. In this post, we will see how to improve the accessibility of iOS apps to make apps accessible as well as testable.

Apple Accessibility Technologies

Apple has done a lot of work so far by improving the API that allows developers to make apps accessible. It takes very little effort and a little bit of code to make apps accessible to everyone, regardless of their needs.

Apple focuses on four major accessibility concerns and has added assistive features, supporting tools, and technologies to support users with those disabilities. The four areas include

  • Motor Control

    Some users can't push with force on the screen or can't accurately tap a target. Apple has added technologies like Switch Control and Dwell Control so that users can easily select and tap on the apps or area they are interested in. Switch Control is now available on all other Apple platforms as well.
  • Vision

    Some users cannot see properly or are blind. Apple added technologies like Display Adjustment and Magnifiers so that users can use the phone camera to magnify the content on the screen.
  • Hearing

    For users who are deaf or cannot hear, Apple has introduced software TTY technology inbuilt with iPhone so that users don't need to use additional big hardware to use TTY.
  • Learning

    Some users have mental health problems or conditions like dyslexia and autism. Apple has enhanced the typing feedback for users with learning disabilities.

On top of this, Apple has improved the Accessibility API a lot, which we will cover later in this post. Apple is investing a lot in accessibility so that their apps can be used for everyone, including people with a disability, and wants you to make apps which are accessible, too.

Why Are Accessibility Considerations Often Ignored?

There are some companies who take accessibility very seriously, like Apple, British Broadcasting Corporation, and some government websites, but it is common that accessibility considerations are ignored by the most other organizations. I don't know the real reasons, but the potential reasons I can think of are as follows:

  • Most e-commerce businesses don't consider the accessibility aspect because they only target a certain audience.
  • Businesses cannot justify spending money on accessibility-related features.
  • Development teams don't understand the technical aspects of accessibility and its importance.
  • Developers feel that it's additional work or burden to implement accessibility features in apps.

Can you think any other reasons?

It is totally fine if implementing accessibility features takes days or weeks to implement, but what about if a line or a couple of lines of code makes someone's lives easy? You should definitely do this for disabled users. If you are deliberately ignoring accessibility, then you are not human. Apple has provided clean Accessibility APIs that can be easily used for making apps accessible.

Audit App for Accessibility

In order to make an iOS app accessible, you need to know the accessibility flaws in your app. Once you know what needs to be improved, then you can fix that using Apple's Accessibility API. So how do we know if our app has accessibility issues or not? The old way to check for accessibility was to turn on the VoiceOver and navigate to every screen of the app and note the issues. However, this is a very time-consuming process. Apple has launched a new tool called "Accessibility Inspector." You should definitely watch the WWDC 2016 video on Auditing iOS App for Accessibility to learn more about Accessibility Inspector. I will cover its practical use in later posts. The Accessibility Inspector helps us to audit our iOS apps within a few minutes and highlights all the issues within an app. Once we know about the issues, then we can fix issues using the awesome Accessibility API provided by Apple.

Common Accessibility Issues

The audit report for accessibility should give a list of the flaws in the iOS app, but some of the common problems that we usually see are

  • Missing Accessibility Labels for the UI elements like buttons, labels, images, etc
  • Missing Accessibility Identifiers for the UI elements like buttons, labels, images, etc
  • Poor design without considering color and fonts
  • Dynamic Font issues
  • Non-localized accessibility labels

There might be some more issues, but the common issues that I can think of are mentioned above.

Use Accessibility APIs

Apple's UIKit framework has standard accessibility baked in so that we don't have to do additional work to fix accessibility issues. We just have to provide the correct accessibility information for each and every UI element that we are declaring in our iOS apps. We can easily fix accessibility issues found during the audit using the UIAccessibility protocol, which has a lot of methods to deal with all possible issues. We can make our app accessible by implementing the methods of the UIAccessibility protocol. Now let's highlight some of these properties and methods and how we can use them to make an app accessible.

IsAccesibilityElement

The UIAccessibility protocol has a property called isAccessibileElement: Bool, which determines whether the element should be exposed to assertive technology like VoiceOver. We can set this property true for the elements that help users to assist with more information. For example, for the background image of UIView, we can set it to false however for the logo we can set it to true so that user will know that its logo on the screen. Assuming we have an image view with the name logoImage and backgroundImage in our app, we can use this property like this:

logoImage.isAccessibleElement = true 
backgroundImage.isAccessibilityElement = false

AccessibilityLabel

The UIAccessibility protocol has another property accessibilityLabel: String, which is being read by assistive technologies like VoiceOver. It's a succinct label that identifies the accessibility element in a localized string. One of the common mistakes that we forget to localize this property. We should localize this value per language so that users from different countries will hear accessibility information in their own languages. For example, we have hellolabel that says hello if we add accessibility information, something like this:

helloLabel.accessibilityLabel = "Hello"

The voice over will read it as "Hello" even though the app language and locale is French. I am sure French people would like to hear "Bonjour" rather than "Hello." We should use localized strings in that case that will make VoiceOver read "hello" in different languages. You can achieve that by writing a simple String extension and use the localized values form translations string for all labels. You can find a sample GitHub project here for reference.

AccessibilityIdentifier

There is another very important instant property for the property accessibilityIdentifier which allows us to uniquely identify a UI element on the screen. The documentation can be found here. This property is super important to make our app testable for Xcode UI Test a.k.a. XCUITest. We  can add AccessibilityIdentifier for helloLable using

helloLabel.accessibilityIdentifier = "Hello"

AccessibilityTraits

The UIAccessibility protocol has another property which characterizes accessibility elements. We can provide trains for buttons, images, adjustable, etc. You can read more about traits here. In order to add UIAccessibility trait to button helloButton, we can use

helloButton.accessibilityTraits |= UIAccessibilityTraitButton

AccessibilityValue

The UIAccessibility protocol has another property, accessibilityValue: String, which is used for determining the value of an element at certain state, e.g. slider, picker wheel, etc. We can add value to mySlider using

mySlider.accessibilityLabel = "\(current.value) points"

There some other API can be used for the custom views, but we are good if we use the above API properly throughout the app.

Benefits of Making Apps Accessible

The question is why you would want to make your app accessible. What are the other benefits of making apps accessible apart from helping disabled people? Here are some quick benefits:

  • Adding accessibility makes iOS apps usable for everyone.
  • VoiceOver users can benefit from their local languages.
  • Adding accessibilityIdentifier makes apps testable by XCUITest, which speeds up the testing process.
  • Xcode UI tests became stable and concrete to provide early feedback during app development.

Conclusion

This is a short post to convince iOS developers, designers, and everyone involved in an iOS team to take accessibility seriously and make the lives of disabled people much easier. Although QA guys are not physically disabled, adding accessibility identifiers makes their lives easy as well. Accessibility is for everyone, and remember, accessibility is humanity. Be human!

Topics:
xcode ,swift ,ios ,accessibility ,mobile ,mobile app development ,apple ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}