Edit comment LC-969 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-968 Next: LC-503

Comment LC-969: Comment Shortname:; Commenter: Al Gilman <Alfred.S.Gilman@IEEE.org>; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Requiring the explanation to be inline before the control is overly restrictive. If and where the explanation gets rendered is appropriately in the domain of the user's view and verbosity controls. Also "authored unit contains" is too narrow. What matters is that the server delivers the material to the browser.

Proposed Change:

Replace "authored unit contains instructions before the control that describe the behavior" with "the delivered information about the control includes a human-understandable explanation of the behavior that is machine-understandable to be explanatory regarding this control."

Align with requirements in 2.4.4 for links that there be human-understandable stuff bearing required information that is associated with the link or other object by an association that is understandable by the user's automation.; Related issues: (space separated ids); WG Notes: [TEAMB] [SM]"Authored unit" is defined in the glossary as "set of material created as a single body by an author" so this would incorporate "delivered information" or material delivered to the browser from the server. I do not know how the commenter means for this to be applied to 2.4.4 [SM]Discussed at Team B meeting of 01/08/06. Discussed in the 03 August 2006 telecon: Resolution: LC-969 sent back to team b to clarify with the commenter. http://www.w3.org/WAI/GL/2006/08/03-wai-wcag-minutes.html Response from commenter: One level of explanation does not work for all. "Layered help" and "tapered prompts" are examples of technologies that afford more or less explanation under different circumstances. But you can't put the whole, maximal explanation where it will always be read first or you will lose many users. It takes flexible application of multilevel prompting resources. This is needed both for a) people receiving audio display only, and b) people with atypical cognitive processing So, yes; there needs to be something provided that, in the default, textual-order presentation comes before the active widget, which cues the user as to what question they are answering when they act on the widget. But the quick prompt that goes in this leading position is not all the help/hint literature that needs to be available; and it is important to support client-side management of how much gets presented when_and_where and not just to have some minimal nugget in that place. That is why I put "linked to the action opportunity by a relationship of machinable semantics" in there at a higher level of criticality than "before the occurrence of the action opportunity in default (textual -- link to other SC) reading order." Likewise, just because it comes before the action opportunity in default reading order does not mean that the speech system and user will parse this as a prompt governing the action opportunity. That's why use of semantic markup like html:label or voicexml:prompt is part of the deal, not just reading order. Form fields may follow a regular two-dimensional pattern and the explanation come from both row and column headers. This is a situation where one has to follow the logical relationships in the markup to assemble a competent prompt for a given control. The brute-force textual-order reading does not meet the user's needs for orientation to the question at hand in this case. Yet one cannot rule such an arrangement out when there are many answers to be given and they answer such a tabular pattern of questions. And "in the authored unit" is not necessary if the path from the point of action to the prompt or other coaching information is readily followed by the user or their client software. Yes, some minimal prompt should be inline in the authored unit; but the total help/hint system can include stuff that is sucked in from stylesheets and glossaries or even at the distance of a hyperlink. Discussed in the 07 September 2006 telecon: sent back to Team B to reconsider http://www.w3.org/WAI/GL/2006/09/07-wai-wcag-minutes.html Note (to add to response from meeting discussion): The working group specificially wanted the information to be presented before the behavior was encountered and not just be available. 09 Oct 2006, LGR: can we require warning, where including text in the web unit is one sufficient technique, but other techniques, including associating a warning or help button programmatically, would also suffice? Discussed in the 19 October 2006 telecon: Resolution: Accept issue 969 with edits suggested in the survey. http://www.w3.org/WAI/GL/2006/10/19-wai-wcag-minutes.html {not-accept? partial accept?} DONE Change SC 3.2.2 to read: Changing the setting of any user interface component does not automatically cause a change of context, unless the user has been advised of the behavior before using the component. XML source updated 16 January 2007; Resolution: Because of the disorientation that can result from unexpected changes of context, the working group wants the information to be presented before the behavior is encountered. In this situation, just requiring that the information be available in a way that the user agent can provide it if the user asks for it seems too weak. However, we have generalized the language of this success criterion to allow a more flexible set of solutions to how to inform the user.; (Please make sure the resolution is adapted for public consumption)