Mobile accessibility – Vision

Okay, but first things first. What is Accessibility? Accessibility refers to the design of products, devices, services, or environments, so that they are usable by people with disabilities. In the context of mobile applications, accessibility refers to the ability of the app to be used by people with a wide range of disabilities, including visual, auditory, physical, speech, cognitive, and neurological ones.

There are several characteristics that can contribute to the accessibility of a mobile app:

The road to perfectly executed accessibility in mobile applications may be fraught with obstacles, but it doesn’t have to be! So, I will show you what accessibility looks like for people with vision problems and how to approach it from both a business and development perspective.

According to Apple Documentation, vision accessibility features aim to support users who are blind or have low vision.

But this little part of documentation is not all we are left off. Apple is showing off all their tricks with helpful links to documentation for developers or product owners. And today, I would like to discuss all those features and toss in my two cents’ worth of knowledge from a developer perspective. Referring to the intro of the article, I’m a pretty young person (that’s what I tell myself when I see gray hairs on my head 😄), but the topic of accessibility simply always was somewhere there for me, even though I’m not facing much of them. And the vision one is one of those easier to find in our day to day lives – simply by looking in the mirror, our parents, grandparents or each other on the street. What do you see? A lot of people have some form of corrective glasses or eye lenses. Some of them even have more conspicuous ones, for instance there are 8 different types of color vision deficiencies and people with such have other types of colored, corrective glasses (in my high school years I had a friend who’s sister had a pair of those). There are blind people, and cities are using special materials that mark the start and the end of street crossings for them. So, we may ask why would Apple or Google not add such features to their systems. And of course they did! Those consist of (quoted from Apple documentation):

And this is going to be a lovely ride for me to be your guide through them in this article.

First, and I would say one of more often used, features is Dynamic Type. This one is tricky, while it gives the user the ability to change the size of the text content on the screen, it also needs additional work from the User Interface (UI)  and User Experience (UX)  side. That might be sometimes a lot of work, while the UI and UX designers need to know how much those elements will scale up or down, depending on the level of dynamic type the user chooses. Below you can see how changing those can change the layout on the screen, and this is not even the biggest or smallest setting yet.

Small Dynamic Type

BIG Dynamic Type

There are 6 basic levels of Dynamic Type and if you click “Large Accessibility Sizes”, this number changes to 12. So, it’s a lot of flavors to consider in such a “small” feature. But it makes a difference for the users with disabled vision, and in SwiftUI (the latest UI framework for Apple Devices) it is supported out of the box and the UI will be resized accordingly to the given size. Of course we can control which level of the dynamic type is the highest in our app. But it’s a good practice to handle at least the 6 basic ones and I always highly encourage that in meetings.

So, a good tip for developers:

And a good tip for product owners:

I will only discuss those features that are not out of the box described by Apple or logically described by name. Interesting thing about those features is that it costs nothing from a development standpoint, but it gives Apple Apps users such support out of the box and the developers don’t need to add any of their work to them.

Buttons Shapes

This feature shows exact shapes of the buttons, for instance if the shape of the button is clipped to Circle, the shape on the screen normally will be rectangle under the hood and this feature will show us that, and what the “hitbox” or padding of the button is.

On/Off Labels

This feature shows user if the toggle is on or off

I recommend you to check out the rest of the features to know how those work and experiment with them, and to place yourself in someone else’s boots. This can dramatically change perspective on development or planning of the features.

Screen accessibility, in my opinion, can be split into two categories: Motion and Zoom/Magnification in iPhones. While the second one of the two has more options, Motion on the other hand only has up to 4. So, let’s briefly go through what can be done easier on those two.

Reduced Motion and Cross-fade

If you have ever had a headache because of the amount of motions created by the navigation system in iOS, here comes the help. You can switch on Reduce Motion and Prefer Cross-Fade Transitions, and the navigation between different apps or screens will be much more motion free which is very nice.

Non Reduced Version

Reduced Version

 Auto-play Messages Effects and Video Previews

In the Messages app, there is an option to send an emoji message with nice sparkle like effects and much more!

But as a user you may not like or just do not feel well when something is jumping on you automatically. Same for Video previews. So, Apple gives you the ability to turn those settings on or off according to your liking.

There is a Zoom Option for iOS and MacOS devices, and it can be very helpful when something is not defined with the accessibility in mind or just to simply zoom for stuff on screen when presenting to your team or family :D. Of course it cannot be only bells and whistles, there is a dark side to it. Some users of your app can turn this option on and it will totally disorient them when they don’t know what they are doing. And then there is a close call to your app service line or email that your app is not visible or not working. So, it’s good to know about this function for future problems.

Screen Reader or as Apple calls it VoiceOver can be great companionship with a pair of VoiceControl. But we are not going to talk about the second one this time as it’s a part of Physical and Motor Accessibility. Let’s focus on VoiceOver which is one of its classes. While I saw the same features on the other system, I do not think those were working so well as the one of Apple. 

When you go to the VoiceOver page, first you will be greeted with a manual of kind, it’s very concise and to the point, teaching you the basics of VoiceOver in seconds. You can even use VoiceOver to get your iPhone to read it for you!

Before I continue with the feature set further, I would like to say that VoiceOver is very much one of the easiest parts of accessibility given to us by Apple for integration into our apps. So, I would like to use this occasion to say a few words about how to implement basic controls for the VoiceOver in iOS, tell you how approaching VoiceOver or accessibility in general, in tasks planning/refining may add additional benefits to users of your app or even protect you from a lawsuit (more about this topic later, but we have a very real example of it in my team).

From the Developer Perspective

First, I would like to introduce you to a good Apple system developers friend, Accessibility Inspector. With this tool, you as a developer or even an end user can check how the accessibility looks like for a given screen or App. It looks something like this:

It may not look like much, but you can select the scope icon in it and inspect every element on the screen of your Mac or iPhone Simulator. And why is this needed? Well, how else would you check if you did a good job? 😀

So, basically for VoiceOver there are 3 controls that are worth mention and those only 3 parts of code will give disabled users a lot of help from you:

AccessiblityLabel – is used for giving an accessibility context to the element, for instance “Account Open Button”, and a user with vision problems will shortly know that, when clicked, it will open his account settings or profile screen.

AccesibilityValues – is used for giving information about a value of the element. This one is mostly used on elements that can have some other state than default. For instance Toggles or Sliders. Toggles have this accessibility out of the box, so it may not be a perfect example :D, but you can add a little bit more context with your own implementation.

AccesibilityHint – is used for displaying the result of a given action, for instance clicking a button opening a safari to some page, and it will be automatically said by the system after a quick pause.

There are a lot of other attributes interconnected with accessibility, but for VoiceOver this is very much enough.

From Task Planning Perspective

So, as you could see in the previous paragraph, VoiceOver has very little impact on the time consumed on development. But it needs some consideration in the task planning part. Probably you don’t need to involve designers to this talk, but it would be wise to keep those localized for your user base. So, in the task description I would see it as max 15 minutes of additional work for the developer and the product manager or someone that is responsible for localizing the texts in the app. And those 15 minutes can be very much beneficial for the future. You remember as I told you that accessibility and VoiceOver can make you dodge the lawsuit? Well, it is true. A dear friend from my team and his project were faced with such a lawsuit. The company making the App he was working on said in their app page that they “support accessibility” and it was not true. They had some parts of accessibility, but not the full implementation. And at that moment, my friend had one of the longest working weeks in his career in front of him. In the end, it turned out fine, but the amount of work it needed later, while it could have been done before, is tremendous. 

If you are still interested in MacOS, there are a few nice accessibility features, like my most loved one that I call “shake it until you see it”. It’s a nifty little trick to see your cursor when you have a lot of screens or just a very little cursor.

So to summarize the article, why you should consider vision accessibility and accessibility in general: