Re: CfC: Checkbox and Radio button labels and 1.3.1

Hi Sailesh

That sounds like the current consensus to me...

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Mon, Dec 7, 2015 at 11:40 AM, Sailesh Panchang <
sailesh.panchang@deque.com> wrote:

> H44 states that only a visible label will satisfy SC 3.3.2.
> Understanding doc for SC 3.3.2 explains that a label needs to be PD
> and also lists the benefit of a PD label and clickable area.
> Example #3 (Search Form) of H65 says the search field with a title is
> sufficient for  passing SC 3.3.2 as visually the search button is
> enough of a visual cue ... i.e. the search button doubles up as a
> label for the field.
> Admittedly, Techniques for SC 3.3.2 lists H65 lower down in the list
> and there is a note, "Note: The techniques at the end of the above
> list should be considered "last resort" and only used when the other
> techniques cannot be applied to the page".
> I have interpreted this as, "the WG by consensus deems the title as
> sufficient" for SC 3.3.2.
> On this basis I have accepted this "double duty"  of the search button
> that has helped a tester turn a blind eye to  SC 3.3.2's need for
> visible label / instruction.
> Likewise, I suppose, for practical considerations,  the WG by
> consensus deems that the title is sufficient for conveying
> info-relationships too for SC 1.3.1 in cases like a search form.
> Right?
> Thanks,
> Sailesh Panchang
>
>
> On 12/5/15, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> > When you have a checkbox and a label next to each other and these are
> > visually and semantically coupled  AND your technology offers tried and
> > proven ways to explicitly encode that info relationship I still do not
> see
> > how a failure to do so is not failing SC 1.3.1.
> >
> > AWK: Because WCAG does not state anywhere that this is a requirement.
> It is
> > a great idea and one that we should consider for future versions or
> > extensions, but currently there isn’t anything in WCAG that indicates
> that
> > the presence of an explicit means to do this is required.
> >
> > I think WCAG should rest on checking proper use of determining explicit
> > programmatic relationships where technologies allow these to be formed.
> I.e.
> > according to standards, not according to what you might get away with in
> > terms of AT repair behaviour.
> >
> > AWK: I completely agree.  But that isn’t what it currently says, we have
> the
> > whole “accessibility support” section that was designed to help ensure
> that
> > developers weren’t just following a spec or a standard that wasn’t
> supported
> > by browsers or AT, but with it came the notion that if browsers and AT
> > supported a technique that wasn’t based on the best part (or possibly any
> > part) of a standard that would be ok.
> >
> > AWK
> >
> >
> > Am 05.12.2015 um 01:45 schrieb Paul Adam
> > <paul.adam@deque.com<mailto:paul.adam@deque.com>>:
> >
> > All modern screen readers determine aria-labelledby properly, if not
> let’s
> > file a bug report.
> >
> > aria-labelledby is an explicit association between an element and the id
> of
> > another element whereas a checkbox and a text string inside the same
> > paragraph have no explicit association and I don’t see how they could
> have a
> > relationship just because they’re in the same paragraph. I understand
> that
> > passes for link purpose in context but I didn’t think for info and
> > relationships?
> >
> > Does that mean that form inputs with error messages below the input or
> input
> > format instructions don’t really need to be associated with the error and
> > info strings? They can just be in the same paragraph? Or in close
> > proximity?
> >
> > I did not think that you could claim WCAG conformance based on how good
> of a
> > guesser a particular screen reader is. I know that JAWS does lots of
> > guessing and VoiceOver does some as well whereas NVDA does not.
> >
> > I really hope we’re not promoting that these methods can pass WCAG!
> >
> > Thanks!
> >
> > Paul J. Adam
> > Accessibility Evangelist
> > www.deque.com<http://www.deque.com>
> >
> > On Dec 4, 2015, at 4:22 PM, Andrew Kirkpatrick
> > <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
> >
> > Paul,
> > When using aria-labelledby which screen readers can determine the label
> of
> > the checkbox?  Which ones determine this properly?  Of course, not all do
> > (yet) and the way that you determine is to test it.
> >
> > Does the less-than-ideal code I suggested pass with all user agents?
> > Undoubtedly not.  Does it pass with some?  Yes, and if those are the user
> > agents that I use to base my accessibility support claim then that would
> be
> > how I’d justify the pass.
> >
> > The relationship can be implicit as well as explicit and I believe that
> also
> > includes the case where you have:
> >
> > <input type=“checkbox” title=“Please send me a ton of email”> Please
> send me
> > a ton of email
> >
> > I’ll re-emphasize that there is no doubt that using the explicit
> approaches
> > are better, but the thinking expressed on the call I believe was that
> even
> > though the other approaches are not as good that we can’t state that they
> > fail.
> >
> > Thanks,
> > AWK
> >
> > Andrew Kirkpatrick
> > Group Product Manager, Accessibility
> > Adobe
> >
> > akirkpat@adobe.com<mailto:akirkpat@adobe.com>
> > http://twitter.com/awkawk
> > http://blogs.adobe.com/accessibility
> >
> > From: "paul.adam@deque.com<mailto:paul.adam@deque.com>"
> > Date: Friday, December 4, 2015 at 16:55
> > To: Andrew Kirkpatrick
> > Cc: "josh@interaccess.ie<mailto:josh@interaccess.ie>", Detlev Fischer,
> David
> > MacDonald, Makoto UEKI, WCAG
> > Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
> >
> > Hi Andrew, no this does not make sense to me.
> >
> > <PastedGraphic-2.png>
> >
> > <p><input type=“checkbox”> Please send me a ton of email</p>
> >
> > You’re saying that this passes info and relationships? Because they’re in
> > the same paragraph? It passes in screen readers that can guess the label
> of
> > the checkbox? Which ones guess properly?
> >
> > I’m not saying that WCAG requires the code to be written in a specific
> way,
> > I’m saying that it requires the relationship association and I don’t see
> how
> > a title attribute that duplicates the visible label text or a checkbox
> > inside the same paragraph as the visible label text counts as a
> relationship
> > association.
> >
> > Thank you all for discussing the issue!
> >
> > Paul J. Adam
> > Accessibility Evangelist
> > www.deque.com<http://www.deque.com/>
> >
> >
> > On Dec 4, 2015, at 3:43 PM, Andrew Kirkpatrick
> > <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
> >
> > In the instance of a control that is implicitly associated with a label
> that
> > may even meet 1.3.1 as well as 4.1.2 through the implicit means:
> > <p><input type=“checkbox”> Please send me a ton of email</p>
> >
> > On Dec 4, 2015, at 3:43 PM, Andrew Kirkpatrick
> > <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
> >
> > Does this make sense to you?  Others?
> >
> > <PastedGraphic-2.png>
> >
> >
>
>