Re: Checkpoint 2.3

another way to characterize benefit is to use the another methodology,
requirement and or justification.

----- Original Message -----
From: "Kynn Bartlett" <kynn-edapta@idyllmtn.com>
To: "Jason White" <jasonw@ariel.ucs.unimelb.EDU.AU>; "Web Content
Accessibility Guidelines" <w3c-wai-gl@w3.org>
Sent: Saturday, October 28, 2000 3:32 AM
Subject: Re: Checkpoint 2.3


> At 3:35 PM +1100 10/28/00, Jason White wrote:
> >For this reason, I propose:
> >1. that the discussion of checkpoint 2.3 be amplified with further
> >explanation and examples; and
> >2. that the detailed elaboration of the requirement of logical structure,
> >be reserved to the Techniques.
>
> I agree with both of these. I have some concerns about the specifics
> below.
>
> >Here is a rough proposal along these lines, which is by no means
complete,
> >and about which I have some reservations.
>
> Understood.  Hopefully my nitpicking at this will help us firm this
> up in a pleasing direction
>
> ><dt>2.3 Use markup or a data model to specify the logical structure of
> >content.
> ><dd><p>Note: this allows a diverse variety of presentations, in different
> >modalities and on different devices, to be generated automatically
through
> >the application of style rules. It also facilitates logical navigation of
> >the content by the user, a capability which is particularly important in
> >voice-based interaction or in circumstances where the content is
presented
> >on a low-resolution display or braille device.
>
> Hm...  I am beginning to believe that we should standardize each
> checkpoint with a <benefit>...</benefit> section which would define
> what exactly each checkpoint does.  I very much like the way how you
> have been presenting the usefulness of each, which also helps with
> increased perception of the _need_ for each checkpoint.
>
> This means that for each checkpoint now we would have to insert a
> "reason" clause.  I think that's doable and in fact I think it is
> mandatory.  Should this be a separate discussion about document
> structure and format?
>
> ><p>The details of which structural aspects of the content should be
> >expressed in the markup or data model, are set forth in the Techniques
> >relevant to each technology [link to 2.0 Techniques]. To provide general
> >guidance however, the following is a non-exhaustive list of structural
and
> >semantic features of content which are considered important:
> ><ul>
> ><li>The division of a document into chapters, sections, paragraphs etc;
>
> One point which came out at the DIW is that traditional _written
> document_ sections are not universal and so we should be very careful
> about stating that division into these _specific_ types of sections
> should be avoided.
>
> For example, a typical television show does not have chapters, sections,
> and paragraphs; instead, it has scenes, acts, and so on.  An SVG
> document has no chapters, sections, or paragraphs, nor does a SMIL
> document.
>
> A better idea is:
>
> <li>Divide the document into sections and subsections as appropriate
> for the content type.
>
> ><li>Lists or groups of related items, for example a bulleted list or a
> >group of user interface controls;
>
> This sounds very HTML-specific, almost too much.  Are these meant as
> principles or as examples?  The phrasing before the list indicates
> principles but some read as examples.
>
> ><li>The division of an image into the distinct objects or items depicted
> >in it;
>
> How about:
>
> <li>Group related content using markup; as examples, group related
> textual concepts in bulleted lists, group related user interface
> controls, and group image definitions related to distinct objects.
>
> ><li>Headings, labels, titles etc. These should be associated explicitly
> >with the information to which they apply, especially in complicated
> >structures such as tables.
>
> <li>Explicitly associate labels such as titles, headlines, column
> headings, and textual equivalents with the information to which they
> apply.
>
> (Basically the same as what you said, just rewritten.)
>
> >  <li>Emphasized text (e.g. as indicated by font changes in a visual
> >presentation);
>
> I'm not sure how exactly this should be phrased, or if it's appropriate
> beyond HTML/text.
>
> ><li>Language changes, especially in multilingual texts where two or more
> >langauges occur;
>
> <li>Identify natural language use explicitly and indicate changes in
> the natural language of content.
>
> Is the above a checkpoint already?
>
> ><li>The use of specialized notations, such as mathematics or computer
> >program code;
>
> Also not sure how to quantify this.
>
> ></ul> </dd>
> >(end of proposal)
>
> Hm.  Thorny.
> --
> Kynn Bartlett <kynn@idyllmtn.com>
> http://www.kynn.com/
>

Received on Saturday, 28 October 2000 08:07:29 UTC