RE: Comments on Web Content Accessibility Guidelines

Sorry for the long delay in responding -

> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Friday, March 12, 1999 12:31 PM
> To: Patrick Schmitz
> Cc: 'Philipp Hoschka'; 'w3c-wai-gl@w3.org'; 'symm@w3.org'
> Subject: Re: Comments on Web Content Accessibility Guidelines
> 
> >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.

I guess I was looking for more information how the "transformation" of
documents would actually take place or be effected.  Chock it up to my
ignorance, but I am not clear how a screen reader works for web pages that
are not straightforward, linear text.  I did assume that in some cases
stylesheets or (XSL) transform sheets might get involved - I have elsewhere
heard of strategies in which some code running on some proxy would transform
general HTML documents into something suitable for things like smart phones.
I am just trying to understand all the steps involved.

> 
> Proposed text:
> 
>       Users with blindness will understand the function of 
>       the image when the text is read aloud by a speech synthesizer.
>  

This is clearer.

> > *       Following point mentions use of altText in tooltips 
> - this means a
> > loss of features for designers, who often use the tooltip text as an
> > invitation to interaction ("click here to learn more").  
> Guideline 15.1 says
> > not to use this at all, and yet interaction designers often 
> recommend doing
> > this.
> 
> Checkpoint 15.1 does not refer to the use of "title" as
> a means of a creating a tool tip. Checkpoint 15.1 talks
> about link phrases, which should be understandable out
> of context, terse, meaningful, and device-independent.
> 
> The "title" attribute in HTML should be used to give advisory
> information about the target of a link. This information
> MAY be used as a tool-tip by a user agent, but this is
> not required in any W3C specification. 
> 
> Do users need to be told that it's possible to interact
> with a Web document? Isn't that so fundamental to the 
> Web that it's not necessary to state for every link
> that this link is meant to be interacted with?

I am thinking of images, ad banners and other elements for which the
hyperlink highlight is not obvious.  IE5 added a "go" button because many
users were not aware they had to hit ENTER.  Much of the growth on the Web
is among new, web-naive users.  For them, it is not at all obvious that they
should click on every image they see.

In practice today (i.e. in the few docs I checked) "alt" is used on images
for text that will be rendered in a toolTip (that is not the only reason it
is specified of course).  I have seen little "title" usage.

Makes sense to discourage alt text of the form "click here" in favor of
"Click here to see joe's used cars".  "Click" is certainly tied to
mouse-drive browsers - not sure how to balance the invitation to interaction
with more the WAI guidelines.  The worst (and quite often seen) is "Click
here to find out more" - typically there when ads are inserted, and a
generic alt can be used for all ads.

> 
> Proposed change:
> 
>   * Why certain pages are not accessible to people with disabilities.

Much friendlier.

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

Just what they do, and how they rely on "proper use..." is what I was
getting at in my request for the transform strategies overview above.
Perhaps when the other referred-to documents appear, it will all become
clearer to me...

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

The SMIL linking doc has some ideas on managing sounds w.r.t links - perhaps
some similar thinking would apply here?
http://lists.w3.org/Archives/Member/symm/1999JanMar/0263.html

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

I see - perhaps a few extra words to make this distinction would be helpful?

Hope this is useful -  Patrick

Received on Thursday, 18 March 1999 19:10:55 UTC