- Hi, my name is Glenda Sims,
and I'm the lead accessibility expert at Deque.
And today we're going to continue talking about WCAG 2.1.
Our focus today will be on mobile.
In our previous sessions,
we've gone in detail on low vision and cognitive.
But now it's time to dive into mobile.
In this WCAG 2.1 working draft,
that's as recent as December 7th,
there are 10 success criterion that are being proposed
that came out of the needs for
accessibility related to mobile devices.
So let's work through those 10
so I can basically give you an introduction.
The first one that comes into play
is the character key shortcuts.
It's proposed at level single A.
And if this isn't done correctly,
and a person is trying to use speech to text,
if character key shortcuts is failed as a success criterion,
then people using speech to text
are gonna end up triggering some kind of activity
that they did not mean to do.
So my persona quote for this one is
oh no, computer, that's not what I mean you to do.
So when we're thinking about why we're doing this.
The specific SC text at this point in time
reads like this.
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.
Unless, there is a keyboard shortcut
for a user interface component
is only active when that component has focus.
So it's written very precisely
and important for testability.
But in general that means
let's make it possible for people that use speech to text
on their mobile devices
to do it without triggering things by mistake.
The second SC that I want to cover
is also to do with speech to text.
And it's called label in name,
a requirement at single A in the proposal.
Imagine you're talking to your computer,
which is far more common these days,
and you're trying to submit a form.
But you don't know what the computer wants you to call
that submit button.
That's what this one is about.
My persona quote for this one is
computer, submit the form,
computer, curse word.
Why aren't you doing what I said?
Why aren't you doing what I want?
And that's because we don't have any requirements
in WCAG 2.0 to cover
how would I verbally tell the computer to do something.
So 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,
so that when we're trying to talk to our computers,
we can do it.
And we'll know the name 'cause we can see it on screen
if recited,
or a person using a screen reader could hear it
because that label would match.
So that's label in name.
Important for us interfacing by voice.
The next SC is called pointer gestures.
Again focused on mobile.
And I have a funny persona quote for this one.
And it 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 it's 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.
So very important SC filling a gap
in WCAG 2.1.
So I'm very hopeful that that one will
make it all the way in.
The next one also has to do with pointers.
And it is called pointer cancellation.
Single level A is the proposal.
And 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 it actually submitted.
You were just trying to move around
or investigate something on the screen,
but it actually went ahead and submitted,
and you didn't intend that.
Pointer cancellation is for providing this way back out.
So, my 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.
So I didn't read all the text to you
'cause it's really long,
but it is allowing you to not get stuck with
trying to do something on your screen
and it actually submitting without that
being your true intention.
So I think that one will be very useful for all of us.
This next one I think you're gonna relate to
whether you have a disability or not.
And it is called target size.
For mobile devices coming in at AA recommended.
So 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 things
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.
So my 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.
So I think this one will be very valuable for all humans.
And right now, it's sitting at this.
I'm gonna read part of the text to you.
The size of the target for pointer inputs
is at least 44 by 22
CSS pixels,
except when there's an equivalent.
So there's another way to do it
somewhere else on the screen that's larger.
Or it was provided by the user agent.
The author didn't do anything.
So I'm not gonna hold the author responsible for something
if that's the way the browser did it by default.
Or it's essential.
So I think this will be one that's very appreciated
by all of us as we use our mobile devices.
Make it so I can actually touch it with my finger
and trigger what I intended to trigger.
Target size that I just went over AA
actually has a AAA version of itself
which is called target size enhanced.
And so it's 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?
So that's what target size enhanced is.
It's just raising that 44 dimension in both directions.
That would be coming in as a AAA.
Anything that you're seeing as a AAA is a best practice.
We certainly encourage it.
But I've never seen it as a legal requirement,
if you're looking at it from that angle.
The next SC is called concurrent input mechanisms.
This one is coming in at AAA,
and it relates to
perhaps as a user,
whether you're using a mobile device
or using a laptop,
perhaps you want to switch between input devices.
Maybe you want to go from touch screen to voice,
you want to add a keyboard in the middle of a workflow.
You should be able to do that.
So concurrent input mechanism,
my persona quote is,
please let me switch between input devices as I need to.
The specific SC text for concurrent input mechanisms,
as it stands now 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.
So I think that even coming in at AAA,
this is something that we should pay attention to
when we care about the usability of our sites.
It's a wonderful best practice.
The next one is motion actuation.
And this one is coming in at single level A.
And it's been a complicated one to get the wording right.
It's related to don't make me, the user,
tilt or shake the device.
And I haven't been following this one as closely.
But in what I'm hearing in conversations is
they're actually thinking about augmented reality
and virtual reality in this.
So making sure as we move into those spaces
that they're fully accessible to all people.
Persona quote again 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.
So in this day and age
where our computers are paying attention to what we're doing
out in space by watching us with their cameras,
or what we're doing to the device
by tilting or shaking it,
make sure that we can prevent accidental activation.
Or make it possible for somebody to activate at all.
So very important.
The next one is called orientation.
And it's coming in at a AA requirement.
And what I hadn't realized is
how important it is to not force a person
to use their device
in a particular orientation.
Whether it's portrait, landscape,
that kind of thing.
So my persona quote is,
don't force me to rotate my mobile device.
Why is this important?
I want you to imagine a person who has a motor disability,
that may be in a wheelchair,
that has a very valuable,
useful mobile device attached to their wheelchair.
And it's attached in one orientation.
And they can't move it.
So maybe its portrait.
If you require that screen
to work only in landscape,
and they can't turn it,
they're kind of stuck using the web like this.
That's really not polite right?
So 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.
So don't worry.
If you have a really good reason
why you have to go portrait or landscape,
and it's one part of your mobile app,
rock on, you're gonna meet the essential exception.
But please don't restrict it and make us walk around
or use our devices like this.
And the last SC
for mobile
that's in the December 7th WCAG 2.1 version
is called status change.
And it's at AA,
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
this movement up here and went oh,
there's a new message up here.
Screen reader user may not have been aware
of that particular thing.
And a person with a cognitive disability
may have missed it as well.
Or heck, we all 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.
So that's what status change is about.
That persona quote again is,
did anything happen?
Did it listen to me?
Did it take my submit?
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 being 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.
That brings us to the conclusion of
an introduction to the new SC
as they sit on December 7th for WCAG 2.1.
We've discussed low vision,
cognitive,
and mobile SC.
Remember there are a total of 20 new proposals on the table.
And we're looking forward to
the January 23rd target date
where we may actually see a candidate recommendation,
which is a more formal version of WCAG 2.1.
That's the target date.
So stay tuned for more information.
And 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.
So join us again in the new year.
Thanks so much for coming along on this journey.