Hey, everyone! In this week’s video I discussed the UI adjustable trait. I recently gave a presentation regarding the UI adjustable trait design pattern at the Bay Area Accessibility Camp by LinkedIn and Microsoft. It was a really great experience and I was able to demo this cool design pattern, but I didn’t have a chance to talk about how and when it should be implemented. That’s what I’m going to dive into in the video below.
Follow along here in my recorded walkthrough if you’d like:
How to Use the Accessibility Inspector to Simulate VoiceOver
To start, open up the accessibility inspector and the app you would like to demo. In this demo and example, you may mark up what is a basic segmented accessibility step where you have these increment and decrement buttons. For example, say you’re going to buy tomatoes and you want to either increase or decrease the number of tomatoes you have. Before you test this design pattern, it is important to know how to use the accessibility inspector. As you open the inspector the first thing you’ll notice is the target icon on the simulator.
To drive this icon, you may drag your finger around and touch targets and this will be reflected in your simulator. In order to lock from touch to explore, you click on the button in question. Basically, what we are doing in the accessibility inspector is simulating Voiceover. It is important to note that a VoiceOver user, which could be a blind VoiceOver user, is probably not going to use Voiceover like that. It is possible that they may occasionally put focus back on the screen or put focus in the middle of the screen, but, more often than not, they’re going to use these swipe right and swipe left gestures. It is possible to simulate the swipe right and swipe left gesture too with our arrow icons. To do this, hit the right arrow.
Discerning Information in the Accessibility Inspector
In this imaginary example, hide your simulator application and only use the accessibility inspector. You could navigate to the adjustable segmented control box. You could swipe right or click the right arrow button to decrement an item. However, you would not be able to see the number queued up at this point because the UI label only announces the label as buy tomatoes. As you swipe right or left is will announce increment or decrement, but not the actual number of tomatoes that you have. What if you wanted to add a hundred items to your card? If you were a low vision or blind user you would have to remember what number you are on as you swipe. It would get very frustrating, very fast.
Real World Applications: Accessible Does Not Equal a Positive User Experience
This is a really simple layout here. In practice, these layouts are going to be much, much more complicated than this. At the end of the day, this is accessible. This UI design pattern meets the Web Content Accessibility Guidelines (WCAG) criteria in a hypothetical world. Another way to explain this is that this UI has two pieces of information within this control. There are a number of items that we have in a cart, and then you have the fact that they can be incremented or decremented. These two pieces of information are being stored separately.
The Solution: Wrapping UI Labels
The solution to this unfriendly user experience is to wrap all this information together. If you were adding tomatoes to your cart, VoiceOver would read one banana instead of banana and increment or decrement. The great part is that this trade is adjustable and you would no longer have the trade up button. Additionally, by wrapping labels together the focus would no longer be on increment and decrement controls separately anymore. Instead, this design pattern has gained a couple of actions here. Not only can you increment and decrement but that information is going to be a trait to a VoiceOver user. Additionally, adjustable also means that VoiceOver users gain access to these actions where you can swipe up and swipe down on a control instead of going to those second increment and decrement controls.
Properties of Design Labels and Tags
By wrapping all of this information together, we have a really concise, collective piece of information. Layout will be wrapped in a special accessibility stepper class. Properties of this class will include a primary label, a secondary label, and the tag of the stepper. In this design, you would assign these tags to the individual views. The individual views are nameLabel and the hintLabel are UI labels. The accessibility label is gonna be the combination of the nameLabel and the hintLabel.
Now, it is important to name these labels as nameLabel and hintLabel for an important reason. The nameLabel requires absolutely the essential information and the hintLabel can either be grouped with the accessibility label or we can just let it be portrayed by the hint itself, depending on how crucial the information is. The overarching layout should be an accessibility element. In other words, the entire thing would be an accessibility element, which will keep the individual elements from being focused. That is all it takes to design an accessible UI adjustable trait with movements. That being said, this is not the way you should do it every time. However, oftentimes it is helpful to have a sensible grouping of information of the design idioms that you work on.