"Covered entities that use the Internet for communications regarding their programs, goods or services must be prepared to offer those communications through accessible means as well." excerpt from U.S. Department of Justice Technical Assistance Letter (#712: www.usdoj.gov/crt/foia/tal712.txt)
Leading the way for improved access to the Internet, the Equal Employment Opportunity Commission unveiled a new brand of web site this summer (www.eeoc.gov). The new EEOC web site uses "cascading style sheets" and "dynamic html" to improve access and enable site visitors to choose from one of four site views: a default view, a large text view with white font on black background, a large text view with black font on white background, or a no frills-linear view for hand-held devices.
The most critical concern of web authors to maintaining accessible web sites is the increased time requirement to maintain a graphics version and a text version of a web site when the graphics version can not be made accessible. Maintenance of a text version and a graphics version can double the work time requirement and increase the potential for error when making a change to one version and inadvertently omitting the change in the second version.
EEOC’s use of cascading style sheets in essence is one set of files as opposed to two--the graphics version and the text version. EEOC’s web author, Adam Guasch-Melendez, first got the idea to use a variation of style sheets instead of just one style sheet from Kynn Bartlett, President of the HTML Writers’ Guild, who used a similar approach on the guild’s AWARE web site (http://aware.hwg.org), which serves as a web accessibility resource. Instead of using one style sheet, they used a couple variations and through the use of CGI scripts gave site visitors the option to choose which view/style sheet they preferred. The use of style sheets also allows for pin-point positioning of text and graphics, rather than relying on tables to layout the page. Tables can especially be a problem for web visitors using screen readers when the cell content is not always clear in explanation.
In May, the World Wide Web Consortium (W3C) released voluntary guidelines for web site accessibility (www.w3.org/TR/WAI-WEBCONTENT). The guidelines encourage the use of style sheets to enhance access. The W3C guidelines also provide critical information for entities covered under Title I, II, and III of the ADA that use the web to communicate to customers and employees. Application of the W3C guidelines can insure entities covered under the ADA are using a web site to communicate that is accessible to people with disabilities whether it be selling a product or listing a job opening.
How did you get the idea to use style sheets to run one site with different views as opposed to the traditional graphics version and text version of a site?
When style sheets were first being publicized as "the next big thing," one of the selling points was the ability of users to select from different style sheets. I was rather disappointed at the lack of implementation of this idea. In most browsers, I can choose to use style sheets or turn them off, but there is no option for selecting alternate style sheets. I've always thought that this approach missed much of the value of style sheets. Not that this is a surprise, considering the generally poor support of style sheets overall.
The idea of implementing what had been left out by the browser manufacturers was not mine. Kynn Bartlett, President of the HTML Writers' Guild, did it first when developing the AWARE web site (http://aware.hwg.org), which serves as the Guild's accessibility resource guide. I saw what he had done earlier this year and loved it. In June, when I began to think about bringing the EEOC web site into compliance with the WAI guidelines, I decided to try to replicate what had been done on the AWARE site. It was fairly simple to set up, with the only difficulties caused by the uneven support for various CSS features across browsers. That's still an issue - not all of the style sheets I developed for the EEOC site work as intended across all browsers. However, among the four style sheets currently available there should be options of benefit to everyone.
When I showed it to people here at EEOC, everyone liked the idea, and the Chairwoman of EEOC, Ida L. Castro, gave me the go-ahead to put it up.
I want to make it clear that Kynn Bartlett should get credit for the idea and the first implementation of it. He's even released some of the code for his implementation. Unfortunately, it was after I did it my own version.
How long did it take you to develop the site?
The site has been around since early 1997, and was under development for a few months before then. Giving an actual time period for development wouldn't really be possible. Far more time has been spent on gathering the information for the site, or working with the originating offices on developing new information, than on the HTML work.
In terms of reworking the site for WAI compliance, and implementing the style sheets, it took only a couple of weeks. Level A compliance with the WAI authoring guidelines was the first target. Level Double-A took a few weeks longer. That's with one person working alone, on a site of 500+ HTML documents. At the time, I was working with a part-time intern, pretty new to HTML, who did most of the work on minor updates and site additions, but otherwise this is a one-person shop.
I did have the advantage of having a fairly accessible site to start with. In 1996, when I started initial development of the site, I was already committed to developing an accessible site. The fact that I work for a federal agency, and more importantly for EEOC, meant that my personal commitment was fully supported by management. At that time, there was not much information available on web site accessibility, so I just made sure that anything I did was accessible through first text-only, and then speech interfaces.
We ended up with a site that could be accessed through any browser, any screen reader, anything that could be thrown at it. The WAI guidelines, however, go further than that, and add additional functionality for adaptive equipment, and build in some nice enhancements that can significantly improve accessibility. Most of my time was spent on these enhancements. Fixing accessibility problems was not a significant issue for me.
What kind of feedback have you received thus far from EEOC website visitors?
Most visitors have been very happy with the changes. The new layout and organizational structure gets most attention, of course. Most visitors seem to have overlooked the style sheet functionality, or have no reason to use anything other than the default style sheet. Those who have tried it have been quite happy.
What kind of technical glitches did you run into that you did not anticipate?
There were no significant problems that were not anticipated. That doesn't mean there were no problems. Developing style sheets that work as expected across browsers is a bit of a challenge, because of the uneven support for CSS features. But I was fully aware of the problem before I began. There are a variety of good CSS resources on-line (start with http://css.nu/) that address issues of cross-browser performance. In terms of what specific features did and did not work ... that's a rather long list. The simple approach to resolving some of those conflicts is to make sure that nothing critical is dependent on style sheet support. Some of what I did with style sheets was for aesthetics, some for ease of use (large fonts, high-contrast options, etc.), but nothing is essential to getting at the information.
There were also a few minor tweaks needed to get the CGI scripts that run the system working, but that's because we don't do our own web hosting. We rely on the Government Printing Office for that, and since we don't have direct access to their servers, there was some last-minute fine-tuning that had to take place. But the scripts are very simple, almost trivial to write if you have direct server control. And that's coming from someone with almost no programming experience.
In terms of implementing the WAI guidelines, there are a few items in the guidelines that are nice but not really supported yet, and in one or two cases can actually interfere with good presentation of the information. I did have to go to the WAI authoring group to clarify that certain items could be set aside until there was real browser support for them. Other than that, there were no significant problems.
If people have further questions, can they contact you as a resource?
Sure, feel free to send e-mail to ADAM.GUASCH@EEOC.GOV
W3C Recommendation for Web Content
Accessibility Guidelines 1.0
Industry leaders and disability organizations come together to endorse a
common solution for web access.
www.w3.org
Bobby
Accessibility tool to verify your web pages meet W3C Web Accessibility
Guidelines. www.cast.org/bobby
HTML Writers Guild's AWARE Center
(Accessible Web Authoring Resources & Education)
http://aware.hwg.org
Microsoft
Accessibility and Web Design
www.microsoft.com/enable/dev/web/default.htm
Sun Microsystems
www.sun.com/tech/access/
Web Accessibility
Initiative by Trace Research & Development Center
www.trace.wisc.edu/world/web
WebABLE
Web Accessibility sites & resources
www.webable.com