Sams Teach Yourself Web Publishing with HTML and CSS in One Hour a Day (5th Edition) P65 pot

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=" />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
.
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
/>If you maintain a personal site, you might also find Mark Pilgrim's online book, Dive Into
Accessibility (
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:
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]