Thread Subject: Re: Action Item - default contrast

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Sean Hayes
Date: Wed, Dec 20 2006 8:05 AM

To follow up on last weeks conversation, here are some thoughts on issues I have been encountering with regard to a testable contrast ratio.

In a previous thread, we considered that there is a chain of components which are required to deliver a given contrast ratio. 1) The source encoding, 2) The platform software and hardware to run it on and 3) The viewing environment. All of these have to be set up properly for the user to perceive 'sufficient contrast'.

We have to decide which parts of this delivery chain 508 wants to address; but there are problems with all of them. In this post I'm only going to deal with the content, which appears at first the easiest to test, since in theory it is testable algorithmically; and the WCAG guidelines are geared to the legibility of text in HTML/CSS content where the choice of colours is seemingly explicit and limited.

However the draft WCAG guidelines do not in fact limit which pairs of colours to test. because we need to consider the CSS box model; foreground and background colours may be applied to the border, padding and content rectangles. Text may stretch across all of these, and also across the margin area and beyond - which means it can appear over any element rendered below the container.

Thus, depending on the layout, which is in turn dependant on the size of the browser window at the time of layout, text may potentially be rendered over any other colour in the presentation - including images (and theoretically over time varying content like video or applets too). Thus any algorithmic test will have to consider the product of all the possible text colours against all the possible background colours (which includes all other text foreground colours).

If we than consider CSS 3 or PNG's, where translucent colours are allowed, life gets even harder, since the final possible background colour set is not in fact determined until layout time.

Whats more perception of contrast is affected by several other factors of the content, including spatial frequency; immediately adjacent colours and ambient colours. In HTML each of these factors is potentially time varying; as well as being dependant on layout. Some of them - such as spatial frequency are also browser dependant as CSS allows selection of abstract widths as 'thin', 'medium' or 'thick', and system colours such as 'Background' and 'ButtonText'. In other content such as PDF, Flash and so on, the authored colours are not readily apparent in the delivered form, making any kind of objective test of the content require access to the source code.

Any complete pairwise test inevitably means that every colour will need to be tested against itself - by definition no content can pass this test.

To limit the pairs of choices, we need to make assumptions about how the content is rendered, which would either mean unacceptable definitions of standard renderer, standard platforms and so on, or to restrict content authoring such that text can only appear on the content rectangle, and outlaw for text and content boxes the use of transparency, semi opacity, image backgrounds and most of the other CSS tricks which designers love.

This latter case may be a possibility for a selectable 'high visibility' mode, but is probably not acceptable for default authoring.


Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University