E-mail List Archives
Thread: Regarding SC 1.3.1
Number of posts in this thread: 3 (In chronological order)
From: Eilana Benish
Date: Mon, May 09 2022 9:26AM
Subject: Regarding SC 1.3.1
No previous message | Next message →
Hello everybody
I am testing a system Which provides Lessons And exercises For students.
This system Should be accessible To meet WCAG 2.0 Level A and AA
In every topic There is 10 buttons in the shape of Rounded square Icons for
each exercise, That can be navigated with the keyboard And they have labels
for screen readers To indicate The number of the exercise.
Keyboard navigation is good with the tab and shift+tab keys and the arrow
keys
The buttons are clearly labeled for the screen readers
focus visible on the buttons when navigating is good
but there is no indication with text such as tooltip or title.
The question is, is it enough two add a visible tooltip or a title- so the
text for the button can be seen with mouse hover and when a button receives
keyboard focus?
I see this implementation for example in the Gmail app for the web, when
the text for the settings button for example can be seen with mouse hover
and when that button receives keyboard focusâ¦
The company that I am testing this application tells me that if not they
should go back to the design stage two change the design of that partâ¦
So is this implementation like in the Gmail app meets success criteria
1.3.3 Sensory Characteristics?
https://www.w3.org/WAI/WCAG21/Understanding/sensory-characteristics.html
Thanks in advance
Eilana Benish
From: glen walker
Date: Mon, May 09 2022 12:07PM
Subject: Re: Regarding SC 1.3.1
← Previous message | Next message →
Hi Eilana, a couple clarifying questions first.
Your subject line mentions 1.3.1 (Info and Relationships) but then your
question at the end asked about 1.3.3 Sensory Characteristics. I don't see
a problem with either guideline given the current information.
If your page includes instructions that the user must click on the "rounded
square button", then that would be a 1.3.3 issue. But if the instructions
said to click on the "rounded square next button" or the "rounded square
answer button", or included some kind of label in addition to a description
of the shape, then it would be ok because the instructions don't rely
"solely" on sensory characters. You also have a button name.
Now, the fact that your buttons only show a picture (I'm guessing) and
don't have a visible label, some would argue that that's not technically an
accessibility failure because it fails for all users. If no one knows what
the button picture means (except for maybe an assistive technology user if
there's an aria-label), then it's an equally bad experience for everyone.
Adding a tooltip like the gmail web interface is a great UX feature but
isn't necessarily required for accessibility.
For buttons without labels, I sometimes try to apply 3.3.2 but that
guideline says you need labels when "user input" is required. Is clicking
on a button considered "user input". Maybe. But the "understanding"
section for that guideline (which is not normative) says "This Success
Criterion does not apply to links or other controls (such as an
expand/collapse widget, or similar interactive components) that are not
associated with data entry."
It's hard to make the call if your buttons are used for "data entry" or
"user input".
The understanding section talks about radio buttons and checkboxes needing
labels because those elements could be part of a form and provide a way to
supply "data entry". I have not seen a form where a button is used for
data entry other than the final submission of the form itself. If you have
several submit buttons, such as "submit form to person X" and "submit form
to person Y", then mayyyyybe that's considered part of the data entry????
At this point, you have to go beyond conformance and decide what's best for
all users whether your situation technically fails WCAG or not.
On Mon, May 9, 2022 at 9:27 AM Eilana Benish < = EMAIL ADDRESS REMOVED = > wrote:
> Hello everybody
>
> I am testing a system Which provides Lessons And exercises For students.
> This system Should be accessible To meet WCAG 2.0 Level A and AA
>
> In every topic There is 10 buttons in the shape of Rounded square Icons for
> each exercise, That can be navigated with the keyboard And they have labels
> for screen readers To indicate The number of the exercise.
>
> Keyboard navigation is good with the tab and shift+tab keys and the arrow
> keys
>
> The buttons are clearly labeled for the screen readers
>
> focus visible on the buttons when navigating is good
>
> but there is no indication with text such as tooltip or title.
>
> The question is, is it enough two add a visible tooltip or a title- so the
> text for the button can be seen with mouse hover and when a button receives
> keyboard focus?
>
> I see this implementation for example in the Gmail app for the web, when
> the text for the settings button for example can be seen with mouse hover
> and when that button receives keyboard focusâ¦
>
> The company that I am testing this application tells me that if not they
> should go back to the design stage two change the design of that partâ¦
>
> So is this implementation like in the Gmail app meets success criteria
> 1.3.3 Sensory Characteristics?
>
> https://www.w3.org/WAI/WCAG21/Understanding/sensory-characteristics.html
>
> Thanks in advance
>
> Eilana Benish
> > > > >
From: glen walker
Date: Tue, May 10 2022 3:19PM
Subject: Re: Regarding SC 1.3.1
← Previous message | No next message
You'll want to see how your solution works on mobile devices too since they
typically don't have a tooltip. That is, how would a mobile user see the
tooltip for the buttons?
On Tue, May 10, 2022 at 1:15 PM Eilana Benish < = EMAIL ADDRESS REMOVED = >
wrote:
> Hi Glen
>
> Well thank you very much for your answer
>
> and yes I meant SC 1.3.3 sensory characteristics
>
> the interface includes 10 buttons that right now have only label provided
> with aria-label
>
> sighted users can see right now only the shape of the buttons and screen
> reader users can hear the labels - exercise one, 2, three etcâ¦
>
> Pressing enter or left click on the mouse on each button we'll open the
> exercise
>
> so, if I understand correctly, in order for sited users to be able to
> understand the purpose of each button two each exercise, then a tooltip can
> be sufficient here with mouse hover and with keyboard navigation with the
> tab key. so everyone can understand the purpose of each button.
>
> I do agree that if the buttons would appear with the text that says
> exercise one, 2, 3 etc - in the first place without mouse hover and
> keyboard navigation - this will provide the best user experience. but I
> guess that the client wants' at least for now, to keep the interface as it
> is.
>
>
>