WCAG: Relative and Absolute Units

WCAG Accessibility Checkpoints

The WCAG (Web Content Accessibility Guidelines) 1.0, Priority 2 Checkpoint 3.4, states that you should:

Use relative rather than absolute units in markup language attribute values and style sheet property values

View the checkpoint

Originally I thought this meant that anywhere a font size, width or height was mentioned I only had the option of use ems or percentages. Then this seemed to be saying to me to design all sites using a liquid layout, which was strange as people were always saying that the guidelines do not dictate design.

I have since found out I wasn’t understanding what ‘relative unit’ meant.

Relative length units specify a length relative to another length property

Source: w3.org definition

So here are the relative units you may use:

  • em: the ‘font-size’ of the relevant font
  • ex: the ‘x-height’ of the relevant font
  • px: pixels, relative to the viewing device
  • %: percentage, relative to another value

Absolute units are as follows and should only be used when the sizes of the output are known – i.e. on a business card:

  • in: inches – 1 inch is equal to 2.54 centimeters.
  • cm: centimeters
  • mm: millimeters
  • pt: points – the points used by CSS2 are equal to 1/72th of an inch.
  • pc: picas – 1 pica is equal to 12 points.

Applying this to WCAG 2.0

This point doesn’t specifically appear in the new WCAG 2.0 guidelines but only “… maps to an advisory technique (Using readable fonts) for Guideline 1.4.”. This guideline contains both Level 2 and 3 Success Criteria which are explained more thoroughly in the Advisory Techniques for Guideline 1.4.

This advisory says you must make it easy to distinguish foreground information from its background. It appears that there will eventually be an advisory section called “Using readable fonts”, at present it shows as link pending.

I find it odd that this isn’t a ‘proper’ guideline, surely ensuring that a user can easily read the text on a page is something that a standards developer would do as soon as breathe!

Information Generalisation

Side Note: WCAG 1.0 was written 7 years ago in a time when the majority of users were surfing in HTML only and so quickly became out of date, they desperately needed to be re-written.

Today the web is used by so many more and different technologies that the new guidelines have been written to ensure that they are technology independent and to be as future-proof as possible.

Application of the (new) Guideline

When you apply the WCAG 2.0 advisory to your development work you need to think about the areas that this guideline could apply to. The basic ones here are:

  1. Ensure that text and background colours have been set and are of high enough contrast
  2. Ensure that non-decorative images have a suitably high contrast
  3. It can also apply to sounds on a page, for instance can the content of the clip be heard well enough over it’s background noise?

Hopefully these points will help to clarify how to apply the existing and future guideline.

Update 2006-06-26: Font sizes should still not be defined in pixels due to IE’s inability to resize text using these units.

Update 2006-07-12: I’m adding this in the interest of showing all sides of the story: The original author of this checkpoint has said that he wants an erratum added to it saying that pixels should be considered an absolute unit. Compared to the others it is relative to the user’s screen – instead of changing font size you have to change your display settings, which is too complicated for most users.

I propose that we also make an erratum to clarify that the units considered
“relative” in this checkpoint are those relative to the user’s font settings
– %, em, ex, but not px, pt, pc, in, mm, cm.

lists.w3.org

3 comments on “WCAG: Relative and Absolute Units”

  1. Dave Hyatt, formerly of the Mozilla Project and now lead developer with Apple’s Safari team, has been trying for several months now to educate people on this matter: http://webkit.org/blog/?p=57

    His point in that and earlier posts is (unless I have misunderstood him) that it’s the fault of browser manufacturers that they have traditionally mapped a CSS pixel to a screen pixel, with the result that people mistakenly believe them to be one and the same thing, even though the CSS spec has always avoided saying this.

    We don’t expect a CSS pixel to map to a device pixel when we send it to a 300dpi printer. Similarly, when we have 300dpi displays (and we will, maybe sooner than we expect), it would be crazy to expect a CSS pixel to map 1 to 1 to a device pixel. This is why the CSS spec defines a pixel in terms of the viewing angle subtended in the field of view of a user, relative to their distance from the display device.

    In my view, redefining a pixel as an absolute unit would be a retrograde step. When very high resolution displays become available, we would have lost the standard definition of how to relate CSS pixels to device pixels, apparently for the sake of making the formulation of one WCAG checkpoint a bit easier for somebody. I don’t believe such a forward-looking part of such a fundamental specification should be discarded because some people have difficulty getting their heads round it.

  2. The official definition of px as relative to the viewing device has no relevance to keeping text legible using CSS to style web pages. What the specs really need is a third category just for px. With neither CSS nor [X]HTML does any author have any clue how many px are available for him to work with, except in his own environment, where he knows only from outside means.

    There are only two uses for px: 1-making it easy for authors to create magazine pages for hosting on the web; and 2-making text too small for many visitors to read. The latter creates a needless accessibility problem. Px isn’t needed at all. Consequently, CSS3 should deprecate the use of px, if not drop it entirely, and not just for font sizing.

Add your comment

Your email address will not be published. Required fields are marked *