[dojo-contributors] Accessibility issues with the use of CSS background images

Tom Trenka ttrenka at gmail.com
Thu Jun 22 17:04:23 EDT 2006


In general, I've been using the Phark Revisited methodology (it's all
over the place on the new Dojo Toolkit site) and to date I've found
that to be the best method of image replacement, particularly since it
doesn't require any extra tags to pull it's stuff.  In fact, I'd
recommend that method over anything else, since you can define it with
one CSS definition without altering the structure of the document to
make accomodations.

One thing that I'm sure would help is if there was a running list of
widgets currently using background images that may fail the 503
test...

trt


On 6/22/06, Becky Gibson <Becky_Gibson at notesdev.ibm.com> wrote:
> As I am working on accessibility for the widgets I am noticing the use of
> CSS background images.   These types of images present a problem for
> accessibility when they are used to convey information.  People who use
> screen readers to access the content get no information about CSS provided
> images.   When a screen reader encounters a standard <img> element it will
> speak the contents of the alt attribute.
>
> CSS background images also present a problem for people who use the
> operating system level high contrast mode (shift-alt-printscreen is
> usually set up to switch to high contrast mode on Windows systems - be
> careful though it changes font size and can rearrange your desktop).  In
> this mode any color or background information is disabled - basically only
> CSS  positioning and visibility/display status is maintained.  So, widgets
> like the slider are currently not usable in high contrast mode.   In
> addition,  The US Government Section 508 of the Disabilities Act [1]
> requires that pages work with CSS turned off: "Documents shall be
> organized so they are readable without requiring an associated style
> sheet."
>
> There are a few possible solutions.
>
> 1) don't use CSS background images to convey information.  Thus the close
> icon on a tab panel or the checkbox icon need to be real <img> elements. I
> know there are concerns about this approach since it prevents changing the
> chrome simply by modifying the style sheet.  There are also performance
> concerns.   The use of real images isn't an ideal situation either since
> images are not turned off by default in high contrast mode.  Someone using
> high contrast mode usually has some sort of vision impairment and might
> have difficulty seeing the image.  The work around for this is for the
> user to turn off images and rely on the alt text. This certainly isn't
> ideal but is an acceptable work-around.
>
> 2) use CSS image replacement techniques [2] where possible to provide the
> necessary text below the non-transparent background-image.  This will work
> in situations like the slider but is more difficult when the text
> description is longer than the image.   For example, the proper
> description of the close X on a tab panel should be "close" or  "close
> tab" but that amount of text certainly won't fit behind the X icon.  One
> could argue that the alternate text for close could be implemented as [x]
> and would probably be recognized but I think we will run into other issues
> where the text will be longer than the image.   There are also
> implications when the font size is made larger and the text no longer fits
> behind the image.
>
> So, my current proposal is to use the second technique, CSS image
> replacement, where possible and fall back to using <img> elements where
> CSS image replacement is not possible.  This still leaves the chrome
> issue.  Does any one have other suggestions?  I'll also be looking for
> help with implementing the CSS image replacement techniques within the
> widgets - I'm certainly not a CSS guru!
>
> thoughts and ideas?
> thanks,
> -becky
>
>
> [1] http://www.section508.gov/index.cfm
> [2] http://www.mezzoblue.com/tests/revised-image-replacement/  (the
> Gilder/Levin Method shows the most promise)
>
> Becky Gibson
> Web Accessibility Architect
>
> IBM Emerging Internet Technologies
> 5 Technology Park Drive
> Westford, MA 01886
> Voice: 978 399-6101; t/l 333-6101
> Email: gibsonb at us.ibm.com
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>



More information about the dojo-contributors mailing list