W3C home > Mailing lists > Public > public-wcag-teamc@w3.org > February 2007

Re: Issue summary 4.1.2 - 587

From: Michael Cooper <cooper@w3.org>
Date: Mon, 26 Feb 2007 18:49:02 -0500
Message-ID: <45E371EE.6070207@w3.org>
To: Sofia Celic <Sofia.Celic@visionaustralia.org>
Cc: List Team C <public-wcag-teamc@w3.org>
Hi Sofia - Team C didn't take your proposal on 587, because of how 
"purpose" fit in with the other attributes which are from a known list. 
It was unclear if your suggestion was an alternate approach to this 
issue, or if you objected to close 587 as I was suggesting. We decided 
to mark it as ready for survey, but if you object, not take it to survey 
and cycle it back for discussion next week. If you can live with the 
proposal as it is (now fleshed out in the issue entry) then we'll go 
ahead with the survey. Let me know -


Sofia Celic wrote:
> 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 
> <http://www.ellaforspam.com>


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/>
Received on Tuesday, 27 February 2007 00:50:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:35 UTC