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: Mike Scott <mscott@msfw.com>
Date: Tue, 4 Dec 2001 22:53:27 -0600 (CST)
Message-ID: <3148.64.108.44.176.1007528007.squirrel@tux.msfw.com>
To: <w3c-wai-ig@w3.org>
Cc: <jim@jimthatcher.com>
> For example, ALL of the pull down menus on sites like www.nsf.gov or
> www.microsoft.com are spoken

Doesn't the alternative (not speaking the "hidden" menus) mean that the 
options on these menus will be inaccessible?  

For example, on www.nsf.gov, the "About NSF" menu has a listing for "Jobs", 
which contains "Vacancy Announcements". Since HPR 3.02 doesn't read these 
dynamically "hidden" menus, I can't get to this item. Yes, it is listed on 
their separate "site map" (http://www.nsf.gov/home/help/sitemap.htm), but 
it is no easier to navigate through that massive listing that it would be 
to navigate through the menus were they to be read in the first place. 

Similarly, on www.microsoft.com, the "Training/Event" menu 
includes "Training & Certification" and "Events" -- with HPR 3.02, I can't 
get to "Events", or even know that it exists.

I agree that there are so many items on these menus that they are barely 
usable, but is ignoring that content really a better option?



Original message:

> I grant that alt text on a "spacer image" is a hack, as is making links
> hidden by using same foreground and background colors. This may be
> offensive to purists but these hacks work.
> 
> Using visibility:hidden or display:none to visibly hide text and expect
> it to be spoken by screen readers seems to be even worse than a hack.
> It is using an attribute for its opposite purpose.
> 
> When HPR (in the previous version, 3.0) incorrectly (in my opinion)
> spoke content with these hidden attributes it was terribly confusing.
> For example, ALL of the pull down menus on sites like www.nsf.gov or
> www.microsoft.com are spoken, usually without the correct attributes of
> activity - i.e., they are not only supposed to be hidden, when visible
> they become active - when hidden they aren't. Other plus-to-expand type
> content was all in the HPR 3.0 text view; the "Plus" to expand and
> "minus" to collapse were meaningless.
> 
> The first job of a screen reader or talking browser is to present, in
> as clear a way as possible, the content that is visually displayed on
> the page. When content is non-textual then the assistive technology
> needs some help, like alternative text for images, headers for the
> information conveyed by positions in data tables, or labels (or titles)
> to convey information otherwise given by positioning in forms. But the
> main job is to present the material that can be seen. Things with
> visibility:hidden or display:none can't be seen and are intended by the
> web designer to not be seen or heard.
> 
> Jim
> jim@jimthatcher.com
> Accessibility Consulting
> http://jimthatcher.com
> 512-306-0931
> 
> -----Original Message-----
> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> Behalf Of Mike Scott
> Sent: Monday, December 03, 2001 2:44 PM
> To: w3c-wai-ig@w3.org; 'Phill Jenkins'
> Subject: RE: Fw: putting reader text in hidden <div> tags / adding
> pauses
> 
> 
>>  Do you have a reference in the CSS spec that suggests that screen
> readers
>>  read out loud content styled with Visibility: Hidden?
> 
> The reference Charles indicated
> (http://www.w3.org/TR/REC-CSS2/propidx.html) is the one I had seen.
> 
>>  nor do I think screen readers should read anything marked hidden.
> 
> "Skip Navigation" links are perfect examples of items that we might
> want hidden but definitely should be read by a screen reader. (Instead
> of the current workarounds like invisible images or text set to the
> same color as the background.) Also, there could be cases where
> dynamically hidden elements (such as pop-up or expanding/collapsing
> menus) also should be read.
> 
> -----Original Message-----
> From: Charles McCathieNevile [mailto:charles@w3.org]
> Sent: Monday, December 03, 2001 10:44 AM
> To: Phill Jenkins
> Cc: w3c-wai-ig@w3.org; RandR@SEC.GOV; Mike Scott
> Subject: Re: Fw: putting reader text in hidden <div> tags / adding
> pauses
> 
> The display propperty is defined as referring to all presentation
> modes, whereas the visilbility property only aspplies to visual modes,
> according to the property index of CSS2
> http://www.w3.org/TR/REC-CSS2/propidx.html
> 
> cheers
> 
> Charles
> 
> On Mon, 3 Dec 2001, Phill Jenkins wrote:
> 
>  Do you have a reference in the CSS spec that suggests that screen
> readers
>  read out loud content styled with Visibility: Hidden?  I couldn't find
> one
>  nor do I think screen readers should read anything marked hidden.
> 
>  WCAG CSS techniques don't mention it, but it does discuss "display:
> none"
>  at
> http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-info-not-in-color-alone
> 
>  Display property in CSS 2
>  http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-display
>  Visibility property in CSS2
>  http://www.w3.org/TR/REC-CSS2/visufx.html#visibility
> 
>  Why would a screen reader want to read out loud something that the
> author
>  marked as hidden?
> 
>  Alt text on an invisible image is still the best choice because it is
>  supported best.
> 
>  HPR 3.02 is currently available from
> ftp://ftp.software.ibm.com/sns/hpr
> 
>  Regards,
>  Phill Jenkins
>  IBM Research Division - Accessibility Center
>  11501 Burnet Rd,  Austin TX  78758    http://www.ibm.com/able
> 
> 
> 
>  Mike Scott <mscott@msfw.com>@w3.org on 12/02/2001 02:12:59 AM
> 
>  Sent by:  w3c-wai-ig-request@w3.org
> 
> 
>  To:   <w3c-wai-ig@w3.org>
>  cc:   <RandR@SEC.GOV>
>  Subject:  Re: Fw: putting reader text in hidden <div> tags / adding
> pauses
> 
> 
> 
>  For what it's worth, the about-to-be-released IBM Home Page Reader
> version
>  3.02 will no longer read text with Display: None (or Visibility:
> Hidden).
>  JAWS (at least as of 4.0.103) will read it if Display: None (or
> Visibility:
>  Hidden) is set in the <style> block or in an external style sheet, but
> not
>  if it is set in-line.
> 
>  According to the CSS specs, screen readers should NOT read content
> with
>  Display: None but should read content with Visibility: Hidden.
> 
>  >
>  > The original senders address was not available but I thought this a
>  > worthy question to toss out.
>  >
>  > Hi, I'm a web developer for a federal agency website and a newcomer
> to
>  > this list. We are experimenting with adding text for for screen
> readers
>  > to our home page and index pages that is hidden from the visual
>  > browser window with the following coding:
>  >
>  > <div style="display:none;">reader text goes here. . . .</div>
>  >
>  > I have verified that Netscape 4.7, Explorer 5, and Opera 5.12 won't
>  > show the hidden text visually but that IBM Home Page Reader will
>  > read the text.  We haven't yet tested the coding with JAWS.
>  > Is anyone else using this coding or can someone recommend another
>  > approach?
>  >
>  > What prompted this experimentation was that in conversation with
> some
>  > of our staff using screen readers, we discovered that our home page,
>  > with 70+ links, is overwhelming. Visually the organization is clear,
>  > but the screen reader simply reads all the links one after the other
>  > without the benefit of identifying main link headings. We want to
> add
>  > a more explanatory menu for screen readers with just the main links
> to
>  > our important index pages, uncluttered by secondary links that they
>  > would find on the second level index pages anyway.
>  >
>  > Second question is: has anyone had success with adding coding that
>  > provides a pause for screen readers between lists of links? Is that
>  > important?
>  >
>  > Thanks in advance for any help.
>  > <snipped>
>  >
>  > Bob Rand, Web developer
>  > Securities and Exchange Commission
>
Received on Tuesday, 4 December 2001 23:53:38 GMT

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