User Responsibility for Web Accessibility (or “Gimme back my pixel font sizes!”)

Proof of concept.

Pixels. Who needs them? Web designers.

Well, maybe “need” is too strong a word. How about “want?” It’s not about the pixels though, it’s about graphic control. Designers want control. We always have, we always will, and we have good reason to. So what’s wrong with pixel-sized fonts? “Accessibility” you say? Maybe...

The problem with pixels

The Web, in its infancy, had no interest in design. The Web was created by scientists: software and hardware engineers, not graphic artists. The Web had no need for font control. The Web was purely a medium for the exchange of information.

As the medium grew, designers began to gain certain amounts of control. Among other things, the HTML specification included a font element that gave designers the ability to control the color, size, and type family of text on web pages... But this was far from level of control designers wanted.

Enter Cascading Style Sheets

Cascading Style Sheets (CSS) were created to solve two problems: 1) Web designers still didn’t have full control over the visual layout of web sites, and 2) all the presentational markup (font, bold, etc.) conceded to those designers was enlarging the size and degrading the data quality of web documents. An in-depth discussion of CSS is beyond the scope of this document, but, suffice it to say, CSS is a good thing.

Since the introduction of Cascading Style Sheets, pixels have been the most consistent unit for specifying font sizes. User settings made point sizes vary from screen to screen, browser vendors chose different interpretation of the relative size units (em and percent), but a pixel was still a pixel on any screen. Because web graphics are sized in pixels too, pixel font sizes could match up with their graphics. Finally, designers had some semblance of control over web design.

Enter the Web Content Accessibility Guidelines

The Web Content Accessibility Guidelines (WCAG) were written to ensure that disabled Internet users would be able to access web content. Vision-impaired, mobility-impaired, hearing-impaired, and other disabled users have certain needs that were addressed by these guidelines.

The WCAG stated that information published on the web should be accessible to users with a variety of needs and internet-enabled devices. The WCAG also gave key examples and recommendations for accessible web technology. For example, HTML authors should associate form inputs with labels for the vision-impaired, and multimedia authors should caption video and transcribe audio for the hearing-impaired. These recommendations are essential for the provision of equivalent access to the disabled and most of the recommendations also benefit non-disabled users.

The recommendation I’ve chosen to use for this example is the issue of pixel-sized fonts.

Checkpoint 3.4 of the WCAG states, Use relative rather than absolute units in markup language attribute values and style sheet property values. Accessibility experts usually interpret this recommendation to mean that pixels are never acceptable for font size. Here is why. Most Accessible Technology (AT) software is designed for the Microsoft Windows Operating System, so the vast majority of disabled computer users still use Windows. Using pixel units (px) for web fonts is discouraged because users of Internet Explorer for Microsoft Windows do not have an easy way to resize their screen text. This problem affects a group of vision-impaired users with a disability commonly known as “low-vision.” This problem also affects non-disabled users who have a preference for larger screen fonts.

Enter the modern web browser

There are many modern standards-compliant web browsers available today. Browsers such as Mozilla Firefox, Opera, and Safari are available for free download and give web surfers much more control over their browsing experience than the Microsoft counterpart. Even so, Internet Explorer offers a wide range of customizable features for accessibility.

But what if the web site’s disabled audience doesn’t know how to customize their browser? What if a certain screen reader does not work well with a certain browser? As web designers, developers, and content creators, how is that our fault?

At what point does accessibility become the user’s responsibility?

Despite the introduction, this argument is not about pixel-sized fonts. It could have easily been about pop-up windows or the use of Macromedia Flash on a web site. The point of the argument is this:

If we use several accessibility techniques to “enable” a disabled user, at what point do we put the responsibility for access on the user, and not the designer or developer? How far is far enough?

Consider these questions:

I am participating in a SXSW Interactive 2004 discussion panel entitled Web Navigation Without a Guide Dog. This is one argument I will pose to the group... I am not expecting a final answer; I just wanted to present a designer’s point of view on accessibility and leave it open for discussion. I will post follow-up notes sometime after the panel eventually.

Skip to the proof of concept.

Proof of concept

Larger text?

Even without the “larger text” link, this page is accessible to low-vision users because there are several other ways to change the pixel-sized fonts to better suit the user’s needs:

  1. User style sheets.
    The user can override the font size with a user style sheet.
  2. Get a better browser.
    Most modern browsers, save one (Internet Explorer for Windows), will let the user scale the font-size even if it is specified in pixels.
  3. Change browser prefs.
    For users that are stuck with Internet Explorer for Windows, there is an accessibility option entitled, “ignore font sizes specified on web pages.”
  4. Alternate style sheets.
    There is an alternate stylesheet specified in the HTML source. Many modern standards-compliant browsers allow use of alternate style sheets.
  5. Use a server-side switch.
    A web page author can provide a server-side method for changing style preferences, such as the “larger text” link used above.

In this case, low-vision users refers to vision-impaired users who do not use screen readers. I realize that some low-vision users still use screen readers, but this demo is specifically referring to users who do not. The reason pixel-sized fonts were originally discouraged was because of this group of low-vision users.

This user style sheet method assumes that the author style sheet has been set up correctly. If you view the pixel-sized style sheet, you’ll notice I used a pixel unit on the body element, but used em units on everything else.