W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2011

Re: F68 forbids WAI ARIA to replace label element

From: JAMES NURTHEN <james.nurthen@oracle.com>
Date: Thu, 30 Jun 2011 12:01:26 -0700
Message-ID: <4E0CC806.6070802@oracle.com>
To: w3c-wai-gl@w3.org
Sailesh,

On 6/30/2011 11:25 AM, Sailesh Panchang wrote:
> I see no reason why LABEL should not be used when visible text label is present for a standard HTML form control. User agents old and new support it.
James: One reason is to retrofit existing code. Using aria-labelledby is 
far less intrusive into the codebase. Take, for example, legacy products 
which have multiple layers of customization on top of them. Adding 
<LABEL> elements will modify the DOM structure which risks breaking 
something in any number of these layers. Using aria-labelledby does not 
change the DOM structure and is therefore a much less risky change. 
Often ARIA can be used to fix something in the current version whereas 
modifying the DOM structure would require waiting until the code is 
rewritten.
If this is supported by the user agents that the product claims to work 
with why should this be invalid?
>   ARIA-LABELLEDBY could be used as a hack to associate multiple labels with a form control but it should not be used if it is the only label for a control.
James: Why do you think this is a hack? To me, the off-screen label 
technique is a hack. Aria-labelledby pointing to multiple labels is a 
far more elegant solution which has good support in modern browsers.

> Even today there are companies who test with IE 6 ... they do so because there are users still using it. There are users who are using older versions of screen readers and cannot afford to buy the latest JAWS / WinEyes. Right NVDA etc. is free but some PWD / older folks are comfortable with their AT and do not want to switch.
> Just because a technique is there does not mean it should be used every where even if it is not recommended in that situation.
James: Quite true in some cases. However in many cases for internal 
applications the browsers and AT combinations are tightly controlled. A 
failure technique should not prevent those who support those user agents 
from using a technique that can be used successfully.

Regards,
James

> Sailesh
>
> --- On Thu, 6/30/11, Adam Solomon<adam.solomon2@gmail.com>  wrote:
>
>
> From: Adam Solomon<adam.solomon2@gmail.com>
> Subject: RE: F68 forbids WAI ARIA to replace label element
> To: "'Sailesh Panchang'"<spanchang02@yahoo.com>, "'David MacDonald'"<david100@sympatico.ca>
> Cc: "'WCAG'"<w3c-wai-gl@w3.org>
> Date: Thursday, June 30, 2011, 1:31 PM
>
>
> While you are all certainly correct in stressing the fact that it is preferable to implement native code, I think it harsh to fail in a situation where aria-labelledby is utilized. We are always stressing the fact that our techniques are sufficient, but not exclusive of other techniques which might work. De facto, aria will currently work for users in a non-primitive user agent environment (unless I'm mistakenly assuming that it is currently supported by modern browsers). How can we then fail this seemingly sufficient technique? Not elegant, yet it does the job. Yes, a hack, but a successful one. I think it unwise to demand state of the art solutions as a prerequisite - better to keep it advisory in nature.
>
> adam
>
> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Sailesh Panchang
> Sent: Thursday, June 30, 2011 6:48 PM
> To: David MacDonald
> Cc: 'WCAG'
> Subject: RE: F68 forbids WAI ARIA to replace label element
>
> David,
>
>> That's a good point Sailesh
>> The HTML spec says each label element has exactly one corresponding>field...... so in those cases, F68 may be OK, but I don't think F68>allows for the freedom that we find in the WAI ARIA language of "wherever>possible", because F68 applies to all field elements.
> Sailesh: F68 applies only where UI has a visible text label and association is not made or made incorrectly.
> F68 does not apply to all situations... meaning all form controls on a page.
>> There may be times when a standard label element must be used to describe>more than one field... I think this is a situation where it is perhaps it>is a good choice, and where the label element doesn't work too well.>Currently this would fail under F68, no?
> Sailesh: Use of title attribute is allowed as per techniques when no visible label is present or  in a situation like a form within data table. Title attribute or off-screen label can be used  to relate col and row header with  form controls to aid non-visuall  / AT users. This is well supported by browsers and AT. ARIA not necessary here.
> Also HTML allows more than one label to be associated with a form control. But user agents do not support this  reliably though this has been in the specs for years. So aria-labelledby / aria-describedby can be relied upon in these situations. Using ARIA here is a hack for user agents' limitations.
> Again, ARIA is meant to be used for dynamic content using scripting and custom elements- not on standard form controls. (No scripting is required to code standard HTML form controls). One uses ARIA as a hack to counter limitations of user agents but thatis not what ARIA is designed for.
> And that is the real problem: when user agents do not support or do not support a feature uniformly the user suffers. One may come out with elegant specs but one is at mercy of user agents. Already we see some ARIA features are better supported in FF and not in IE or not at all.
> Another example: The title attribute may be used on most HTML elements as per specs but is not uniformly supported by user agents.
> Sailesh Panchang
> www.deque.com
>
>
>
>
>
> David MacDonald
> www.eramp.com
>
> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Sailesh Panchang
> Sent: June-29-11 10:32 PM
> To: WCAG
> Subject: Re: F68 forbids WAI ARIA to replace label element
>
> I think one needs to take a step back and look at the WAI-ARIA  specs. The intro clearly states that one should use standard HTML elements wherever possible because these are natively supported and role, state etc is exposed to browsers and AT. ARIA  is designed to improve the accessibility of dynamic content generated by scripts including custom elements / widgets. It is referred to as a bridging technology by the specs.  HTML works just fine with browsers and AT. Use technology for purpose it is designed and intended and documented.   
> I quote, "It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects".
> So it is indeed a failure if one uses aria-labelledby on a standard HTML INPUT element without using HTML LABEL element. Use ARIA where standard HTML is not designed to work. 
> Refer to 1.3 and 1.4 on
> http://www.w3.org/TR/wai-aria/introduction
>
> Thanks,
> Sailesh Panchang
> www.deque.com
>
> Tel 571-344-1765
> --- On Wed, 6/29/11, Chris Beer<chris@codex.net.au>  wrote:
>
> From: Chris Beer<chris@codex.net.au>
> Subject: Re: F68 forbids WAI ARIA to replace label element
> To: "WCAG"<w3c-wai-gl@w3.org>
> Date: Wednesday, June 29, 2011, 6:12 PM
>
> Agreed. Furthermore it will need an careful genericising rewrite to account not only for the fact that ARIA labelledby can be applied to more than simply form/input controls, but also to make it HTML5 applicable as well as 4.0x and XHTML.
> If no one gets to it, its on my to do list with HTML5 STs, (yeah yeah, I know) but that said, we'll need to look at all the techniques after they move to generalized (X)HTML for ARIA conflicts and impacts.
> Chris Beer (iPhone)
> On 30/06/2011, at 3:24, David MacDonald<david100@sympatico.ca>  wrote:
>
> http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/F68  �As we ramp up for the introduction of WAI ARIA, we may need to fix some of our failures. F68 is a binary check that requires a<label>  element. If not there is a failure of 4.1.2 �I think we�ll need to allow for wai-aria (labelledby), while acknowledging the preference to native code. �David MacDonaldwww.eramp.com
>
>
>
>
>
>
Received on Thursday, 30 June 2011 19:02:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 30 June 2011 19:02:24 GMT