User Experience

New Accessibility Guidelines Part II: Operability

The World Wide Web Consortium recently approved new accessibility guidelines. Passed in December 2008, the new “Web Content Accessibility Guidelines 2.0” is the official recommendation for web accessibility for the disabled.

The new guidelines focus on four principles.

  • Is it perceivable?
  • Is it operable?
  • Is it understandable?
  • Is it robust?

This is the second article in my series on WCAG 2.0. The first installment, “New Accessibility Guidelines A Welcomed Update,” we published last month.

The concept behind website operability is simple: Can everybody use the tools and mechanisms required to operate your website? Operability may seem easy, but it can be very challenging. Every control, every link, and every button on your site is a potential point of failure for operability. Without appropriate consideration for the disabled, you run the risk that disabled users will be unable to access your site.

Start with Smart Architecture

A lack of smart information architecture is often one of the first points of failure for accessibility. We’ve all visited websites where the content was disorderly to the point of chaos, leaving us frustrated by the challenge required just to find the information we seek. If able-bodied users are unable to navigate the information buried in your site, users with mental or physical challenges are even more likely to turn their attention elsewhere.

A WCAG 2.0 compliant website will follow three basic tenets required for accessibility:

  • Navigation that identifies the current page or section;
  • Supporting navigation in “breadcrumbs” or similar positional navigation;
  • Headings and labels that describe each section of the page.

These three techniques allow users to know where they are in your site and easily identify a logical path to return to a chosen location.

Keyboard Navigation for Sight Impaired

While many users have challenges in navigating the overall architecture of a website, single page navigation can be a much greater challenge for the blind or keyboard-only user. Since keyboard navigation and screen readers are essentially linear, the ability to quickly scan the page is not an option.

A WCAG 2.0 compliant site will provide methods for users to bypass blocks of repeated content, such as navigational menus. The pages of an accessible site can be navigated by a keyboard in an order that preserves meaning, and the keyboard-focused elements are clearly perceivable.

Keyboard accessibility is a major issue for operability, particularly when applied to rich media methods such as AJAX (asynchronous JavaScript and XML). Many of the AJAX techniques, such as drag and drop interfaces, click and type editing areas and quick edit screens, are unfortunately driven by methods which are not keyboard accessible.

But the problem isn’t inherent with AJAX. Attentiveness to the needs of disabled users when creating AJAX-driven applications can allow you to solve many of the problems you’re likely to encounter. You can read more on “Accessibility and Usability Issues with AJAX” to design an accessible AJAX interface.

Guideline 2.2: Enough Time to Complete

This particular guideline is primarily targeted at timed processes – online testing, for example. The WCAG 2 rules for timed processes are fairly complicated, but they involve ensuring that users have the ability to extend the time allotted for situations where the time limit itself is an essential part of the process.

Guideline 2.2 also applies to the expiration of authenticated sessions, which could apply to checkout processes. When an authenticated session expires, users should be allowed to continue the activity without loss of data after re-authenticating.

Guideline 2.3: Seizures

It is fairly well known that flashing content can trigger seizures, an event that would undeniably prevent the user from being able to operate your website. The new accessibility guidelines suggest that web page content should not flash more than three times per second.

Test Your Site For Operability

Testing the operability of your site in every set of circumstances requires you to answer just one simple question: Can you use it?

Of all the accessibility tests you can perform, keyboard operability is possibly the easiest. Simply disable your mouse and get started. Navigate your pages and do everything on your site via your keyboard. If there’s anything you can’t do, you’ve identified a problem.

Testing for operability with screen readers requires installing and using screen reader software—a bit more complicated than just disabling your mouse. (Both Microsoft and Apple offer built-in screen reader software. Microsoft’s Narrator program comes with Windows and Vista, and Apple’s VoiceOver comes with newer versions of its operating system.) Nonetheless, it will be a worthwhile exercise to help you determine whether your website is WCAG 2.0 compliant.

See the next installment, “Part III: Understandability.”

Joseph C. Dolson
Joseph C. Dolson
Bio   •   RSS Feed


x