Buttons

It is also important to keep it as short as possible; we don’t want to create experiences that are too verbose. But there are some cases in which a bit more context is needed. For example, a good label for a button with a “+” icon could be just “Add.” That would be enough in some situations. If it is placed in the navigation bar, for example, it is probably representing a global action in that section of the app where the context is clear. Could it be adding a new note? Or creating a new photo album? But if it is within the content of the app, it may require further clarification. Consider a music app example: is it clear that you are adding the album to your music library? Or are you adding a song to a playlist? Or are you following an artist in which case “Follow” would be a better label? If it is not clear, you may want to add some more information in the accessibility label, like “Add song.” If it is still not clear, you can also use a hint for further explanation on what actioning the button does. We will talk about hints later in the chapter.

We also want to avoid redundancy. Back to the music app example, if we are in the player, we also know we are dealing with a song. Instead of “Play song,” “Pause song,” “Skip song,” “Repeat song,”… we can just use “Play,” “Pause,” “Skip,” or “Repeat.”

Some buttons also change their state and mean different things. In that case we want to remember to update the label when the state changes. If we have a follow button, when pressed, it may change to an unfollow button. Or a button for adding a song to a playlist may change to delete from the playlist, once added.

And finally, when adding accessibility labels, please never add the type of the element to the label, as VoiceOver will already vocalize the traits of the component. More on accessibility traits later in the chapter too. This is something that happens a lot in the case of buttons. It wouldn’t be a good practice to use the word “button” in the accessibility label. If we added the label “Add button” in the previous example, VoiceOver would read “Add button. Button” and that would just be unnecessary duplicated information.

In short, I would say that, when setting our accessibility labels, we want to give as much context as possible avoiding verbosity and redundancy.

Abbreviations

Sometimes you will also need to set a different accessibility label to the title of the UI component. A classic example is when showing times like 01:30 for minutes and seconds or when using abbreviations like 2d for 2 days or 2 days ago, although sometimes VoiceOver is smart enough to read properly some date abbreviations.

Remember to test it

But there are many other tweaks and configurations available. So, if when testing VoiceOver anything sounds odd, you may find something in the attributed strings documentation for accessibility attributes that helps you create a more natural experience with VoiceOver: https://developer.apple.com/documentation/uikit/accessibility/uiaccessibility/speech_attributes_for_attributed_strings

And one more thing…, or two

Animations and spinners: it is quite easy to forget to configure a label for your animations that are communicating important information, for example, when “Loading…,” “Updating…,” or “Uploading…” any content in your app. Please give your spinner a label. I know most of times your app loads really fast, but sometimes users might have poor signal and it can take a couple seconds.

The verbosity exception rule: I know I said we must avoid verbosity, but sometimes in order to give enough context, you may need to be verbose. This may happen with information that is very visual. If there are photos, it is great to properly give some details about the images. Or with a stickers pack app, where it is great to explain what each sticker is about. It is all about finding the right balance: avoid unnecessary verbosity while providing information that is useful.

Header

Some traits make navigation much easier. Imagine having to read this book without any headings at all. Think about how useful it is to be able to quickly visually identify the different chapters and sections in the book to find the information you need straight away or to pick it up where you left it before. There is a way of letting VoiceOver users jump from one section to the next/previous one, and, for that, we’ll need to introduce the concept of the Rotor first.

You can use the Rotor (Figure 3-1) and select one of its options by using two fingers and rotating them on the screen around a center point, as if you were using an invisible knob. And as you rotate, it will speak all the options you can use to navigate the app. Once you select the Headings option, for example, you can navigate using swipes up/down to go to the previous/next header.

One of the options is “Headings.” So if you select to navigate by headings in the Rotor, you can swipe down to go to the next heading or up to go to the previous one.

Finally, in the VoiceOver settings, you can customize the options in the Rotor. There are tons of them (speaking character by character/word by word..., changing the speaking rate, changing the typing mode, etc.), and it is worth going through the list to check that your app supports them correctly.

This is quite common when you need to group some content in an app in different subsections in one view controller, for example, when you have headers in a table view or collection view. The screenshots (Figure 3-2) are two good examples. The first one is from the Search screen in the BBC News app. Just imagine how many swipes you would need to get to the “More Topics” section if those headings didn’t have the right header trait configured. The second example is from the Settings screen in the BBC+ app. It would be difficult to mentally structure and group all the settings options in the different categories if they weren’t organized in subsections with their corresponding heading.

Button

You will also find that sometimes you need to configure a specific accessibility trait when you are trying to write a custom component that will mimic a native counterpart. For example, you may want to write a custom button because you want it to have a nice animation when the user taps on it.

Adjustable

For example, if your slider shows prices from $100,000 to $2,000,000, you might want to increment and decrement in chunks of $100,000 - which would be the value of the variable stepSize in the code -, and not of $1 or $10, or it would be almost impossible to adjust it to sensible values.

You may also want to send a value-changed action just in case you are relying on that action for some other logic, like updating the text of a label so that it reflects the value of the slider.

Don’t worry about the accessibility value for the moment, we’ll get to it in the next section, in which we’ll also see an example of a possible implementation for the readableValue() function.

The important thing to remember here is that this is the way you can allow a user to adjust your adjustable UI component and to decide which value to set the component to when it gets incremented/decremented.

Some other examples of adjustable components you may have in your app can be carrousels for picking up an item or custom components for rating like the one in the image (Figure 3-3), which is included in the code examples repository of the book.

And more

The best thing you can do is to go to Apple’s documentation and familiarize yourself with some of the traits available (link, selected, not available, etc.) and come back to them especially when you are creating custom UI components or navigation patterns in your app: https://developer.apple.com/documentation/uikit/accessibility/uiaccessibility/accessibility_traits.