SC-958, 1218 not quite agree [was: Re: Your comments on WCAG 2.0 Last Call ...]

[see new at end]

  Loretta Guarino Reid wrote:
>----------------------------------------------------------
>Comment 5:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-959)
>
>The non-text content must be implemented such that it can be ignored
>anyway, even if the text equivalent provides full equivalent
>facilitation.  You can't have the video frame-change events capturing
>the AT's attention, etc.  The requirement stated here applies all the
>time, not only for pure decoration.
>
>Proposed Change:
>
>Break out into separate requirement on the "as communicated"
>representation of the content, a.k.a. the "data on the wire."
>
>----------------------------
>Response from Working Group:
>----------------------------
>
>Although this is theoretically accurate, the assistive technology does
>not have settings to ignore all content. The current wording seems to
>best communicate the intent.

Please see the comment on 1.1.1. If you state specifically that the
information-free quality of "what the text should be equivalent to"
can be mechanically recognized by the User Agent from the encoding,
you make this requirement clearer for implementers than "implemented
such that it can be skipped." You are expecting the reader to read
your mind too much with the current language. Yes you mean what you
mean, but you haven't said what you mean. Go back to saying things
like that this fact (the absence of information to equate to) is
expressed by the semantics of the encoding.

>
>----------------------------------------------------------

>----------------------------------------------------------
>Comment 49:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-1218)
>
>the concepts of 'content' and 'presentation' as used here are
>indadequate to explain the needs of users with disabilities even with
>today's technology.
>
>Content v. Presentation
>
>Since this is one of the holy cows of accessibility, and I at least
>feel that this explanation is fundamentally problematical, I think
>this is a fertile area for discussion.
>
>Hypothetical dialog:
>
>Joe:
>
>"rendering" refers to the rendered content, like an "artist's
>rendering" of a planned building. This includes everything, the glyphs
>for making writing evident (perceivable or recognizable) and all the
>CSS-added effects such as font face, size, bold, and color that the
>authors mean to imply by 'presentation.'
>
>Moe:
>
>No, the use of 'rendering' here doesn't mean the as-rendered result,
>it refers to the process of generating that result.
>
>What's wrong with this story?
>
>Preliminaries in terms of terminology
>Both "presentation" and "rendering" are used in plain English to refer
>to either the activity that transforms the content or the resulting
>representation of the content at the User Interface. This ambiguity
>could be resolved by more surgical word-smithing.
>
>more serious
>
>The transformation is entirely determined by the technology choices of
>the author. So if we say 'presentation' is defined by the function of
>this transformation, we are at the whim of the encoding used between
>server and User Agent, and we haven't really isolated a genuine
>rhetorical or semantic distinction.
>
>If we go with "the process that generates the final representation at
>the User Interface" we find that the division between content and
>presentation is determined by the author's choice of file format and
>the implied client-side transformation to the pixel plane or audio out
>channel.
>
>To make this clear, consider that if we define the difference between
>presentation and content by the rendering transform, the
>text-in-images is image content. At least the way PF has been
>approaching things, this is an erroneous model. Because the text in
>the image will be _recognized_ by the general user as being a sample
>of written language, or some sort of code using the writing system of
>a written language, that language or symbology defines a re-purposable
>baseline for adapting the look and feel of the user experience to get
>within the capture regime of the user's sensation, perception, and
>conception.
>
>* most serious:
>
>The distinction is not only not defined by this language in the
>document, it is not definable in any stable and fair way.
>
>Starting at the sensible user interface, we can articulate different
>deconstructions, or "content hypotheses" for what is presented to the
>user. In the case of textual content, that's not a big problem, the
>Unicode character set provides a good level of abstraction that
>
>a) supports client-side personalization of the rendered form of the
>writing, and b) is readily verifiable by the author as "yes, that's
>what I said."
>
>The problem is that a lot of the connotations that are communicated by
>arrangement and other articulable features in the scene presented to
>the user are much less readily articulated or validated by the author.
>And depending on the media-critical skill and habitual vocabulary of
>the knowledge engineer doing the deconstruction, you will get rather
>different information graphs as an articulation of the 'content' of
>the scene.
>
>Contemporary web page design is more poster design that essay
>composition. And it is more interactive than what was supported in
>HTML1 or HTML2. It is the design of a richly decorated and annotated
>button-board -- a collection of clickables which the site and author
>think would appeal to the visitor based on what they know from the
>dialog so far. But that doesn't guarantee a lot of relationship
>between the different fragments mashed together into the page. If the
>page does focus on one coherent story, the page will list higher in
>search results. But that hasn't taken over practice in the field yet.
>
>So the information that is implicit in the [complete, including
>glyphs, etc.] rendered form of the content is a mix of that which is
>readily articulable, and the author will readily recognize as
>articulable, and other information that at first seems ineffable until
>a skilled media critic analyzes it and presents an analysis to the
>author or designer; only then can they recognize that there are
>articulable properties about their stuff. If the analyst is working
>from an information model of properties and relationships that are
>known to survive re-purposing and re-enforce usability in the
>re-purposed rendering, then this process of backing up appearances
>(including sonic appearances if included) with an articulable model
>will in fact enable better access, better usability in the adapted
>experience. And it will also improve usability on the whole in the
>un-adapted user experience, but more weakly. There will be fewer task
>failures for the nominal user if the model underpinnings are not
>provided than for the user who has to depend on an adapted user
>experience, an off-nominal look and feel.
>
>** so where do we go? how to do it right?
>
>My latest attempt at a summary is the presentation I did at the
>Plenary Day on 1 March.
>
>
>
>afford functional and usable adapted views
>         function: orientation --
>           Where am I?
>           What is there?
>           What can I do?
>         function: actuation --
>           from keyboard and from API
>           navigation: move "Where am I?
>         performance: usable --
>           low task failure rate confirms access to action, orientation
>           reasonable task-completion time confirms structure,
>             orientation, navigation
>
>
>
>What gets into our 'content' model, where we ask authors to encode and
>share the answers to selected questions, is a modeling decision driven
>by what we *know* about the functional differences between PWD and
>nominal use of the User Interface.
>
>In other words, we know that the "current context" -- the user's gut
>understanding of the extent of the answer to "where am I?" -- that you
>can reliably keep in foreground memory on the fly in a Text-To-Speech
>readout of a page is a smaller neighborhood than what the visual user
>perceives as the context that they are operating in. This is why there
>has to be information that supports the system prompting the user
>about where they are and where they can go -- navigation assitance --
>*inside* the page, more consistently and at a finer grain than the
>full-vision user needs.
>
>The screen reader user without Braille has more local neighborhoods
>that have to be explainable in terms of "where am I?" and hence more
>levels of "where am I?" answers in the decomposition of the page. Most
>of those levels or groupings are evident in the visual presentation,
>but we have to coach the author in articulating, labeling, and
>encoding the industrial-strength explanation of page structure beyond
>what is enforced by better/worse differences in user experience under
>nominal use conditions.
>
>This effect is readily understood in the area of orienting for "what
>can I do?" This requires good labeling for hyperlinks, form controls,
>and other presented objects that invite user action. This is pretty
>well set out in
>
>Both WCAG1 and WCAG2.
>
>The model of what information to ask for as regards intra-page
>structure is less well resolved in the community (there is less
>endemic agreement on what this information is). We have hopes for the
>"time to reach" metric analysis used in ADesigner (from IBM Japan) as
>a way to communicate when and where they need to improve the markup of
>intrapage structure.
>
>The bottom line is that we should stop trying to generate
>disability-blind specifics at a level as low as the Success Criteria
>without getting more specific about known disability-specific
>adaptations in the look and feel of the web browse experience. Analyze
>the usability drivers in the adapted look-and-feel situations, and
>then harmonize the content model across multiple adaptations of look
>and feel including the null adaptation.
>
>[one principle I missed in the Tech Plenary presentation:]
>-- the first principle, that I did brief, is to:
>
>- enable enough personalization so that the user can achieve a
>functional user experience (function and performance as described at
>Plenary)
>
>-- the second principle that we have talked about with DI but did not
>discuss in the brief pitch at Plenary is to:
>
>- enable the user to achieve this with a little perturbation in the
>look and feel as possible; in other words the equivalence between the
>adapted and unadapted user experiences should be recognizable at as
>low a level as possible. Using adaptations (equivalent facilitation)
>which require a high level of abstraction (task level) to recognize
>their equivalence is both necessary and OK if there is no less
>invasive way to afford a functional user experience. But most of the
>time there's an easier way, and while what is hard should be possible,
>what is easy should indeed be easy.
>
>Proposed Change:
>
>Apply the suggestions under "two interfaces" comments, to wit:
>Articulate requirements a) against the rendered content as it
>contributes directly to the user experience b) against the content as
>communicated between the server and the user agent -- the formal model
>created by the format and exposed by the document object that results
>from the "clean parse (see IBM suggestions there).
>
>Enumerate information requirements that have to be satisfied by the
>formal model in terms of questions that the content object must be
>able to answer in response to a predictable query (programmatically
>determined requirement).  Most of these are context-adapted versions
>of "Where am I?  What is _there_? and What can I do?"
>
>----------------------------
>Response from Working Group:
>----------------------------
>
>As with issue LC-1204, we believe that reorganizing the guidelines in
>this fashion would be much more difficult for people to understand and
>use than our current structure.
>
>----------------------------------------------------------

Being clear about what is a human factors requirement and what is a
computer science requirement will not require a wholesale rewrite. But
it will make the document much clearer for the most important audience
for this document: the people who produce web content.

I understand that nobody ever went broke underestimating the
intelligence of the public. But you are not trying to get rich, and
you don't need to communicate with the public. You are trying to
reform web practice so as to broaden access to Web-borne information
and services. To change web practices you need to communicate with
the people who develop web content. They have the technical
background to benefit from a discussion at a more technical level
than the current draft.

Some incremental and concrete suggestions to this effect have been
included above and in the discussion of the 'perceivable' principle.

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

Al

Received on Wednesday, 27 June 2007 21:32:36 UTC