Hey everybody. Josh here with Online ADA, and in this video we’re covering 3.2.2 on Input. This is a single level, A requirement and the description reads “changing the setting of any user interface component does not automatically cause a change of context, unless the user has been advised of the behavior before using the component.”
Uh, that’s a big one. Basically, what this article is trying to say is that when you are interacting, as a user, when you’re interacting with content on a page, you want it to be predictable. You wanna know what’s gonna happen and not have to think about whether you’re being redirected somewhere, your focus is changing, or what have you. The exception, of course, being if you are describing–before interacting with that content– what’s gonna happen.
So, let me give you some examples. When I do audits for sites, I’m–basically, I come across a lot of these situations where folks like to input a select element, and what they do is when you make a choice on the select drop down they’ll initiate something–some action–whether it takes you to a new page, it loads new content, something like that.
That would be an example of on input. You have made a choice in the drop down, but what if you made the wrong choice? What if you are just exploring what the different choices there are by simply using the down arrow? Well, every time you do that you’re making a choice, in this context. So that would be a bad idea. A way around that would be to instead provide a button next to the select element and once you’ve made your choice, then you hit submit. That would be the way around that. That would be predictable, okay?
Another way to fail this criteria would be to have a form that’s submitted, uh, just once you had finished interacting with all the components. Let’s say you have five form fields that need to be filled out and as soon as you’ve filled out the requirement for the last one and you’ve moved past it or even just typing in, it submitted the form for you. That would be pretty crazy, right? It wouldn’t be predictable. I wouldn’t know that that was gonna happen unless you specifically said that it wouldn’t. Even then, that’s probably tricky. You wouldn’t really want that because you want a lot to allow people to backtrack and undo errors that they’ve made. So it’s important to make sure that your site is predictable.
I do feel that it’s important to identify what a change of context might be. In this case, and in many cases, a change of context are something like a new tab or a new window or just being redirected to a new URL, effectively removing the option that initiated the change. If you are using a radio button or radio group and you have three options, and when you choose one it just opens a new page, then you would have to go back and find that element again. That’s a change of context. If your content on the page, if you have, for instance, a one page checkout, for instance, you could have a situation where you’re making a choice of, um, maybe quantity or you’re trying to enter a coupon or something, and as soon as you have typed something in or you’ve made a selection it changes to the next page. It didn’t change to a new URL–it just loaded new content, and your option has been taken away. What if you made a mistake and you wanted to undo that? That’s a change of context.
A situation where it IS okay to do something like this is like a tab list. If your radio buttons, instead, change what content is presented below the radio buttons as you make your choices across them, new content appears–that’s changing just part of your context. You haven’t removed their ability to, uh, make a new choice, and that is okay in this instance. Another common situation I see that’s worth noting is on form fields that require a phone number. Maybe they’ve broken up the phone Into three separate boxes, right? And so the first one is the area code and then you’ve got your different three-digit, four-digit situation. Well, if you are allowing a user to tab into the first, the area code box, and then as soon as they type in three numbers it just moves to the next box–that is a change of context. You’re no longer in the same element, right? You’ve been you–your option to change what you’ve just typed in has been removed from you. You have to go find that. And imagine how difficult that would be for a non-visual user who, now, is in a different input box and they don’t realize it, um, assumingly.
So, in this case, if you describe ahead of time that that is what the behavior is, then it’s acceptable, according to this criteria. So we just wanna be mindful that our interactions are predictable and that we’re not disorienting our users by providing, um, non-standard interactions with our interactable elements. Okay?
Thanks for joining me and I’ll see you in the next video.