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

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:

• If I use pixel sizes for the default font, but offer several ways to override the initial font setting, have I sufficiently fulfilled my duties as an accessible web designer?
• Checkpoint 10.1 of the Web Content Accessibility Guidelines states, Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. Does that mean I no longer have to warn users about pop-up windows?
• If I utilize all the accessibility options in Flash, is it still my fault that a user can’t access my content because they don’t have the right version of the browser, plug-in, or screen reader?

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.