Re: Comments on Web Content Accessibility Guidelines

Patrick Schmitz' comments on the Guidelines document, annotated first by
Ian Jacobs, with my further comments interspersed - look for PS: IJ: and
CMN: (some of Patrick's points, along with Ian's response, have been
snipped)

  Patrick Schmitz wrote:
  > 
  > It is great to have a document like this, and I think that it has great
  > potential to improve web content with respect to accessibility.  As a guide
  > to toolmakers, it should help as well.  I do think that it strikes a tone
  > that design is not as important as accessibility, which may not go over too
  > well with some authors.
IJ:  
  We attempt to emphasize that good design produces accessible documents,
  thus I don't think there's a conflict. However, if the tone leans
  towards accessibility, I think that's to be expected from this document.
  Nonetheless, I will review the language of the introduction.

CMN:
It would seem foolish in a document about how to produce accessible
content to do anything other than stress accessibility as more important
than design.

PS:   
[snip]  
  >In addition, I think it would help if there was a more
  > general discussion of strategies to be employed, such as the use of
  > stylesheets to transform documents.  
  
  I'm not sure what you mean by strategies. Could you be more specific?
  The prose at the beginning of section A discusses general
  principles (these are not exactly strategies, admittedly) and the
  checkpoints themselves are strategies for addressing the
  guidelines. Perhaps a more implementation-oriented discussion
  of strategies belongs in the techniques document. Any suggestions
  are appreciated.

CMN:
It may be that the techniques document should include a 'general
strategies' section. The general principles are made clear in teh
Guidelines document, but as Ian says implementation details belong in teh
techniques document. I agree with Patrick that a brief discussion of
general strategies, particularly those which will cover multiple
checkpoints, would be useful.

PS:
[snip]   
  > I think it would be worth mentioning up front that in some cases the best
  > approach will be to author an alternate page.  Various guidelines mention
  > this, but especially as relates to media-rich content, I think it worthwhile
  > to acknowledge that effective design for the different audiences often
  > requires alternate documents.
IJ:  
  The Working Group has strong reservations about making
  such a statement because of the difficulties raised by
  alternative pages (see the Note after the checkpoints
  in Guideline 13). Furthermore, the Working Group feels
  that the checkpoint about alternative pages (13.5) should
  be listed *after* the others of that guideline despite
  the fact that it is a priority 1 checkpoint in order to
  dissuade authors from using this solution as a first
  option. Authors should attempt to make their pages
  accessible, not separate but equal.
   
CMN:
Often media-rich documents can be written in a manner which includes,
within the one document, multiple presentations of information or
function. This is the case with the incorporation of Multimedia via OBJECT
in HTML, and with the use of SMIL, to name two examples. In other cases,
such as Mathematics, and hopefully Vector Graphics, languages are used
which encode the information in a way which makes it readily amenable to
presentation through a variety of media. As a general principle it seems
better to me that we support such standards rather than a number of
individual, 'separate but equal' pages. When there is a widely
implemented means of linking the various alternatives so they can be
addressed as a single resource it may be possible to achieve more
efficient transfer, but the primary concern for accessibility is keeping
equivalent representations together, and in a single document is generally
the best way to do this.

PS:  
  >  The
  > three requirements for claims of conformance are pretty vague - where should
  > these items be noted?  In comments?  In some meta-element? In a separate
  > document?
IJ:  
  Eric Hansen has sent some interesting suggestions [1]
  about the conformance section that the Working Group
  has not yet had the opportunity to review. I trust that
  some of your questions will be addressed during that review.
  
  [1] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0295.html

CMN:
I don't see any need for the document to specify where a claim to
conformance might be. any or all of the above suggestions could be used,
as well as in the contract which commissions a website design, on the
poster used to advertise information, and anywhere people would like to
make a statement about the accessibility of their website, making
reference to WCAG.
[snip]   
PS:
  > section:  Guidelines
  > 
  > *       The intro to this section introduces the notion of transformation of
  > documents.  This is a change from the tone of the intro.  Perhaps an
  > additional section on strategies/mechanisms for transformation of documents
  > would help to explain the underpinnings of the approaches.  If the
  > assumption is that stylesheets will be the basis for much of the
  > accessibility guidelines, then that should be stated.
IJ:  
  It is interesting that you are associating the term "transformation" so
  strongly with "style sheets". Does that connection come
  from an XSL perspective?
  
  Style sheets provide some of the solutions listed in the
  guidelines, but others rely on proper use of markup,
  organization of content and of an entire site, navigation
  tools, etc. 
CMN:
The transfomration referred to is that which is caused by the rendering of
the document in different device types - a TV and a braille display cannot
render the same object. Information, in being rendered as an object or
series of objects, undergoes some or all of one possible set of
transformations to be rendered on TV and some or all of a different set of
posible transformations to be rendered by a braille display.
[snip]
PS:   
  > *       Checkpoint 1.2 - this should perhaps be qualified to describe
  > programmatic elements that have a direct visual representation. Some objects
  > are added to extend the functionality of the page, but do not have any
  > specific associated visual element (they may manipulate the DOM for various
  > elements).  The alternates should concentrate on the presentation, rather
  > than on code that may play a part in presenting the information.
IJ:  
  Proposed change to 1.2:
  
    Provide text equivalents for all applets and other programmatic
  objects
    that present visual information.
CMN:
I disagree. Where a script or applet provides a functionality, that is
dealt with in other sections of the document - especially checkpoints 8.3,
8.5, and 10.1. The checkpoint here may be redundant, as it essentially
refers to information presented by the object (also covered by 8.3).
Restricting it to visually represented information is a mistake - first
because it may be an audio object, and second because the notion of text
equivalent explicitly includes the possibility of rendering nothing.

PS:   
  > *       For media rich pages, some additional guidelines seem appropriate to
  > cover how audio should layer, especially when it is used for accessibility.
  > If music is playing on the page, how should this interact with an audio
  > alternative to a movie or animation?  How should audio cues added to buttons
  > add to this?  How do screen readers manage all the audio?  I know that I am
  > ignorant of what is available, but I think that especially in the area of
  > multimedia, some more guidance would probably be useful.  How does a screen
  > reader deal with text that interactively "pops up" somewhere as an
  > alternative to some graphic effect? Perhaps I just need to understand better
  > how screen readers are used...
IJ:  
  These subjects are discussed in section 2.9 of the Techniques Document.
  However, we will look further into a discussion of CSS2's aural
  cascading style sheets and how they can control cueing, background
  sounds, etc. The editors will also look into more information about
  synchronization and SMIL.
CMN:
These seem to be problems which are strictly in the domain of User Agents.

PS:   
  > *       Guideline 5 seems to be in conflict with the goal of supporting
  > users with downlevel browsers.  Several of the practices recommended against
  > are used because they are the most portable means of specifying a formatting
  > effect.  Not much we can do here, except note the conflict (as is done in
  > the techniques doc).
IJ:  
  Yes, the conflict must be clearly documented. We will also re-examine
  checkpoint 13.1, which says to use the latest W3C technologies. 
  The phrase "wherever possible" must be clarified. It may be more
  appropriate to use CSS1 features, for example, than some CSS2 features
  until CSS2 is more widely supported. It is crucial for authors
  to ensure that whatever features they use transform gracefully,
  and style sheets are designed to do so.
CMN:
Some practices used as a way of providing a formatting effect for
down-level browsers cause accessibility problems. Unless the formatting is
itself crucial to the accessibility of the document, it needs to be
sacrificed if the ultimate goal is accessibility. Which it is in this
case. Particularly where the techniques used are abuses of the specified
semantics of the language, I think that it qualifies as a benefit
accessibility can provide to everyone that documents become better
structured, and the standard is better implemented.

PS:   
  > *       Guideline 5.6 says "Use relative rather than absolute units in
  > markup language attribute values ..." and then the techniques document says
  > in the layout section below "Layout, positioning, layering, and alignment
  > should be done through style sheets (notably by using CSS floats and
  > absolute positioning)".  Guideline 5.6 should perhaps be clarified to except
  > positioning attributes.
IJ:  
  As confusing as it may sound, CSS allows you to
  use relative units in absolute positioning (and you should). 
  Thus, you may position an image to be offset by "3em" from
  the top of its containing element. This is a fixed distance,
  but is relative to the current font size, so it scales
  nicely.
  
  Thus, relative "units" should be used wherever possible.
  
  Thank you for your comments,
  
  - Ian Jacobs and Wendy Chisholm
  
  -- 
  Ian Jacobs (jacobs@w3.org) 
  Tel/Fax: (212) 684-1814 
  http://www.w3.org/People/Jacobs
CMN:
I second the vote of thanks.

Charles  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Friday, 12 March 1999 18:18:17 UTC