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/>