W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2001

RE: Fw: putting reader text in hidden <div> tags / adding pauses

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 06 Dec 2001 11:26:22 -0500
Message-Id: <200112061616.LAA1848011@smtp2.mail.iamworld.net>
To: <w3c-wai-ig@w3.org>
>>>> "Mike Scott" <mscott@msfw.com> 12/03/01 17:12 PM >>>
>by screen readers. We really need some concensus on what the
>specs/guideline say if we can expect web developers (or user agent
>developers) to know how to handle this issue.

AG::

This has been considered at length in the development of the User Agent
Accessibility Guidelines 1.0 which is currently a Candidate Recommendation.

The answer there is that all 'conditional content' should be exposable by the
user, by some combination of mode settings and interactive commands, in any
user agent.  The profiling of what is shown first and how easy it is to get to
what is not shown can vary from delivery context to delivery context.

In this sense, anything marked as hidden by a style must be considered
'conditonal content.'

 <http://www.w3.org/TR/UAAG10/guidelines.html#gl-content-access>http://www.
w3.org/TR/UAAG10/guidelines.html#gl-content-access

At 10:33 AM 2001-12-06 , DAN BILLINGSLEY wrote:
>I think Mike has a great point.  If screen readers do not read hidden
>text they will be missing most of the content on a web sites with dhtml
>menus.  If you are unable to navigate a site with a screen reader or the
>keyboard, you might as well not include all the subpages on a site.
>
>Any content on a web page that was not meant to be viewed or read,
>should be excluded before the page gets served to the browser!  

AG::  Thank you for saying that.  This should be the basic deal as regards web
content and access control, encryption issues aside.  There can be arcana in
web pages that are primarily intended for the client-side automation.  But not
secrets from the user.

Al

>...Any
>variables should be passed via form or appended to the end of the URL. 
>Content can be changed dynamically on the server, to parse accessible
>code.  Using display and hidden for the purpose of completely hiding
>content form the user is a misuse of the style.
>
>Dan Billingsley
>
>
>>>> "Mike Scott" <mscott@msfw.com> 12/03/01 17:12 PM >>>
>> There is a design debate about ... hiding the "Skip navigation" link.
>... But the
>> reason we recommend the "current work around" [alt text on invisible
>images] is
>> because it works! And it has to when CSS it turned off! Visibility:
>hidden wouldn't
>> work with CSS off.
>
>It doesn't "not work" without CSS, the skip navigation link simply
>becomes visible, it is still functional (i.e. "graceful
>transformation").
>
>Additionally, the invisible image workaround ignores all the sighted
>users who use only the keyboard. (It's nearly as tedious to tab through
>a long list of links as it is to listen through it.) Wouldn't a better
>solution be to use hidden (but spoken) text that could also be
>dynamically displayed using the onfocus event? (Although I suppose you
>could do that with images as well.)
>
>> By honoring the visibility properties affected by JavaScript, the
>JavaScript
>> page can be made directly accessible and - more importantly - usable.
>> For example, web applications "hide" content when it is not pertinent
>> to the user's profile.  Blind users should not be forced to read all
>> the hidden content, usually out of order and context,  when the
>sighted users
>> doesn't have to.
>
>This seems to be a case that would not work with CSS off (assuming that
>there really is so much hidden content that the page would be unusable
>with it shown/read.)
>
>It's not hard to find real-world examples that support both arguments --
>that text hidden using visibility should be read or should not be read
>by screen readers. We really need some concensus on what the
>specs/guideline say if we can expect web developers (or user agent
>developers) to know how to handle this issue.
>  
Received on Thursday, 6 December 2001 11:16:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:58 GMT