As part of their ongoing efforts to pursue and promote accessibility, the Web Accessibility Initiative ([WAI]), joined forces with the W3C HTML Working Group in the design of [HTML4.0], which became a W3C Recommendation in December, 1997. For this latest release of the World Wide Web's publishing language, the WAI group sought remedies for a number of authoring habits that cause problems for users with:
In particular, the WAI group addressed:
In the following sections, we look at how WAI contributions to HTML 4.0 (in conjunction with style sheets) allow authors to avoid accessibility pitfalls even as they create more attractive, economical, and manageable pages.
Highly structured documents are more accessible than those that aren't, so HTML 4.0 has added a number of elements and attributes that enrich document structure. The new constructs will also allow software tools (e.g., search robots, document transformation tools, etc.) to extract more information from these documents. The following structural elements are new in HTML 4.0:
HTML was not designed with professional publishing in mind; its designers intended it to organize content, not present it. Consequently, many of the language's presentation elements and attributes do not always meet the needs of power page designers. To overcome layout limitations, the W3C HTML Working Group decided not to add new presentation features to HTML 4.0, but instead to assign the task of presentation to style sheet languages such as Cascading Style Sheets ([CSS1] and [CSS2]). While style sheets are not part of HTML 4.0 proper, HTML 4.0 is the first version of the language to integrate them fully.
Why did the HTML Working Group adopt this strategy? For one, experience shows that distinguishing a document's structure and its presentation leads to more maintainable and reusable documents. Also, by extracting formatting directives from HTML documents, authors may design documents for a variety of users and target media in mind with minimal changes to their original HTML documents. The same HTML document, with different style sheets, may be tailored to color-blind users, those requiring large print, those with braille readers, speech speech synthesizers, hand-held devices, tty devices, etc. But style sheets have another significant impact on accessibility. They eliminate the need to to rely on "tricks" for achieving visual layout and formatting effects. These tricks have the unfortunate side-effect of making pages inaccessible.
For instance, HTML does not have an element or attribute to indent a paragraph, so many authors have resorted to using the BLOCKQUOTE element to indent text even when there is no quotation involved (many visual browsers indent the content of the element). This is misleading to non-visual users: when an audio browser encounters a BLOCKQUOTE element, it should be able to assume that the enclosed text is a quotation. More often than not, that assumption proves incorrect since the element has been misused for a presentation effect.
The BLOCKQUOTE example demonstrates the misuse, for presentation purposes, of an element intended to provide logical information. Many similar traps can seduce HTML authors: they use tables and invisible GIF images for layout; they use H2 or H3 to change the font size of some text that is not a header; they use the EM element to italicize text when in fact, EM is meant to emphasize text (often presented with an italic font style, but rendered differently by a speech synthesizer); they use lists for alignment, etc.
Now, style sheets will give authors a richer palette for layout and formatting at the same time they eliminate the accessibility problems that arise from markup abuse.
A picture may be worth a thousand words to some people, but others need at least a few words to get the picture. Authors should always complement non-textual contexts -- images, video, audio, scripts, and applets -- with alternate text content and textual descriptions. These are vital for visually impaired users, but extremely useful to may others: those who browse with text-only tools, those who configure their browsers not to display images (e.g, their modem is too slow or they simply prefer non-graphical browsing), or for those users who are "temporarily disabled," such as commuters who want to browse the Web while driving to work.
In HTML 4.0, there are a host of new mechanisms for specifying alternate content and descriptions:
The "title" attribute has many accessibility-related applications. For instance, with the new ABBR (abbreviation) and ACRONYM elements, it may indicate the expansion text of an abbreviation. Or it may provide a short description of an included sound clip. Or it may provide information about why a horizontal rule (the HR element) has been used to convey a structural division (although authors should be sure use structural markup as well, such as the DIV or SPAN elements).
But of all the new elements, the OBJECT element (for including images, applets, or any type of object) is the most important for specifying alternate content. With it, authors may specify rich alternate content (i.e., that contains markup, impossible with attribute values) at the same location they specify the object to be included. When a browser cannot render the image, applet, etc. included by an OBJECT element, it renders the OBJECT's (marked up) content instead.
One important application of this OBJECT feature involves client-side image maps. In HTML 4.0, the content model of the MAP element has been expanded to allow marked up anchor (A) elements that give the geometries of the map's active regions. When placed inside of an OBJECT element, the textual version of the image map will only be rendered if the graphical version cannot be. Thus, authors may create graphical and non-graphical image maps at the same location in their documents.
Visually impaired users have tremendous difficulties browsing pages where navigation options rely largely on graphical cues. For instance, image maps with no textual alternatives are next to impossible to navigate. Or link text that offers no context (e.g., a link which simply reads "click here") is as frustrating as a road sign that reads only "Exit" -- exit to where? Or adjacent links not separated by non-link characters confuse screen readers, which generally interpret them as a single link.
HTML 4.0 includes several features to facilitate navigation:
Investing in physical-world accessibility modifications, (wheelchair ramps, curb cuts, etc.) has benefitted a much larger community than those with disabilities: how often have parents with baby carriages or cyclists appreciated these same improvements? The benefits from accessibility innovations can similarly be generalized to other situations:
The WAI group has produced a set of guidelines for page authors. The guidelines, and related documents, describe good authoring practice in detail as it relates to accessibility.
The W3C Web Accessibility Initiative is pursuing accessibility of the Web through five primary areas of work: addressing accessibility issues in the technology of the Web; creating guidelines for browsers, authoring tools, and content creation; developing evaluation and validation tools for accessibility; conducting education and outreach; and tracking research and development. Depending on an individual's disability (or the circumstances in which one is browsing the Web, for instance on a device with no graphics display capability, or in a noisy environment), graphics, audio content, navigation options, or other aspects of Web design can present barriers.
The WAI International Program Office (IPO) enables partnering and coordination among the many stake-holders in Web accessibility: industry, disability organizations, government, and research organizations. The IPO is sponsored by the US National Science Foundation and the Department of Education's National Institute on Disability and Rehabilitation Research; the European Commission's TIDE Program, and W3C industry Members including IBM/Lotus Development Corporation, Microsoft Corporation, NCR, and Riverland Holding. Disability and research organizations on several continents also actively participate in the WAI.
For more information about the World Wide Web Consortium, see http://www.w3.org/
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
The authors welcome comments: