RE: WCAG 1.0 Checkpoint 10.2 Action item

Certainly if the definition of "programmatically defined" was modified
then these SC would fit better.  However I still don't believe that the
revised definition covers it.  I believe the expected definition of
"programmatically determined" will always be essentially "machine
readable" and "person readable" is something else entirely.

Cheers,
Gian


-----Original Message-----
From: Ben Caldwell [mailto:caldwell@trace.wisc.edu] 
Sent: Wednesday, 31 August 2005 5:27 AM
To: w3c-wai-gl@w3.org
Cc: Gian Sampson-Wild
Subject: Re: WCAG 1.0 Checkpoint 10.2 Action item

Gian Sampson-Wild wrote:
...
> 
> I believe we can map this to GL 2.4 (Provide mechanisms to help users 
> find content, orient themselves within it, and navigate through it.) 
> Level 2 SC: More than one way is available to locate content within a 
> set of /delivery units/ 
> <http://www.w3.org/TR/WCAG20/#deliveryunitdef#deliveryunitdef>.  For
my 
> reasoning as to why it does not map anywhere else, see below.

I'm not sure I see how WCAG 1.0 checkpoint 10.2 (Until user agents 
support explicit associations between labels and form controls, for all 
form controls with implicitly associated labels, ensure that the label 
is properly positioned.) maps to this SC. Guideline 2.4 L2 SC1 is about 
sets of delivery units and I'm not sure I follow how having more than 
one way to locate content relates to form controls and their labels.

I think the best short-term mapping (i.e. applicable to our current 
draft) for this is to say that it is covered in advisory information. 
Because this is an "Until User Agents" checkpoint, we would likely list 
this in the guide doc as an optional strategy  and write a repair 
technique in that describes the issue in greater detail.

However, while using the label element with the "for" and "id" 
attributes solves the problem for current screenreaders, there are still

some situations where not having the label in close proximity to it's 
form control would still be an issue (ex. not having labels nearby would

be confusing for screen magnfication users as well as a problem for 
those with cognitive limitations).

I wonder if our current definition of "programmatically determined" is 
confusing things here.

"programmatically determined" is currently defined as follows:

programmatically determined means that the specific value can be 
determined in a standard, machine or software readable form.

We've been using the term in discussions as though it means that 
assistive technology has access to the programmatically determined 
information, but that is not made explicit in the definition as written.

What if we revised the definition as follows?

<begin proposed>
programmatically determined means that the specific value can be 
determined in a standard and supported, machine or software readable
form.
</proposed>

Then, we could map checkpoint 10.2 to guideline 4.2 L1 SC4 (The label of

each user interface control that accepts input from the user can be 
programmatically determined and is explicitly associated with the 
control.) and guideline 1.3, L3 SC1 (When content is arranged in a 
sequence that affects its meaning, that sequence can be determined 
programmatically.) and it would cover the following:

  - use of layout tables where one cell includes a group of labels and 
another a series of input fields in cases where the table information 
has been linearized
  - use of CSS to position a label or group of labels near their 
controls  such that the reading order no longer makes sense when CSS is 
turned off or alternate styles are applied

Thoughts???

-Ben

--
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>

Received on Wednesday, 31 August 2005 03:56:37 UTC