Re: CfC: Checkbox and Radio button labels and 1.3.1

PS

Jon, your examples ring true for me, as to the current consensus.

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 1:43 PM, David MacDonald <david100@sympatico.ca>
wrote:

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