This technique relates to the following sections of the guidelines:
Task:
Identifying paragraphs
Paragraphs often appear visually as blocks of text followed by white space. User agents can sometimes "guess" where a paragraph ends based on character combinations that aren't visible to the eye. But visual formatting or special key combinations may not be enough to identify paragraphs reliably.
Structural markup, such as the HTML paragraph element (<p></p>), enables user agents to identify individual paragraphs in a reliable way. If you are using a Web technology that does not provide a paragraph element, it may be necessary to create one, or to create rules that transform specific elements into HTML paragraphs.
Use CSS to control the visual appearance of paragraphs.
HTML Techniques
Editorial Note: There are no techniques for <ul> or <dl>, and the techniques for nested lists are discussed only under ordered lists. JAWS supports <ol>,<ul>, and <dl>; announces the beginning and end of each list; announces nesting level; reports list bullets and automatically generated list-item numbering via <ol>; indicates <dd> by saying "equals" allows jumping from list to list by pressing the letter "L" and allows users to bypass lists with a single keystroke.
CSS Techniques
This technique relates to the following sections of the guidelines:
Task:
Separate the structure of lists and list-items from presentation
Content presented in a bulleted or numbered list may be easier to read than long sentences that present the same material as a series of words or phrases separated by commas.
Example 1. A list in sentence form.
Some of the structures within Web content include paragraphs, lists, images, mathematical expressions, forms, data tables, etc.
Example 2. The same items presented in an unordered list. Some of the structures within Web content include:
Paragraphs
Lists
Forms
Data tables
Images
Mathematical expressions
Etc.
Using appropriate structural markup enables user agents to recognize lists and the items that belong to them even when the list is spoken by a screen reader or the visual presentation is adapted to meet the needs of users with low vision or other disabilities. Lists can still be formatted in visually appealing ways: there are several CSS properties that enable designers to control the visual presentation of lists and list items, including nested lists.
This technique relates to the following sections of the guidelines:
Task:
Separate the structure of forms and form controls from presentation
Online forms usually include several parts, such as text fields, radio buttons, and checkboxes. Many people can identify these items based on their visual appearance. However, it is important to separate the form and its parts from the way they look on the page, so that people who cannot see the form or do not use graphical browsers can still identify and access the form. This can be done through structural markup, which enables user agents, including assistive technology, to identify the form as well as all of its parts, and to associate each part of the form with an appropriate label. (See the section on identifying relationships between form controls and their labels for information about associating labels with controls.)
CSS may be used to enhance the visual appearance and layout of the form, improving usability for users who can take advantage of the visual presentation.
It should be noted that XForms separates the structure of form controls even more sharply from presentation. There is no <form> element in XForms, unlike HTML; and the visual appearance of controls should be specified using CSS.
This technique relates to the following sections of the guidelines:
Task:
Separate the structure of tabular data from presentation.
Tables have been used for two purposes: to control the placement of content on the screen (layout tables) and to present data in a two-dimensional way (data tables). One way to determine whether a table is used for layout or to present data is to move the content of a cell to another cell. If the meaning of the cell's content stays the same (for example, a link to the About Us page remains the same even if it is moved to a different location in the navigation bar), the table is being used to control layout. If moving the content changes its meaning, the table is used for data.
Although the use of layout tables is likely to continue for some time, it is no longer considered good practice: Web designers are encouraged to use CSS rather than tables for positioning and layout. If tables are used for layout, structural markup for identifying column and row headers should not be used, and there should be no caption or summary.
Data tables are used to show relationships, such as the relationship between products and prices, population figures, economic data, schedules and calendars, election returns, the status of legislation, etc. Data tables may be simple or complex.
Simple tables include no more than one row of header cells plus one or more rows of data cells. The table may also include row headers and a caption or summary.
Editorial Note: The question of whether the summary attribute is required for data tables and/or forbidden for layout tables has been actively debated on the WAI-IG mailing list and is now under discussion by the Techniques Task Force. The previous paragraph will be revised as needed pending the outcome of those discussions.
Complex tables include two or more sets of column or row headers, and there may be several groups of columns or rows, each with its own headers.
A well designed table makes it easy for most users to see header cells, data cells, and groups of cells. However, if only visual techniques are used, people who cannot see the information or have difficulty seeing it will find it difficult or impossible to identify the parts of the table. Using structural markup to display tabular data makes it possible for people using a variety of user agents to identify data and header cells and their groupings. A short explanation of the table's purpose and organization may aid users with visual or cognitive impairments that make it difficult for them to see or comprehend complex visual representations.
For simple tables, Guideline 1.3 L1 SC1 can be satisfied by using structural markup to identify the table and its header and data cells. For complex tables, additional markup is required to separate the relationships between data cells and header cells from their visual appearance. A later section of this document discusses general techniques for associating data cells and header cells.
CSS can be used to control the visual appearance and auditory aspects of the table and tabular data.
This technique relates to the following sections of the guidelines:
Task:
Display images as structural elements within valid Web documents
Images are structural elements in their own right, in HTML and other W3C languages. Using markup such as the img or object elements in HTML or comparable elements in SVG enables user agents to identify images and treat them appropriately, for example by associating them with text alternatives as required by Guideline 1.1 L1 SC1. In HTML, an image cannot be explicitly associated with the required text alternative if the image is not defined as an element within an HTML document. That is, the image cannot simply be displayed by itself in a new window. It must be placed in an HTML document, even if that document has no other content.
This technique relates to the following sections of the guidelines:
Task:
Make the structure of images perceivable
Like other types of Web content, images also have structure. For example, flowcharts, wiring diagrams, architectural blueprints, scientific illustrations, etc., often include clearly defined structural components. Photographs and works of visual art may also be said to exhibit structure.
However, most graphic formats in use on the Web in 2004 do not provide means to directly identify structures within an image. The following paragraphs suggest different techniques that may be appropriate to different technologies.
Editorial Note: This technique is optional, since it doesn't make it possible to determine image-structure programmatically.
Information about the structure of complex images may be included in a long description that satisfies guideline 1.1 level 1, item 2.
In some cases, it may be possible to use an image map or image-"slicing" technique together with short text alternatives (required by Guideline 1.1 Level 1 SC1.a) to represent the structural components of a larger image. The following two examples suggest how these image map and "image-slicing" techniques might be applied:
Example 1: A flowchart converted into an image map.
Each shape on the flowchart is a selectable area whose function and content are identified by its alt attribute.
Example 2. An architectural blueprint presented as a set of "sliced images."
What most users perceive as a single image is actually composed of many small images. Each of these small images represents a structural component of the blueprint (such as a doorway, a room, etc.). Each image is identified by an appropriate text alternative.
Additional General Techniques
How to describe complex images
HTML Techniques
CSS Techniques
This technique relates to the following sections of the guidelines:
Task:
Simulate separation of structure from presentation by using multiple modes of presentation
Editorial Note: The following technique is optional. It uses multiple presentation modalities -- images, simplified illustrations, tactile representation, text, and animation -- to expose the structure of a complex work of visual art. But the structure of the image cannot be programmatically determined -- it is available only for human inspection -- and except for the textual presentation and the option to print simplified images on special paper, each modality depends heavily on a particular type of presentation. I would argue, though, that it goes a long way toward meeting the spirit if not the letter of Guideline 1.3.
Graphics can be made more accessible to users with low vision by providing enlarged images or "zooming" in for close-up examination of specific details. Such functionality is often provided by museum Web sites and sites that offer maps and driving directions .
The Tate Gallery of London (England) used Macromedia Flash to help users with low vision understand the visual structure of complex works by the modern artists Pablo Picasso and Henri Matisse. For each work shown in the IMAP project, the designers created a sequence of simplified, high-contrast drawings based on the painting. Each drawing highlights a specific aspect of the work, which is described in accompanying text, as required by guideline 1.1 Level 1 SC3. The images and text descriptions appear in separate frames. Users can move through the sequence using either the mouse or a keyboard interface developed for the project. A separate page (without frames) enables users to download the images for printing on special "swell paper" that can be heat-treated to produce relief drawings. (The text descriptions can also be read independently.) (See "Text and Animations." Available at http://www.tate.org.uk/imap/pages/animated/pairs_ani.htm. Accessed August 26, 2004.)
HTML Techniques
Editorial Note: 10.7 Long description of images is not appropriate here-it would work only in cases where the Flash player was not installed on the end-user's system. If the Flash player is installed on the user's system, descriptions and links included in the body of the object element will not be rendered. Technique 12.2 alt content for embed is inappropriate for the same reason. 12.3 alt text for embed should probably be included in General Techniques for Guideline 1.1. The titles of techniques 12.2 and 12.3 are confusingly similar.]
Editorial Note: The title attribute for the frame element is supported by JAWS, Window-Eyes, and Home Page Reader, and possibly other screen readers. Is it still necessary to require the name attribute as well as title?]
This technique relates to the following sections of the guidelines:
Task:
Providing "zoomable" views of mathematical expressions
The National Center for Accessible Media (NCAM) recommends providing a method for allowing users with low vision to "zoom" in on mathematical expressions. As with maps and other complex images, this can be done using the W3C's Scalable Vector Graphics (SVG) format.
It is important that the zooming function can be operated from the keyboard or a keyboard interface, as required by Guideline 2.1 Level 1 SC1.
National Center for Accessible Media, Making educational software and Web sites accessible: Design guidelines including math and science solutions. Guideline 8: Provide access to scientific and mathematical expressions for all users with disabilities. Available at http://ncam.wgbh.org/cdrom/guideline/guideline8.html#skip. Includes an appendix listing resources on spoken mathematics as well as a link to a demonstration project that includes numerous examples of accessible equations.
This technique relates to the following sections of the guidelines:
Task:
Using markup to identify the structure of mathematical expressions
Providing a "zoomable" view of mathematical expressions is valuable for users with low vision, including many users who are older, but it does not enable users who are blind or deaf-blind to access mathematical expressions. Enabling such access requires support for screen reading software, which can render the equation either as synthetic speech output or in tactile form on a refreshable Braille display. The preferred method for representing the structure of mathematical expressions is to use the W3C's Mathematics Markup Language, or MathML. "MathML is an XML application for describing mathematical notation and capturing both its structure and content" (http://www.w3.org/TR/MathML/).
Editorial Note: User agent issues MathML is directly supported only by the Mozilla and Netscape browsers (get version numbers). Assistive technology so far provides limited support for MathML. However, MathPlayer 2.0, a plug-in for Internet Explorer 6.0 and higher released in April 2004, supports screen readers including Window-Eyes, HAL, and JAWS. Support for MathML under Linux is possible through emacspeak , developed by T.V. Raman.
HTML Techniques
Other resources
National Center for Accessible Media, Making educational software and Web sites accessible: Design guidelines including math and science solutions. Guideline 8: Provide access to scientific and mathematical expressions for all users with disabilities. Available at http://ncam.wgbh.org/cdrom/guideline/guideline8.html#skip. Includes an appendix listing resources on spoken mathematics as well as a link to a demonstration project that includes numerous examples of accessible equations.
The W3C Math Home Page lists numerous resources, including software for creating, editing, and rendering MathML. Available at http://www.w3.org/Math/.
The Texas School for the Blind and Visually Impaired maintains a Web site on Teaching Math to Visually Impaired Students that includes many resources and strategies for making mathematics accessible. Available at http://www.tsbvi.edu/math/.
Liddy Nevile's "Accessible Mathematics" page (2002) provides an excellent and detailed overview of issues and challenges in making mathematics accessible as well as suggested techniques for meeting those challenges and links to additional resources. Available at http://www.latrobe.edu.au/webaccess/maths.html.
This technique relates to the following sections of the guidelines:
Task:
Use markup to associate form controls with their labels
Besides identifying forms and parts of forms, as discussed in the technique for Identifying forms and form controls, users and user agents must also be able to identify:
relationships between form controls and their identifying text (labels); and
groups of related form controls, such as a multiple-choice question (that is, a question with several possible answers).
Labels must be programmatically associated with form controls to ensure that users and user agents can identify form controls correctly in all presentation forms.
This technique relates to the following sections of the guidelines:
Task:
Use markup to associate data cells with header cells
Tables are widely used to present structured data such as schedules, prices, tax rates, population figures, and so on. Typically, the table consists of some data cells plus at least one set of headers. The headers are used to determine the meaning of the data in the cells. Therefore, it is essential that user agents can identify all header cells that are associated with each data cell.
It may be helpful to think of each cell as a character in a very short (one-sentence) "story,"" as Alan Cantor has suggested. For example, we can write a little story about Column 2, Row 4 of the first table at http://www.cwrl.utexas.edu/~slatin/webaccess/2002/schedule.htm, which shows part of the schedule for a university class.
The table has four columns. In order, the column headers are: Date, Topic, Reading, and What's due. We'll use the data cell as the grammatical subject of our sentence, then use the column and row headers to tell its "story," like this: "Encountering Barriers was the topic for September 5."
This might seem obvious. But suppose the table did not have any column headers. users might be able to figure out what the phrase "Encountering Barriers" meant, but they might not-and in a larger table with dozens or even hundreds of rows of data cells, confusion would probably set in quickly, especially if the table contained a great deal of numerical data.
This technique relates to the following sections of the guidelines:
Task:
Separating functionality from presentation in online forms
Forms are structural elements (in HTML). They also contain structural elements. Some of these structural components are functional. These include input elements of various types (text, radio, checkbox, submit, reset, image), textareas, and lists of options (select, option, and optgroup elements).
Using appropriate markup makes it possible for user agents, including assistive technology, to identify the form controls and their status so that users know what actions are available to them (e.g., entering text, selecting a checkbox, submitting a form).
Functionality is more completely separated from presentation in XForms than in HTML. The W3C's "XForms for HTML Authors" explains:
"XForms provides equivalents of all HTML Form controls. But there is a major difference in approach: HTML mainly specifies how the control should look, while XForms specifies what the control should do. So while the HTML specification says that the select element creates a menu, and the radio type of input creates radio buttons that allow a single choice to be made, XForms has the select and select1 elements, which only specify the intent of the controls, to select zero or more, or only one, element from a list. How they are presented to the user can vary across devices, or according to a style sheet. On a mobile telephone where screen space is scarce, both might be represented with menus, while on a larger screen both might be represented with selectable buttons. You are allowed to give a hint to what you want, or you may use a stylesheet to give precise styling, but if you don't, a device, or a style sheet, may make a choice for you."The W3C's Xforms page is available at http://www.w3.org/MarkUp/Forms/
The W3C's list of XForms implementations is available at http://www.w3.org/MarkUp/Forms/#implementations