| The way you design a Web site determines, to a very large extent, who is able to access that site. If you're concerned only about those with the latest version of your favorite browser and the fastest hardware and connection, there's no guarantee that you'll make a Web site that can be used by anyone who falls outside of those parameters. There's a very large group of users who tend to fall outside of nearly everyone's target audience when developers design for the Web users with disabilities. If you haven't thought about disabled Web users before, that's okay don't beat yourself up for it. It's hard to imagine some of the problems faced by disabled computer users unless you've experienced them yourself, usually through observation. Web users with visual disabilities are often stymied by Web pages that rely on images, color, or visual layout to convey the meaning of the site's content. Those with limited vision will have difficulties with low-contrast colors or small fonts. Deaf or hard-of-hearing users won't hear the sound tracks of multimedia. Users with limited physical dexterity might not be able to drop and drag or do other activities requiring a mouse. Pages with complex text that lack illustrations and summaries will be very difficult for users with cognitive disabilities. The Web isn't always easy to use if you have special needs. Some users, such as those who are blind, can rely on special assistive technologies such as screen readers, Braille displays, or screen magnifiers for Web access. However, these tools will work with your site only if you've carefully built your sites to allow access. TIP To learn more about how people with disabilities access the Web, visit the site of the International Center for Disability Resources on the Internet, at http://www.icdri.org/.
The process of creating a site that can be used by anyone regardless of disability is called accessibility. To properly create a Web site that is accessible, you'll need to know all about assistive technology, about how people with disabilities use the Web, and about how HTML and other Web languages function in browsers. You'll also need to be an expert on accessibility's close cousin, usability, which is the study of how people use computers effectively. Sound like a lot of work? Well, it is, believe me but fortunately you won't have to do all that work yourself. The knowledge you need to have to construct accessible Web sites has been codified into accessibility standards which function as a checklist of sorts, so that you simply have to follow these rules to produce a site with no barriers to access. Dreamweaver MX makes it even easier for you to follow those standards, because they're built right into the software itself. By using Dreamweaver MX's accessibility features to create and check your work, you can greatly simplify the process of creating accessible Web sites. Standards Resources When it comes to the World Wide Web, there is one primary source for nearly all of the standards you'll use the World Wide Web Consortium (W3C for short). The W3C is an international association of some of the major players in the Web, from browser makers to research organizations. The official specifications for HTML, XML, cascading style sheets (CSS), and other key Web technologies were created by the W3C's working groups and released as recommendations for adoption on the Web. TIP The W3C's Web site is located at http://www.w3.org/ and is the definitive source for Web specifications. However, most Web specifications are incredibly dry reading, and unless you're some sort of masochist, you won't want to dive right into them. A better idea is to start at the Web site of the Web Standards Project (http://www.webstandards.org/), a group of expert Web developers who promote standards compliance.
One branch of the W3C concerns itself exclusively with access by people with disabilities the Web Accessibility Initiative (WAI). Just as the W3C has produced standards for the HTML language, so has the WAI produced standards for accessibility. Web Content Accessibility Guidelines For Web developers, the most important WAI standards are contained in the Web Content Accessibility Guidelines (WCAG), which are a set of guidelines, checkpoints, and associated techniques that describe how to ensure the accessibility of your Web site. TIP You can read the full WCAG recommendation and download a checklist for easy reference from the W3C's Web site at http://www.w3.org/tr/wcag/.
The WCAG recommendation lists 14 basic principles, or guidelines, which promote accessibility: Provide equivalent alternatives to auditory and visual content. Don't rely on color alone. Use markup and style sheets and do so properly. Clarify natural language usage. Create tables that transform gracefully. Ensure that pages featuring new technologies transform gracefully. Ensure user control of time-sensitive content changes. Ensure direct accessibility of embedded user interfaces. Design for device independence. Use interim solutions. Use W3C technologies and guidelines. Provide context and orientation information. Provide clear navigation mechanisms. Ensure that documents are clear and simple. Each of these guidelines is supported by one or more checkpoints. For example, the checkpoints for guideline 2 ("Don't rely on color alone") are 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. 2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. Each checkpoint is given a priority value. A priority of one means that the failure to follow that checkpoint will exclude members of your audience with specific disabilities. Priority two checkpoints are designed to reduce the difficulty of access by people with disabilities, and priority three checkpoints actively improve the quality of access for individuals with special needs. In WAI terminology, if your site fulfills all the priority one checkpoints, it is said to be Single-A compliant with WCAG. Meeting all priority one and two checkpoints grants your site Double-A status; and successfully meeting all the checkpoints qualifies a site as Triple-A level. WCAG compliance levels have been accepted by many public and private organizations as the minimum requirement for sites they control. For example, California community college Web sites must meet at least WCAG Double-A standards, and the HTML Writers Guild (http://www.hwg.org/) has adopted Single-A accessibility requirements for official Guild sites. Section 508 In addition to being directly adopted, the WCAG standard has been used to create specialized Web accessibility policies. The most influential of these is the standard employed by the United States of America for most government Web sites. The requirements for federal sites are described in Section 508, subsection 1194, of the 1998 amendments to the Rehabilitation Act. That's a mouthful to say at once, so everyone simply refers to a set of requirements as Section 508. The aim of Section 508 is to ensure that government information technology is accessible to people with disabilities, both those working within federal agencies and those citizens who are using public Web resources. The Section 508 requirements for Web sites are modeled after the priority one checkpoints in WCAG, with a few modifications. Specifically, Section 508 adds some new requirements and eliminates a few priority checkpoints, while generally rewriting from the technical recommendation language of the W3C to the form of bureaucratic regulation favored in government work. TIP The official Web site for Section 508 is http://www.section508.gov/ but as with other standards sites, you might find more gentle introductions elsewhere. Jim Thatcher's Web site at http://www.jimthatcher.com/ contains indispensable advice on meeting 508 standards as well as Web accessibility in general, and it deserves a place in your bookmarks.
Which Standard to Follow? It's been said that the great thing about standards is that there are so many to choose from. Despite the humor of this statement, there's still some truth to it there's not one universal standard for accessibility but several, including Single-A WCAG, Double-A WCAG, Triple-A WCAG, and Section 508. The overlap between Single-A WCAG checkpoints and Section 508 requirements remains very strong, however, so the techniques used to make a site accessible by one standard will generally ensure that the other standard is met. The Double-A and Triple-A WCAG standards are harder to meet, because they go beyond basic accessibility and require that Web pages not be difficult to use. In some cases, you may be able to choose which standard to follow. Most commercial and personal Web sites are unregulated, and thus you can select your level of compliance. Many commercial sites will aim for Single-A compliance, but Double-A compliance improves site access for disabled users or employees. Private organizations or corporations that provide services to people with disabilities will want to achieve Triple-A compliance. As mentioned previously, public sector Web sites may have legal requirements for accessibility, depending on the location and type of public entity. For example, U.S. federal agencies such as the Department of Forestry are required to meet the Section 508 requirements, and universities in Australia must meet WCAG Double-A. Your organization's legal or disability officer can advise you on specific regulatory obligations that apply to your Web site. Conform with Standards Conforming with accessibility standards provides many benefits. Besides reducing your potential legal complications (especially if you are subject to specific requirements), it can also improve the overall usability of your site because the considerations needed for producing an accessible Web site will also lead to a site that is improved for everyone. For example, a transcript of an audio speech can benefit anyone accessing the Web from a quiet public library. Accessible standards also encourage designs that can be used on a diversity of Web access devices, including set-top boxes, Internet appliances, and PDAs. The same techniques that guarantee access for non-visual browsers also improve access for users of text-only cell phones. Creating an accessible Web site consists of ensuring that you've coded your site so that a broad audience can use it. Your audience will include not only traditional browsers and Web devices, but also specialized programs or hardware collectively called assistive technology. Examples of assistive technology include screenreaders, pointing devices, voice recognition software, screen magnifiers, Braille terminals, and onscreen keyboards. Assistive technologies are usually very innovative and clever approaches to overcoming obstacles, but like any computer feature, they can work only with what they're given, in terms of information. If a Braille terminal encounters an image that isn't labeled property (with an alt attribute), there's no way it can tell automatically if the image is a spacer GIF, a simple decoration, an important piece of content necessary for understanding the page, or a banner ad. As the author of a Web page, you can provide this necessary information so that the assistive technologies can function properly. Here's an example the Web page shown in Listing A.1 was created in Dreamweaver MX as an example of a straightforward design that nonetheless has serious accessibility problems for users with disabilities. Listing A.1 An Inaccessible HTML Page Made in Dreamweaver MX <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Re-Elect President Littletree!</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body> <img src="/books/4/291/1/html/2/littletree.gif" width="125" height="125" align="right"> <img src="/books/4/291/1/html/2/votebanner.gif" width="350" height="72"> <p>Do your patriotic duty as a loyal citizen and re-elect President Littletree when you vote! Remember, only TERRORISTS would even think of voting for the opposition!</p> <p><strong>Looking for an accessible voting place?</strong> All of the polling stations marked in <font color="#990000">RED</font> have special voting booths for the blind!</p> <div align="center"> <table border="3" cellpadding="3" cellspacing="3"> <tr> <td>Gorelick Observatory</td> <td><font color="#990000">Turner Morgan Memorial Park</font></td> </tr> <tr> <td>Bradford Avenue Park</td> <td><font color="#990000">R. Francis Smith Middle School</font></td> </tr> <tr> <td><font color="#990000">T.A. Baker Senior Center</font></td> <td>Corner of Plotnik and Knott</td> </tr> <tr> <td>Wetmore Dam Park</td> <td><font color="#990000">Lee-Barnsley College</font></td> </tr> </table> </div> <p><strong>Littletree's Most Recent Speech:</strong> <a href="speech04.wav">Listen now! (308K wav)</a></p> <hr> <p align="center"><font size="2"> <a href="mailto:web@reelectlittletree.com">web@reelectlittletree.com</a> </font></p> </body> </html> What does this page look like? It's fairly simple; see Figure A.1 for how it displays in a browser. It certainly doesn't look inaccessible at first glance. Figure A.1. This looks like a simple Web page on screen; how inaccessible could it be?
Note, however, that the red color used on the page doesn't reproduce well in a black-and-white screenshot. It's difficult to tell which polling locations are accessible to the blind. What would this site be like for blind users? To test, we'll use a text browser named Lynx (http://lynx.browser.org/) and view the page. Lynx displays all Web pages without images or colors, just as plain text. This is a useful approximation of what blind users experience when accessing a Web page. Most users who can't see will use a screenreader program that reads out loud the text from a browser (such as Internet Explorer or even Lynx) or a Braille display with raisable dots. Both of these methods are roughly equal to the text display of Lynx. Figure A.2 shows us some serious problems the banner at the top isn't identified beyond [IMAGE], and the color markings are clearly lost. Figure A.2. The page is inaccessible when viewed in Lynx, a text browser.
A further problem exists but may not be immediately obvious the speech link presents a problem to deaf users. Because the text of the speech is only available in a WAV file, anyone who is unable to hear sounds won't be able to know what this candidate stands for. In Listing A.2, you can see a revised version of the page. This version was created by using the built-in accessibility check function in Dreamweaver MX, which is covered later in this appendix. The changes to the source code are shown in bold. Listing A.2 An Accessible Version of the Page in Listing A.1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Re-Elect President Littletree!</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style type="text/css"> <!-- .access { color: red; } .footer { font-size: smaller; text-align: center; } --> </style> </head> <body> <img src="/books/4/291/1/html/2/littletree.gif" width="125" height="125" align="right" alt="President N.K. Littletree" longdesc="littletree_longdesc.html"> <h1><img src="/books/4/291/1/html/2/votebanner.gif" width="350" height="72" alt="Vote for President Littletree!"></h1> <p>Do your patriotic duty as a loyal citizen and re-elect President Littletree when you vote! Remember, only TERRORISTS would even think of voting for the opposition!</p> <p><strong>Looking for an accessible voting place?</strong> All of the polling stations followed by [Accessible] have special voting booths for the blind!</p> <div align="center"> <table border="3" cellpadding="3" cellspacing="3"> <tr> <td>Gorelick Observatory</td> <td><span >Turner Morgan Memorial Park</span> [Accessible]</td> </tr> <tr> <td>Bradford Avenue Park</td> <td><span >R. Francis Smith Middle School</span> [Accessible]</td> </tr> <tr> <td><span >T.A. Baker Senior Center</span> [Accessible]</td> <td>Corner of Plotnik and Knott</td> </tr> <tr> <td>Wetmore Dam Park</td> <td><span >Lee-Barnsley College</span> [Accessible]</td> </tr> </table> </div> <p><strong>Littletree's Most Recent Speech:</strong> <a href="speech04.wav">Listen now! (308K wav)</a> <a href="speech04.html">Read the transcript!</a></p> <hr> <p > <a href="mailto:web@reelectlittletree.com">web@reelectlittletree.com</a> </p> </body> </html> You'll notice that several new attributes such as alt and longdesc have been added. The word [Accessible] has been used to mark special voting sites, and a transcript link was placed after the audio file link. Also, <font> tags have been replaced with CSS styles. The revised page is shown in Figure A.3 in Lynx; although the changes aren't dramatic, they are enough to allow a broader group of users (and voters!) to access the page. Figure A.3. Lynx now can view the page, as can many users with disabilities.
Apply Standards to New Designs It's always easiest to make a Web page or Web site accessible from the start and not have to spend time going back and redoing it from scratch. The effort of retrofitting is much harder than doing it right the first time. Dreamweaver MX makes it easier to build accessible Web sites by providing accessible templates and by prompting you for necessary information when adding new HTML elements. Accessible Design Templates Dreamweaver MX comes with a default set of page designs; unfortunately, the basic page designs weren't created with accessibility in mind. Fortunately, an additional set of page designs were provided that include accessibility features such as <label> tags and variable font sizes, which allow you to set up an accessible page easily. To use one of these templates, open a new file by going to File and selecting New. Select the category Page Design (Accessible) and you'll see a list of page types that can be used. Select one as shown in Figure A.4, open it up, and you're ready to start. Figure A.4. Choose an accessible template as a starting point for a new Web page.
CAUTION Merely using an accessible template does not guarantee that the final result will be accessible. You'll need to use the accessibility checker, described later in this appendix, and you should test your page carefully.
Accessibility Dialog Boxes Dreamweaver MX also provides for a way to automatically be prompted for required accessibility information via dialog boxes. By default, these dialog boxes are turned off, but you can turn them on to ensure that you don't leave out any important attributes or tags. Go to the Preferences menu and select Accessibility. You'll see the Options panel shown in Figure A.5. Figure A.5. Setting the accessibility options turns on accessibility dialog boxes.
Each of the five options Images, Frames, Forms, Media, and Tables turns on a different dialog box. When you insert one of those elements in your page, the dialog box will appear and prompt you for information. For example, if you try to add an image, you'll see the dialog box pictured in Figure A.6. Figure A.6. The accessibility prompt for images requests alt and longdesc attributes.
Each dialog box requests a different set of accessibility related attributes or information. These are shown in Table A.1. Table A.1. Accessibility Dialog Boxes Are Activated by Setting Accessibility Options | Option (HTML Tag) | Accessibility Attributes | | Image (<img>) | Alternative text (alt), Long Description (longdesc) | | Frame (<frame>) | Frame Title (title) | | Form (<input>, <textarea>) | Label (<label>), Style (nesting of <label>), Position (location of <label>), Access Key (accesskey), Tab Index (tabindex) | | Media (<object>) | Title (title), Access Key (accesskey), Tab Index (tabindex) | | Table (<table>) | Caption (<caption>), Align Caption (<caption align>), Summary (summary), Header (scope) | You're probably already familiar with the alt attribute; this is a text replacement for the image. An alt attribute isn't a description of the image, but a functional replacement for it. If the image has no function beyond decoration, the alt value should be alt="". For little bullet icons, use alt="*", not alt="red circle". And definitely don't use the name of graphic, such as alt="redbullt.jpg". NOTE Many people erroneously refer to "alt tags" but alt is an attribute, and <img> is the tag. If you really want to bug the living daylights out of your least favorite HTML pedant, talk about "alt tags" constantly, but if you want to look like you're part of the markup intelligentsia, call it an alt attribute.
The longdesc attribute is used to provide a description of an image; unlike alt, longdesc is not a text value, but the URL of a page which describes the image in text. A longdesc should be used if the image contains information that isn't shown by the alt text, such as a chart or a graph. It can also be used to describe the contents of photographs or paintings. The title attribute is a name or short description of a frame or object that is meant to be read to a human. A frame usually has a name attribute, but this is used by the browser to identify the frame and isn't necessarily written to make sense to the user. For example, name="mnnav" is confusing. The title should be clear and understandable and describe the function of the frame or object, such as name="Main Navigation Panel". The accesskey and tabindex attributes are used to enable improved keyboard navigation. The accesskey attribute designates a specific key that can be pressed in conjunction with the modifier key usually the control or alt key to activate a link or object. The numbers 1 through 0 work best for accesskey values. The tabindex key sets an order for tabbing through links and objects; pressing the Tab key advances you through the page in order of the tabindex attributes. The <label> tag provides a text label for form controls, such as text fields or check boxes. You can determine the position of the label tags using the label settings on the dialog box. The <label> is important for screenreader users who need to know what each form field does when they can't rely on visual layout clues. Tables have a number of attributes, such as scope and summary, that can be used to describe the relationship between the table header and the contents of the table cells. In addition, the <caption> tag can be used to add a caption to the table. TIP For more information on HTML tags and attributes used to make pages more accessible, be sure to visit the excellent accessibility tutorials at the Web Accessibility In Mind (WebAIM) site, http://www.webaim.org/.
Apply Standards to Existing Sites As noted earlier, it's more efficient to build a site accessibly from the beginning. However, you may be dealing with older sites that need to be updated, or even sites you didn't design and have inherited responsibility for. Dreamweaver MX assists you in bringing these existing pages up to compliance with the accessibility standards through accessibility reports which analyze your page, looking for specific problems. You can even run reports on all pages in one folder on your hard drive or on the entire Web site. Check Accessibility The accessibility report built in to Dreamweaver MX is set to check against both the WCAG and Section 508 standards. The WCAG standard is checked against only level Single-A accessibility; Double-A and Triple-A checkpoints aren't tested. To check the accessibility of a page you're working on, first save the page. Then select the Check Page submenu from the File menu; the first choice is Check Accessibility, as shown in Figure A.7. Selecting this option will generate an accessibility report on your existing page. Figure A.7. The Check Accessibility function can be found in the File menu.
NOTE The Check Accessibility function can be used only after you've saved the file you're working on. If you don't save before checking, the accessibility report won't reflect any recent changes.
An example of the output of an accessibility report can be seen in Figure A.8 this report was run on the Web page in Listing A.1, the uncorrected campaign page. Figure A.8. The accessibility report identifies problems and potential problems.
The accessibility check function runs an analysis of each part of your Web page, testing it against certain criteria called accessibility checks. For each one, it gives one of three results: pass, fail, or can't determine. If your page fails a check, you'll need to correct that to improve the accessibility of the page. A failed test is represented by a red X in the accessibility report. WARNING An automated checking program can do only so much; there's no perfect way to make software fix Web pages. It's possible for a page to pass every automated test and still be inaccessible. For this reason, you may want to read up on more accessibility techniques at the W3C's Web Accessibility Initiative site (http://www.w3.org/WAI/) and consider acquiring for your own testing purposes one of the programs used by people with disabilities.
Manual Checks If the accessibility report has a question mark for the result of a test, that indicates that human judgment is necessary to determine if a test was passed. This is known as a manual check. A good example of a manual check is the alt attribute for an image. The computer can tell if the <img> tag has an alt attribute, but it isn't able to determine whether the alt attribute is accurate. The purpose of the question mark is to tell you to evaluate the question yourself to determine if accessibility problems occur on the page. Sitewide Accessibility Reports To test a large number of Web pages, you don't have to individually load each one and run an accessibility report. Instead, you can simply use the Macromedia site report function. This lets you select whether to run an accessibility report on the current page, the entire Web site you're working with, selected files in that site, or all the Web files in a folder. To use the site reports, choose Reports from the Site menu. You'll see the choices shown in Figure A.9. Be sure to check the box for Accessibility and choose the appropriate files to test from the pull-down menu. Figure A.9. You can test an entire site or a folder of HTML pages at once via the site reports function.
The accessibility report shown in Figure A.10 resulted from checking all the files within one folder. Figure A.10. The accessibility report for an entire Web site.
In addition to specifying the files to be checked, you can also set the report parameters to include or exclude certain accessibility checks. By default, the accessibility report checks both the WCAG Single-A standard and the Section 508 standard. To change this, highlight the accessibility report option by clicking on the word Accessibility, and then click the Report Settings button. This calls up the choices shown in Figure A.11. You can toggle open the list of options by clicking the triangles beside each category. Using the Enable or Disable buttons, you can customize your report to check only the tests, or groups of tests, that matter to you. You can also set the report to list all checks performed, not just those that were failed or that need human judgment. Figure A.11. You can turn off or on specific accessibility tests in the report options.
TIP If you need more advanced accessibility evaluation and repair features, you may want to look at LIFT for Macromedia Dreamweaver, by UsableNet. This add-on for Dreamweaver MX sells for around $300 and can automate your accessibility upgrade process. For more details, see http://www.usablenet.com/lift_dw/lift_dw.html on the Web.
| 
