LC-1209 agree w/comment Re: Your comments on WCAG 2.0 Last Call ...]

[see new at end]

At 4:27 PM -0700 17 05 2007, Loretta Guarino Reid wrote:
>Comment 40:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-1209)
>
>This document is trying to be universal in two many dimensions at
>once.  What results is impenetrable access-babble.
>
>Proposed Change:
>
>*executive summary*
>
>break down the cases addressed by assertions (guidelines, success
>criteria, and testable assertions in test methods) using
>sub-categories both of content and of presentation.
>
>- content: genre and task
>
>genre: distinguish narratives, grids, mash-ups, etc. (see details for more).
>
>task: navigating passive content, interacting wth atomic controls,
>interacting with composite widgets, following multi-stage tasks,
>checkout from a business process, etc.
>
>- presentation: specialization of the delivery context, describably
>using terms such as in the W3C Delivery Context Overview and the IMS
>Global Learning Consortium Accessibility Specification terms for user
>preferences.
>
>*details*
>
>Testable assertions should come in collections of test conditions that
>have the same content presented in multiple alternate look-and-feel
>adaptations.  Check multiple assertions in each of these renderings.
>Don't try to make things universal across prsentation and testable at
>the same time where that is hard.  Allow yourself the ability to say
>"Must A under condition B and must C under condition D, etc."
>
>This is particularly applicable to the suitability of requred text
>explanations.  It is possible by controlling the exposure of the
>content to the tester through a prescribed dialog to make all
>necessary judgements determinable by a lay person; not an
>accessibility-knowledgeable individual.  We need to get there or go
>home.
>
>The second axis of particularization that has been missed and needs to
>be put to use is the classification of content by task and genre or
>structural texture.  The structure classes:
>
>- bag (collection of random-category items)
>
>- collection (collection of like-category items)
>
>- list (collection of items with an intrinsic semantic order --
>alphabetical does not count)
>
>- narrative (stream of text etc. that tells a coherent tale)
>
>- tree (collection of content with embedded smaller, tighter collections)
>
>- grid (two-dimensional array of content fragments)
>
>- graph (collection of articulable objects linked by significant 
>relationships)
>
>.. these are structure classes that apply to regions in the content,
>and guide the applicability of information requirements -- each of
>these cases has its own proper short list of what needs to be in the
>"what user needs to be able to understand -- through user
>comprehensible media connected by machine-comprehensible
>associations."
>
>Likewise if we break out tasks such as:
>
>- managing navigation within the page
>
>- managing navigation around the site
>
>- interacting with an atomic control
>
>- interacting with a composite control (HTML forms and Windows Combo
>Boxes and Dialogs are examples of the latter).
>
>- money-free On Line Transaction Processing -- getting something to
>happen at or through the server site.
>
>- money-involving OLTP
>
>- security-sensitive OLTP
>
>We will have a much better handle on what the requirements are for 
>the content.
>
>----------------------------
>Response from Working Group:
>----------------------------
>
>Thank you for your comment.  Much of what you propose here would
>require a complete restructuring of the document or changing it into a
>note.  Without a concrete restructuring proposal that shows how this
>would happen without creating other problems, we are not able to
>evaluate this clearly.  If there are specific changes that you could
>suggest particularly around your idea of providing additional
>information on scope or application of success criteria and techniques
>we would be very happy to consider them as we move forward on evolving
>the understanding and techniques documents.  We will also keep these
>comments in mind as we are working on these documents and trying to
>provide such information as we identify it ourselves.

I understand that a complete reflow is not something you can undertake
at this point.

In my disposition responses I have tried to isolate a few concrete steps
that you can take that will make the success criteria both clearer and easier
to implement and enforce.

Specifically:

a) don't use the same words in identifying what needs to be
perceivable and what needs to be understandable.

The thing that has to be perceivable is sensory artifacts that need to be
recognizable.

What needs to be understandable is rather what you would test for the
recall of.

So talk about the medium and the message separately. The information
needs to be understandable, don't use the same terms in the
perceivable or recognizable principle -- make it the presentation or
rendering of the information. This way you can make it clear that you
have moved to a new more concrete level of viewing the interface in
the latter case.

My suggestion is just an example of how to get this across:

<quote
cite="http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0145.html">

Information and operable objects must be presented to the use so as
to be perceivable.

</quote>

This is one small change in the direction of "address two interfaces
separately" that by itself will make the guidelines more approachable
and clearer in what people need to worry about.

b) use the answer to "what can I do?" as the discriminant to break out
different cases of what the text associated to a non-text content fragment
must communicate.  See the response dealing with SC 1.1.1 for details.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0221.html

This allows you to state much clearer requirements for the associated
text than "equivalent except when ..." as in the present draft.  And be
more thorough in your coverage and positive in the expression at the same time.

This is one easily doable way that you can use the 'genre' (as you
have) and 'task' axes to break out cases in a way that makes the
requirements both tighter and easier to understand.

Al

Received on Wednesday, 27 June 2007 21:10:21 UTC