Adapting Existing Federal Web Sites For The Disabled?

Rafajafar asks: "I work as part of a federally-funded Webteam for a prestigious laboratory in the states. It has recently come to my attention that our government has placed a burden on us. Congress passed the Rehabilitation Act back in '98 which instantiated a committee to ensure that all federal technologies do not treat those with disabilities unfairly. This board released a set of standards that they created to ensure that the government doesn't violate the Rehab Act. This, although wonderful for the disabled, leaves many of us media lackeys at these federal facilities with a bit of a conundrum. How do we fix all this stuff within 6 months? Our site has thousands of pages that would need to be sorted through by hand and even with us abandoning all projects for 6 months, we would not be able to guarantee all pages to be fixed. I know our team isn't the only one with this problem, so I was wondering if you guys have any good ideas on how to go about changing our site, our videos, our presentations, and pretty much anything else that relies on one sense over another. We would prefer to avoid using the 'Undue Burden' clause as much as possible."

First stop: the Web Accessibility Inititative

The w3 [w3.org] has been talking about this for years. The Web Accessibility Initiative [w3.org] is their site dedicated to exactly this issue, and is rich in information and resources for implementation. See particularly the guidelines [w3.org], checklists [w3.org], and techniques [w3.org] sections.

You do have a lot of work ahead of you. It's much easier to start with accesibility in mind than to retro-fit everything. You might be able to script some of it, as others are suggesting, but your first step should be to thorougly familiarize yourself with the information at the WAI.

TomatoMan

Re:Nonsense

First of all, there was no such thing as "HTML 1".

HTML 4 Strict is useful even for "plain pages" because it provides style sheet hooks (CLASS [htmlhelp.com] and ID [htmlhelp.com] attributes), internationalization (LANG [htmlhelp.com] and DIR [htmlhelp.com] attributes, BDO [htmlhelp.com] element, entities [htmlhelp.com] for characters such as the euro), as well as useful new elements like ABBR [htmlhelp.com] and ACRONYM [htmlhelp.com] that allow you to give the long form of the abbreviation through the TITLE [htmlhelp.com] attribute.

HTML 4 Strict also adds accessibility aids such as the LABEL [htmlhelp.com] element for indicating the text associated with a form control.

Web sites don't rely on one sense

Web sites don't rely on one sense over another unless they've been written poorly. A well-written Web site will adapt seamlessly to any display device, whether it's your 21" monitor, your PalmPilot, or your speech browser.

Of course most Web sites are written poorly, so now you have to fix the mess. Good luck.

Have a look at the W3C [w3.org]'s Web Accessibility Initiative [w3.org] for some guidelines and techniques.

A possible plan

While I think that the federal government is really going way overboard on "disability compliance", etc. etc., there is one way that this burden might be reduced. If all of the pages on a site are formatted the same, you could use a Perl script to automate a lot of the changes. If you're using stylesheets, even better; a simple addition of extra media types will make many pages instantly "handicapped accessible."

Why worry so much?

It seems to me as though this is a piece of legislation that has been passed to make people happy rather than to actually be implemented in full. Sure you should make some of your more critical web pages compliant, but if I were you I'd prepare a time study detailing exactly how long it'll take you to get all these changes implemented, and watch how fast they decide it falls into an "Undue Burden" category...

If you really need to do so at some later point it can be done then, but as it is it's a lot of effort for no real gain. This sounds harsh, but sometimes it's just not worth the time to cater for such a small part of your audience - just look at how many sites are giving up on supporting Netscape because it's dead and there's so little point in spending the time to keep a site compliant for different audiences...

Wow, you really DO have a problem

I have to congratulate Jlab on doing a stunningly great job on the safety pages. I was awestruck that you put the emergency evacuation plans available for the public to see, right down to showing where the extinguishers are in each building. Amazing.

However, each one of these pages alone represents a true barrier to the handicapped. For example, if a visually impaired user heard the fire alarm, and navigated to the Jlab web site in order to find their way out of the building, one can just imagine their screams of fright when they realize that their only resource is a JPEG. Oh, the horror. If only the web designers had thought ahead, and planned for these kinds of circumstances, death could have been avoided.

Sarcasm aside, man, you really do have a heck of a case for the undue burden clause. A lot of the stuff on this site is frills. (An image of each building?) You could indeed make them more accessible, or you could just plain delete them. I love the site, you're doing a great job of disseminating information, but some of that stuff just isn't necessary for the outside world to see over the internet, is it?

Re:Nonsense

Just because you can do something does not mean you should.

Just because you can create a five-minute Flash flyover of Washington D.C. to play before anyone can get into your site does not mean you should.

Practical advice from someone who's doing it

I am currently working on a US government web site. (OK, it's a state web site, but they are holding us to the federal rules because they know they're next...) Here's some practical advice:

1. Read the W3 Accessibility Initiative [w3.org] to get an idea of the concepts of making the web accessible. Contrary to popular opinion, the web is for everyone.
2. Use Bobby [cast.org], a free automated tool written in Java that can check your entire site for accessibility problems. It categorizes problems based on priority level, checks pretty much everything listed in the WAI, and tells you what you still have to check manually that it can't check automatically.
3. Read the W3 Techniques for Web Accessibility [w3.org] to get an idea of how to implement the changes. Contrary to popular opinion, HTML 4 has many features specifically for blind/deaf/disabled users.
4. Test your site yourself. Use Lynx [isc.org] to see what your site looks like to the blind. Do all your images have meaningful ALT tags or LONGDESC tags? Do your tables have SUMMARY tags? Is your navigation usable without Javascript or Flash?
5. Set your text size to maximum to see what your site looks like to visually impaired users. You are using relative sizes for your fonts and percentages for your table widths, aren't you?
6. Turn off your speakers to see what your site looks like to the deaf. If you have audio feeds, do you also have transcripts? If you have video feeds, are they closed-captioned?

It's not rocket science once you know what you're doing. Personal anecdote: I applied the same principles to my own web site, even though I didn't have to and my friends told me I was wasting my time because "nobody uses Lynx anymore." In the first week, I got 10 Lynx visitors.

-M

You're smart; what haven't you learned Python yet? http://diveintopython.org/ [diveintopython.org]

Re:Disabled people

I don't see any reason that we shouldn't have to customize websites for persons with disabilities.

I can.

A properly-designed web site does not need any customization for persons with disabilities.

A web site which is not universally accessible is an indication of gross incompetence on the part of its designer.

Obviously, not every adornment and photo needs to be described in painstaking detail. But - and this is particularly important on government sites, which exist to make important information available to the public - there should be no frivolous impediments to the transmission of information. And this goes from Day One.

A couple years ago I was with a government agency which, to its credit, decided to get an early move on this and get all its pages accessible.

It was a tremendously valuable project, because running all the pages through Bobby and other validators not only highlighted the pointless inaccessiblities that riddled the web site, but called attention to all the other coding errors and other latent problems lying beneath the surface.

It also made it very clear which of the web developers knew what they were doing, and which were utterly useless goldbrickers, tossing together nonsense using FrontPage when they had claimed to know HTML.

Many of these same people thought it was impossible to have pages that are visually engaging and accessible at the same time. This is precisely because they did not know HTML, and thought that the only things that could show up on the web were the fetid oozings from the back end of FrontPage and its ilk.

So, here's the Rapid Accessibility plan:

1. Conduct spot checks and immediately fire anyone on whose computer FrontPage shows up in the recently-used applications
2. Use a tool like Bobby [cast.org] to get a detailed review of problem areas
3. Study these to determine patterns (missing Alt attributes, etc.).
4. Assemble tools (using Perl or some other rapid-development language) to automate the repair of the patterned problems. For instance, for the missing Alt attributes, write a program that presents each image on each page, asks an operator to write a label for it, and then writes the page back out with the labels added.
5. Conduct another spot check to see if you missed any of the FrontPage users the first time around.

Re:Why worry so much?

Oh, baloney.

All that has happened is that they're having their hands slapped for being so *stupid* as to design the site so that the "This Page Best Viewed Using MSIE" warning had to be used.

If they'd stuck to the damn *standards*, they'd never have encountered this problem.

Now that they're forced to be smart, the web pages will be viewable not only by disabled-friendly browsers (browsers that provide 500x zoom for the visually impaired; browsers that will read the content to the blind; browsers that will send output to a braille interface), but the pages will also be viewable to people using Palm Pilots, Netscape, Lynx and any other browser.

So what's it gonna take? Not a whole helluva lot: get rid of browser-specific tagging. Get rid of frames. Add ALT text to all images. Provide text descriptions of any animations/Flash/videos.

In other words, they have to do all the things they *SHOULD* have been doing, right from day one.


--

Can't feel sorry for ya

If the job had been done properly using the tools available at the time this situation would never have come up. I'm sorry but I can't feel bad for a government agency which did a poor job and now wants us to feel sorry for them because they're being told to correct the problem.

Go spend an afternoon browsing through the W3C archives, useit.com, and htmlhelp.com and when you realize that this is nothing new but rather exactly what those with clear vision have been advocating since the dawn of the web maybe you'll just have to crawl back to your post and do your job properly.

Do Some More Research

Call the people at the access-board.gov. The regulation only applies to things created/contracted for after June 22, 2001. You do not have to retroactivly alter your entires site. Also note that,
1. Most of the regs, refered to as Section 508 are really just good coding practice (like using alt tags on web sites.)
2. Any disabled person could have sue you since 197X under the ADA and force you to be accessible, you should have been thinking about this all along.
3. This regulation appliies to everything IT related, not just web pages.

Here's a possible answer:

Here's a possible solution.

The standards don't aim at eliminating graphics and animations, but <quoting> Generally, this means use of text labels or descriptors for graphics and certain format elements. (HTML code already provides an "Alt Text" tag for graphics which can serve as a verbal descriptor for graphics). This section also addresses the usability of multimedia presentations, image maps, style sheets, scripting languages, applets and plug-ins, and electronic forms </quoting>

What if the whole site were transformed into text which could then be read aloud?

IBM's WebSphere Transcoding Publisher was designed as a helper to servers for wireless devices, because it takes normal websites and transforms the *ml into something a wireless devices' browser can handle. It does this on the fly with little or no performance hit, changing sites to text, to voice, resizing and altering images for whatever device you may be browsing from.

In this case, it could transcode a normal website like yours into VoiceML and be read aloud, or into text and be read using the blind users' screen reader. You wouldn't have to redesign anything about your site, except to ensure that disabled users got the properly transcoded site.

It really appears to me as though Transcoding Publisher running on your server would solve your problems.

Look at http://www-4.ibm.com/software/webservers/transcodi ng/

and http://www.research.ibm.com/networked_data_systems /transcoding/ibmtranscoding/html/proxydemo.htm

email me if you want to talk more about it.

A host is a host from coast to coast, but no one uses a host that's close