In CSS, Scripting and Screenreaders When Does Invisible Mean Inaudible?

Based on a few postings on this list and its sister, I've developed a
hypothesis about the way screenreaders respond to text rendered invisible
using CSS (or temporarily so using scripting and CSS). (Cites to various
posts below.)

It seems like some screenreaders (JAWS 3.3?) will read all text, even if it
is invisible. This would mean that CSS menus and the like are read in full
(for good or ill). As an example, if text is repeated (with one visible
iteration being swapped for an invisible one on mouseover in order to create
a psuedo-hover-psuedo-class for Netscape 4.x), an echo effect occurs.

On the other hand, it seems that other screenreaders (JAWS 3.7?) will only
read text which is visible. This results in unusable menus, since the PC
cursor does not trigger any event handlers and the user is unaware of the
hidden text.

Can anyone confirm if this is true?

If it is, it seems that in order to have a properly accessible menu:

--It would have to work with javascript turned off.
--It would have to work when all text would be read out.
--It would have to work when only visible text would be read out.
--It would have to work even though it didn't know which flavor of
screenreader it was dealing with.

I believe javascript turned off or non-existent can be dealt with by:

--putting together a site map or home page that provides links to the same
resources as the menu would
--placing links to the site map/home page on the page on which the menu
would appear, at top and bottom of page and defining a "CLASS" for those
links
--using javascript "document.write( )" to write CSS which gives the
link-to-home page class a CSS "display" property set to "none"
--Use javascript "document.write( )" to write HTML and CSS to create the
menu

With javascript on, this would create redundancy where the screenreader read
the visible and invisible alike, since the fallback link would be audible as
well as the menu. With javascript on and a screenreader that only reads
visible text, this would only be as good as the menu itself (since the
fallback link would be hidden).

I believe that javascript on and screenreader that reads everything can be
dealt with by the the same expedients one would always use with visible
menus:
--keeping the menu as short as possible
--putting the menu at the bottom of the page so it doesn't have to be waded
through to get to content

Would this work?

This also leads to a couple of questions in my mind:
--should all menu items be <A> elements, to facilitate use by screenreaders
which give link lists?
--could alterations of document structure (change in innerText/innerHTML or
their DOM-compliant cousins) be a better alternative?

As to the "read-only-the-visible" browsers, I confess myself baffled. Could
making the menu items <A> elements and setting their "ALT" or "TITLE"
attributes draw enough attention to them so that a screenreader user would
know to tab to/click on them to make the menu audible? What (if anything)
can be done?

Regards,
Chris

CITES:

J-M D'Amour noting that J Ley's menu did not work in (unspecified) version
of JAWS since event handlers were not triggered.
http://lists.w3.org/Archives/Public/w3c-wai-ig/2001JulSep/0744.html

J Ley noting that menu worked under JAWS 3.3 and failed under JAWS 3.7
http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/1050.html

J Chetwynd noting echo effect in KSU page under JAWS 3.31
http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0976.html

I also think there was a discussion with Bruce Bailey a while back regarding
the internet.com site's menu which was similar, but with the W3C search
down, I can't find it.

Received on Tuesday, 2 October 2001 00:52:36 UTC