E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Schafer, Carmen
Date: Mon, Mar 25 2024 11:36AM
Subject: SC 3.3.2: Labels or Instructions (Level A) violation?
No previous message | Next message →

Hi everyone,
We have a third-party web app that has a drag-and-drop feature where you can change the order of sections (or layout of the dashboard contents). On the webpage it says, "Drag and drop the handle (=3D) to change the order of the sections on your home screen." You can change the order of the sections using the mouse and keyboard. The section elements are keyboard-focusable (Most Popular, Find Academic Resources, Get Involved, Take Care of Your Health, Task Centers, My Recently Used, Student Essentials, Canvas Courses). You can Tab to each section and use the Up and Down arrow keys to move the selected section up one or down one level to create the order you want them to appear on the dashboard. Since there are no instructions on how to use the drag and drop on the webpage using a keyboard, is this considered a violation of Success Criteria 3.3.2: Labels or Instructions (Level A)?<https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html> I did not find where the guideline explicitly mentions requiring keyboard instructions, but they do emphasize ensuring that all functionality of a website can be operated via a keyboard interface. Thanks for any help.
[Main Page Layout heading. Reset Layout button. Done editing button. Text instructions: Drag and drop the handle (=3D) to change the order of the sections on your home screen. Keyboard focusable elements: Most popular, find academic resources, get involved, take care of your health, task centers, my recently used, student essentials, canvas courses.]
Best,
Carmen

From: Steve Green
Date: Mon, Mar 25 2024 12:05PM
Subject: Re: SC 3.3.2: Labels or Instructions (Level A) violation?
← Previous message | Next message →

The Understanding page states that SC 3.3.2 only applies to data entry. Although drag and drop functionality can be associated with data entry, it isn't in your case so the lack of instructions is not a non-conformance of that success criterion.

I have never understood why there isn't a similar requirement for functionality that is not associated with data entry. Can anyone shed any light on that?

Steve Green
Managing Director
Test Partners Ltd

From: Patrick H. Lauke
Date: Mon, Mar 25 2024 12:07PM
Subject: Re: SC 3.3.2: Labels or Instructions (Level A) violation?
← Previous message | Next message →

3.3.2 Labels or Instructions is aimed at controls that "require user
input" - e.g. text inputs and similar. It's not a generic "any type of
control that could do with instructions".

So technically, I'd say this doesn't fail. Though of course it makes for
bad usability if the keyboard controls aren't explained anywhere.

P
--
Patrick H. Lauke

* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke

From: Schafer, Carmen
Date: Mon, Mar 25 2024 12:29PM
Subject: Re: SC 3.3.2: Labels or Instructions (Level A) violation?
← Previous message | Next message →

Thank you, both!

From: Brooks Newton
Date: Tue, Apr 02 2024 2:32PM
Subject: Re: SC 3.3.2: Labels or Instructions (Level A) violation?
← Previous message | Next message →

In my opinion, limiting the interpretation of SC 3.3.2 Labels or
Instructions to a narrowly scoped rule for text inputs discriminates
against a broad range of people with disabilities. I know I'm not the only
professional in this field who has run into scenarios where users of screen
reader software get better instructions for operating page content, forms,
and other types of interactive functionality than users with disabilities
who don't use AT. And, I don't think screen reader users will necessarily
get a clear representation of how a complex custom interface works by
simply providing programmatic indications at the component level without
adequately explaining how all of the integral parts of the interface work
together (also known as "instructions.")

The text of each Success Criterion (SC) in WCAG is normative. This
normative text should be able to stand on its own over time. Text in the
Understanding documents that accompany each SC is informative, and that
text will likely be edited over and over to suit the needs of changing
technologies, implementations, design sensibilities and even the politics
of the day.

For SC 3.3.2 Labels or Instructions, the normative SC text is as follows:
"Labels or instructions are provided when content requires user input."

I take a broader perspective on "user input" as do some in this forum
project. I think of "user input" as whenever users are required to
interact with the page/screen.

There are a lot of interactive page features designed by folks of all
abilities, where adequate onscreen instructions or labels are left out
because the designer simply doesn't recognize that some users with
disabilities (memory difficulties and other cognitive deficits, low-vision,
etc.) aren't going to be able to access content without some onscreen
help. Notice I didn't say these users with disabilities aren't going to
have an optimal user experience. What I said is that some users with
disabilities "aren't going to be able to access the content" due to the
omission of onscreen instructions and labels that are critical to
understanding page interactivity.

When a person compartmentalizes a Success Criterion by interpreting it with
the narrowest possible meaning, they may be favoring some disability groups
over others. I don't think that works well for the WCAG standard or the
broad community it hopes to serve.

Here's an example: If you have to have a full view of the screen to know
how all of the component parts of a custom interface work together, then
that application will likely need onscreen instructions to provide access,
not just enhanced usability, to people with certain disabilities.
Beneficiaries who may need onscreen instructions in this scenario include
low-vision users who may not get the benefit of understanding cause and
effect of the interface's component parts when zoomed in tight to a single
control. The interface's structure, logical dependencies, even component
roles may be ambiguous to users with disabilities if onscreen instructions
and labels available to all are not included in the design.

The page designer might have thought that instructions for operating the
interface were unnecessary and maybe even junked up the screen that added
to the page's "cognitive load." Since when did well-written, succinct
instructions make operating a web page more difficult? Plus, designers can
use progressive disclosure techniques to lighten the cognitive load for
users who don't need onscreen instructions.

Burying labels and instructions in the page code hoping that users with all
disabilities impacted will have the appropriate assistive technology (AT)
to uncover critical interface information is, in my opinion, a failure to
conform to S.C. 3.3.2 Labels or Instructions.

I'm not OK with just letting this narrow interpretation of WCAG SC 3.3.2
fly by on the discussion thread without commenting. Of course, this is my
opinion, and I may be wrong. But I don't think so, and I'm willing to hash
this out with anyone who wants to discuss.

Brooks Newton


On Mon, Mar 25, 2024 at 1:07 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> 3.3.2 Labels or Instructions is aimed at controls that "require user
> input" - e.g. text inputs and similar. It's not a generic "any type of
> control that could do with instructions".
>
> So technically, I'd say this doesn't fail. Though of course it makes for
> bad usability if the keyboard controls aren't explained anywhere.
>
> P
> --
> Patrick H. Lauke
>
> * https://www.splintered.co.uk/
> * https://github.com/patrickhlauke
> * https://flickr.com/photos/redux/
> * https://mastodon.social/@patrick_h_lauke
>
> > > > >

From: Dean.Vasile
Date: Tue, Apr 02 2024 4:55PM
Subject: Re: SC 3.3.2: Labels or Instructions (Level A) violation?
← Previous message | Next message →

Brooks,
I agree with you wholeheartedly.
And I really think that this is a well written argument.
Have you posted this on the W3C website?
It may or may not get some action from them.
However, I think this is an important dialogue to keep moving forward.
As a screen reader user I come into many situations where they are not necessarily form elements, that I'm dealing with, but I could definitely use some more instruction to understand what I am doing. and trying to get accomplished.
Thank you for bringing this up Because again, I think it's a great argument
Dean Vasile


617-799-1162

> On Apr 2, 2024, at 4:32 PM, Brooks Newton < = EMAIL ADDRESS REMOVED = > wrote:
>
> In my opinion, limiting the interpretation of SC 3.3.2 Labels or
> Instructions to a narrowly scoped rule for text inputs discriminates
> against a broad range of people with disabilities. I know I'm not the only
> professional in this field who has run into scenarios where users of screen
> reader software get better instructions for operating page content, forms,
> and other types of interactive functionality than users with disabilities
> who don't use AT. And, I don't think screen reader users will necessarily
> get a clear representation of how a complex custom interface works by
> simply providing programmatic indications at the component level without
> adequately explaining how all of the integral parts of the interface work
> together (also known as "instructions.")
>
> The text of each Success Criterion (SC) in WCAG is normative. This
> normative text should be able to stand on its own over time. Text in the
> Understanding documents that accompany each SC is informative, and that
> text will likely be edited over and over to suit the needs of changing
> technologies, implementations, design sensibilities and even the politics
> of the day.
>
> For SC 3.3.2 Labels or Instructions, the normative SC text is as follows:
> "Labels or instructions are provided when content requires user input."
>
> I take a broader perspective on "user input" as do some in this forum
> project. I think of "user input" as whenever users are required to
> interact with the page/screen.
>
> There are a lot of interactive page features designed by folks of all
> abilities, where adequate onscreen instructions or labels are left out
> because the designer simply doesn't recognize that some users with
> disabilities (memory difficulties and other cognitive deficits, low-vision,
> etc.) aren't going to be able to access content without some onscreen
> help. Notice I didn't say these users with disabilities aren't going to
> have an optimal user experience. What I said is that some users with
> disabilities "aren't going to be able to access the content" due to the
> omission of onscreen instructions and labels that are critical to
> understanding page interactivity.
>
> When a person compartmentalizes a Success Criterion by interpreting it with
> the narrowest possible meaning, they may be favoring some disability groups
> over others. I don't think that works well for the WCAG standard or the
> broad community it hopes to serve.
>
> Here's an example: If you have to have a full view of the screen to know
> how all of the component parts of a custom interface work together, then
> that application will likely need onscreen instructions to provide access,
> not just enhanced usability, to people with certain disabilities.
> Beneficiaries who may need onscreen instructions in this scenario include
> low-vision users who may not get the benefit of understanding cause and
> effect of the interface's component parts when zoomed in tight to a single
> control. The interface's structure, logical dependencies, even component
> roles may be ambiguous to users with disabilities if onscreen instructions
> and labels available to all are not included in the design.
>
> The page designer might have thought that instructions for operating the
> interface were unnecessary and maybe even junked up the screen that added
> to the page's "cognitive load." Since when did well-written, succinct
> instructions make operating a web page more difficult? Plus, designers can
> use progressive disclosure techniques to lighten the cognitive load for
> users who don't need onscreen instructions.
>
> Burying labels and instructions in the page code hoping that users with all
> disabilities impacted will have the appropriate assistive technology (AT)
> to uncover critical interface information is, in my opinion, a failure to
> conform to S.C. 3.3.2 Labels or Instructions.
>
> I'm not OK with just letting this narrow interpretation of WCAG SC 3.3.2
> fly by on the discussion thread without commenting. Of course, this is my
> opinion, and I may be wrong. But I don't think so, and I'm willing to hash
> this out with anyone who wants to discuss.
>
> Brooks Newton
>
>
>> On Mon, Mar 25, 2024 at 1:07 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> 3.3.2 Labels or Instructions is aimed at controls that "require user
>> input" - e.g. text inputs and similar. It's not a generic "any type of
>> control that could do with instructions".
>>
>> So technically, I'd say this doesn't fail. Though of course it makes for
>> bad usability if the keyboard controls aren't explained anywhere.
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> * https://www.splintered.co.uk/
>> * https://github.com/patrickhlauke
>> * https://flickr.com/photos/redux/
>> * https://mastodon.social/@patrick_h_lauke
>>
>> >> >> >> >>
> > > >

From: Brooks Newton
Date: Wed, Apr 03 2024 9:50AM
Subject: Re: SC 3.3.2: Labels or Instructions (Level A) violation?
← Previous message | No next message

Hi Dean,

Thanks for your email and for letting me know you agree with my stance
advocating for a more expansive interpretation of the requirements for SC
3.3.2 Labels or Instructions. Gathering support from your personal
perspective means a lot to me. I've shared my position on this issue over
and over with the W3C, both as a member of the Accessibility Guidelines
Working Group (2017-2020 - WCAG 2.1 and WCAG 2.2 involvement) and as a
participant on this and other online discussion forums. There are plenty
of W3C folks on this thread who have every opportunity to engage me and
(more importantly) the larger disability community on this topic. Feel
free to crosspost my argument to any appropriate forums.

Thank You,

Brooks Newton

On Tue, Apr 2, 2024 at 5:56 PM = EMAIL ADDRESS REMOVED = <
= EMAIL ADDRESS REMOVED = > wrote:

> Brooks,
> I agree with you wholeheartedly.
> And I really think that this is a well written argument.
> Have you posted this on the W3C website?
> It may or may not get some action from them.
> However, I think this is an important dialogue to keep moving forward.
> As a screen reader user I come into many situations where they are not
> necessarily form elements, that I'm dealing with, but I could definitely
> use some more instruction to understand what I am doing. and trying to
> get accomplished.
> Thank you for bringing this up Because again, I think it's a great
> argument
> Dean Vasile
>
>
> 617-799-1162
>
> > On Apr 2, 2024, at 4:32 PM, Brooks Newton < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > In my opinion, limiting the interpretation of SC 3.3.2 Labels or
> > Instructions to a narrowly scoped rule for text inputs discriminates
> > against a broad range of people with disabilities. I know I'm not the
> only
> > professional in this field who has run into scenarios where users of
> screen
> > reader software get better instructions for operating page content,
> forms,
> > and other types of interactive functionality than users with disabilities
> > who don't use AT. And, I don't think screen reader users will necessarily
> > get a clear representation of how a complex custom interface works by
> > simply providing programmatic indications at the component level without
> > adequately explaining how all of the integral parts of the interface work
> > together (also known as "instructions.")
> >
> > The text of each Success Criterion (SC) in WCAG is normative. This
> > normative text should be able to stand on its own over time. Text in the
> > Understanding documents that accompany each SC is informative, and that
> > text will likely be edited over and over to suit the needs of changing
> > technologies, implementations, design sensibilities and even the politics
> > of the day.
> >
> > For SC 3.3.2 Labels or Instructions, the normative SC text is as follows:
> > "Labels or instructions are provided when content requires user input."
> >
> > I take a broader perspective on "user input" as do some in this forum
> > project. I think of "user input" as whenever users are required to
> > interact with the page/screen.
> >
> > There are a lot of interactive page features designed by folks of all
> > abilities, where adequate onscreen instructions or labels are left out
> > because the designer simply doesn't recognize that some users with
> > disabilities (memory difficulties and other cognitive deficits,
> low-vision,
> > etc.) aren't going to be able to access content without some onscreen
> > help. Notice I didn't say these users with disabilities aren't going to
> > have an optimal user experience. What I said is that some users with
> > disabilities "aren't going to be able to access the content" due to the
> > omission of onscreen instructions and labels that are critical to
> > understanding page interactivity.
> >
> > When a person compartmentalizes a Success Criterion by interpreting it
> with
> > the narrowest possible meaning, they may be favoring some disability
> groups
> > over others. I don't think that works well for the WCAG standard or the
> > broad community it hopes to serve.
> >
> > Here's an example: If you have to have a full view of the screen to know
> > how all of the component parts of a custom interface work together, then
> > that application will likely need onscreen instructions to provide
> access,
> > not just enhanced usability, to people with certain disabilities.
> > Beneficiaries who may need onscreen instructions in this scenario include
> > low-vision users who may not get the benefit of understanding cause and
> > effect of the interface's component parts when zoomed in tight to a
> single
> > control. The interface's structure, logical dependencies, even component
> > roles may be ambiguous to users with disabilities if onscreen
> instructions
> > and labels available to all are not included in the design.
> >
> > The page designer might have thought that instructions for operating the
> > interface were unnecessary and maybe even junked up the screen that added
> > to the page's "cognitive load." Since when did well-written, succinct
> > instructions make operating a web page more difficult? Plus, designers
> can
> > use progressive disclosure techniques to lighten the cognitive load for
> > users who don't need onscreen instructions.
> >
> > Burying labels and instructions in the page code hoping that users with
> all
> > disabilities impacted will have the appropriate assistive technology (AT)
> > to uncover critical interface information is, in my opinion, a failure to
> > conform to S.C. 3.3.2 Labels or Instructions.
> >
> > I'm not OK with just letting this narrow interpretation of WCAG SC 3.3.2
> > fly by on the discussion thread without commenting. Of course, this is
> my
> > opinion, and I may be wrong. But I don't think so, and I'm willing to
> hash
> > this out with anyone who wants to discuss.
> >
> > Brooks Newton
> >
> >
> >> On Mon, Mar 25, 2024 at 1:07 PM Patrick H. Lauke <
> = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >> 3.3.2 Labels or Instructions is aimed at controls that "require user
> >> input" - e.g. text inputs and similar. It's not a generic "any type of
> >> control that could do with instructions".
> >>
> >> So technically, I'd say this doesn't fail. Though of course it makes for
> >> bad usability if the keyboard controls aren't explained anywhere.
> >>
> >> P
> >> --
> >> Patrick H. Lauke
> >>
> >> * https://www.splintered.co.uk/
> >> * https://github.com/patrickhlauke
> >> * https://flickr.com/photos/redux/
> >> * https://mastodon.social/@patrick_h_lauke
> >>
> >> > >> > >> > >> > >>
> > > > > > > > > > > > >