WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Brooks Newton
Date: Apr 3, 2024 9:50AM

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