RE: Comments on Web Content Accessibility Guidelines

Just a few responses (heavily snipped).

> -----Original Message-----
> From: Charles McCathieNevile [mailto:charles@w3.org]
> Sent: Friday, March 12, 1999 3:18 PM
> To: WAI GL
> Cc: Patrick Schmitz
> Subject: Re: Comments on Web Content Accessibility Guidelines
 
> 
> 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.

Perhaps - I guess it all depends on your expected audience.  If you are only
preaching to the choir, then this makes sense.  If not, perhaps a different
tone would be more effective.  Just a thought.

> 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.

I was just hoping for more explanation of what actually happens.  The
techniques describe how to support this process, but I was curious for more
understanding of the process itself.  What does a braille display handle,
what it ignores, how it handles layout that is not straightforward linear?
The additional docs Ian referred to will help, I'm sure.

> [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.

I was actually just referring to objects that represent code that supports
functionality elsewhere in the page.  Examples include signed CAB files for
java applets (the applet is declared elsewhere on the page), "DHTML
behavior" support in IE5, etc.  The point is pretty minor, and so can
probably be ignored in your docs.

[snip]
> 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.

That is a "benefit" that some content producers may not appreciate as they
try to maximize their reach.  Number one on their list is # of people that
can browse their site (x-platform times x-browser times x-version gets
really ugly really fast, and leads to some ugly LCD HTML).

I am suggesting that accessibility may not be their #1 goal - don't make it
easier for them to ignore it altogether by recommending constraints that
they cannot live with.

Patrick

Received on Thursday, 18 March 1999 19:30:00 UTC