WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: SC 3.3.2: Labels or Instructions (Level A) violation?

for

From: Dean.Vasile
Date: Apr 2, 2024 4:55PM

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