- From: <josh@interaccess.ie>
- Date: Mon, 07 Dec 2015 19:58:28 +0000
- To: "Paul Adam" <paul.adam@deque.com>
- Cc: "Andrew Kirkpatrick" <akirkpat@adobe.com>, "Detlev Fischer" <detlev.fischer@testkreis.de>, "David MacDonald" <david100@sympatico.ca>, "Makoto UEKI" <ueki@infoaxia.com>, WCAG <w3c-wai-gl@w3.org>
- Message-Id: <em2a90420b-6d71-4086-bea3-2d31aee4c9fe@josh_machine>
>Hi Josh, I would definitely be happy to join a call if folks would like >to discuss the issue. Great stuff Paul, I think that would be helpful :-) Thanks Josh > >>As to the first point, I don't understand how a user is supposed to >>click on a non-visible label in the first place? Could you comment >>further on what you are thinking? Do you mean that even if a label >>isn't visible the 'hit area' may still be active as if there was a >>visible label? > >The requirement is that if a label is visible it must have a >relationship association. I’m not talking about controls that don’t >have visible labels. For example this code: <p><input type=“checkbox”> >Please send me a ton of email</p> fails info and relationships because >the is no association from label to control. > >Thanks! > >Paul J. Adam >Accessibility Evangelist >www.deque.com > >>On Dec 5, 2015, at 4:07 AM, josh@interaccess.ie wrote: >> >>Paul, >> >>Just to be clear - the original thread brought up a couple of >>interesting issues. >> >>1) There are no examples of radio button or checkbox without a >>visible label that is programmatically connected to the input so that >>you can click on the label to check the checkbox or radio button. >> >>2) You raised the issue that always having a clickable label is a >>desirable thing. In many cases the larger the better, as it makes >>these controls accessible to many users. All well and good, and no-one >>in the group would say this is a bad thing. >> >>However, to comment on the second item first, and on clickable labels >>in general - it just may not be desirable in *all* cases to mandate >>that developers do this - it may not be a suitable pattern depending >>on the environment, the way a form is put together etc. This is one of >>the main blockers to your original suggestion/issue IMO. So we are >>hesitant in suggesting that the group takes this direction. Yes, we >>have spoken about this at length on the calls and are discussing it >>here and the consensus supports our decision to leave things as they >>are. Again, no one is saying that per say, clickable labels are bad >>but they may just not be appropriate in all situations and our spec >>needs to provide gestalt guidance, and then as you drill down into our >>resources - specific suitable techniques that support a wide range of >>use cases. >> >>As to the first point, I don't understand how a user is supposed to >>click on a non-visible label in the first place? Could you comment >>further on what you are thinking? Do you mean that even if a label >>isn't visible the 'hit area' may still be active as if there was a >>visible label? >> >>Finally, on the first point, as Andrew points out we have existing >>examples of there inputs can be connected to visible label via >>aria-labelledby by and for/id combinations and even when there are no >>labels you can use the well supported @title attribute on <input> >>elements. All good. So no-one is arguing against programmatically >>determined relationships, and we are aware that we need to keep our >>techniques up to date as development and design patterns change (and >>are actively working on this). >> >>So I look forward to more input from you on this, actually it would be >>great if you could attend a call to discuss - as this topic is >>interesting nuanced discussion - and may point the way to wider issues >>that the group need to deal with. >> >>Thanks >> >>Josh >> >> >> >>------ Original Message ------ >>From: "Paul Adam" <paul.adam@deque.com> >>To: "Andrew Kirkpatrick" <akirkpat@adobe.com> >>Cc: "josh@interaccess.ie" <josh@interaccess.ie>; "Detlev Fischer" >><detlev.fischer@testkreis.de>; "David MacDonald" >><david100@sympatico.ca>; "Makoto UEKI" <ueki@infoaxia.com>; "WCAG" >><w3c-wai-gl@w3.org> >>Sent: 05/12/2015 00:45:59 >>Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1 >> >>>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 >>>http://www.deque.com/ >>> >>>>On Dec 4, 2015, at 4:22 PM, Andrew Kirkpatrick <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 >>>>http://twitter.com/awkawk >>>>http://blogs.adobe.com/accessibility >>>> >>>>From: "paul.adam@deque.com" >>>>Date: Friday, December 4, 2015 at 16:55 >>>>To: Andrew Kirkpatrick >>>>Cc: "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 >>>>http://www.deque.com/ >>>> >>>> >>>>On Dec 4, 2015, at 3:43 PM, Andrew Kirkpatrick <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> >>>>>wrote: >>>>> >>>>>Does this make sense to you? Others? >>>> >>>><PastedGraphic-2.png> >>> >> >
Received on Monday, 7 December 2015 19:58:10 UTC