Fw: Sufficiency/checkpoint satisfaction criteria (repost of last week's draft)

----- Original Message -----
From: <mailto:lseeman@globalformats.com>Lisa 
<mailto:lseeman@globalformats.com>Seeman
To: 
<mailto:jasonw@ariel.ucs.unimelb.edu.au>jasonw@ariel.ucs.unimelb.edu<mailto: 
jasonw@ariel.ucs.unimelb.edu.au>.au
Sent: Wednesday, July 11, 2001 10:39 PM
Subject: Re: Sufficiency/checkpoint satisfaction criteria (repost of last 
week's draft)

I would be more explicit about

<quote> Where this is not possible, that is, where the non-text 
presentation cannot be described in words (e.g. the case of artwork, music 
etc., such as Beethoven's fifth symphony as in Gregg's example) a label 
identifying the content will suffice.</quote>

  I would say

Where this is not possible, that is, the  non-text is does not contain any 
semantic information and, the none of the non-text functionality can not be 
made equivalent through  text, (e.g. the case of artwork, music etc., such 
as Beethoven's fifth symphony as in Gregg's example) a label identifying 
the content will suffice.

I think that otherwise the door is too far open for saying "I could not 
make the same functionality so I just labeled it"


what on earth is
<quote> Form controls and other user interface components must be labeled 
with consistent terminology.</quote>

<quote> behaviors that are likely to confuse the first-time user, must be 
clearly documented.</quote>   I think may also be open to abuse
maybe <quote> behaviors that are likely to confuse the first-time user, 
must be clearly explained</quote>
You can document all you like, but if do not explain it to the user, it 
won't help none.


Checkpoint 3.3. Here we go!

<quote> The language used must be no more complex than that which members 
of the intended audience can be reasonably expected to comprehend. In 
identifying the intended audience, consideration should be given to the 
range of educational levels and anticipated background of individuals who 
are likely to be interested in reading the content, to the level of detail 
at which you propose to provide the information.

Terminology which may not be familiar to members of the intended audience, 
and which may create obstacles to understanding, must be clearly explained 
and defined.
</quote>
What? No, I protest, not at all.
this can say, <quote> hey I am writing to my lecture students, so everyone 
is intelligent.</quote>
Not the point
What is not understood by most people, is that learning AND even cognitive 
disabilities (such as semantic pragmatic, can be members of ANY selected 
target audience, meansa or scientist or artists, ANY (Ok not if this page 
is set up just for your grandmother)
And people who are semantic pragmatic, need clear non metaphoric langwige. 
People with dyslexia nee.... oh well you have heard this all before.
You knew I'd say this, didn't you.

<quote>
Illustrations must be designed to portray important concepts or 
relationships employed in the content. </quote>

not all illustrations must be designed to portray important concepts. 
Illustrations must be included that portray important concepts  ....

<quote> Where the markup or data model permits, the abbreviations/acronyms 
and their expansions, and the terms and their definitions, respectively, 
must be explicitly associated with each other. </quote>

do you mean at least once per page?

I need to look though the rest, but that is my start on it
>----- Original Message -----
>From: <mailto:jasonw@ariel.ucs.unimelb.edu.au>Jason White
>To: <mailto:w3c-wai-gl@w3.org>Web Content Guidelines
>Sent: Tuesday, July 10, 2001 2:42 AM
>Subject: Sufficiency/checkpoint satisfaction criteria (repost of last 
>week's draft)
>
>As agreed at the meeting, I am here posting, for the second time, my
>draft of sufficiency/checkpoint satisfaction? criteria for working
>group review. I have changed some of the commentary (and the title) to
>reflect discussion at the meeting.
>
>Please note: at the meeting it was decided to incorporate these,
>albeit perhaps after some editing, into the next internal working
>draft of WCAG 2.0.
>
>Review is requested, particularly in relation to those criteria which
>state, explicitly, that yet to be defined complexity thresholds must
>be met.
>
>
>----------
>
>
>Notes on WCAG 2.0: sufficiency/checkpoint satisfaction? criteria
>
>
>
>The following are just brief notes and comments, marked up in HTML for 
>convenience.
>
>Guideline 1
>
>
>
>Checkpoint 1.1 criteria:
>    * To each auditory, graphical or multimedia presentation there must 
> correspond a text equivalent.
>    * The text equivalent must be associated explicitly with the auditory 
> or graphical presentation to which it corresponds, either in markup, in a 
> data model accessible to the user agent, or via a hypertext link.
>    * The text equivalent must, so far as possible, fulfil the same 
> function and convey the same information, in context, as the non-text 
> presentation. Where this is not possible, that is, where the non-text 
> presentation cannot be described in words (e.g. the case of artwork, 
> music etc., such as Beethoven's fifth symphony as in Gregg's example) a 
> label identifying the content will suffice.
>Checkpoint 1.2. The sufficiency criteria of checkpoint 1.1 apply, subject 
>to the following:
>    * All significant scenes, actions and events in the multimedia 
> presentation must be described.
>    * All significant dialogue and sounds within the multimedia 
> presentation must be captioned.
>    * Descriptions and captions must be synchronized with the events they 
> describe to within a tolerance of (whatever the standard is, whether it 
> be measured in seconds or specified in a more general way).
>Checkpoint 1.3. The criteria specified with respect to checkpoint 1.2 
>apply, but in addition:
>    * So far as possible, the auditory description should be integrated 
> into pauses in the dialogue of multimedia presentations, and should, 
> where possible, avoid obscuring important sounds. (I haven't had much 
> experience with auditory descriptions of multimedia, but I think this is 
> the basic idea).
>Checkpoint 1.4:
>    * The hierarchical structure of the content (see examples already in 
> guidelines) must be unambiguously represented in the markup or data model.
>    * Important non-hierarchical relationships, such as cross-references, 
> or the correspondence between header and data cells in a table, must be 
> represented unambiguously in the markup or data model.
>Checkpoint 1.5:
>    * There must be sufficient markup, or a sufficient data model, to 
> ensure that a logical, linear reading order can be derived from the 
> content. For example, it must be possible automatically to distinguish 
> the columns of a multi-column document and to identify the association 
> between header and data cells in a table.
>    * To the extent that the technology allows (see checkpoint solutions) 
> the markup or data model representing the structure of the content, must 
> be logically separated from the presentation, either in separate data 
> structures or in a style sheet.
>
>
>Guideline 2
>
>
>
>Checkpoint 2.1 (as proposed in current draft). If the web site involves 
>more than x documents, or meets some other complexity threshold yet to be 
>defined, then at least one of the following must be provided:
>    * An index/site map/table of contents
>    * An overview describing the site's scope and purpose, with links to 
> relevant parts of the content.
>    * A search facility.
>Checkpoint 2.2. Where you provide hypertext links, form controls or other 
>interactive content that creates a user interface:
>    * The logical placement of user interface controls must, where 
> possible, be consistent within your web site as a whole.
>    * Form controls and other user interface components must be labeled 
> with consistent terminology.
>    * Where practicable, operating system or application conventions 
> likely to be familiar to the user should be followed.
>    * Any unusual user interface features or behaviours that are likely to 
> confuse the first-time user, must be clearly documented.
>Checkpoint 2.3. Where user agents do not provide control over such 
>mechanisms (see techniques documents for discussion of user agent support):
>    * A form or other user interface must be provided through which the 
> user can elect to deactivate processes or features that cause extreme 
> changes in context.
>    * Such a user interface must be clearly identified on, and accessible 
> from, the home or primary page of a mutli-document web site.
>    * It must be possible to access such a user interface, via the home 
> page and any intermediate pages, without triggering unexpected changes in 
> context.
>Checkpoint 2.4: Analogous to checkpoint 2.3. If we change 2.4 (and 
>possibly 2.3 as well) in accordance with Gregg's proposal, then an 
>absolute minimum (Gregg suggested 10 seconds) time-out period would be 
>specified, and it would be made clear that time-outs are only permitted 
>under exceptional circumstances.
>
>Checkpoint 2.5. Where device-independent event handlers are provided by 
>the API, and the desired user interaction, or its effects, can be 
>described in words (Gregg's qualification drawn from US regulations):
>    * Generic event handlers (e.g., focus events, activations etc.), are 
> to be used in preference to event handlers that require or assume a 
> specific kind of input device, for example a keyboard or pointing device.
>    * The use of device-specific event handlers to customize the user 
> interface, in circumstances where device-independent event handlers are 
> specified as well, does not constitute a violation of this checkpoint.
>
>
>
>Guideline 3
>
>
>
>Checkpoint 3.1:
>    * Each type of structural element occurring in the logical structure 
> of the content (see checkpoint 1.4), for example headings, tables, user 
> interface controls etc., must be presented using the same formatting and 
> layout conventions throughout a document or web site, as the case may be.
>Checkpoint 3.2. With respect to each media type (in the CSS sense, e.g., 
>screen, print, aural) for which you provide style sheets or other control 
>over presentation:
>    * Each type of structural element (see checkpoint 1.4) occurring in 
> the logical structure of the content, must be reflected in the 
> presentation via a specific style or combination of style properties 
> (this terminology does not imply that style sheets must be used, but only 
> that specific and identifiable style properties be associated with each 
> type of structural element).
>    * The place of a structural element within the hierarchy (e.g., the 
> level of a heading within a document), where this information is 
> significant in conveying the over-all structure of the content, must be 
> assigned a distinct style.
>Checkpoint 3.3. Here we go!
>    * The language used must be no more complex than that which members of 
> the intended audience can be reasonably expected to comprehend. In 
> identifying the intended audience, consideration should be given to the 
> range of educational levels and anticipated background of individuals who 
> are likely to be interested in reading the content, to the level of 
> detail at which you propose to provide the information.
>    * Terminology which may not be familiar to members of the intended 
> audience, and which may create obstacles to understanding, must be 
> clearly explained and defined.
>Checkpoint 3.4:
>    * Illustrations must be designed to portray important concepts or 
> relationships employed in the content.
>    * Where appropriate, illustrations should be referred to in the text 
> (e.g., in a caption or as part of the textual exposition), to provide the 
> reader with an appropriate context in which to interpret the illustration.
>Checkpoint 3.5: Where a yet to be defined complexity threshhold is exceeded:
>    * Provide a summary which clearly conveys the main ideas or 
> relationships expressed in the content.
>    * Where the markup or data model allows, the summary should be 
> associated explicitly with the content that it is intended to summarize.
>Checkpoint 3.6:
>    * Abbreviations, acronyms and terms which occur frequently in the 
> content, or which need to be understood in order to comprehend the main 
> concepts or ideas expressed in the content, must be defined.
>    * Where the markup or data model permits, the abbreviations/acronyms 
> and their expansions, and the terms and their definitions, respectively, 
> must be explicitly associated with each other.
>Where the size of a unit according to some ill-defined complexity 
>threshold is too great, it must be divided up. This is really vague.
>
>Guideline 4
>
>
>
>Checkpoint 4.1. In comparing alternative formats, API's, protocols etc., 
>with which to implement content, preference must be given to those which 
>provide features that directly support the requirements set forth in these 
>guidelines. To satisfy this checkpoint, technologies must be chosen which, 
>of the technologies under consideration, best support as many of the 
>following as are applicable:
>    * Text equivalents (including, where applicable, synchronization 
> and/or auditory descriptions);
>    * The provision of logical structure in markup or in a data model;
>    * The logical separation of structure and content from presentation;
>    * Device-independent event handlers.
>Checkpoint 4.2: Refer to the conformance requirements of the specification 
>in question. In particular, if there is a formal grammar (e.g., a document 
>type definition or schema) or other definition of conformance, this must 
>be satisfied.
>
>Checkpoint 4.3: See the checkpoint solutions and techniques for discussion 
>of specific cases. In general:
>    * API's, user interface components etc., must be chosen which are 
> known to be compatible with assistive technologies, in accordance with 
> any usage conventions (e.g., of the operating system or application 
> framework) which are documented as being required in order to provide 
> such compatibility.
>Checkpoint 4.4. There is little that I can add to the checkpoint itself, 
>which prescribes exactly what is needed. Examples will help to clarify 
>what is required.
>    * It must be possible for a conforming user agent that supports the 
> format(s) in which the content is written, to render it, or create the 
> necessary user interaction (e.g., a form) when the features under 
> consideration, either individually or in combination, are turned off or 
> not supported.
>
>
>
>Notes
>
>
>    * An additional checkpoint should be defined under guideline 1 to 
> address semantic elements of content which are not structural, but which 
> need to be provided in markup or a data model. Natural language changes 
> and emphasis are the two examples which have been discussed at recent 
> meetings.
>    * The order of checkpoints 3.1 and 3.2 should be reversed.
>    * I have used the words must and should with care: the former refers 
> to a criterion which, in the author's judgment, must be met in order to 
> satisfy a WCAG 2.0 checkpoint; the latter to additional functionality 
> that may, but need not, be provided. In many checkpoints however, there 
> are only requirements; and thus we may need to consider whether to divide 
> the criteria into checkpoint conformance requirements, stricto sensu and 
> non-normative (sufficiency) examples--conditions that may be satisfied.

Received on Wednesday, 11 July 2001 15:42:35 UTC