Joe Dolson: Accessible Web Design

Hat tip to John Rhodes of WebWord.

Sitepoint has recently released their Usability Kit, first edition: a binder containing 400 pages of documentation (usability evaluation and design techniques, forms, templates, blueprints, etc.), a CD-ROM containing digital versions of the contents, and a complete set of “Magnetic Web Widgets” (while stocks last.)

At $197, this isn’t precisely a “cheap” guide to usability: but hey — you get magnets.

Actually, if you’re going to buy this, I’d suggest buying it soon. The free magnetic web widgets could be a great tool for playing with different layout concepts and ideas. Certainly for myself, as a non-artist, being able to throw together alternate layouts very quickly would be nice. You can design your new sites on the fridge!

Judging from the sample download, I’d agree that it’s well-written and worthwhile. Granted, there are dozens of freely available resources for usability out there: but this compilation of documents might make for a great reference. If you’ve got $197 to burn, buy it (at least for the magnets).

On a day to day basis, I deal with W3C standards. However, there are certainly sets of standards (or guidelines) outside of the W3C which are good to be aware of. Thanks to Kim Krause Berg, I’m now aware of another document: Research-Based Web Design and Usability Guidelines, courtesy of the United States Government.

One of the keys which makes this worth noting is those two first little words: “Research-Based”. There’s nothing better than research (and user testing) to provide you with a better idea of how your ideas will go together.

From the foreword, by Dr. Ben Shneiderman:

Guidelines should be more than one person’s lightly-considered opinion, but they are not rigid standards that can form the basis of a contract or a lawsuit. Guidelines are not a comprehensive academic theory that has strong predictive value, rather they should be prescriptive, in the sense that they prescribe practice with useful sets of DOs and DON’Ts. Guidelines should be presented with justifications and examples.

Download it, read it, and absorb it.

Part of building an accessible website is making meaningful choices in the code you use to markup your content. In some cases, this is a very easy decision: <p> descrbes a paragraph, <blockquote> describes a blocked quote, and <acronym> describes an acronym. No problems.

But some issues are more complex: take the calendar. What is the logical structure of a calendar? Is it tabular data? Is it an ordered list? Is it a definition list? All of these are completely reasonable and logically justifiable structures for a calendar: how do you pick?

Tabular Calendar Structure

In a table structure, the columns represent days of the week, rows represent the week number of the month or year. In practical use, weeks of the year are rarely applied. The Vienna (Austria) transit system uses them: buying a weekly pass gives you transit access for that specific week of the year, but I’ve rarely seen them in other applications. Weeks of the month, however, are in frequent use: Thanksgiving is always the fourth Thursday in November, Election Day is the second Tuesday in November.

So, the tabular structure is reasonably well justified. Colloquial language does actually use those data references for the information, so, if appropriately marked up, this seems reasonable. It’s not perfect, however: the layout inevitably means that either the table will inevitably contain data for a previous month, or will contain empty cells. Not the end of the world; but imperfect.

Ordered List Structure

Time is, for most people, a pretty linear experience. As such, dates can very reasonably be structured sequentially. Again, only really usable for single month length calendars, as the numbering must repeat otherwise, but reasonable. This is certainly a data structure in normal use: the 22nd day of October, etc. The list itself could be labeled with the month, each day would be a list item. In addition, the days of the month would be automatically numerically labeled appropriately. Additional data for the day could conceivably be contained in a nested list.

This layout is a less common look for print calendars; so users are likely to be less familiar with it. However, it’s certainly a reasonable approach.

Definition List Structure

The days of a month can be described as the definition of that month: February is a month containing these 28 days. Each day, furthermore, can be defined by the events of the day. From a structural perspective, this is significantly similar to the ordered list approach. Definition lists do have one advantage, however: each list item has an independent definition. Although not necessary for a basic calendar, these could be useful for an events calendar.

I tend to feel that a definition list stretches the semantic association a bit too far: although a <dl> can be applied for a calendar, and with some justification, it seems to stretch a bit beyond the fundamental meaning of a list of definitions.

Conclusion?

Ultimately, there is no one structure which is perfectly suited for a calendar. Dates are referenced and used in a significant number of ways: the visual layout should generally be that of a table, because this is what most users are familiar with. Usability would certainly suggest that familiarity should carry some weight.

My own tendency is to use tables. That is the visual layout I want; and I see a very reasonable justification for the semantics. I don’t believe there are any major hurdles to accessibility, as long as the table has been appropriately designed.

Numerous articles in the last few days have suggested serious problems in either defining web accessibility or in the way it’s handled. Trenton Moss considers the future of accessibility. Alastair Campbell follows up with his own opinions. Gez Lemon and Mike Cherim co-published an article outlining two supposedly opposing views of accessibility at Accessites. Roger Johansson chimed in with his reasoning for universality. And, to cap if off, Mike Davies wrote an excellent (if possibly inflammatory) four-part series declaring Accessibility in Trouble.

All of these articles seem to revolve around two central points: whether web accessibility is about people with disabilities or whether it’s about universal access, and whether more advanced technologies (such as AJAX or Flash) are acceptable for use in accessible web design. These aren’t entirely separate issues: the whole universe of web accessibility is tightly entwined with the use of technology.

Who is Web Accessibility For?

First and foremost, web accessibility is about users with disabilities. It’s my firm opinion that the first goal of an accessible website is to ensure that users who, for whatever reason, are unable to make use of a website using standard user agents and settings, are able to use the website. This includes, amongst many other techniques:

• Providing for screen readers through alt texts, image long descriptions, and appropriate labels
• Using an acceptable default color contrast
• Using acceptable typography and providing the ability to alter text size (through browser settings or website settings)
• Providing appropriate link texts and explanatory information for acronyms and abbreviations.
• Avoid the creation of any access barriers requiring specific knowledge or abilities.

These are the first priorities: they make a website usable (in the sense of “possible to use”) by disabled visitors. A second priority is in making the site easy to use. Is this accessibility? Web accessibility is commonly defined according to the principles espoused in the WCAG. However, this debate seems to reach out more broadly. From a policy perspective, web accessibility means following the WCAG guidelines. But from a logical perspective, some of these guidelines are actually about making a website easier to use for visitors with disabilities. Usability is not identical to accessibility: it supplements accessibility.

Take, for example, the provision of WCAG 2.0 calling for skiplinks:

Blocks of repeated material, such as navigation menus and document headers, are marked up so that they can be bypassed by people who use assistive technology or who navigate via keyboard or keyboard interface. [V]

WCAG 2.0 Guideline 2.4

Bypassing a menu is not precisely an issue of accessibility: it’s an issue of ease of use. I’d say that this is the challenge of making the experience of a disabled user better, rather than possible. Is it any less important? Absolutely not. On the same grounds, I’d argue that any use of technology which improves the user experience is an acceptable part of accessibility.

One key with accessibility is to add features without ever subtracting from the overall accessibility. Many, many accessibility experts will recommend consistently against the use of AJAX, JavaScript, and Flash because these technologies have accessibility problems. I won’t argue against this: these technologies DO have accessibility problems. Are they inherent? Not really. It’s entirely possible to construct highly usable, accessible websites using these technologies: it does, however, take a very high level of knowledge to do it. I won’t do it. It’s not because I am fundamentally opposed to the use of advanced technologies, I’m just opposed to my own use of them. It would be a massive disservice for me to build anybody a Flash or JavaScript heavy website. I don’t yet have the breadth of experience to work effectively with these technologies.

For me, I will continue to recommend against them while consulting, unless the client is also willing to support extensive user testing: the only truly effective way to guarantee accessibility.

Universal or Accessible?

In Part 3 of his article series, Mike Davies states:

The position of disallowing technologies such as Flash stands quite contrary to providing accessible content. Here the goals of universality are conflicting with web accessibility.

Web accessibility has always been about reaching out to disabled people - using what we have at our disposal: technology and technique. Starting with an accessible website, and ripping out the Flash (because there’s no Flash plugin for Lynx) is a step backwards for web accessibility. And yet, this is what zealots want you to do.

Its very reminiscent of the tools that create a text-only version of a website - by stripping out the images and multimedia. Both the concept and the process do more to hinder the accessibility of a website.

He’s got a great point: universality and accessibility are NOT the same thing. Universality, though an acceptable goal, is measurable only in device specific terms. Accessibility is only measurable in human specific terms. The challenge for an accessible web developer, however, is in finding an appropriate balance. Let’s be honest: how many of us really do extensive user testing? I don’t. My clients usually can’t afford it, or won’t spring for it if they can. I would love to be able to, but for now, it’s not a practical approach for me. That simple fact renders Flash an unsupportable candidate for my own development. And, I’ll opine brashly, it should also leave it unacceptable for anybody else who isn’t doing user testing.

I’m not speaking against Flash explicitly: I’m simply saying that accessible Flash is a relatively untested field. It’s not impossible, and for the knowledgeable it’s probably not even all that difficult. (For more about accessibility recommendations for Flash, you may want to read Bob Regan’s 2005 white paper on the subject.)

What Does Accessibility Need?

Well, obviously, more user testing is always called for. What I’d love to see, although I’m not capable of putting it together myself, would be a full scale accessibility study of Flash and AJAX websites which have been specifically designed with accessibility in mind. User testing, limitations, the whole banana. Accessibility needs better awareness of using Flash. AJAX has received a fair amount of attention: articles from Standards-Schmandards, WebAIM, WebStandards.org, and many others have given developers a fair shot at addressing the limitations and possibilities in AJAX accessibility. Flash has been almost entirely disregarded by the web standards and accessibility community. I’d like to see it given an equal chance.

Accessibility does not, however, need a particular agreement on who accessibility needs to serve. At least, not an agreement which refines between “disabled” and “everybody”. In my opinion, a lot of this trouble in defining web accessibility comes from petty bickering on terminology. Fine, some people define accessibility as providing for users with disabilities. Others call it providing for all users, regardless of abilities. Perhaps the second group is better defined as providing universal websites; but I can’t bring myself to be too concerned. Both camps agree without hesitation that they need to provide access for users with disabilities.

Universal web designers won’t use Flash under any circumstances, because it isn’t supportable in some rare browsers (Lynx, for example.). Fine. Does this reduce the accessibility (for disabled users) of their work? I don’t think so: it merely limits the tools they’ll work in. I find it hard to support Mike Davies’ claim that:

If zealots have their way, websites would only use HTML, with an optional CSS for presentation. And yet, this combination of technologies is inaccessible to certain groups of disabled people - certain groups that can be reached with Flash and JavaScript.

I can’t help but be curious exactly what groups of disabled people can be reached with Flash and JavaScript, but not with HTML and CSS. I’ve sat here and tried to imagine that situation; but have had only limited success. I’m imagining individuals with ADD not being capable of sitting still long enough to read a text document; but that’s a problem correctable through content changes. I would love to know what user group cannot be reached using standards-based HTML.

Just in the last few days I’ve been struggling with a design which just wouldn’t quite work the way I wanted. A somewhat unusual layout - four columns, fluid. The problem has been in finding proportions which are successful across the whole spectrum of widths - from 800 pixels to my own 1600 pixel monster. Imagine my good cheer when Cameron Moll writes up two successive posts which directly relate to my problem! Thanks, Cameron!

In fact, believe it or not, this wasn’t a personal favor - just a coincidence. Funny, but I guess the fact that I don’t know Cameron actually reduces the likelihood he was reading my mind.

The first post was on a fairly straightforward question about optimizing design width for 1024px resolution. Now, this doesn’t directly bear on my struggle, since I’m not creating a fixed width design. However, it does raise one important question: do we need to use the entire width of the screen?

That was one of the biggest problems I had: at extremes, the layout just looked crummy. It worked; you couldn’t say that it fell apart, but it didn’t look right. But why use those extremes? Oh, yes…because IE6 doesn’t support min-width and max-width. (IE7 may not be perfect, but it sure is an improvement.)

So I picked a max-width: it may not be relevant in every browser right now, but it should age well.

The second article was also quite interesting: Should all sites be fluid?. Ah…tough one. "Should" is a difficult question. How to address it? The original article and comments attached to it are largely considering the question from a designer or publisher’s perspective: but I want to think about the user’s experience. Are there actually sites which can benefit the user by using a fixed layout?

So…that’s a question I can’t answer.

I’m trying to think of a concrete reason that a fixed width would be advantageous for a site. I can see how a poorly-designed fluid site would be a problem; but I’m going to operate on the assumption that we’re only talking about fluid designs which don’t have obnoxious problems such as text being covered at very small widths, etc.

Neither Cameron’s original post nor any of the comments name a specific reason that a fixed layout is better. There are plenty of reasons why one might choose to develop a fixed layout inside of fluid - and I’m certainly not disputing that there are perfectly good reasons to develop fixed layouts. Faster development and testing is pretty clearly advantageous where budgets are concerned. But these are advantages to the development team and to the company paying for the work: not for the user.

John Dilworth makes an interesting comment:

Do I want and need the user to control that part of the experience? Or, does the designer need to control that part of the experience?

Are there situations where designer control trumps the user’s choice? John’s point is that there are content-oriented sites which may benefit from designer control of the text. But I don’t see how this plays to the advantage of the user. The designer can’t determine that he will automatically provide short line lengths to users who prefer it and long lines to others. Only the user can actually make this decision.

Mark Boulton talks about how proportion is a key element of a design, and one of the big problems designers have in creating flexible designs is the loss of control on proportion. Your design ceases to be a unit and becomes a spectrum. What he would like to see (and I don’t argue) is the ability to expand the proportions along with the canvas. This is a problem with em based designs - although the view expands effectively when the text size is increased, the size of the viewport is ignored. Finding an effective way to combine text-based sizing with viewport would be highly valuable, and perhaps would encourage designers to pursue fluid designs.

Regardless, there’s nothing conclusive which indicates that a fixed design has user benefits. It appears to have significant advantages from the perspective of designers, but less certain from the user perspective.

If anybody can suggest a good reason - for users - that a website design should be fixed, I’m very curious to hear it.

And no neutering jokes, please.

One of the biggest annoyances I ever see in a website’s source code is layers upon layers of complexity. 20 nested <table>s, 30 nested <div>s - what’s the difference? Building a consistent and semantic website isn’t just an issue of whether or not you’re using valid code or mistreating a poor table by filling it with non-tabular data - it’s a question of whether you’re using logic to decide what element should be used to represent your content.

How deeply does a piece of information actually need to be buried in your document? Well, optimally (and arbitrarily), no more than 7 layers:

Read more: Keep it Simple, Stupid

A couple days ago, Roger Johansson published a complaint about the problems he’d been encountering recently with light text on dark backgrounds. It’s an interesting subject - is there a distinct usability difference between dark text on light versus light text on dark? For Roger, there’s no question - light text causes pain. If it hurts, it’s not going to happen. But how general is this kind of problem?

Roger points out an interesting quote from designer Mark Boulton specifying how to deal with reversed color schemes and text. However, Mark hasn’t provided a concrete usability-related reason for his reasoning.

When reversing colour out, eg white text on black, make sure you increase the leading, tracking and decrease your font-weight. This applies to all widths of Measure. White text on a black background is a higher contrast to the opposite, so the letterforms need to be wider apart, lighter in weight and have more space between the lines.

Mark Boulton

Are these designs with inverted white on black more difficult to read because they haven’t followed this rule, or because white on black is inherently less readable?

There are studies on the readability of various color contrasts, which generally demonstrate that dark colored text on lighter backgrounds are easier to read. However, I’ve been unable to locate a study which also considered more complex design considerations such as the kerning or specific color contrast of the text - which certainly must play a role. A study by Dr. Lauren Scharff and student Alyson Hill (more information) of Stephen F. Austin State University shows the expected results - black text on a white background is the best rated combination for readability:

…the most readable color combination is black text on white background; overall, there is a stronger preference for any combination containing black. The two least readable combinations were red on green and fuchsia on blue. White on blue and red on yellow were ranked fairly high, while green on yellow and white on fuchsia were ranked fairly low. All others fell somewhere between these extremes.

Also, in every color combination surveyed, the darker text on a lighter background was rated more readable than its inverse (e.g. blue text on white background ranked higher then white text on blue background).

Following these initial findings, the study continued to perform a more complex examination of the question including considerations of font style and font face - however, the choice of color combinations did not include any reverse pairings, so this second examination doesn’t provide any useful information.

A second study, at the Adaptive Technology Resource Centre of the University of Toronto, approaches the question in a more rigorous manner. This study uses algorithmic measurements of contrast and hue to determine whether text should have high readability. The study considered the difference between a bright text on dim background and mapped the results to discern whether there was any apparent benefit to one or the other:

In order to assess whether the direction of the brightness difference (i.e. bright text on dim background vs. dim text on bright background) is of any importance in determining readability ratings, brightness difference was calculated as the difference between background and text brightness. In the case where the background was brighter than the text, this difference was found to be positive. For those images in which the text was brighter than the background, this difference was negative. The brightness difference was then plotted against the median rating, and yielded a ‘U-shaped’ plot, shown in Figure 6 (below). This plot suggests that the direction of the brightness difference does not appear to be of importance in determining overall readability ratings.

 [D]

The suggestion at this point is that a preference for one or the other is predominantly related to personal preference. It’s an interesting issue, however - I, for one, certainly have a strong preference for dark text on a light background. Anybody else?