Understanding WCAG 2.1 – Reviewing Mobile Success Criteria
Hi, everyone! I’m back to talk more about WCAG 2.1 and its latest December 7th working draft. Our focus today will be on the ten new success criterion related to accessibility for mobile devices. In our previous sessions, we’ve gone in detail on low vision and cognitive, but now it’s time to dive into the mobile success criteria.
Feel free to follow along with the video below:
Success Criterion 2.4.11: Character Key Shortcuts
The first criterion is the character key shortcuts, which is proposed at level single-A. If this feature isn’t done correctly and a person is trying to use speech to text, then people using speech to text will trigger something they did not mean to. The persona quote for this is “oh no, computer, that’s not what I mean you to do!” The specific SC text at this point in time reads, “if a keyboard shortcut consists entirely of one or more character keys, is implemented in content, then a mechanism is available to turn it off or remap it to a shortcut that can be used with at least one non-character key.” This SC does not apply if the keyboard shortcut for a user interface component is only active when that component has focus. In general, this criterion’s intention is to make it possible for people that use speech to text on their mobile devices to do it without triggering things by mistake.
Success Criterion 2.4.12: Label in Name
The second success criterion also relates to speech to text. It’s called label in name, a requirement at single-A in the proposal. Imagine you’re talking to your computer, which is very common these days, and you’re trying to submit a form. However, you don’t know what the computer wants you to call that submit button. The persona quote for this is “computer, submit the form, computer, curse word. Why aren’t you doing what I said? Why aren’t you doing what I want?” That’s because we don’t have any requirements in WCAG 2.0 to cover how one would verbally tell the computer to do something. The requirement for label in name is “for user interface components with labels that include text or images of text, the name contains the text presented.” We’ll know the name because we can see it on screen if we are sited, or a person using a screen reader could hear it because that label would match.
Success Criterion 2.5.1: Pointer Gestures
The next SC is called pointer gestures. The persona quote for this one is “you expect me to do that complex hand gesture? Are you kidding me? What is this, the finger Olympics?” Because while it may be simple for some of us to make certain hand gestures on our mobile devices or any touchscreen device, for people with a motor disability, that might be impossible for them to achieve. So this new pointer gestures SC recommended in WCAG 2.1 is about making sure that pointer gestures are possible for everyone to achieve. The specific SC text for pointer gestures is “all functionality which uses multi-point or path based gestures for operation can be operated with a single pointer. Unless that multi-point or path based gesture is essential.” This is a very important SC filling a gap in WCAG 2.1.
Success Criterion 2.5.2: Pointer Cancellation
This next success criterion also refers to pointers. Pointer cancellation is a proposed single level A. Imagine that you are working with your mobile device and maybe you have a motor disability, maybe you don’t, and all of a sudden you were just trying to do something and you accidentally submitted something. You were just trying to move around or investigate something on the screen, but you accidentally submitted something. Pointer cancellation intends to correct situations like these. The persona quote for this one is “holy curse word, I didn’t mean to just do that.” The SC text for this particular one is “for functionality which can be operated using a single pointer, at least one of the following is true. That it doesn’t happen on a down event, that there’s a way to undo it, and that if you pull up it will reverse it, or there is an essential exception.” This criterion will be very useful for all of us.
Success Criterion 2.5.3: Target Size
This next one is called target size, it relates to mobile devices and it is coming in at AA recommended. Have you ever tried to use your mobile device and you’re trying to tap on one thing, but it’s so close to another that you hit the other thing by mistake? That’s because sometimes the icons that are active on the screen are so small you really can’t get your finger on it, or it’s very difficult to get your finger on just that one thing. The persona quote on this one is “what the heck? How am I supposed to touch something that small? Who do you think I am? Ant-man? My fingers are this big.” The requirements for this success criterions is “the size of the target for pointer inputs is at least 44 by 22 CSS pixels, except when there’s an equivalent.” In other words, there is another way to do it somewhere else on the screen that’s larger or it was provided by the user agent. This will be one SC that will be appreciated by all of us as we use our mobile devices. It will require that one can actually touch an element with their finger and trigger what they intended to trigger.
Success Criterion 2.5.4: Target Size Enhanced
Target size, the success criterion above, has an AAA version of itself which is called target size enhanced. Basically, this is really the same concept, but instead of the size of the target for pointer inputs being at 22 by 44 CSS pixels, wouldn’t it be awesome if it was 44 by 44 CSS pixels? In summary, this requirement raises the 44 dimension in both directions. Anything that you’re seeing as an AAA is a best practice.
Success Criterion 2.5.5: Concurrent Input Mechanisms
The next SC is called concurrent input mechanisms and it is coming in at AAA. This SC relates to when you’re using a mobile device or using a laptop, perhaps you want to switch between input devices. In other words, you want to go from touch screen to voice or you want to add a keyboard in the middle of a workflow. Concurrent input mechanism aims to fix this problem. The persona quote for this SC is, “please let me switch between input devices as I need to.” The specific SC text for concurrent input mechanisms, is “web content does not restrict the use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.” Even coming in at AAA, this is something that we should pay attention to when we care about the usability of our sites as it is a wonderful best practice.
Success Criterion 2.6.1: Motion Actuation
The next SC is motion actuation and it is coming in at a single level A. This has been a complicated one to get the wording right. This SC requires that the user does not have to tilt or shake the device. This SC is targeted towards augmented reality and virtual reality. Making sure that as we evolve into those spaces that they’re fully accessible to all people. The persona quote is, “please don’t make me tilt or shake. I may need to perform the action in some other way. Through a keyboard, through speech. Give me some other options.” The specific SC text for this is “functionality which can be operated by device motion or user motion, can be operated by user interface components, and can be disabled to prevent accidental activation, except when it’s accessibility supported or it’s essential.” In this day and age, it is important to make sure that we can prevent accidental activation via tilt or shake or make it possible for somebody to activate these potential features.
Success Criterion 2.6.2: Orientation
The next one is called orientation and it’s coming in at a double-A requirement. It is so important to not force a person to use their device in a particular orientation. Whether it’s portrait, landscape, etc. The persona quote for this SC is, “don’t force me to rotate my mobile device.” Why is this important? Imagine you are a person who has a motor disability, that may be in a wheelchair which has a very valuable, useful mobile device attached to their wheelchair. This device is attached to one orientation and it cannot move it. The SC text for orientation is “content does not restrict its view and operation to a single display orientation, such as portrait or landscape unless a specific display orientation is essential.” If you have a really good reason for why you require a device to be portrait or landscape, don’t worry, you’re going to meet the essential exception. However, please do not restrict this feature otherwise.
Success Criterion 3.2.6: Status Changes
The last SC for mobile is called status changes and it’s proposed to be at AA. My persona quote is simply, “I can’t tell if anything has happened.” If you’re a screen reader user, and something has changed on the screen, sometimes it’s hard to know that. Sometimes the screen reader hasn’t been given that extra piece of information that a person that can see the screen saw. For example, if there is a pop-up message that appears on the screen. Screen reader users and persons with a cognitive disability may not have been aware of that particular thing. Even someone without a disability may have missed it because it was just hard to see. But in the case of people with visual disabilities or cognitive disabilities, it’s a major barrier.
The SC text for this particular one is, “in content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assisted technology without receiving focus.” I think that this will be another one to discuss in greater detail later because many people may already be calling this as a failure in WCAG 2.0 where it is not a failure of the normative language, unfortunately of WCAG 2.0. It is certainly within the spirit of WCAG 2.0, but WCAG 2.1 is meant to fill that gap and make sure that we can call it a failure in WCAG 2.1.
Conclusion
We’ve discussed low vision, cognitive, and mobile success criterion. Remember, there are a total of 20 new proposals on the table. The WCAG working group is looking forward to a late January target date, where we may actually see a candidate recommendation, which is a more formal version of WCAG 2.1. Stay tuned for more information! We’re also looking forward to introducing you in more detail to Silver, which is the big update that’s further out on the accessibility guidelines. Thanks so much for coming along on this journey.
