- From: Sean Hayes <Sean.Hayes@microsoft.com>
- Date: Fri, 9 Mar 2007 14:17:19 +0000
- To: Gregg Vanderheiden <gv@trace.wisc.edu>, 'WCAG-WG' <w3c-wai-gl@w3.org>
- Message-ID: <7261AC2A5F73904CA41773C8F00813FF1C670A2F@EA-EXMSG-C309.europe.corp.microsoft.co>
GV: 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? Sean: Yes, I'd have to agree, contrast is notoriously difficult to measure. When you try to come up with a general method which is going to work across all web technologies I think you are on a losing wicket. Which is why previously I have tried to argue for a more functional approach based on whether the content could be used by individuals who have been assesed under clinical conditions to have atypical sight. Not that the content has to necessarily be tested by such individuals (although clearly that is the best approach), but that (with high inter-rater opinion) it could be. 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. Sean: HTML and similar technologies are too fluid to consider there being a single "author defined presentation", there are many things that cause text to move wrt. its background, scrolling, resizing the viewport etc. - is the author relieved from responsibility when these happen? I'd guess you'd say not, but then it outlaws any scrolling container with a border. 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. Sean: I'm more worried about the text moving about in front of the background. If you have to take worst case scenario's this is going to be almost impossible to meet in even fairly pedestrian and perfectly accessible content. GV: If you do not specify the font or background color then you automatically pass. Sean: But you are specifying the colors - you are just using symbolic names. You have to use these symbols correctly. It has been pointed out that CSS3 deprecates system colors, but its been in CR since 2003. It also allows opacity in all colours, which completely screws your formula. 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. Sean: What is typical for 'cursive', and in which browser? Plus you have the issue of fallback fonts. I don't think this is good enough. GV: I believe those can all be converted as necessary using standard formalae. Could they not? Sean: Unfortunately no, there is no single conversion method between two spaces; there are many - depending on what aspects you are trying to preserve, each of which is applicable in different circumstances. 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. Sean: The issue is how you find the poorest point given that it is not predictable which part of the text is in front of which part of the background. It is also unreasonable if the poorest point is a single pixel which has no bearing on readability; especially since HTML is not a predictable pixel perfect output mechanism - your content may pass on FF and fail on IE, or vice versa. 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. Sean: Repeating pattern, but not repeating colours in the pattern; e.g if it is dithering a gradient or image. The average colour you get is dependant on the center and radius of the averaging circle. If you are talking about text dithered onto a dithered image, you can't 'move over'; if you move the sample point you are not measuring the contrast ratio around the text but something else. GV: you don't need to calculate to every point in time. Just to the minimum contrast. Sean: Whch is when? If the output is being calculated algorithmically you may never know if you have seen all the boundary cases. Sorry to be a pain about this, as I do believe that high contrast modes are valuable to end users and we need to find a way to ensure they are available; I just don't believe we will come up with a single defensible test that we can write down which will actually be effective. Sean Hayes Standards and Policy Team Accessible Technology Group Microsoft Phone: mob +44 7977 455002 office +44 117 9719730 ________________________________ From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: 09 March 2007 05:30 To: Sean Hayes; 'WCAG-WG' Subject: RE: A few issues with the proposed definition of contrast 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 14:18:00 UTC