Writing Accessible HTML Writing Accessible HTML When it comes to writing accessible HTML, there are two steps to follow. The first step is to use the same tags you normally use as they were intended. The second step is to take advantage of HTML features specifically designed to improve accessibility. I've already mentioned a number of times that tags should be used based on their semantic meaning rather than how they're rendered in browsers. For example, if you want to print some bold text in a standard size font, <h4> will work, except that it not only boldfaces the text, it also indicates that it's a level 4 heading. In screen readers or other alternative browsers, that might cause confusion for your users. Tables This problem is particularly acute when it comes to tables. I've already mentioned that it's not a good idea to use tables for page layout when you're designing for accessibility. Alternative browsers must generally indicate to users that a table has been encountered, and then unwind the tables so that the information can be presented to the user in a linear fashion. To make things easier on these users, you should use tables as intended where you can. Even if you can't avoid using tables to lay out your page, be aware of how the table will be presented to users. If possible, try to avoid putting lots of navigation text and other supplemental text between the beginning of the page and the content the user is actually looking for. When you're presenting real tabular data, it's worthwhile to use all of the supplemental tags for tables that are all too often ignored. When you're inserting row and column headings, use the <th> tag. If the default alignment or text presentation is not to your liking, use CSS to modify it. Some browsers will indicate to users that the table headings are distinct from the table data. Furthermore, if you label your table, using the <caption> tag is a better choice than simply inserting a paragraph of text before or after the table. Some browsers indicate that the text is a table caption. Finally, using the summary attribute of the <table> tag can be a great aid to users with alternative browsers. How you use the summary and caption are up to you. The caption can explain what the table contains, and the summary can explain how the data in the table is used if it's not obvious from the row and/or column headings. Here's an example of a table that's designed for accessibility: <table summary="This is the famous Boston Consulting Group Product Portfolio Matrix. It's a two by two matrix with labels." border="1" cellpadding="12"> <caption>Boston Consulting Group Product Portfolio Matrix</caption> <tr> <td colspan="2" rowspan="2"><br /></td> <th colspan="2">Market Share</th> </tr> <tr> <th>High</th> <th>Low</th> </tr> <tr> <th rowspan="2">Market Growth</th> <th>High</th> <td align="center">Star</td> <td align="center">Problem Child</td> </tr> <tr> <th>Low</th> file:///G|/1/0672328860/ch17lev1sec7.html (1 von 3) [19.12.2006 13:49:59] Writing Accessible HTML <td align="center">Cash Cow</td> <td align="center">Dog</td> </tr> </table> Links As mentioned in Lesson 16, "Writing Good Web Pages: Do's and Don'ts," avoiding the "here" syndrome is imperative, particularly when it comes to accessibility. Having all the links on your page described as "click here" or "here" isn't very helpful to disabled users (or any others). Just thinking carefully about the text you place inside a link to make it descriptive of the link destination is a good start. To make your links even more usable, you can employ the title attribute. The title attribute is used to associate some descriptive text with a link. It is used not only by alternative browsers, but many standard browsers will display a tool tip with the link title when the user holds her mouse pointer over it. Here are some examples: <a href="http://www.dmoz.org/" title="The volunteer maintained directory.">dmoz</a> <a href="document.pdf" title="1.5 meg PDF document">Special Report</a> Navigational links are a special case because they usually come in sizable groups. Many pages have a nice navigation bar right across the top that's useful to regular users who are able to skim the page and go directly to the content that they want. Users who use screen readers with their browsers and other assistive technologies aren't so lucky. You can imagine what it would be like to visit a site that has 10 navigational links across the top of the page if you relied on every page being read to you. Every time you move from one page to the next, the navigation links would have to be read over again. There are a few ways around this that vary in elegance. If you're using CSS to position elements on your page, it can make sense to place the navigational elements after your main content in your HTML file, but use CSS to position them wherever you like. When a user with a screen reader visits the site, he'll get the content before getting the navigation. Another option is to include a link on your page that enables the user to skip past the navigationyou can use CSS to hide this link from users who can see the page, leaving it in place for disabled users who can benefit from it. Tip It's worth remembering that many disabled users rely on keyboards to access the Web. You can make things easier on them by using the accesskey and tabindex attributes of the <a> tag to enable them to step through the links on your page in a logical order. This is particularly useful if you also include forms on your page. For example, if you have a form that has links interspersed in the form, setting up the tabindex order so that the user can tab through the form completely before he runs into any links can save him a lot of aggravation. This is the sort of convenience that all of your users will appreciate as well. Images Needless to say, images are a sticky point when it comes to accessibility. Users with impaired vision file:///G|/1/0672328860/ch17lev1sec7.html (2 von 3) [19.12.2006 13:49:59] Writing Accessible HTML may not be able to appreciate your images at all. However, clever design and usage of the tools provided by HTML can, to a certain degree, minimize the problem of image usage. Images are known for having probably the best-known accessibility feature of any HTML element. The alt attribute has been around as long as the <img> tag and provides text that can stand in for an image if the user has a text-only browser or the image wasn't downloaded for some reason. Back when everybody used slow dialup connections to the Internet, it was easy to become intimately familiar with alt text because it displayed while the images on a page downloaded. Later, some browsers started showing alt text as a tool tip when the user let her mouse pointer hover over an image. Despite the fact that alt text is useful, easy to add, and required by the XHTML 1.0 specification, many pages on the Internet still lack meaningful alternative text for most (if not all) of their images. Taking a few extra minutes to enter alt text for your images is a must for anyone who uses HTML that includes images. Also bear in mind that using alt="" is perfectly valid and is sometimes appropriate. In particular, some sites use very small images to help position elements on a page. Although this practice is strongly discouraged, it's still used. Text-based browsers will, in the absence of alt text, generally display something like [IMAGE] on the page. If you include the alt attribute but leave it empty, the label IMAGE will be left out, making things easier on your users. HTML also provides an another way of describing images that's meant to improve accessibility: the longdesc attribute of the <img> tag. The longdesc attribute is intended to be used as a place to enter long descriptions of images. For example, if an image is a chart or graph, you can explain how it is used and what information it is intended to convey. If the picture is a nice photo of a waterfall, you can describe the waterfall. In many cases, images are used simply to make web pages flashier or aesthetically pleasing, and nothing more than alt text is required. However, when the actual meaning of a page is conveyed through the use of images, providing descriptions of those images is a key to accessibility. For example, let's say that you're working for a financial publication, and a story on the declining stock market includes a graph showing the consistent decline of the major indexes over the past few years. In print, that image would probably include a caption explaining what's in the image. On the Web, you could put that caption in the image's longdesc attribute. Or, if you prefer, you could put it on the page as a caption, as long as your layout indicates in some way that the caption refers to the image in question. Here's an example of what I'm talking about: <img src="graph1.gif" longdesc="Graph showing that the S&P 500 and Dow Jones Industrial Average have dropped an average of 20% annually over the last 3 years." /> There's one final area to discuss when it comes to imagesthe marriage of images and links in the form of image maps. As you might imagine, image maps can be a major accessibility issue. The only way around this is to provide users with an alternative to imagemaps in the form of text links. Whenever you use an image map, you should make sure to include text equivalents of the links somewhere on the page. file:///G|/1/0672328860/ch17lev1sec7.html (3 von 3) [19.12.2006 13:49:59] Designing for Accessibility Designing for Accessibility Just as important as taking advantage of the HTML features provided specifically for accessibility is taking care to design your pages in a manner that's as accommodating as possible for users who are in need of assistance. Most of these techniques are relevant to all users, not just those using alternative browsers or assistive technologies. Use Color A common pitfall designers fall into is using color to confer meaning to users. For example, they print an error on the page and change the font color to red to indicate that something went wrong. Unfortunately, visually impaired users won't be able to distinguish your error message from the rest of the text on the page without reading it. Needless to say, putting two elements on the page that are the same except for color (such as using colors to indicate the status of something) is not accessible. You can add borders to elements that need to stand out, or you can label them with text. For example, you might display an error message this way: <p class="error">ERROR: You must enter your full name.</p> Fonts When you specify fonts on your pages, you can cause accessibility problems if you're not careful. In some cases, font specification doesn't matter at all because the user accesses your site with a screen reader or alternative browser that completely ignores your font settings. However, users who simply see poorly can have an unpleasant experience if you set your fonts to an absolute sizeparticularly if you choose a small size. If a user has set his browser's default font to be larger than normal, and your pages are hard coded to use 9-point text, that user will probably dump your site altogether. In many cases, it makes sense to leave the default font specification alone for most of the text on your site. That way, users can set their fonts as they choose, and you won't interfere with their personal preferences. If you do modify the fonts on the page, make sure that the fonts scale with the user's settings so that they can see the text at a size that is comfortable for them. Take Advantage of All HTML Tags It's easy to fall into the trap of using <i> or <b> instead of more specific tags when you need to add emphasis to something. For example, let's say you're citing a passage from a book. When you enter the book title, you could indicate to your users that it's a proper title by putting it inside the <i> tag, or you could use the <cite> tag. There are plenty of other underutilized tags as well, all of which provide some semantic meaning in addition to the text formatting they're associated with. Even in cases in which you really just want to emphasize text, it's preferable to use <em> and <strong> over <i> and <b>. These tags provide a lot more meaning than the basic text formatting tags that are often used. Not all alternative browsers will take advantage of any or all of these tags, but conveying as much meaning as possible through your choice of tags won't hurt accessibility for sure, and will help some now and could help more in the future. There's no downside to taking this approach, either. Frames and Linked Windows file:///G|/1/0672328860/ch17lev1sec8.html (1 von 2) [19.12.2006 13:50:00] Designing for Accessibility Frames are, to put it bluntly, a barrier to accessibility. There are some workarounds available, but the bottom line is that if you're really concerned about accessibility, you should probably avoid frames. Using linked windows and pop-up windows can also be a huge hassle from an accessibility perspective. If you opt to use frames, you should include titles for all of your frames, not just the document containing the frameset. Using regular browsers, the titles of these documents are suppressed. That's not necessarily the case with alternative browsers. Some will provide links to the individual frames when you pull up the frameset, and having titles makes it easier for users to distinguish between them. Forms Forms present another thorny accessibility issue. Nearly all web applications are based on forms, and failure to make them accessible can cost you users. For example, large online stores have a serious financial interest in focusing on form accessibility. How many sales would Amazon or eBay lose if their sites weren't accessible? Some work on making sure the forms that enable you to purchase items are accessible can really pay off. One key thing to remember is that disabled users often navigate using only the keyboard. As I mentioned when talking about links, assigning sensible tabindex values to your form fields can really increase both the usability and accessibility of your forms. The other advanced form tags, such as fieldset, optgroup, and label, can be beneficial in terms of usability as well. file:///G|/1/0672328860/ch17lev1sec8.html (2 von 2) [19.12.2006 13:50:00] Validating Your Sites for Accessibility Validating Your Sites for Accessibility There's no reason to rely on luck when it comes to determining whether your site measures up when it comes to accessibility. Just as you can use the W3C validator to verify that your HTML files are standards compliant, you can use the WebXACT, the accessibility validator, to determine how well a page complies with accessibility guidelines. The validator can be found at http://webxact.watchfire.com. It can validate a site against the Section 508 guidelines mentioned earlier, or against the Web Content Accessibility Guidelines developed by the W3C. Its operation is virtually identical to that of the HTML validator provided by the W3C. If you submit your page to the validator, it will generate a report that indicates which areas of your page need improvement, and will also provide general tips that can be applied to any page. It also prints out the full content of the page and adds in links to the report so that you can see exactly which places on the page the report refers to. Figure 17.5 is a screenshot of WebXACT's report on the digg.com page. Figure 17.5. An accessibility report generated by WebXACT. [View full size image] Another nice feature of WebXACT is that the report contains links to specific ways to address the issues it raises. For example, Figure 17.6 is the page that WebXACT links to when you have repetitive navigation links on a page. Figure 17.6. Advice from WebXACT on how to fix an accessibility issue. file:///G|/1/0672328860/ch17lev1sec9.html (1 von 3) [19.12.2006 13:50:00] Validating Your Sites for Accessibility [View full size image] WebXACT is provided free of charge by Watchfire, which is in the business of providing website management tools. The downside of the free version is that it validates only one page at a time. This isn't as bad as it sounds because most larger sites have a lot of common markup from page to page so if you fix an issue in one place, you can often fix it on all of your pages. However, Watchfire also offers commercial versions of WebXACT that can be installed on a server or used by a single user to validate entire sites. Further Reading This lesson is really the tip of the iceberg when it comes to handling accessibility on websites. If you're going to make a commitment to creating an accessible site, you'll probably want to research the issue further. Your first stop should be online accessibility resources. The W3C provides a huge body of information on accessibility as part of their Web Accessibility Initiative. The home page is http://www.w3.org/WAI/. If you maintain a personal site, you might also find Mark Pilgrim's online book, Dive Into Accessibility ( http://diveintoaccessibility.org/), to be a useful resource. There are plenty of other sites that discuss accessibility as well. Just enter the word accessibility into your favorite search engine to get a list. The WAI also provides a list of resources at http://www. w3.org/WAI/References/. There have also been several books written on web accessibility. Joe Clark's Building file:///G|/1/0672328860/ch17lev1sec9.html (2 von 3) [19.12.2006 13:50:00] Validating Your Sites for Accessibility Accessible Websites is very well regarded. You can find out more about the book at the book's website: http://www.joeclark.org/book/. Other books include John Slatin and Sharon Rush's book, Maximum Accessibility: Making Your Web Site More Usable for Everyone, or Constructing Accessible Web Sites, which is a group effort from Glasshaus. file:///G|/1/0672328860/ch17lev1sec9.html (3 von 3) [19.12.2006 13:50:00] Summary Summary HTML 4.01 and XHTML 1.0 accommodate the needs of many visitors by providing three different approaches to website design. Hopefully, you now realize that the needs of your visitors also can affect the approach you use in your website design. The key is to anticipate those needs and try to address them as broadly as possible. Not every site has to be filled with multimedia that implements the latest and greatest web technologies. On the other hand, certain topics almost demand higher levels of page design. Listen to the needs of your visitors when you design your pages, and you'll keep them coming back. Even though accessibility issues ostensibly affect only a small percentage of web users, they should not be ignored. Many accessibility-related improvements actually improve the web experience for most users. Leaving out disabled users by not accounting for them in your designs is inconsiderate, and can often be a poor business decision as well. Adding accessibility features to an existing site can be challenging, but when you build new sites from scratch, making them accessible can often be done with little additional effort. If I've convinced you of the importance of accessibility in this lesson, you'll probably want to dig into the resources listed previously for more information. file:///G|/1/0672328860/ch17lev1sec10.html [19.12.2006 13:50:00] Workshop Workshop As if you haven't had enough already, here's a refresher course. As always, there are questions, quizzes, and exercises that will help you remember some of the most important points in this lesson. Q&A Q Feedback from visitors to my site varies a lot. Some want my pages to use less multimedia, whereas others want more. Is there an easy way to satisfy both of them? A You've already learned that you can provide links to external multimedia files. This is the best approach for visitors who want less multimedia because they won't see it unless they click the link. You can also simply ask them which version of your site they want to see. I generally recommend building a site that works well for users regardless of their connection speed or browser capabilities, but in some cases it makes sense to create alternative versions of your site. You can start out with an entry page that allows your users to choose between the different versions of the site, or you can start out with the fancier page and provide a link to the text version that shows up regardless of their browser's capabilities. Q I use a lot of external files on my website, and they can be downloaded from several different pages. Wouldn't it be more efficient to include a link to the correct readers or viewers on the pages where the external files appear? A Although it's much easier for the visitor to download an external file and the appropriate reader or helper application from the same page, it might be more difficult for you to maintain your pages when the URLs for the helper applications change. A good compromise is to include a Download page on your website with links to all the helper applications that the visitor will need. After the visitor downloads the external file, she can then navigate to your Download page to get the helper application she needs to view that file. Q If I don't make my site accessible, what percentage of my audience will I lose? A Even if you weren't wondering about this yourself, there's a good chance your boss probably wants to know. Unfortunately, there's no hard and fast number. I've seen it reported that 10% of the population has disabilities, but not all of those disabilities affect one's ability to access the Web. file:///G|/1/0672328860/ch17lev1sec11.html (1 von 4) [19.12.2006 13:50:01] . <table> tag can be a great aid to users with alternative browsers. How you use the summary and caption are up to you. The caption can explain what the table contains, and the summary can. the waterfall. In many cases, images are used simply to make web pages flashier or aesthetically pleasing, and nothing more than alt text is required. However, when the actual meaning of a page. market includes a graph showing the consistent decline of the major indexes over the past few years. In print, that image would probably include a caption explaining what's in the image.