 | ||
|
| ||
| ||
|
| ||
January 26, 1998
The following article was originally published in the Site Builder Network Magazine. (Now MSDN Online Voices.)
Let's start with a couple of exercises.
Exercise 1: Unplug your mouse. Now try to browse the Web.
Frustrating isn't it?
Exercise 2: Turn off your monitor. Now try to browse the Web.
Silly of me to suggest such an exercise. But if you were blind, you wouldn't think so. You would know that you could use a screen reader to describe Web pages, using either voice or Braille. If you don't provide captions for your images, there won't be anything for the person to experience.
The World Wide Web is supposed to be a place where everyone has the ability to find information or shop. It's not supposed to matter who you are or where you are. But not every person and not every client machine is the same. Sure, as Web developers, we spend lots of time thinking about the performance aspect. We want our sites to be speedy and spiffy. We May even test our sites for low bandwidth. That's great. We need to keep doing that. But we also need to be mindful of how accessible our Web pages are.
Accessibility is a software product's ability to be used by people with disabilities, including motion impairment, low vision, blindness, and deafness. If your motion is impaired such that using a mouse is out of the question, the software you use must be accessible via the keyboard. If you have low vision, the software must accommodate customization of font size and color. If you are blind or deaf, all of the elements on a Web page must have a textual representation in order to be experienced, even WAV files.
Animated graphics, streaming media, and other flashy new uses of HTML and Dynamic HTML have made Web pages much more entertaining and inviting. But these new widgets shouldn't be used to the detriment of accessibility. When you create pages, try to follow these three basic rules:
Also consider creating a "text-only" version of your site. This is an important accessibility feature for users who are running a browser that displays only text. This is especially important if you have a fairly complex page that you really want the user to read.
I remember the first time I worked on an application using a windowing environment (OS/2). I created this great dialog. The only problem was that you couldn't get to all of the items in the dialog box with the keyboard. So, if you didn't have a mouse, you were out of luck. I haven't designed very many Web pages myself (for that, we have professionals with some taste at Site Builder Network). But I imagine that I would fail the keyboard test.
Some browsers take care of some of this for you. Microsoft Internet Explorer automatically turns <A> tags (anchors), controls, and image maps into tab stops.
With DHTML, the technology supported in Internet Explorer 4.0, you have an added complexity, since any element can respond to an OnClick event. That is, DHTML code is written to react whenever the mouse is clicked on the element. The problem is that a tab stop cannot be set for an event. One solution is to put OnClick handlers on only those elements that automatically get tab stops: <A> tags, controls, and image maps. If you want to be able to click on some random text, surround it with an <A> tag and put the handler on the <A> tag.
<A href="" onclick="foo()" style="text-decoration: none; color: black">Click here</A>
To navigate via a tab to an anchor, you need to specify HREF="". You can tell you are on an anchor because anchors are typically displayed in blue and underlined (hyperlinks), and the cursor turns into a hand when it is over the link. Because anchors are normally links, clicking on the anchor usually causes the user to jump to a different Web page. To stop navigation, you need to set the returnValue to FALSE. or 0 by inserting a script between the <A> and </A> tags.
<SCRIPT language=javascript>
function foo()
{
alert("hi");
window.event.returnValue=0;
}
</SCRIPT>
All non-textual elements need captions. Non-textual elements include images, sounds, image maps (new for Internet Explorer 4.0), and intrinsic controls (these existed in Internet Explorer 3.0, but were extended for Internet Explorer 4.0). All elements support some type of ToolTip (i.e.: TITLE), so there's no reason not to use them.
All images should have alternate text.
<img src="logo.gif" alt="Microsoft Logo">
To add a caption to an image map (<AREA>) or sound (<BGSOUND>), use the new TITLE attribute.
<BGSOUND src="waterfall.wav" TITLE="Sound of falling water">
An intrinsic control is an element, such as a radio button or a text box. Intrinsic controls existed in Internet Explorer 3.0, but the HTML 3.2 specification did not support the association of text with a control. Internet Explorer 4.0 has more extensive support for intrinsic controls. You can now supply a caption for a control by using the <LABEL> tag to enclose the text associated with the control.
<INPUT type=radio id=radio1> <LABEL for=radio1> I'm the text for the first radio button </LABEL>
Discoverable access keys are also made possible in a Web page when LABEL or BUTTON is used. In the example below, note the addition of SPAN and Cascading Style Sheets-style text-decoration. The letter A will appear underlined and be available via the <ALT> + <A> key combination.
<INPUT type=radio id=radio1> <LABEL for=radio1>Choice <SPAN STYLE="text-decoration:underline">A</SPAN> </LABEL>
There are many ways to resize content. You can:
The best way to ensure that your pages are accessible is to test them in different size settings. The biggest area of concern is two-dimensional sizing. Objects positioned in pixels do not scale when the font size is changed, causing items to overlap. The solution to this problem is to specify 2D elements in "em" units. An em unit represents the size of the letter "m" in the current font. By using em units, you will know that the item will scale well with fonts. Of course, you still need to test it - specifying via em units doesn't relieve you of that responsibility.
If you are using Cascading Style Sheets (CSS) positioning, keep accessibility in mind. The Internet Explorer 4.0 object model supports some properties (i.e.: pixelLeft, pixelTop) to expedite your development. If you are using pixels, take advantage of these properties.
Aside from the recommendations given above, you need to keep a few other things in mind if you are creating a sophisticated Web application (known these days as a "weblication").
Microsoft provides an application programming interface (API) known as Active Accessibility 
(MSAA) that assists in creating accessible software. For example, MSAA allows an application to expose its contents to a screen-reader program. The screen-reader program can then read the Web page aloud to the user. This is very helpful to the blind or low-vision user.
As a general rule of thumb, if you are creating a new user interface based on Windows common controls, you probably don't have to worry about Active Accessibility. Accessibility is built in by default in the Windows common controls. If you cannot use the Windows common controls, be sure to implement Active Accessibility on your new user interface. You will need to ensure that you plan for this implementation and the testing of accessibility in your user interface.
If you decide to use a Windows common control in a way that the control was not designed to be used, check that you aren't sacrificing accessibility. For example, toolbars have no concept of hierarchy. So if you base a control on a toolbar, the control will not get exposed by default via Active Accessibility.
When you are designing a new feature, bear in mind that the user May not be able to use a mouse. Be sure that you design a keyboard method for accessing all elements or features. For example, ensure that accelerator keys exist for commands.
It's easier to make changes early in the development of a project than later on. You May be designing yourself into an accessibility nightmare, so be sure to begin your testing early. We've learned the hard way. But you can benefit from our mistakes. Here are some areas to check:
.
Internet Explorer 3.0 was a very accessible product,: It supported Active Accessibility and more. When Internet Explorer 4.0 was developed, many new features were added, but there were some problems with accessibility. The biggest? Version 4.0 did not support Active Accessibility. We were boneheads, and you let us know in a big way. The good news is that Internet Explorer 4.01 fixes this problem (and a few bugs).
Internet Explorer 4.01 provides new accessibility features that allow users to customize the appearance and behavior of Web pages, including the control of colors, font sizes, and font styles. Full keyboard accessibility is also provided in the update. This means that all objects on the Web pages on the Active Desktop interface can now be accessed using keystrokes instead of just a mouse, providing full access directly from the keyboard to all parts of the new shell.
Other accessibility features added in Internet Explorer 4.01 are:
Nancy Winnick Cluts, developer-technology writer to the stars, has recently moved to a very toney neighborhood, but to us she'll always be that winsome gal next door.
For more on making your Web pages accessible:
Microsoft Accessibility Home Page - To find out everything you can about Active Accessibility.
Microsoft Active Accessibility Page - To find out all about Active Accessibility and how to use it in your Web pages.
Trace Research and Development Center 
- Provides guidelines for the design of accessible Web pages, software, even such non-computer-related items as trails and housing.
Web Accessibility Initiative - The proposed standard for writing accessible HTML code.
Yuri Rubinsky Insight Foundation - Creators of the WebABLE accessibility Web site.
Photo Credit: Russell Illig/PhotoDisc; Neil Beer/PhotoDisc
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top