W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [css3-images] [Fwd: RE: CSS Image Values and Replaced Content Module Level 3 - very brief review]

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 14 Mar 2012 14:31:35 -0700
Message-ID: <CAAWBYDDewajUTqBorhKz7pfkQ0_=eraANfjAPM1hL1NbPdhLMQ@mail.gmail.com>
To: Michael Cooper <cooper@w3.org>
Cc: CSS WG <www-style@w3.org>, WAI PFWG <w3c-wai-pf@w3.org>, WAI XTech <wai-xtech@w3.org>, WAI Liaison <wai-liaison@w3.org>
On Wed, Mar 14, 2012 at 1:24 PM, Michael Cooper <cooper@w3.org> wrote:
> Below is some unvetted review by members of PFWG of CSS Image Values and
> Replaced Content Module Level 3
> http://www.w3.org/TR/2012/WD-css3-images-20120112/. We appreciate your
> accommodating us on a review extension but unfortunately were not able to
> process a full group review on time. The comments below were proposed by
> members of the group and we decided it was best to send you this as is
> sooner than a full formal review later.
>
> -------- Original Message --------
>
> I gave this a brief review and while the overall concept of image
> replacement is widely abused I couldn't find much in this spec to
> specifically comment about.
>
> I agree.  This spec deals with ways to reference and create images.  The
> primary issue with CSS images is that there is no concept of a
> foreground-image, which seems to be outside the scope of this spec.
>
> 3.3 Using Elements as Images
>
> A note should probably be added here to note that the element referenced
> will contain none of the structural content of the element which is
> referenced. It should note that while there are uses for this technique
> there are also many places where using this will result in accessibility
> issues.

Added a note: "Note that the ''element()'' function only reproduces
the <em>appearance</em> of the referenced element, not the actual
content and its structure.  Authors should only use this for
decorative purposes, and must not use ''element()'' to reproduce an
element with significant content across the page.  Instead, just
insert multiple copies of the element into the document."


> EXAMPLE 8
>
>
> This example does not meet accessibility requirements. When background
> images are disabled the next/previous buttons will no longer be visible.
> Also - there is no text alternative provided for screen reader users. The
> example should be refined so it meets all accessibility requirements.

Good idea.  I tried to minimize markup in this example, as it was
already huge, and so didn't give a lot of attention to the a11y stuff
I normally would have.  Done.


> the example also suggests using click handlers to make the previews
> navigable.  These should be links, or at least use ARIA with the click
> handlers.

Changed to links.


> EXAMPLE 11
>
> It should probably be stated that this silly example would result in
> accessibility issues. Normally, anywhere text appears in a background image
> is a problem.

This seems covered by the note added above, and it's a non-realistic
example in the first place just meant to illustrate the functionality
in the most trivial and obvious way possible, so I haven't added
anything.


> 4. Gradients
>
> It should probably be stated that gradients can cause subtle issues with
> maintaining a sufficient luminosity contrast ratio between the text and its
> background. (an informative note about making sure to meet WCAG2 1.4.3 is
> probably good)

How is this any different from the generic situation with background
colors/images and contrast?  I haven't added anything about this.


> it might also be a good idea to advise against animating repeating radial
> gradients, as they may cause flashing and seizure issues.

Gradients can't yet be animated, so I haven't added anything about this.

Please let me know if this response was acceptable.

~TJ
Received on Wednesday, 14 March 2012 21:32:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:51 GMT