Re: [css3-background] PFWG review of css3-background 2009-10-15 LCWD

This is a PFWG acknowledgement of your response to our comment on CSS 3
Backgrounds and Borders. PFWG approval to send this acknowledgement is
recorded at http://www.w3.org/2010/02/10-pf-minutes.html#item12.

We're still somewhat concerned the CSS allows only for a
background-image, and not for other types of images.  We are also not
convinced that allowing for a high-contrast-foreground-image and
high-contrast-background-image would constitute a hack.  It is possible
that the image module or media queries is the right place for this
functionality.  We are, however, aware that our feedback came quite
late, and that it may not be possible to incorporate for this version of
CSS.  Should that be the case, please consider this use case as a
feature request for the next version.

You state that "There is also an effort in the CSS Images module to
address spriting directly and make it generally useful in CSS, rather
than only being useful in backgrounds."  We were unable to locate that
module.  Can you point us to the document, so that we may provide input
to that group?  Is it in Last Call as well?

While we appreciate the effort to take CSS3 to last call we are working
to define new CSS attributes to allow people with disabilities to render
alternative content to HTML 5 elements, like canvas, to make it
accessible. Since CSS3 features have a tight association with HTML 5
features we request that the new features for content selection, and
which are based on IMS Global Learning Consortium, access for all
features be agreed upon in the HTML working group and included in the
CSS 3 media query specification before it can complete CR.

We appreciate this is disruptive. The canvas accessibility working group
is working to have a recommendation on canvas accessibility by Feb 25.
Should we agree to use media queries as the vehicle to address selection
of alternative content we will submit our requests by this date to
discuss requirements.

For the PFWG:
Michael Cooper
Staff Contact

Tab Atkins Jr. wrote:
> On Wed, Jan 6, 2010 at 11:53 AM, Michael Cooper <cooper@w3.org> wrote:
>   
>> The following is review comments from the Protocols and Formats Working
>> Group on CSS 3 Backgrounds and Borders, Last Call Working Draft of 15
>> October 2009 <http://www.w3.org/TR/2009/WD-css3-background-20091015/>. We
>> are aware these comments are late (due to process difficulties on our end)
>> and apologize for that, and will take our delay into account in how we
>> address your responses. PFWG approval to send these comments was obtained 6
>> January 2010 http://www.w3.org/2010/01/06-pf-minutes.html#item05.
>>
>> The basic issue is that in low-vision scenarios, CSS backgrounds are often
>> disabled. This is correct behavior, because in these scenarios, the user
>> agent changes all the colors, and removes background decoration, gradients,
>> etc. in order to improve readability. This happens with Operating System
>> High Contrast settings, and is also done by some assistive technology.
>>
>> Many Web developers are using CSS to apply images that are necessary for
>> understanding and operating a Web site, for example, a graphic that defines
>> a button or other clickable area.  The developers are doing this to improve
>> performance, by adding all the graphics for a page to a single image file,
>> and using CSS positioning and clipping to apply to it various UI elements,
>> thereby reducing the number of http requests.  This approach is sometimes
>> called ‘sprites’.  Developers who use sprites are often unwilling to give up
>> the performance in order to provide accessibility to low visions users, as
>> doing so can often have rather significant monetary costs (additional
>> servers, increased bandwidth consumption, etc).
>>
>> Users who use high contrast settings or AT with similar behavior, will not
>> see sprites, and the site will not be accessible to them.
>>
>> What is needed is a mechanism that allows developers to indicate that a
>> particular application of an image by CSS is a sprite, and should not be
>> removed when backgrounds are removed.  It would also be nice to have a
>> mechanism to provide different graphics to these users, such as graphics
>> drawn in high contrast.
>>     
>
> The current usage of sprites is a dirty hack, and is a problem only
> because (a) as you said, there are performance benefits to spriting in
> many circumstances, and (b) using the background property is currently
> the only reliable way to extract a sprite from an image.
>
> Better ways to address this use-case are being developed.  There are a
> few suggestions about how to generalize the idea of sending multiple
> resources in a single item, and easily make the sub-pieces available
> to the page.  There is also an effort in the CSS Images module to
> address spriting directly and make it generally useful in CSS, rather
> than only being useful in backgrounds.  Finally, the Media Fragments
> WG is developing a syntax (with a public draft already published) to
> allow addressing a portion of an image directly in the url identifying
> it, so as to make sprites generally available to all web technologies.
>
> The first and third approach listed apply in HTML as well as CSS, and
> would allow authors to use ordinary <img> tags (with alt text) while
> gaining the performance benefits of current spriting techniques.
>
> I don't believe layering another hack on top of the current
> background-image hack is the correct solution; rather, we should find
> ways to meet author's performance needs in a way that is more flexible
> and generally useful than current spriting techniques.
>
>   
>> Here’s one suggestion of how to address this issue.
>>
>> foreground-image:  Foreground images sit on top of background images, but
>> are otherwise identical.  They are semantically different, in that they are
>> images that are intended to be the only rendered representation of the
>> element.  Foreground images MUST NOT be disabled by assistive technology.
>>
>> foreground-image-high-contrast:  If this property is specified, this image
>> MUST replace the foreground image when the user agent is rendering in high
>> contrast mode, in response to operating system, browser, or assistive
>> technology settings.
>>
>> background-image-high-contrast:  If this property is specified, this image
>> MUST replace the background image when the user agent is rendering in high
>> contrast mode, in response to operating system, browser, or assistive
>> technology settings.
>>     
>
> High-contrast situations should be differentiated through Media
> Queries, I would think.  This would allow you to specify different
> background images, and also different values for any other property
> that requires tweaking.
>
> ~TJ
>
>
>   

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>