Project Management

Develop a Web site accessible by visually impaired users and comply with the law

Poorly designed Web pages create a significant challenge to someone who cannot see your Web pages. However, it is easy to make good decisions about page design -- once you understand the Section 508 standards and have some tools in your back pocket. By using the tools outlined, you broaden the audience for your products or services and put your Web site in compliance with U. S. Federal law.

At a large public university, I recently assisted a project team in testing a Web-based application we made available to several hundred thousand alumni. Application usability was a key success criterion for the project. Recognizing that numerous alumni might be blind, color blind, or have some other visual impairment, we worked to make the application comply with the Federal standard for accessibility, Section 508 of the Workforce Investment Act of 1998. This law "requires that Federal agencies' electronic and information technology is accessible to people with disabilities, including employees and members of the public."

This blog post is also available as a TechRepublic download.

Demographics

If you do not work for a Federal agency, the law probably does not apply to your organization. That being said, I firmly believe that equal access to Internet resources is a moral issue that we developers should strive to address. In the United States alone, countless people are affected by visual impairment.

The American Foundation for the Blind estimates there are approximately 10 million visually impaired people in the United States, of which approximately 1.3 million are legally blind. Citing statistics from a 1999 U.S. Bureau of the Census report, the Foundation indicates that just over 1.5 million visually impaired people in the United States have access to the Internet.

Projecting from a report on the Internet World Stats Web site, which states the usage of the Internet in the United States has doubled since 1999, we can reasonably conclude that approximately three million visually impaired people in the United States have access to the Internet.

Globally, that number is probably many times higher, based at least upon projections from the All About Market Research organization. They indicate Internet usage worldwide has quintupled since 1999. It is easy to see that by making your Web site accessible, you may open doors for many more visitors.

Take a test

Would a blind person find your organization's Web site easy to use? Take a simple test: Go to your organization's home page, close your eyes, and try to navigate the Web site. Since you no longer can see the visual cues that simplify navigation, your interaction with the Web site becomes a frustrating experience. You may wonder how someone with a visual impairment explores your Web site. Happily, there many simple accommodations you can make to improve accessibility.

Screen readers

Someone with a visual impairment could browse the Internet with the help of a screen reader. Such tools narrate the text that appears on a Web page, and give the user an auditory roadmap of the structure, links, and controls on the displayed Web page. These tools also provide a comprehensive set of keyboard shortcuts for Web site navigation.

Unfortunately, poorly designed Web pages create a significant challenge to someone who cannot see your Web pages -- even when using a sophisticated screen reader. Since the screen reader commonly scans text from left-to-right, rows and columns of data are difficult for the user to decipher. Images on the site have no value unless they are tagged with narrative text. If a field and its title appear on separate rows, the screen reader cannot link the two together.

Even with these few examples, you can understand how easy it is to make life hard for someone with poor vision. Here is the good news: It is easy to make good decisions about page design -- once you understand the Section 508 standards and have some tools in your back pocket.

Tools

Several useful tools are available for the developer to create and test a Section 508-compliant Web site:

  • A useful checklist for Section 508 compliance is available from the Web Accessibility In Mind Web site.
  • A Canadian special interest group, JA-SIG, offers an introductory slide show of programming techniques.
  • An expert in the field, Jim Thatcher, provides a well-written online tutorial concerning Web accessibility.
  • A handy tool for testing compliance is the Functional Accessibility Evaluator available on the University of Illinois at Urbana-Champaign Web site. You may test accessibility by simply providing the URL of a Web site (assuming it is public). The test follows the standards for best practices defined by the Illinois Center for Information Technology Accessibility (ICITA). For developers, the ICITA has a helpful add-in for the Mozilla Firefox browser. The tool provides a robust accessibility menu for the Firefox menu bar. It includes several validation checkers to diagnose HTML and accessibility issues.

The real test

Of course, the value of human usability testing is well known. My teams use it to great advantage when we test a new software release. I personally find it fascinating to sit with an end-user and watch as they try the new system and complete some work task I've given them. While they decipher the screens, navigate, and enter data, I am furiously writing notes about what I observe. I watch for the roadblocks they encounter and for the choices they make in completing a task. I try to evaluate how efficiently and completely they are able to finish the task I gave them. The experience always enlightens (and sometimes humbles) me.

When you develop a Web application compliant with Section 508, you should also conduct usability testing with someone who is visually impaired. At the university where I work, we are blessed with someone who is blind and quite savvy with screen readers. He recently helped us test accessibility for the alumni Web application I mentioned.

I sat with him for an hour or so as he completed several work tasks using the new application. Despite the project team's thorough effort in writing Section 508 compliant software, he discovered several places where the system needed improvements. We corrected those problems and confidently made the system available to a wide audience of alumni.

Next steps

It is not difficult to provide improved access for visually impaired visitors. By doing so, you broaden the audience for your products or services. Most importantly to a visually impaired person, he or she gains access to your corner of the Internet world. I hope the tools I've mentioned assist you in this endeavor.

24 comments
jg1646
jg1646

Developing Web site accessibility for blind people may be noble,but how is it moral?

Jaqui
Jaqui

Develop a Web site accessible by visually impaired users and comply with the law. hmm, this sounds like what I have said fairly frequently here on the subject of website development. You missed the simplest test of all for usability by those who are visually impaired.. just view the site in a text only web browser. if it can be used in that, then it will work for all assistive technologies, including braille terminals. You also get the benefit of the site is compatible with mobile devices then.

Mark W. Kaelin
Mark W. Kaelin

Have you developed a Web site in compliance with Section 508 of the Workforce Investment Act of 1998? What obstacles did you have to overcome when creating your compliant Web site? Do you anticipate that you will be asked to develop a Section 508 compliant Web site in the near future? Are you prepared to comply will all of the standards established by that law?

DanLM
DanLM

because I am not sure I am reading your post correctly... And before I become a twit with an attitude, I think I at least should have a clue what you meant. In other words, hu? Dan

Justin James
Justin James

Jaqui - You know I'm in with you on this one too. I check my work in Lynx; if it looks wrong there, it will look wrong to a screen reader. Just as nice, looking good in Lynx is looking good to the search engine. :) J.Ja

jspurbeck
jspurbeck

I'm in the final developmental phase of a thick-client product, (name of product suppresed), 1. the can attach to numerous vendor databases on the server side, including the metadata and codebases. 2. provide the developer-user the tools to layout a website/webscreen, attach the data object definitions to any input fields, and perform a laundry list of development needs, including adding additional 'alt-tag' text, and other info, much like Dreamweaver or other similar apps. 3. However the output of this product is a full-fledged web application that has an extremely small footprint, is ADA Section 508 compliant while still being visually pleasing for non-handicapped users. 4. The output has been run-through the W3C compliance checker, and is certified HTML 4.01 Strict and CSS Level II. 5. I do not use Bobby (section 508) checker, because their method of certification is based on an older W3C technical model, and this product was designed from the ground up to be used to develop web applications for government agencies. So, I anticipate a long, active, satisfying future in this arena.

DanLM
DanLM

My eyesite sucks. I think I have 20/200 with my glass's on. One eye is 20/20 and one being 20/200. I guess if I wore a patch over the bad eye, things would be alot easier. You see me waa and moan about TR, but with my limited eyesite. TR for the most part has large easy to see fonts in most of their pages. You have ANY idea how thankfull I am for that? I can't read a phone book because the font is too small. When I find websites who either have font's real small, or the combination of their color schema and font size(with so close a color). If the magic ctrl + doesn't work, I move the hell on. That being said, there isn't a single site I have ever worked on that is compliant. Even though I can see it(which was my test), I have had people come to me and complain that it was hard to read. Font being too small.... I increased the font size(got to love css). Only 1 site has javascript in the navigation, which makes it real easy to navigate... But, the google spider bot only registers the first page. I think just a few simple things would help people with bad eyesite. Bloody font that isn't the size of a nat. Colors, they may look pretty... But more basic colors make it much easier. Remember, not everyone is totally blind. Some of us just have crap eyesite. Look around your office sometime to get an idea of how many. If you don't think you need a completely compliant website, your probably right. But think about the number of people that have impared vision you may be missing because you used that small font or reall pretty color schem. Dan

Jaqui
Jaqui

a sadly ignored tool that is the best testing tool any web developer or designer could use. the no javascript, no images, no tables, no frames, no flash, no audio limitation is exactly what search engine bots and screen readers work best with. it pushes developers to use server side code for app logic, which is better for the website anyway, if they make it function in lynx. Though the no images thing is probably why most ignore lynx, they don't see the value in designing a site the works without images.

johnw
johnw

I won't bore by going over the same ground as DanLM. Colours that do not have enough contrast when they are combined make it impossible to read with defective colour vision. I have ruined a lot of meals because I could not see all the instructions. Also I have no right peripheral vision. so any popups that are just a bit offcentre also get missed. If input is required, make sure thst it starts and finishes no less than 1/4 of the way in from either edge of the screen, otherwise we get fed up waiting for something to happen because we cannot see the input box sitting in the middle of the screen. We need a panel of visually impaired people who can give real advice about issues that we know affect us. Not people who think that they can understand the problem. I thought that I understood until a stroke made me understand.

jspurbeck
jspurbeck

You hit it on the nail for commercial sites. Thank you for sharing that personal experience. Your mention of javascript being making the site easy to use, in your case, seems to answer many questions mentioned in this thread.

Jaqui
Jaqui

You know the two worst colours to use for a background on a site? Black and White. either background causes the monitor to emit a glow that makes it harder to read the page. off white is much easier on the eyes for a background colour.

jspurbeck
jspurbeck

Thank you for sharing that. Seems this subthread was saying similar things from different perspectives. The graceful degradation capability can be handled in many ways. I'm sure that graceful degradation is not too pleasing or graceful. Please ask your accesibility-guys if one of the primary reasons they take the position of supporting the lowest common denominator in their approach as to what can and not be done at the client-side. Most likely reason given: There are still a lot of browsers out there that don't do this or that. I'm writing code for corporations and agencies that reinvest regularly in their technical infrastructure. And part of that investment is to ensure their employees use the lastest (W3C) proven browsers. They do this because they see this as a technical investment that will pay off be creating advantages over their competitors, or by meeting their Section 508 mandates. So, I guess I'm in a rare position to demand use of the most updated user-agents. That's for intranets only, or government-facing-people applications. For true www, do not expect me to build a 508 application for a face-book plugin, or any image intensive app, just does not make sense. Now, I believe that you should not have to worry at all about the target client, as long as that (browser) client complies with the W3C specification. I am writing code today, that executes properly in the top 10 browsers (those that use the MSIE model and those that use the Mozilla (W3C) model). This code provides smooth execution flow from object to object for those that are visually impaired, while providing a rich, 'full-featured', GUI for those fortunate enough to be able to see. Those that can see, can 'skip ahead' in the 'flow' by using a mouse. Otherwise 'flow' moves from the first most obvious object to the next in an orderly fashion, each appropriate object has alt and title tags, as well as NO in-line styles. I do not use frames, tables, h, li, p, span, or any of the many nuisance tags. I would estimate that 95% of the objects in the application are DIV tags. The remainder are IMG where necessary, INPUT text, TEXTAREA(sparingly), and FORM. Literally, the BODY tag looks like "". Not another tag in between. All objects created by javascript, perfectly for each compliant browser. I remove the all styles to CSS, and each object is reference by class and id. In other words, ALL objects are created using compliant code. This is where the world is heading. And no, I will not provide links. jaqui ... Keep your clients in the dark ages, and you will be the one losing your contracts.

techrepublic.com.com
techrepublic.com.com

The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. In addition... The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents.... As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. Further... A web browser is not obliged to use DOM in order to render an HTML document. However, the DOM is required by JavaScript scripts that wish to inspect or modify a web page dynamically. Typically, a "compliant" browser is "compliant" to some level of a spec: XHTML 1.1 compliant, or CSS level 3 compliant. And a browser can be "compliant" with one spec while not being "compliant" with another. Typically though, when people talk about a browser being "compliant" they mean its ability to render the markup according to a specific DTD. Notice that the Acid2 test (http://www.webstandards.org/action/acid2/guide/) doesnt test for DOM compliance (though Acid3 will). Your Acid2 test results should look the same with or without javascript as the test does not use the DOM. It has long been a rule of thumb, especially in regards to Accessibility, that you build your sites to degrade gracefully. That way, your site is just as functional with or without javascript. As it is, I have built numerous web applications for an entity that does have to comply with 508. I'm lucky in that we have a department specific for Accessibility technologies that I can work with to ensure that my applications meet a minimum level of acceptance in order to comply. One of the main points they always come back to is to NOT rely on javascript that manipulates the DOM. Always have a way for that same information to be accessible when javascript is not available.

jspurbeck
jspurbeck

jaqui, you need to read a whole lot. a DTD defines the layout of a document. you apparently do not know the Document Object Model. It is NOT a place for running scripts, as you suggest. Why don't you visit the W3C.com site, and study, study, study. Then, and only then, will I respond to any more posts from you. if you took the cigarette out of your avatars mouth long enough to study, you might just learn something, instead you spout off nothing but smoke and bull----. Wrap you head around this: A user does not navigate a site. A user navigates a document. That page is (at that point), contained within the Document Object Model (DOM), from where, it is rendered and made accessible to the user. At this point, those rendered objects must be usable by the screen-readers discussed in this thread. Those objects must be stacked in an appropriate way to allow proper navigation under the rules outlined in Section 508. I believe that you do not know enough about your own user-agent (amaya) to understand that once an html document is received, it is parsed into objects that are inserted into the DOM. And from there it is rendered. Otherwise I can only suggest that amaya is a 'hack', and not worthy of future support. Now, if you have something intelligent to add to this thread, please do so. I'll be watching. So far all I've heard are complaints and fears.

Jaqui
Jaqui

DOM defines active script objects. until you wrap your mind around that reality, you do not know what you are talking about. every site MUST have a DTD, not a DOM.

jspurbeck
jspurbeck

the Document Object Model (DOM) must exist for any user-agent to be considered a browser. Even a 'static-screen' HTML file is parsed upon reciept at the browser, and each HTML element is introduced into the DOM for presentation at it is parsed. Then styles are applied, if any. You can call it anything you like however, ask yourself these questions: 1. When an HTML document is received by your user-agent, in this case amaya, do you see the HTML document, or do you see words that make sense (non-HTML code)? If you see words, then the HTML was parsed. 2. If the HTML document was parsed, what happened to the other non-displayed information that was in the HTML document originally? Was it simply thrown away? Was it used? hmmm.... 3. Again, if the document was parsed, the stuff you do see, was placed in another document for viewing. Do you think that this is what is happening, or is it something else? 4. If you feel it is something else that is happening, then I simply do not know what more I can possibly tell you about the DOM. 5. If you feel I described what is happening properly, the amaya has a DOM, no matter what you call it. 6. In any and all respects, I will no longer respond to this sub-thread until you present something more than simple disagreement, or to respond to your particular environmental concerns.

jspurbeck
jspurbeck

1. Browser vendors are very close to W3C compliance with the latest versions of their respective products. 2. Blind-reader and other ADA vendors were promised ages ago that if they designed their future products to the spec, eventually the world community (market) would provide browsers that would support their product on the client side. To date, they have had to read the input stream and, after parsing it to death, might, just might have a useable document. As I said earlier, a simple in-line style, not properly coded, can render the document unusable. (btw, one of the benefits of CSS, by design requirement). 3. The purpose of Section 508 was not to drive every web application to plain-jane vanilla text with a few buttons thrown in. The purpose was to impose on government agencies the requirement to ensure that any business conducted over the web by the agencies public, must not be designed requiring a graphical (visual) user interface (GUI). 4. When MS-DOS screens ruled the day (circa 1980-1990), visually impaired users could still work with software in their roles at work. MS Windows, while dazzling in it's day to viaually capable personnel, esentially drove handicapped personnel out of the new era, and enslaved them 'digitally', to the dark ages. (Pardon the pun, this is not funny stuff.) Not only were they affected in their jobs, products were coming off the shelves of American stores that were increasingly marginalizing handicapped people in our society and throughout the world. After the great strides and innovations that had been conceived and developed to bring these folks into the community, in a matter of two years, the gains acheived seemed to lose their charm, because all new products were designd assuming visual capability, a keyboard and mouse. 5. Section 508 is one of those rare pieces of legislation that binds the government to their people. It has teeth. However, web technology up to this point has been yet again focused on the visual consumer. Organizations responsible for compliance, simply shoo it away saying the tech does not exist. With the most recent browsers, that has changed. The reader-vendors are ready. But until the agencies change, all is for naught. 6. It seems that to date, most developers are trapped in the old HTML model, and will be for a quite a while. Software service companies that embrace the new model will see an increase in interest and sales.

Jaqui
Jaqui

is that not EVERY site uses the tech, since a STATIC site has no dom. The fact that there are several browsers that don't support clientside scriptng should be warning you to WRITE your websites to function WITHOUT it, anything else will just have the company getting emails from thoose who use those browsers telling them they lost any possibility of a sale from the clientside scripting requirement. enough of those, YOU lose your contracts. clientside scripting is EQUAL: to non ACCESSABLLE for visually impaird.

jspurbeck
jspurbeck

imho, if it does not comply with the W3C DOM then NO, it is not a "compliant" user-agent. This does not mean that it does not have a purpose. However, as the web-community adopts the W3C standards, non-compliant browsers will simply 'learn to comply' or 'fade into the sunset'. jer

Jaqui
Jaqui

is not a full fledged user agent either ]:)

jspurbeck
jspurbeck

Pursuing ADA (Section 508) compliance has been a major theme throughout my career. Working with USAEC and UI Urbana-Champaign, and other Government Organizations, ADA compliance was deemed the holy grail of web computing. I have had the most wonderous opportunity of working with totally blind web-savvy database engineers. What enlightenment! The Lynx test, of course, should be part of the useability test. However, I will interject a somewhat contrary view of what can be done in the immediate term to satisfy ADA and non-visually impaired audiences. Well-defined, W3C (x-browser), ADA compliant HTML documents can be achieved, and achieved using javascript, in a "HTML-less" .htm file. Well, not quite HTML-less, but not one tag between the tag. Most of the document contains superior metadata. If the browser does not support javascript, then the browser is NOT a full-fledged user agent. The whole purpose of W3C specs is to move the user-experience forward, and not stagnate (too-long). That being said, think of the document object as a template upon which objects are added (x-browser compatible) after the entire document loads. Not a drop of , , , or other nuisaince tags. Each object is custom-defined first as a element, properties, classes, methods are attached, and then the object is inserted into the DOM, in the most appropriate manner for both visual-impaired and other users. "In-Line" styles, most commonly used pre-CSS, but still in great use today, presents great problems to any screen-reader. Converting to a purely class-based CSS methodology is the very first step an organization must take pre-design. Extensive use of javascript-enabled DOM-objects provides the ability to control the focus of objects in the DOM, ensuring that the blind-readers are 'pointing' at the most obvious 'next' object in the application stack. If anybody is interested in more info along these lines, chime in.

Justin James
Justin James

I'm now working with the W3C. A few days ago, I said, basically, "if it requires user intervention to cause a DOM event to be fired, it is not accessible". I also pointed out that the "Lynx test" is a good test for the "semantic Web" because anything Lynx can't handle is too presentation oriented to be "semantic". I got cynicism in response, things like "Lynx is not a full fledged user agent, neither are search engines". What a load of hogwash. Anything capable of opening an HTML document and parsing it according to the spec, and performing any of the mandatory interpretations is a full fledged user agent. J.Ja

Justin James
Justin James

Black text on white backgrounds should, in theory, provide maximum readability. However, as Jaqui has pointed out, the pure white is actually hard to read. Why? Because using a computer monitor is like staring into a lightbulb; it is a light emiter, not simply a light reflecter. If we were using alight reflecter, like an e-Paper type of deal, a pure white background would be best. Personally, I dial a Web site in to have a nearly white background, usually going for a slightly cream color. That retains white's readability, while being less harsh on the eyes. J.Ja

DanLM
DanLM

I've found that I like a soft blue for a background... Ya know, the one thing I did learn in my little bit of experience of web design(besides I hate it) is that even with my limited eyesite. Finding that perfect middle ground is hard, and still keeping a nicely designed(roflmao, they tell me my site s suck) site. Again, I think just very simple measures can help more people access it.

Editor's Picks