RE: F68 forbids WAI ARIA to replace label element

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 17:31:42 UTC