WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Regarding SC 1.3.1

for

From: glen walker
Date: May 9, 2022 12:07PM

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 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
> > > > >