W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2002

RE: WA - background-image in CSS - PRACTICAL APPLICATION

From: Al Gilman <asgilman@iamdigex.net>
Date: Sat, 19 Jan 2002 00:15:23 -0500
Message-Id: <200201190515.AAA4157514@smtp2.mail.iamworld.net>
To: RUST Randal <RRust@COVANSYS.com>, w3c-wai-ig@w3.org
At 03:04 PM 2002-01-18 , RUST Randal wrote:
>Rather than continue the infighting, let's look at a practical use of images
>in a CSS background.
>
>Using the CSS-2 Spec, I can apply background images to the link element,
>thereby creative a rollover menu without the use of Javascript.  Here is an
>example: 
<http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html>http://www.me
yerweb.com/eric/css/edge/complexspiral/demo.html
>
[...]
>I'd like to get some PRACTICAL feedback on this, because in the document
>that I am writing regarding accessible web pages, this is the method that I
>suggest for rollovers.  I think it works much better than using Javascript.
>
>In my document, the technique that I put forth DOES NOT use the image in the
>background, but the background color changes, so that the user is more aware
>that there is a link on the menu.
>
>Does this technique conform to the WCAG guidelines?  Either with or without
>the graphics.  This is a serious question, and I'd rather not get into any
>conjecture, so please stick to the guidelines, not personal interpretation.
>

AG::

[attempting to couch in practical terms.  But this _is only_ my personal
interpretation, nonetheless.  If you want anything other than personal
interpretation, ask the WCAG group for a clarification and wait. 
<<http://www.w3.org/WAI/GL/>http://www.w3.org/WAI/GL/> .]

Summary:  

1) Do whatever you do to links in terms of :hover response on the :focus
condition as well.
2) Consider browser implementation issues before relying too heavily on this
technique.

The visual effects as you style them may in fact be more usable by some
individuals with disabilities than the default effects supported by the
browser.  On the other hand, some cognitively impaired individuals may not
recognize your effects as meaning the same thing as the customary effects, and
suffer a degradation in link recognition.  But all of this is speculation. 
Since browsers generally allow the user to override styling of this nature,
there is no uncorrectable downside.  On the other hand, there is no sure
upside.  There is no way to establish a convincingly reliable upside given that
the needs of the user are determined by the different conditions of the users,
and the dynamic style effects that the author picks are determined by the
author.

Details:

Using only :hover to trigger the rollover is mouse-specific.  This denies the
benefits of your dynamic styling gesture to some people who could benefit from
it.  Compare with UAAG 10.2.  You can leave the keyboard-only user [broad class
of disabilities] limping along with the default focus indication of the
browser, or you can highlight the current menu item with your extra-strength
accentuation with :focus.  If it is supported.

That is a genuine practical question: how good is the support for :focus and
:hover?  I don't know.  [The guidelines don't tell you, either.]  The Eric
Meyer demonstration page tells you it is not good.  That's a practical
consideration.

[If I recall correctly Netscape is working with might and main to fix keyboard
operability.  On the other hand, a shortfall in that area as of now would
suggest that the joint availability of keyboard operability and support for
:hover and :focus in CSS is rather limited.]

The other practical issue is text legibility [visual impairment].  But the
generally good browser support for UAAG Checkpoints 3.1 and 4.3 seems to
indicate that you are not in deep trouble there.

In summary:

It's not an accessibility barrier if you use this effect.

Do bind to :focus as well, in order to be more Universal Design, regardless of
whether the difference crosses an access threshold or not.

Do think -- for your own purposes, not for satisfaction of accessibility
requirements -- about how many of your visitors have browsers that support this
effect and what users with non-supporting browsers will see.  Also realize that
because of other, un-related accessibility issues, various users with
disabilities may not have as many practical options when it comes to switching
browsers. 

Al

>Randal Rust
>
Received on Saturday, 19 January 2002 00:15:33 GMT

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