Although I’m not a lawyer, I do pay some attention to the nature of legal issues surrounding web accessibility. They’re murky, but this article attempts to shed some light on how the law covers accessibility issues on the internet.

Hope you’re able to get some value out of the article!

Copyright 2004 – 2008 Joseph C Dolson

New Column at Practical eCommerce: Accessibility and the Law

It does, however, intimate one of my pet peeves in documents promoting web accessibility:

Hey good lookin’

“But accessibility always compromises the design, doesn’t it?”

Wrong. Your site can still look beautiful.

This doesn’t precisely say that compromise is not required for accessibility; but it’s certainly implied by the language chosen.

To suggest that compromise is not required is simply a mis-representation of the truth about accessible web design: you do have to make compromises. Whether they’re compromises concerning how information is presented, the color contrast between elements, the specific uses of language or technology, you have to make compromises.

The perception seems to be that making compromises for accessibility means that you create an unattractive web site or otherwise decrease the aesthetic value of your web creation. This is not true: but it’s inaccurate to say that you don’t make compromises.

Truth: Effective accessible design has requirements which will require compromise in many areas.

It’s important to educate all participants in a web design project on accessibility before any serious work is done, to help prevent problems. If the designer knows to check contrast levels before proposing a design, they’ll start by creating an aesthetically elegant design with the color palette available. If they aren’t aware of these problems, you’ll end up making compromises on colors — and, without extensive modifications, it is entirely possible that these compromises could have a damaging effect on the aesthetics of the site.

Compromise shouldn’t damage aesthetics or accessibility: but poor planning almost certainly will.

Copyright 2004 – 2008 Joseph C Dolson

Making compromises for accessibility

Wouldn’t have thought I had that much to say on the subject of being robust, but there you have it. Enjoy!

Copyright 2004 – 2008 Joseph C Dolson

Installment No. 4 at Practical eCommerce: Robust Websites

President Barack Obama’s approach to information transparency is admirable. His connection to the public through the major media channels of the digital age: the White House web site, Facebook, Twitter, YouTube, and other social media methods is impressive. It’s a great way for the public to keep up to date on the activities of their government.

Unfortunately, the accessibility level of these web resources is — all in all — not really up to the levels one would hope for.

Obviously, the government has no control over the accessibility of the external resources they’re using to help promote their agenda and communicate with the public. These social media sharing sites are what they are, and regardless of their independent accessibility levels, I agree with the administrations choice to use them — to connect with their strong user bases — rather than attempt to build an expensive and potentially abandoned project to imitate the functionality.

However, the government does have direct and complete control over their own web presences, and would truly have wished to see a more thorough approach to web accessibility from the extensive network of new information-bearing web sites created by the Obama administration.

Obama’s network of web sites includes The White House and Recovery.gov as of May 2009. These sites exhibit a common set of problems; indicating a fairly straightforward set of issues which have been overlooked by the development team.

What’s Right?

In many respects, the accessibility of the Obama web resources is actually quite strong — the basics are well covered:

• Headings use appropriate HTML markup, providing strong navigation cues for visual and screen reader navigation.
• Most images provide appropriate and useful alternate text.
• Videos are captioned and transcribed.
• Parts of the web site are available in Spanish. (Only a very small part, however — this is definitely not equivalency.)

In other respects, however, the site is wretched.

What’s Wrong?

The principle offender — hands down — is keyboard accessibility. (Yes, that was an intentional pun. Sorry.)

According to Section 508 of the Rehabilitation Act, which covers the accessibility of government web properties, keyboard accessibility is a requirement, and one which neither of these web sites actually pass successfully.

In my accessibility consulting business, I rarely address Section 508, since these rules are relatively feeble compared to their more modern standards covered in the Web Content Accessibility Guidelines, but in the case of a government entity, Section 508 of the Rehabilitation Act applies specifically and is legally binding, unlike other accessibility standards. As such, it’s critical to address the specific points of Section 508 when considering government web sites.

Subpart B — Technical Standards

§ 1194.21 Software applications and operating systems.

(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

Official Section 508 web site (emphasis added)

The White House and Recovery web sites are particularly offending in the area of keyboard focus. When navigating either of these sites, there is no indication outside of the browser default available at any point; and in some areas, not even this indicator is present.

In addition, the drop down navigation menus throughout both sites are unavailable to a keyboard operator. Although these navigation elements have been duplicated in an area in the footer, that footer is not readily available to a keyboard navigator — a skip link has been provided to skip from the top of the page to the main content, but not to jump to the navigation, requiring keyboard users to manually tab all the way through the main content.

With no keyboard focus, this is a very difficult task, requiring you to observe very, very carefully to attempt to identify where you are on the page — let alone distinguish which link you’re activating when you finally do reach this footer area.

On the home page of WhiteHouse.gov, there is a set of featured items; usually in a video format. Using a keyboard, it is only possible to trigger the initially featured video, since the links to trigger other features are completely inaccessible to a keyboard user.

Once a video has actually been reached, the keyboard user will be unable to play the video without downloading it (although these options are available, fortunately.) The video player used has a very common accessibility problem: although the player itself can be navigated using a keyboard, this is only true if you can successfully navigate focus into the player, which is not actually possible using standard keyboard navigation — it requires mouse activation to move focus to the video player.

All in all, a disappointing experience for the keyboard-only internet visitor.

Other Problems

Although I haven’t conducted a complete accessibility survey of these sites, there are a few other issues which stand out immediately. I’m just going to mention these in passing, but this doesn’t make them any less important:

• Links in some contexts are not highlighted (no differentiation by color or by decoration.) ^Figure 1
• Because some links aren’t highlighted, anything placed in a position which seems like a link might be; this causes some difficulty with breadcrumbs, since there is an area towards the top of each document which looks like breadcrumbs ^{Figure 2}, although the actual breadcrumbs are found below the content area. ^Figure 3
• Footer links have insufficient contrast (2.73 according to the WCAG 2 luminosity contrast ratio.) These links include key references not represented elsewhere, including the link to the Spanish language version of the site and, ironically, the link to accessibility information. ^Figure 4
• Comment forms are woefully inadequate — there are no label, legend, or fieldset elements. Although some fields are required, the only indication of this requirement is shown using a background image, and that information is therefore not available to anybody except a normal visual user. ^Figure 5
• With images disabled, some additional color contrast problems are shown. The contrast level in some text-bearing images (including the header graphic) is well below acceptable accessibility levels.

How much work is this to solve?

None of these problems are really challenging to solve; there are web video players which offer much stronger accessibility than the default YouTube player currently in use (Easy YouTube by Christiann Heilmann or Accessible JW Player for self-hosted video, for example.)

Solving the keyboard accessibility issue is easy, as well. Including some basic CSS to provide a strong indicator for keyboard focus will immediately render keyboard navigation significantly easier. Something like the following will provide all that’s really needed:

<code>
a:focus {
outline: 2px solid #58b; 
background: #9cf!important;
color: #000!important;
}
</code>

Though the drop down navigation isn’t keyboard accessible, the web sites have already included all the links within the drop down set up at the bottom of the page. Adding a simple skip link which links to the bottom of the page (“Skip to keyboard-accessible navigation,” or something to that effect,) would quickly remove the bulk of that challenge.

This is the core of the accessibility problem on both web sites: a few very simple changes could eliminate a significant array of accessibility problems. Taking into consideration the change process in a government entity, it’s probably not a one hour solution; but it’s certainly not something that will cost taxpayers a significant sum.

Supplementary Figures

Copyright 2004 – 2008 Joseph C Dolson

Obama’s Web Transparency: not for everybody.

It’s exactly what it says on the cover: a discussion of the “Understandable” guideline from the four principles laid out in WCAG 2.

Enjoy!

Copyright 2004 – 2008 Joseph C Dolson

Understanding WCAG 2 part III: Understandability

Thankfully, the reason for his blogging silence is pretty straightforward: he’s been writing a book. Sweet!

The book is entitled “Selling Usability,” which is a bit of a misnomer, since the subject of the book is perhaps more accurately described as “Making Usability Happen, Despite the Regrettable Lack of Understanding on the Part of Your Managers.” To be fair, that would be a pretty unusable title.

It’s clear within the first 20 pages that John and I share a core philosophy concerning the application of usability: as much as you’d like people to buy in to the core ideals of user experience, you need them to buy in to making the change. By hook or by crook, making the change is what needs to happen in the end.

You can only teach those who are willing to learn; but you can guide anybody to the right decision if you use the arguments they understand and care about.

Selling Usability: User Experience Infiltration Tactics is a guide to convincing decision-makers towards user-experience focused decisions by using business-focused arguments and tactics.

“Selling Usability” is about communicating effectively.

John’s writing is frank and clear. He writes in a casually persuasive voice which quickly drives through the description of a problem into the analysis of why this is a problem — and how you might start to solve it.

This book is not about usability. You’ll learn a lot about understanding and communicating the user experience by reading this book, but it’s not going to teach you how to study user interaction.

Buy it now. You’ll learn more than you think you will, no matter your background.

Copyright 2004 – 2008 Joseph C Dolson

“Selling Usability,” by John Rhodes.

Usually, I spend a day going back and forth with the editor before a new article is published — but I guess that this one just didn’t need that much editing.

At any rate, New Accessibility Guidelines, Part II: Operability, published on March 24th, 2009 at Practical eCommerce.

Copyright 2004 – 2008 Joseph C Dolson

Practical eCommerce Article: WCAG 2, part II: Operability

The interview includes discussion of the W3C, web standards and accessibility standards in general, and common accessibility issues with e-commerce sites.

A transcript of the interview should be available sometime next week.

Copyright 2004 – 2008 Joseph C Dolson

Interviewed by Practical eCommerce

And, as the developer, it’s your job to figure out how to re-do these projects. Usually, there will be more than one way to get the job done: at minimum, you’ll see a quick and dirty method and an arduous, finicky, complicated method which makes tears spring to your eyes in anticipation of the painstaking hours.

Finding the “right” way to do the job is a matter of balancing needs. In an ideal world, the “right” way is the method which gives you perfect accessibility, fantastic usability, and helps sell a million copies of your client’s product in the first 24 hours.

In the real world, it’s the best compromise between your time, your client’s budget, and the needs of the site audience. It may even be a more specific audience — the users of the specific portion of the site which is creating this challenge.

The Challenge of Scale

When you encounter a dozen pages with code which is layered with font elements, excessive span elements and dozens of unnecessary style attributes it’s a trivial task to strip the extra HTML and replace it with the bare minimum required for your needs. When you encounter 12,000 pages like this, of course, you may be looking at man hours which aren’t available anymore.

The Challenge of Legacy Systems

Rebuilding that CMS to deliver a reasonable facsimile of conforming HTML may not only be beyond the scope of practicality — it could well be a violation of the client’s license to use the software. If it’s expensive software, sacrificing a support relationship with the software developer could be very damaging.

With major CMS rebuilds, the most important thing is to identify the scope of changes you can make. Maybe you can’t replace every problem, but it’s honestly not worth discarding $30,000 worth of software investment for the sake of validation. It is worth discarding $30,000 worth of software for the sake of legitimate accessibility barriers. If the system will not allow you to create an accessible form, or generates a shopping cart which cannot be operated without using a mouse, that software should be replaced.

The Challenge of Fancy Widgets

Your client is in love with that poorly-designed Flash widget provided from CrazySite.com. They’ve just gotta have it! It can’t be used by anybody who isn’t using a mouse, the font size can’t be adjusted and is set to 8pt Arial, and there’s a constant red flash which might trigger seizures. But it’s just so cool!

Before you even start discussing the issues above — the un-sexy and hard to sell accessibility problems — it’s good to have a serious discussion with the client the answer one key question: Why. Does the widget serve a purpose for their business? Does it help their users? Does it help sell their product? Sometimes you can successfully get a client to make the right decision on their own once they realize that a function does not actually support their business in any way.

If, on the other hand, it does actually support their business, you’ve potentially stuck yourself with the greater challenge: replacing the functionality of the widget using an alternate means. Programming APIs are great, but not every site actually offers one.

The Challenge of Impossible Functionality

“Impossible” functionality is actually a bit of hyperbole. In my own experience, I’m not sure I recall ever having been asked for something which was actually impossible. However, I have been asked for functionality where the labor to value ratio was extremely unfavorable to the client, which is probably close enough.

Now, this is a highly variable challenge. Sometimes, the best thing to do here is just to ask for a second opinion from a programmer with more specific knowledge than you have. However, assuming that the request is actually unreasonable, the challenge is pretty much the same as above – find out what the client really wants. Sometimes, the difficulty is simply terminology. Some clients might use technical terms in an overly general manner, which can sometimes lead to misunderstandings.

Learning to inquire about project needs without using technical terminology is one of the most valuable tools in your scoping toolkit — it can save you tremendous amounts of time, wasted effort, and frustrated miscommunication.

What is doing it right?

So, in the end, what does it mean to do something right? Ultimately, it means not getting lost in the impossibilities of requests and avoiding being distracted by confusing requests. Doing a project right always starts with good scoping: continually asking questions until you’re absolutely certain that what you’re working on is really the project requested. Once the project is properly defined, the tools are known and understood, then doing the project itself is simply a matter of time and normal best practices development!

Copyright 2004 – 2008 Joseph C Dolson

Let’s find a way to do this right!

My latest article New Accessibility Guidelines: A Welcomed Update was published yesterday (and I totally failed to make note of it here) at Practical eCommerce magazine. This is part one of a four part series reviewing each of the four guiding principles as described in WCAG 2.0.

But I do have things in mind to be published here as well, so I hope not to be this quiet for too long.

Copyright 2004 – 2008 Joseph C Dolson

New article at Practical eCommerce on WCAG 2