Web Essentials ’04 notes

What follows are notes from a presentation made 2004.10.01 in Sydney at the Web Essentials ’04 conference.

Day 2: Modus operandi

Topics

Today, we’ll discuss some of the practical issues in designing and developing Web sites that actually provide accessibility for the disabled groups we talked about yesterday.

If you’re an experienced standardista, you will have heard a lot of this advice before, but I expect that at least some of it will be new to all of you.

Principles

• Start with valid code
• Design for highest compliance
• Simplify

Where accessibility standards come from

I’ve got a whole section on this topic in another set of speaking notes.

WCAG

• The Web Content Accessibility Guidelines 1.0 are the currently-available version
• Since you don’t work for the U.S. government (which has its own rules, called Section 508), your only option to claim accessibility is to comply with WCAG
• The current WCAG gives you three levels of “conformance.” You can declare that your page or your site meets any of three priority levels of accessibility. Naturally, each level has two different names.
  1. Level A means you meet all the Priority 1 guidelines. There are 15 of those.
  2. Level AA means you meet all the Priority 1s and 2s. There are 29 of those.
  3. Level AAA means you meet absolutely all the guidelines, Priorities 1 through 3. And there are 18 of those.
• In practice, there are fewer sites online that meet Level AAA than there are people in this room.
  • Some people make the case that the Priority 3 guidelines are so vague and contingent that it’s actually impossible to meet them.
  • For example, in the U.K. they released a survey of Web accessibility of 1,000 sites (HTML version). Using automated testing, they found no sites whatsoever that met Level AAA. Now, automated testing can’t tell you everything, but it is at least indicative.
  • And in practice, Priority 2 gives you the biggest bang for your buck. If you don’t meet Priority 1, some people with disabilities will have trouble using your site, WAI tells us. If you don’t meet Priority 2, some people may have trouble. So if you meet Priorities 1 and 2, you serve the largest single chunk of people with disabilities online.
  • Also, Priority 1 doesn’t require valid code, while Priority 2 does, and that’s known to be important to screen readers. And anyway, as we all know, valid code represents Correct Thought.
• WCAG 1.0 is seriously flawed and we need your help to improve WCAG 2.0, scheduled for release in 2005

Usability and accessibility

• Usability is a precursor to accessibility. If you don’t know for sure that people with disabilities can use your site, it flunks the usability test right then and there.
• And interestingly, we’ve got recent research (from the U.K., but the only HTML version is on my site) that shows that inaccessible sites are hard for nondisabled people to use.
• If you can at all afford it, do usability testing. Even six subjects can be valuable. (And be sure to publish it)
• Encourage the use of better browsers. A goal for the next year is to eliminate IE/Win entirely

Start with valid code

Accessibility is a form of Web standards, and you need valid code for everything to work properly. A small number of minor errors aren’t gonna kill you, but valid code is actually a requirement of WCAG and it’s known to be beneficial to screen readers.

Design for highest compliance

Ask a standardista how to build a Web site and he or she will tell you to get everything working in a highly-standards-compliant browser like Mozilla, Firefox, Opera, or Safari first, and then fix things so it also works in browsers with worse standards compliance, like Internet Explorer for Windows.

That advice is also good for accessibility. Make everything compliant with whatever accessibility level you’ve decided on and then make any small improvements necessary. And the most important of those improvements is the principle I’m going to talk about next.

Simplify

A great many problems in Web accessibility can be solved by making your site easier to use.

You can get around the fact that it’s difficult for screen-reader users and people with mobility impairments to skip over large blocks of navigation links by simply rethinking your navigation. Do you need large blocks of navigation links? Is there another way to do it?

You can get around the fact that forms are confusing and tedious to fill out for nearly everyone with a disability by making your forms simpler. Can you split it up into a couple of smaller forms? Do you really need a side-by-side layout, which usually means more complicated HTML?

We have some research that shows that accessible sites are easier for nondisabled people to use. What I’m saying is that simpler sites are more accessible, which in turn means that their ease of use increases further.

Specific topics

Now let’s consider some specific issues in Web design and the accessibility implication of each one.

Images

• Gets the most attention, and it is important
• Do not be afraid to use images of any kind
• alt text is widely understood
• Much-discussed longdesc is rarely actually needed, with some exceptions
• Use CSS background-image as much as possible to avoid the problem altogether
• Ancillary uses like list bullets, for which the preferred method now is Bowman’s background-image

Multimedia

• Overlooked –  and sometimes deliberately ignored, since it’s difficult and onerous
• WCAG Priority 1 requires captioned and (where necessary) described multimedia
• Transcripts are mandatory for audio, optional for video; in practice, transcripts are needed only for certain audio types (e.g., not online streams)
• It’s hard to do – even if you send your video out of house, which in most cases is what you should do
• Open accessibility is easier than closed
• Many videos do not require description, which has almost no history in Australia, but that must be assessed case by case and not by genre or category
• If you go for closed captions and/or descriptions, don’t use Windows Media, unless it’s on an intranet and the user base is known for certain. That’s because Windows Media has more annoying limitations than QuickTime or Real do. (Note that none of those formats is without annoying limitations)
• For open captioning and description, Windows Media is barely tolerable
• QuickTime and Real are slightly better options

Navigation and layout

• Simplify everything
• Navigation at the right (in left-to-right languages) is marginally better
• Improved information architecture avoids or solves many problems
• Use valid code: Menus, for example, should be lists
• In 2004, CSS only, please; using tables for layout is officially dead
• Provide alternate stylesheets for reformatting (the subject of a forthcoming article for A List Apart)
  • dark vs. light
  • large vs. small type
  • single- vs. multi-column

Intranets

1. Can streamline for known user base
2. The downside is: It may change. Hence you must have a plan worked out up front to accommodate new users on your closed network
3. Valid code and usual principles apply

---

Q&A

A superspecial extra! Here are some notes based on questions posed during the Web Essentials Q&As – just the ones with value for posterity.

What about MathML? Or should we just use CSS to simulate mathematics?

No, there’s now a plug-in for IE/Win that allegedly makes pages written in MathML (and how many of those are there?) actually accessible and usable to screen readers.

What about the real-world implications of Web accessibility? If I’ve got an accessible Web site, does that mean my offline business has to be accessible, too – accepting TTY calls, producing alternate-format materials, and the like?

Probably, but not necessarily. What you definitely must do, though, is have a contingency plan for such requests, as I explain in my book.

How different are WCAG 1.0 and the U.S. Section 508 regulations?

Jim Thatcher is the master of that question.

I’ll add more here as people jog my memory.