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

Jon Sykes jon.sykes at media-hive.com
Thu Jun 22 17:27:54 EDT 2006

+1 for phark revisited (it currently only fails in Images off, Css  
'fully' on) which is a pretty crazy browser setup.

I would add that I think there needs to be care taken as to the point  
where users stop getting dojo'istic presentation, and the information  
should revert back to traditional methods of input.

Take for example the slider.

Is the plan to render the slider using imageless methods, if a user  
is in an OS or browser mode where background images or actual images  
are useless ?  So in theory we might be presenting the user with


Where [x] is draggable ???

Surely there must be a level of accessibility where the above just  
renders in traditional format, say as an input field, or a drop down  

I'm not thinking we 'penalize' people with accessibility concerns,  
more that we cater to how they are used to operating.

Jon Sykes

On Jun 22, 2006, at 5:04 PM, Tom Trenka wrote:

> 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
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list