Validation of one's HTML documents is perhaps the most important, and the easiest, thing that an author can do to aid accessibility. A validator checks the document's HTML against a document type definition to ensure that the syntax of the HTML is correct.
Forgetting a quotation mark or using the wrong attribute value is often very easy to do when writing HTML. While many browsers will recover from authoring errors, the way in which they recover tends to differ, and new versions of a browser may change the error recovery method. An excellent example is the change in behavior from Netscape 1.22 to Netscape 2.0; Netscape 1.22 did not care if the author forgot the closing quote in code such as <A HREF="oops.html>Oops</A>, but Netscape 2.0 required the closing quotation mark. A document that had been validated would be fine under either browser, but a document which the author had just visually checked under Netscape 1.22 was often missing half its content in Netscape 2.0.
The WDG HTML Validator should be used to check Web pages. Be wary of programs that falsely claim to be validators; while document checkers or lints can be valuable tools, they are not substitutes for HTML validation.
Wherever possible, Web pages should be platform independent, meaning that they should be accessible regardless of the user's platform and settings. While validation is a key step in ensuring platform independence, it alone is not sufficient. Authors should also take care to ensure that Web pages are not dependent on a certain resolution, color depth, font size, or window size.
Authors concerned about their documents' accessibility are encouraged to view their pages with varying resolution, color depth, font size, and window size. Well-authored pages will adjust and remain accessible in any browsing environment. Authors can also view their Web pages on numerous browsers (preferably including a text-only browser like Lynx), and can have a friend read their Web pages aloud to simulate how blind or in-car users might hear the pages. Two helpful tools for authors in evaluating the platform independence of a Web site are the Web Page Purifier and Web Page Backward Compatibility Viewer.
Since people access the Web in different ways, platform-dependent phrases should be avoided. For example, "click here" is inappropriate to anyone without a mouse, and is also useless when a link anchor is read aloud or printed at the end of a document as a summary. Authors should also avoid phrases like "see below" since "below" is meaningless when a document is spoken aloud.
When writing HTML, authors should concentrate on the structure of the document rather than its presentation. A document marked up structurally can easily adapt to different browsing environments. When composing HTML, authors should think about what the content means instead of how it should look. If you want text to be bold, think about why you want this style; if what you really want is to express emphasis or strong emphasis, use HTML's EM or STRONG elements.
The FONT element is commonly misused when strong emphasis or a heading is the intended meaning. Rather than <FONT COLOR=red>Warning!</FONT>, use <STRONG CLASS=warning>Warning!</STRONG> with .warning { color: red; background: transparent } defined in a style sheet.
Some HTML presentation attributes, such as the ALIGN attribute, can safely be used as presentation suggestions. In general, style sheets provide a more flexible solution that favors both authors and users. To maintain accessibility, documents should never be dependent on a particular presentation, including one achieved through style sheets.
When using the IMG or AREA elements, authors should always use the ALT attribute to provide a textual alternative. The ALT attribute is presented to those not loading images--estimated to account for 30% of all Web users.
The ALT attribute is best used to provide the function of the image rather than a description of the image. For example, ALT="Welcome to the Web Design Group" is more useful to those not loading images than ALT="Web Design Group logo". In general, users of a text-only browser like Lynx should be unaware that there are any images on the page, unless the image is content that cannot be completely replaced with text. In this case, such as in a photo album or art gallery, the image's function and description are essentially the same thing, and so a description of the image would be appropriate for the ALT text.
Images that are purely decorative should use ALT="" to indicate explicitly that the image is not content. Decorative bullets should be replaced with ALT="*" or something similar--not ALT="Round yellow bullet". When images are alongside text or other images, some form of separation may be necessary, such as ALT=" [Photograph of me] " or ALT="Web Design Group ~".
For a thorough discussion of the ALT attribute, see the article Use of ALT texts in IMGs.
Images of text are quite common on the Web, but they can be difficult for those with poor vision or with high resolutions on small monitors. In HTML, text is sized according to the user's preferred font size, but when using images of text the author must choose an absolute font size in pixels for the user. Since different users have different tastes, trying to guess a suitable font size is not a good idea. Thus, authors should avoid using images of text as much as possible.
Cascading Style Sheets can often be used to provide attractive text without the need for images. With CSS, the author can suggest numerous physical properties of text, including its font, color, background, letter spacing, and more.
Image maps are problematic because of their poor support for those not loading images. When using an image map, one should use a client-side image map in combination with a server-side image map wherever possible. With client-side image maps, the ALT attribute of the AREA element should always be used.
Image maps should be avoided when they are not "natural." For example, most graphical toolbars could more easily and more efficiently be created using a number of separate images or simply using text. On the other hand, an image map for linking to organs of the body, or an image map linking to regions of a country, would be natural and less contrived than the graphical toolbars common on the Web. If feasible, a textual alternative would be helpful in these cases.
If setting colors using HTML's BODY attributes, an author should specify all color attributes. By specifying only one or a few of BGCOLOR, TEXT, LINK, VLINK, and ALINK, authors risk an inaccessible document since the user's chosen colors may be unreadable against the author's specified colors. As an author, do not assume that users have the same browser settings as you.
BODY colors should always be specified with a hexadecimal triplet in the form #rrggbb or #RRGGBB since older browsers do not support color names. Netscape 1.22 will interpret all color names as blue.
Authors who specify a background image using BODY's BACKGROUND attribute should also specify all color attributes. Be sure to select a BGCOLOR that will be readable against the text colors, since those not loading images will see the background color in place of the background image.
HTML's FONT element (and its cohort BASEFONT) should generally be avoided in creating accessible Web sites. While attribute specifications like SIZE="+1" or SIZE="-1" are relatively harmless, absolute sizes like SIZE=1 can result in text that is too small to read. Style sheets allow authors to suggest relative changes in font size with much greater flexibility than is allowed under FONT.
The FONT element's COLOR attribute should always be avoided since many supporting browsers still honor the font color when the user tries to override author-specified colors. The result could be an unreadable document if the font color does not contrast well against the reader's chosen background.
The FACE attribute of the FONT element can also not be overridden by the user in many supporting browsers. This may result in the browser choosing a font that is very difficult to read given the user's platform and environment settings. Remember that the same font may look very different on platforms other than your own.
The FACE attribute should also not be used in an attempt to get Greek letters, mathematical symbols, or dingbats. The FONT element only suggests a presentation, so the content should still make sense in the absence of that presentation. Browsers should not render <FONT FACE=Symbol>a</FONT> as the Greek letter alpha; this bug may be corrected in the future.
For a more in-depth discussion of the FACE attribute, see <FONT FACE> considered harmful. Another excellent discussion on the FONT element is Warren Steel's What's Wrong With FONT?.
Authors should avoid using tables simply for layout as much as possible. Unfortunately, completely avoiding tables for layout can limit an author's flexibility since CSS layout methods are not supported well enough to fully replace tables. When using tables for layout, authors should keep the following ideas in mind:
JavaScript (or JScript or VBScript) is not supported by all browsers and some users choose to disable it. When JavaScript is used, it should not be relied upon.
For example, when using JavaScript to open a small popup window from a link, authors should not use
<A HREF="javascript:window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120')">
since the link will fail to function for those without JavaScript enabled. The following would work in all browsers:
<A HREF="foo.html" ONCLICK="if (window.open) { window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120'); return false; }">
Accessibility Index ~ Why Write Accessible Pages? ~ Accessibility Myths
Copyright © 1996 - 2006. Liam Quinn. All rights reserved.