- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Thu, 8 Mar 2007 23:30:18 -0600
- To: "'Sean Hayes'" <Sean.Hayes@microsoft.com>, "'WCAG-WG'" <w3c-wai-gl@w3.org>
- Message-ID: <005b01c7620c$08778a50$0f6fa8c0@NC84301>
Hi Sean Good questions Let me walk your questions as best I can. First, many of these comments don't have to do with the proposal per se. They are generic questions about background that would apply to any contrast measurement I believe. Would you agree? My comments below are marked GV: Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. > -----Original Message----- > From: w3c-wai-gl-request@w3.org > [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Sean Hayes > Sent: Thursday, March 08, 2007 5:44 PM > To: WCAG-WG > Subject: A few issues with the proposed definition of contrast > > > Following up from our call, I thought I'd jot down a few of > the issues around the proposed contrast provision. > > > HTML and CSS issues. > > Definition of background: > In CSS the definition of background of an element > refers to the background of the content, padding and border > areas, each of which can have a different color, be > transparent or be an image with some opacity. In addition it > is possible for text and images to abut, or overlap with > border areas and to overflow outside of these areas. > > So does the "background of text" mean background in > the more limited css sense, or in the more general, "what the > strokes of the glyph are drawn over in a specific rendering", sense? > GV: The background would be what is immediately surrounding the letter in the author defined presentation. It the user scales the font or changes the background etc, then the author is not responsible under this guideline. There is an L3 SC that addresses font scaling but not this one. > Images: > > background-repeat may cause different strokes of the > text to abut against different areas of the background > depending on the size of the container and the size of the font. > background-attachment = scroll/fixed can cause the > background image to change with respect to the text in front > of it as the user scrolls the window. > > The use of opacity in an image applied to content, > padding and border, means computing a colour from the product > of these three rectangles, as well as the elements behind the > element. This number is not exposed by browsers; and may > change with layout changes - including simple scrolling of the text. > GV: Yes all this is true. The author should not have a background image moving about behind the text that would not be different enough from the text to have the required contrast. If the position cannot be determined then the most similar part of the image could be used for the contrast measurement. Remember this is an L2 provision. > Color: > The definition is not testable with the use of system > colors, since we don't know what the colors actually are. > GV: If you do not specify the font or background color then you automatically pass. It would then be up to the user to use a browser/user agent that provides good contrast for default > Font: > The clause for relaxing to 3:1 is based on font but > the selection of font may be by the browser, so the height > and stem width may not be known. > GV: If you are using default fonts then assuming what is typical (e.g. for the ratio of font size for H1 vs body text) can be used. It would then be up to the user to use a browser/user agent that does not use fonts smaller than typical. > > General content issues: > > Although HTML and CSS use sRGB, other content may not > - for example many JPG images from digital cameras use > AdobeRGB which has a different gamut, and so we need to > define the mapping from other colour spaces into sRGB. Some > material may be in colour separated CMYK, or Duotone forms. GV: I believe those can all be converted as necessary using standard formalae. Could they not? > > In general content it is possible to use richer text > effects, such as text which is stroked and/or filled with > gradients and images. The same issues of relative movement, > e.g. due to scrolling would then apply. GV: I understand rich text effects. You would measure the poorest point. I do not understand scrolling as it would relate to rich text effects. > > The 'averaging' technique for use with dithered > backgrounds does not define the width or shape of the > averaging window; or how to deal with text strokes that fall > within the averaging window. GV: dithering uses a repeating pattern. You can pick an area sufficient to find the average value and use it. if you encounter a text stroke, move over til you don't. > > Text and vector graphics in Flash moves of its own > volition - and thus calculating contrast is time dependant. > GV: you don't need to calculate to every point in time. Just to the minimum contrast. > > > > > > > > > Sean Hayes > Standards and Policy Team > Accessible Technology Group > Microsoft > Phone: > mob +44 7977 455002 > office +44 117 9719730 > >
Received on Friday, 9 March 2007 05:30:38 UTC