- From: Gian Sampson-Wild <giansw@ifocus.com.au>
- Date: Wed, 31 Aug 2005 13:55:39 +1000
- To: "Ben Caldwell" <caldwell@trace.wisc.edu>, <w3c-wai-gl@w3.org>
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