RE: Issue summary 4.1.2 - 587

For 587 [1]:

 

How about adding the word "purpose" to the list of attributes that need to be programmatically determined?

 

SC 4.1.2 would read:

"For all user interface components, the name, role and purpose can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies."

 

Plus the situation(s) in the How to Meet document suggested in Michael's summay.

 

Sofia

 

[1] http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=587

 

________________________________

From: public-wcag-teamc-request@w3.org [mailto:public-wcag-teamc-request@w3.org] On Behalf Of Michael Cooper
Sent: Wednesday, 21 February 2007 5:20 AM
To: List Team C
Subject: Issue summary 4.1.2

 

Here is an issue summary for 4.1.2 issues that were recently assigned to us. Rough proposals are provided here - if discussion accepts them, or yields an alternate consensus, I'll formalize them. Michael

587 <http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=587>  requests that we reinstate a clear requirement to provide labels for form controls, à la former 4.1.3 "The label of each user interface control in the Web content that accepts input from the user can be programatically determined and is explicitly associated with the control." While I agree that this requirement is in fact properly covered under 4.1.2, I also agree with the commenter that it's a bit difficult to understand that. I propose we create an additional "situation" in How to Meet 4.1.2 <http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20/#ensure-compat-rsv>  entitled "The accessible name for user interface components is provided in text external to the component" and move technique H44 under that, as well as the draft advisory technique Positioning labels to maximize predictability of relationships <http://trace.wisc.edu/wcag_wiki/index.php?title=Positioning_labels_to_maximize_predictability_of_relationships> . This would be a partial accept I guess.

618 <http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=618>  asks that we provide an explicit requirement to indicate live regions. Live regions are sections of the page that update automatically, possibly frequently, and not necessarily in direct response to user input, such as the interesting parts of AJAX pages. I believe this is adequately covered by the existing wording, at least as modified by comment 935 <http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=935>  which added states and properties to the requirements. Since ARIA States and Properties <http://www.w3.org/TR/aria-state/#live> is pretty specifically what this is about and describes live regions, this should cover it and we can mark this as an accept.

627 <http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=627>  requests unique titles for live regions unless they can be programatically determined as live, and also says that SC 2.4.1 about skipping repeated blocks is no longer needed. Becky put in some discussion that the need for titles is only a temporary one until the ability of live regions to be programatically determined is widespread. I agree and don't want to muck with it too much. Becky did propose that we create a L3 SC "Blocks of content that become updated should be uniquely titled or its role can be programatically determined." I would prefer to generalize that proposal, and add a L3 SC under 2.4, not under 4.1, entitled "Pages are organized into sub-sections with titles". Becky's sufficient techniques would still map, and we might add one about using headings as appropriate. This would probably be partial-accept then.

912 <http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=912>  asks if the requirement to provide name, role, value etc. applies to every single thing that is rendered in the user interface, including basic things like paragraphs. Discussion from Team A indicates they believed this to be true, but it was referred back from the whole group to consider focusing only on interactive UI components. 

I have some difficulty with this one, because as a single SC it's so broad. I think we would want to say the role, state, properties, and value of all components should be programatically determined and notification of changes provided. A paragraph, for instance, has a role of "paragraph", a value of its text, and maybe some states and properties. We'd certainly want to require notification of changes if its content/value does change, even though that's not the usual place changes to content are expected to happen. 

I had to do some looking around to figure out what might have been meant by the term name, and concluded that it's what I call a "label": a human-understandable label/identifier for a component, referred to as "Accessible Name" in accessibility APIs.  In the case of form controls in HTML, this would literally be the <label> element. But I don't know what the "name" of a paragraph is, unless it's the same as the value. If name is intended to be same as value in such cases, then although that's weird to me, all we need to do is clarify that in How to Meet 4.1.2 <http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20/#ensure-compat-rsv> . But if that's not what we meant, then I think we've got a situation where parts of 4.1.2 apply to all rendered components, and parts apply only to interactive components. 

In that case we might need to split the SC in two: remove "name" from the existing SC, and create a new one that says "For interactive user interface components, the name can be programatically determined." Note that if we did that, we'd be moving back in the direction requested in 587 above, and might just as well reinstate 4.1.3 "The label of each user interface control in the Web content that accepts input from the user can be programmatically determined and is explicitly associated with the control." 

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org> 
Information Page <http://www.w3.org/People/cooper/> 


________________________________

<< ella for Spam Control >> has removed 495 Spam messages and set aside 215 Later for me
You can use it too - and it's FREE!  www.ellaforspam.com