W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2000

[w3c-wai-gl] <none>

From: Andi Snow-Weaver/Austin/IBM <andisnow@us.ibm.com>
Date: Thu, 14 Sep 2000 14:55:44 -0500
To: w3c-wai-gl@w3.org
Message-ID: <OFECB566F1.CAADB814-ON8625695A.006D10FB@raleigh.ibm.com>
I think Jason's rewrite is a step in the right direction. Some specific
comments below....

  At 11:50 AM 9/9/00 +1100, Jason White wrote:
  >           Draft Reformulation of Web Content Accessibility Guidelines
  >
  >Principles and Guidelines
  >
  >   Principle 1: Design content which can be presented visually,
auditorily
  >or tactually, according to the needs and preferences of the user.

  >WL: I believe that we might infer some "and/or"ness by using
  >"visually/audibly/haptically".

AS: I like Jason's rewording of Principle 1. The previous wording "All
information must be available entirely...." made it sound like the web
author has to provide all
the different renderings. The rewording above conveys more of an enabling
spirit which is what I think we want.



  >     Guidelines
  >
  >    1.1 Ensure, by providing textual equivalents to auditory and
graphical
  >           presentations as necessary, that every component of a
document,
  >           web page or multimedia presentation can be rendered as text
in
  >           a standard character set.
  >           Note: a textual equivalent can take a variety of forms. It is
  >           intended to fulfill the same function, and serve the same
  >           purpose as the auditory or visual presentation to which it
  >           provides an alternative. Thus, in writing a textual
equivalent,
  >           it may be appropriate, in some contexts, to provide a short
  >           label or descriptive phrase that can be substituted for the
  >           auditory or graphical material. In other circumstances,
  >           however, a longer explanation, description or exposition may
be
  >           required. A textual equivalentmay consist of structured
content
  >           or metadata, if appropriate.

 >WL: Why do I prefer "text" to "textual"? Also to me everything between
 >"Ensure" and "that every" can be eliminated. And I would like to see the
 >"text equivalent" note elsewhere as a linked-to glossary item.

AS: I feel just the opposite of William. I think the guideline is "Provide
text equivalents to auditory and graphical presentations." The rest of the
guideline is the
rationale for why you need to do this. BTW, I also prefer "text" to
"textual".



  >    1.2 For any time-based multimedia presentation (e.g., a movie or
  >           animation), synchronize the textual equivalents (e.g.,
captions
  >           of the audio track or descriptions of the video track) with
the
  >           presentation.
  >           This guideline applies to multimedia presentations which have
  >           auditory and visual components. Where one component (either
the
  >           audio or video track) contains no significant information, a
  >           synchronized caption or description need not be provided,
  >           though a textual equivalent, for example a description which
  >           can be retrieved by the user in place of the multimedia
  >           presentation, is still required (see guideline 1.1).

  >WL: I hope that there is really some need for this elaborate an
  >explanation. Whoever spoke of "hidden text" was probably thinking of
having
  >a way of leaving the "This guideline applies" paragraph in a place where
  >those who got the idea from the first stating of the guideline from
being
  >faced with explanatory material that, for them, was unnecessary.

AS: Jason asked in another posting if this rewording incorporates my
suggestions for this guideline. I think Jason's rewording covers the ideas
in my suggestion but it
is more obtuse.



  >   Principle 2: Separate content and structure from presentation, and
ensure
  >   that significant structural or semantic distinctions are captured
  > explicitly
  >   in markup, or in a data model.
  >

AS: "...and ensure that...are captured..." is passive. Suggest rewording as
"....and capture significant structural or semantic distinctions explicitly
in markup or in a
data model." I also wonder about the choice of the word "capture". To me,
capture implies that something exists somewhere else and you have somehow
acquired it
for your own use. Would "provide" or "define" convey the right meaning?


  >     Guidelines
  >
  >    2.1 Use markup languages properly and in accordance with
  >           specification.
  >           This guideline requires not only that document instances
comply
  >           with any formal grammar or other test of validity provided
for
  >           in the relevant markup language specification, but also that
  >           structural elements, attributes etc., be used to convey the
  >           meanings which have been assigned to them in the
secification.

 > WL: This is a perfect place for external elucidation. Many people are
  >clueless as to "proper" use of ML. And "grammar" has a specific meaning
  >that conflicts with *most* readers' experience of that term. The "how"
of
  >conveying assigned meanings is also a candidate for elaboration. Many
  >(most?) authors are unaware that italics are other than a prettification
or
  >that H1 is structure - whatever that is.

AS: The first sentence of this guideline is not understandable without the
explanation below. Further, the explanation expands to two requirements. I
still think this
would be simpler, but still accurate, if split into two guidelines:
2.1(a) Use standard markup languages and data models. Do not use
non-standard
extensions. For example, use XHTML that validates to the XHTML
specification.
2.1 (b) Use markup elements to identify the type of content being
presented,
not to control presentation. For example, use the HTML <blockquote> tag to
identify quotations, not to achieve paragraph indentation.



  >    2.3 Use style languages, where available, to control layout and
  >           presentation. Where practicable, provide (or link to)
multiple
  >           style sheets, each supporting a different output device.
  >           Style languages permit a high degree of separation to be
  >           maintained between content and presentation, by allowing the
  >           rules which control the rendering of the content to be
  >           separated from the markup codes that denote its structural
  >           features. Typically, style rules are stored separately from
the
  >           content to which they apply, in resources which are referred
to
  >           in these guidelines as style sheets. To facilitate the
  >           presentation of web content by a range of devices (high and
  >           low-resolution displays, printers, speech devices, etc.), it
is
  >           advisable to associate a variety of style sheets with your
  >           documents.

  >WL: Perhaps I'm overly concerned with "tersification" but it seems that
if
  >this is to be read as an entity that the explanations should be
"hideable".
  >In the legal analogy a constitution doesn't explain in this much detail
  >what "freedom of speech" maps to.

AS: I don't know if we have to "hide" it as William suggests but with the
proper HTML markup, the first sentence can be communicated as the terse
guideline and
the rest as backup explanation. For example, use <h3> or <h4> for the first
sentence. The rest is a followup paragraph. This comment applies to all of
the
guidelines.



  >    2.3 Where presentation is used to communicate distinctions of
meaning
  >           or structure within the content, ensure, if possible, that
  >           these distinctions are captured in equivalent data or markup
  >           which can be obtained and accessed by a user agent.
  >           It should be noted that, in accordance with the above
  >           requirement, the structural markup or metadata, and the
  >           presentation, respectively, need not reside in the same file
or
  >           logical resource. Thus, purely presentational versions of the
  >           content (e.g., in a graphical format or a page description
  >           language) may be provided, so long as there exists a version
  >           which can be retrieved by user agents and contains markup
which
  >           preserves the same structural and semantic distinctions that
  >           are implicit in the "presentational" version. In such
  >           circumstances, techniques of content negotiation may be used
to
  >           select the version which best meets the user's requirements.

  >WL: Note that "the structural markup or metadata, and the presentation,
  >respectively, need not reside in the same file..." is pretty much what
all
  >my above comments signify only instead of
  >"markup...metadata...presentation" it's about
  >"explanation...definition...elaboration".

AS: My earlier comment about passive voice applies here too; i.e.
"...ensure ... is captured..."



  >    2.4 Do not rely on presentation alone (E.G. colour or font changes)
to
  >           express semantic distinctions.
  >           This is a corollary of the preceding guideline. It should not
  >           be interpreted as discouraging the use of colour or other
style
  >           properties to enhance the presentation of content. It can be
  >           satisfied by ensuring that the distinctions conveyed by the
  >           presentation are also reflected in the markup.

AS: A more positive wording of this would eliminate the need for the
disclaimer about discouraging the use of color or other style properties.
Suggest: "2.4 Use
presentation (e.g. color or font changes) to enhance semantic distinctions
but not as the only means to understand them.


  >
  >    2.5 Ensure that the logical structure of the content is preserved in
  >           the markup or data model, together with any additional
semantic
  >           distinctions that facilitate rendering of the content in the
  >           visual, auditory and tactile modalities.
  >           The logical structure of the content needs to be explicitly
  >           preserved for two purposes. First, it allows style rules
(other
  >           than those provided by the author) to be applied, thus
enabling
  >           the content to be presented effectively and appropriately in
  >           different modalities, with a range of output devices.
Secondly,
  >           it provides the basis for structural navigation by the user.
In
  >           order for the content to be rendered in all three modalities,
  >           it is also necessary to capture such distinctions as emphasis
  >           and changes in the natural language or notation in which the
  >           text is written. Note also that if this guideline is
followed,
  >           it will enable more sophisticated analysis of the content by
  >           search engines and other document processing applications.

  >WL: Ditto this one. The problem with putting *some* of the required
  >explanation in the guideline itself is that it's very difficult to
decide
  >which terms need elaboration, e.g. for me "data model" has no "what" to
it.
  >I couldn't tell you what that means.

AS: Another passively worded guideline: "Ensure ...is preserved..." Also, I
have the same problem with the word "preserved" as I do captured.
"Preserved" implies
that it exists already and you are maintaining it. Suggest " Use markup or
a data model to provide logical structure to the content, together with any
additional
semantic distinctions that facilitate rendering of the content visually,
auditorily, or tactually." BTW, I'm not sure what "additional semantic
distinctions" means.



  >   Principle 3: Design for ease of comprehension, browsing and
navigation
  >
  >    Note: this principle is applicable only in circumstances in which
the
  >    web content consists of a document or user interface which is
intended
  >    to be presented to a human reader. A structured data base or
  >    collection of metadata, in circumstances where the user interface is
  >    supplied entirely by the client application, lies outside the scope
of
  >    this principle.

  >WL: I'm not sure that this principle doesn't apply equally to "machine
  >readability", in other words you must also follow the rules for "machine
  >comprehension, etc." if there is such a thing - and I think there is.

  >     Guidelines
  >
  >    3.1 Use a consistent style of presentation in which the structural
and
  >           semantic distinctions expressed in the markup, are associated
  >           with appropriate formatting conventions that enhance the
  >           readability and intelligibility of the content.
  >           The purpose of presentation is to communicate the meaning of
  >           the content, as effectively as possible. Thus, to aid
  >           understanding, it is vital that the structure and semantics
of
  >           the content be readily apparent from the presentational
  >           conventions chosen by the author.

  >WL: As to whether the purpose is to communicate the meaning: this is
where
  >there is some divergence with a huge body of practitioners who think the
  >purpose resides as much (or more) in "fashion" as in what we usually
think
  >of as "content" - if it's "cool" not much else matters.

  >    3.2 Provide clear and consistent navigation mechanisms throughout a
  >           document or web site.
  >           Such navigational mechanisms may include logically organized
  >           groups of hypertext links, an overview or table of contents,
a
  >           site map (with an appropriate textual equivalent; see
guideline
  >           1.1), an index, etc. They should be easy to locate within the
  >           over-all structure of the content and consistent across web
  >           pages or related documents.
  >
  >    3.3 Divide large blocks of information into more manageable groups
  >           where natural and appropriate.
  >           For example, divide user interface controls into logically
  >           organized groups. Use headings, paragraphs, lists etc.,
  >           appropriately to communicate relationships among items,
topics
  >           or ideas.
  >
  >    3.4 If search functions are provided by a web site, enable different
  >           types of searches for different skill levels and preferences.
  >           Examples needed here.
  >
  >    3.5 Place distinguishing information at the beginning of headings,
  >           paragraphs, lists, etc.
  >           Examples? Explanations?
  >
  >    3.6 Use the clearest and simplest language appropriate for a site's
  >           content.
  >           This guideline is intended to facilitate comprehension of the
  >           content by all readers, especially those with cognitive
  >           disabilities. It should not be interpreted as discouraging
the
  >           expression of complex or technical ideas. Authors should
  >           however strive for clarity and simplicity in their writing,
and
  >           review the text with these considerations in mind prior to
  >           publication on the web.
  >
  >    3.7 Supplement text with graphic or auditory presentations where
they
  >           will facilitate comprehension of the content.
  >           Auditory and graphical presentations can do much to improve
the
  >           comprehensibility of a web site, especially to people with
  >           cognitive disabilities or to those who are unfamiliar with
the
  >           language in which the textual content is written. Note that
  >           material provided in auditory or visual forms must also be
  >           available as text (see guideline 1.1).

  >WL: The clear implication of 3.7 is that *this* document's comprehension
  >cannot be improved with these devices. If we *say* it and don't *do* it,
  >then... I submit that the "language in which the textual content is
  >written" in this case makes a great many people think that English must
be
  >our "second language" after whatever we call what we use in these
  >documents. I mean if we are saying that graphic/auditory can improve
  >comprehensibility and then don't use them, something's amiss.

  >    3.8 Use headings, labels and titles appropriately to identify
  >           structurally significant divisions within the content.
  >           For example, use headings to identify important topics or
  >           subdivisions within a document. Label table headers, user
  >           interface controls and other complex structures within the
  >           content. Note that in addition to full, descriptive labels,
it
  >           may also be appropriate, in designing complex structures such
  >           as tables and forms, to provide abbreviated labels which can
be
  >           used when the content is rendered on small displays or via
  >           speech output.

  >WL: This part we actually do in the documents, but the previously
  >alluded-to stuff is totally ignored *except in passing reference*.

  >    3.9 Provide an overview or summary of highly structured materials,
  >           such as tables and groups of user interface controls.
  >           A discussion of which types of structures should be
considered
  >           complex, and the circumstances in which this guideline
applies,
  >           should be added here.
  >
  >    3.10 Define key terms, and provide expansions for abbreviations and
  >           acronyms, which should be identified using appropriate
markup.
  >           Note: only the first occurrence of an abbreviation or acronym
  >           occurring in a document need be expanded. Expansion
  >           dictionaries, for instance in metadata, may be provided as an
  >           alternative to an expansion in the text of a document.

  >WL: I may feel different in the morning but right now this seems at a
  >different level than what's gone before.

  >   Principle 4: Design user interfaces for device independence
  >
  >    Note: this principle applies only where the content provides its own
  >    user interface (for example as a form or programmatic object).

  >WL: I'm again not sure that this is an "only". Device independence is so
  >loaded for me right now that I think that for the first time in the
  >document I'm actually looking for expansion!

  >     Guidelines
  >
  >    4.1 Associate an explicit label with each user interface control.
  >           This guideline applies not only to individual user interface
  >           controls, but also to groups of such controls, which should
  >           likewise be provided with descriptive labels.
  >
  >    4.2 Ensure that user interface controls are grouped logically.
  >           Note that there is an upper limit to the number of user
  >           interface controls that should occur in a single group; see
  >           guideline 3.3.
  >
  >    4.3 Ensure that event handlers are device-independent.
  >           Examples?
  >
  >    4.4Design user interfaces to be compatible with assistive
  >           technologies.
  >           Use standard software conventions to control the behaviour
and
  >           activation of user interface components. Note that
  >           platform-specific guidance may be available for your
operating
  >           system or application environment.

  >WL: There's some message about the beleaguered area of "Universal
Design"
  >available for this section but I may just be dreaming in that regard.

  >   Principle 5: Design content to be compatible with the features and
  >   capabilities of user agents, including those which only support older
  >   technologies or standards.
  >
  >     Guidelines
  >
  >    5.1 Make sure that web sites which take advantage of newer
  >           technologies continue to be usable when such technologies are
  >           turned off or not supported.
  >           Note: it may be desirable to provide multiple versions of the
  >           same content in order to ensure backward compatibility. In
  >           determining the extent to which older technologies should be
  >           supported, content designers should bear in mind that
assistive
  >           hardware and software are often slow to adapt to technical
  >           advances occurring in other areas, such as web-related
  >           standards. Also, for significant groups of users, it may not
be
  >           possible to obtain the latest software or the hardware
required
  >           to operate it.

  >WL: What? No "graceful transformation" - thank you!

  >    5.2 Avoid causing content to blink or flicker otherwise than under
the
  >           control of the user.
  >           Note that although some user agents may permit blinking or
  >           flickering to be suppressed, this is not universally the
case.
  >           Content designers should therefore exercise special care in
  >           avoiding such presentational effects.

  >WL: Someone recently mentioned that whenever one pushes the "next page"
  >control there is technically a "blink". In all I think this gets more
  >attention than it deserves, but so be it. I remember the old "blink"
  >feature in DOS with amused disgust. It was a drag then and it's still a
  >drag but... I've never (personal prejudice?) thought this rose to the
  >"guideline level".

  >           5.2 Avoid causing pages to be refreshed or updated
  >           automatically, otherwise than in response to a user's
request.
  >           Note that this requirement can be satisfied by providing an
  >           option to deactivate automatic updating, or to control the
rate
  >           at which it occurs. User agents may also offer control over
  >           this effect.

  >WL: Good enough.

  >    5.3 Where it is likely that some user agents will not support the
data
  >           format or encoding in which the content is supplied, provide
  >           metadata, a transformation filter, a style sheet or other
  >           mechanism to enable the content to be processed by the user
  >           agent.
  >           This requirement is especially relevant in circumstances
where
  >           a data format or markup language which is not widely
supported,
  >           by default, in user agent software is relied upon. Note also
  >           the discussion of backward compatibility in guideline 5.1.

  >WL: Again the much appreciated absence of "graceful transformation".

  >I think this has been a remarkable and on the whole excellent
realization
  >of the "work item" posed some months ago to provide a more
abstract/general
  >statement of the principles of accessible Web design. My above quibbles
are
  >really rather minor and I think it's close to what I hoped for. As to
what
  >it does for anybody else...

  >--
  >Love.
  >                 ACCESSIBILITY IS RIGHT - NOT PRIVILEGE

Andi
andisnow@us.ibm.com
IBM Accessibility Center - Special Needs Systems
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo
Received on Thursday, 14 September 2000 15:57:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:06 GMT