WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Does WCAG require that when you click a label it checks the checkbox or radio button?

for

From: Paul Adam
Date: Nov 20, 2015 9:52AM

The problem is that "Best Practices" are considered "nice to haves" or "usability" recommendations that aren't really required to do so they won't get the extra time or money spent on them when people are under tight deadlines and they may not even get pushed to future releases once the "required" issues are fixed.

Even if you say the "Best Practice" has a "Critical" impact to the user with a disability, if it's not required by WCAG then it may not get done unless people are interested in going "above and beyond" the minimum.

So anytime you make something a best practice only then the Accessibility expert has to fight harder to get the issue fixed when it would be easier to move on to the next hundred a11y problems on the site.

I'd rather not have to make experts expend more time on persuasion tactics asking to please implement these best practices when they really should be requirements.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 20, 2015, at 6:55 AM, Alastair Campbell < <EMAIL REMOVED> > wrote:
>
> Paul Adam wrote:
>
>> "So WCAG is fine if let's say I make all my buttons operable with the
>> Escape key only. No enter or space bar must press escape to activate the
>> buttons. That would not fail keyboard operable? If not, WCAG indeed has
>> many loopholes."
>>
>
> And Bevi wrote:
> "As it is now, WCAG is the antithesis of plain language."
>
> I think this thread has highlighted some contradictory requirements for
> WCAG guidelines:
> - Closing loopholes in the detailed implementation, presumably by being
> more prescriptive about solutions. (Would you agree with that Paul?)
> - Easy to understand.
> - Technology agnostic (a goal of WCAG version 2).
>
> I'm sure there are improvements, but one of three requirements cannot be
> met in the normative text. If it is more prescriptive, it will be less
> tech-agnostic and probably harder to understand. If it is easier to
> understand, there will be more loopholes (I think).
>
> I think the balance comes from what helps in practice. Patrick emphasises
> "we however strongly advise that...", and we do something similar where we
> present the best practice as the default way something should be done.
> Usually we find more basic errors and present the best practice, so the
> 'technical pass' never comes up. Usually if someone knows enough to add a
> label and title they'd know enough to use for/id, the technical-pass
> scenario is quite rare.
>
> Perhaps you come across more scenarios where developers are using automated
> testing or have a very technical view of accessibility and then implement
> to 'conformance' instead of 'accessible'?
>
> If so, I would suggest using persuasion tactics that are less about the
> guidelines, and more about how people use things.
>
> From Matt May's framework: "This is the problem and this is how it affects
> people and you can solve it and if you don't, these are the consequences."
> [1]
>
> The consequences might be non-conformance, but in practice I find the human
> scenario more persuasive, e.g. Someone using a slipper mouse (thanks Julie)
> will struggle to use this, and all you have to do is add a couple of
> attributes.
>
> I'd also like to +1 Mike Moore's suggestion to move it upstream, and get
> the best practices into their specs/pattern libraries, so the argument
> doesn't come up again.
>
> I guess this doesn't answer the question as such, but my response comes
> from an appreciation that closing all the possible loopholes in WCAG,
> making it easier to understand, and make it work across technologies could
> not happen unless all technological advancement is paused for a few years
> whilst we wrangle the guidelines!
>
> -Alastair
>
> 1]
> https://modelviewculture.com/pieces/articulating-and-advocating-for-accessibility
> > > >