W3C home > Mailing lists > Public > wai-xtech@w3.org > May 2007

Re: Developers' Poll: support for overflow: hidden;

From: Gez Lemon <gez.lemon@gmail.com>
Date: Tue, 22 May 2007 19:32:05 +0100
Message-ID: <e2a28a920705221132v56a398fdle186c972cb8902e6@mail.gmail.com>
To: unagi69@concentric.net
Cc: "Gregory J. Rosmaita" <oedipus@hicom.net>, wai-xtech@w3.org, wai-liaison@w3.org

Aloha, Gregory,

I went to Amazon's website with IE7 and JAWS on a Windows XP platform,
and the hidden link was announced correctly. I'm not sure why you're
not hearing the link, but I was obviously wrong about it being hidden
with display: none, as it's being announced to me. It might be that
the validation errors the website results in it not work correctly on
your setup.

I suspect that Amazon's intention is to have the link announced to
aural devices, and aren't concerned that the link will also be
displayed to non-CSS capable user agents. That probably seems quite
reasonable from their viewpoint, but it does cause another problem in
that keyboard users who don't use AT will focus on something that
isn't visibly on the screen, which will be confusing.

In answer to your question about whether this is an effective
technique for what they want to achieve, my response would be that it
isn't effective, because it causes other accessibility problems (such
as losing track of the cursor for people with mobility problems that
don't necessarily use AT, but do use the keyboard to navigate a web
page). The technique is a valid technique for providing contextual
information, but even then I have concerns about the amount of
contextual information well-meaning people feel compelled to provide.
If the technique is used correctly, then it can be very helpful.

Gregory said:
what i am ultimately attempting to determine is, what is the proper
way to use CSS to paint to the aural canvas while leaving the visual
canvas unmodified?  given the state of the CSS 2.1 draft and its
ambiguities, i sincerely think this needs to be sorted out, one way or
the other, which is why i proposed a quote render unquote meta media
property, which unambiguously signals to all canvases that what is
marked hidden is to be hidden from all possible canvases, and what is
marked exposed is exposed to all possible canvases...  this would
allow display:none to be a visual property, affecting only the visual
canvas, leaving the text so styled available to the aural and or
tactile canvases, while visibility:hidden (a modality-dependent
property) would be to the visual canvas what volume:silent is to the
aural canvas (leave a silent gap corresponding to the hidden block,
just as visibility:hidden; hides content, but leaves an empty,
canvas-consuming block.

likewise, speak:none; is the aural equivalent of display:none, in that
it does not interupt the aural flow to indicate invisible text, as
does volume:silent

This is effectively what positioning content off-screen does - it's
still in the content, so should be announced by aural devices, but
isn't available visually, as it's positioned outside of the viewport.

Gregory said:
so i'm trying to figure out a way of assisting amazon in conveying
content to the aural, tactile and the CSS-incapable canvas without
intruding or leaving a footprint on the visual canvas...  i understand
that the collapse property allows the content so styled to be
invisible, hence hidden, from the visual canvas, but does a property
named visibility really apply to the aural and tactile canvases,
especially when the analogy -- or rather, synonymetry -- between
visibility:hidden and volume:silent is so explicitly apparent?

One of the problems of visibility: hidden is that it leaves the space
required to render the hidden content visibly on the screen, which is
why developers opt for display: none, when it absolutely isn't
required by any canvas, but is needed for scripting; or positioning
the content off-screen when they want it available for non-CSS user

Best regards,


Supplement your vitamins
Received on Tuesday, 22 May 2007 18:32:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:32 UTC