Web checklist

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

• Rationale

• Required development and unit test techniques

• Recommended development techniques

Rationale

The purpose of this checkpoint is to ensure that information displayed visually is also available programmatically so that the information is accessible to everyone. For example, someone using a screen reader or a different style sheet cannot access headings on a Web page formatted in a bold text, unless proper HTML markup defines the heading.

The techniques below address many different types of structures that are perceived visually, but they need HTML markup for the information and relationships to be available to someone with a disability. For example, a sighted user can distinguish paragraphs on the page because they are separated by a blank line. Screen readers can read a page by paragraph only if the paragraphs are marked using the HTML paragraph (<p>) element. While a sighted user can scan a table visually to understand its purpose, a screen reader cannot. Adding a summary and caption enables a blind user to receive the equivalent information that is available visually.

Required development and unit test techniques

• General examples
• HTML examples
• Script examples
• Text examples
• IBM^® Lotus^® Domino^® examples

To comply with this checkpoint, you must meet the following technique. This technique is defined in WCAG 2.0 Level A Success Criterion 1.3.1.

1. Semantic elements: Use semantic elements, such as standard HTML, and standard text formatting conventions to mark up structure.

Note: The examples presented in the techniques are not exhaustive. They are meant to illustrate the spirit of this checkpoint.

At this time WAI-ARIA examples are only fully supported in Firefox version 3.6 or later and version JAWS 12 or later. If your product needs to be accessible in Internet Explorer and mobile Safari/VoiceOver, one or more of the required HTML/CSS specific techniques must be implemented, as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and Internet Explorer and mobile Safari/VoiceOver fully support it, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint.

Applications that provide WAI-ARIA must add the following statement to the checkpoint comments column of the Web Accessibility Checklist:

Note: This product uses WAI-ARIA to comply with this checkpoint. WAI-ARIA is supported on Windows using Firefox version 3.6 or later and JAWS version 12 or later, and supported on iOS v5.0 and later using Safari and VoiceOver.

General examples

1. Semantic elements: Use semantic elements, such as standard HTML, and standard text formatting conventions to mark up structure.

To comply with this technique, you must implement all of the following examples.

General example 1

Use semantic elements to mark up structure AND use semantic markup to mark emphasized or special text. The <blockquote> element is used to identify the following quotation from Ed Brill, IBM Business Unit Executive, Worldwide Lotus Notes/Domino Sales, following Lotusphere 2006.

For additional information, refer to the WCAG 2.0 examples for using semantic elements to mark up structure.

Required unit test for general example 1

Perform the following unit test.

• For each element that has a semantic function, manually verify that the content has been coded using appropriate markup if corresponding semantic markup exists in the technology. Either examine the source code or use a screen reader to verify the semantic information.

General example 2

Use the <strong> element to provide visual emphasis. Text that is bold (<b>) provides visual emphasis that is not available to assistive technology. Rather than using bold, use the <strong> element (as shown in the following example) to emphasize the importance of the warning to all users.

Required unit tests for general example 2

Perform the following unit test.

Use a syntax analysis tool to validate general example 2. Most tools can automatically validate this example, so no manual test is required.

General example 3

Use the <code> element to provide visual emphasis. Text that has a fixed width (tt) provides visual emphasis, but that information is not available to assistive technology. Rather than using fixed width elements to emphasize a code block embedded in text, use the <code> element, as shown in the next example.

Required unit test for general example 3

Perform the following unit test.

• Manually confirm that <code> elements are used to emphasize a code blocks embedded in text.
• Or use a screen reader to confirm the code block is announced appropriately.

General example 4

Use semantic markup when color cues are used. Text that is written in a different color can give emphasis for a sighted user that can distinguish color. However, blind or color blind users may not be able to see the color difference. Using the <strong> element provides another way for a color blind user to see the emphasized text. Some assistive technologies recognize the <strong> element, which makes it a good option for blind users. The following example uses the <strong> element to indicate that the the accessibility call is open to everyone:

Attention investors: IBM conducts a quarterly investor conference call. For more information, go to ibm.com. This call is open to anyone interested in hearing about IBM's business.

Required unit test for general example 4

Perform the following unit test:

• When color cues are used to emphasize text in the content, remove the color using browser options and manually confirm that the emphasis is still identifiable by another form of cue using semantic markup.

Back to top

HTML examples

1. Semantic elements: Use semantic elements, such as standard HTML, and standard text formatting conventions to mark up structure.

To comply with this technique, you must implement all of the following examples.

HTML example 1

The techniques for caption, summary and scope reference the following example table.

Boys and Girls in Elementary School Classes

Class	# of Boys	# of Girls
1st Grade	11	10
2nd Grade	7	12
3rd Grade	9	11
4th Grade	13	12
5th Grade	12	12

Specifying a caption on a data table is optional. However, if a caption is specified, the <caption> element must be used to programmatically associate data table captions with data tables. If a summary is also specified for the data table, ensure that the caption text does not duplicate the summary text.

The <caption> element is used to associate a table description with the table itself. A screen reader announces the caption when you navigate to the table. If you code the description using a <p> element, the text and the table have no association. The caption is displayed visually on the page and spoken by screen readers.

The following HTML markup is for a caption used in the example table.

For additional information, refer to WCAG 2.0 examples for using caption elements to associate data table captions with data tables.

Required unit tests for HTML example 1

Perform the following unit test.

Use a syntax analysis tool to validate that the caption is appropriately associated with the table element. Most tools can automatically validate this example, so no manual test is required.

HTML example 2

Use table markup to present tabular information. The most basic type of data table contains one row of column headings and/or one row of row headings. Use the <th> element to identify table heading cells of rows and/or columns in a simple data table.

The table below shows the number of boys and girls in each class of an elementary school. Without proper HTML markup to identify row and column headers, a person using a screen reader might have trouble understanding, for example, that there are 12 girls in the 2nd Grade class. They would navigate to row 2, column 3 and hear "12". With proper markup of headings using the <th> element, you hear "Second grade. Number of girls. 12".

Boys and Girls in Elementary School Classes

Class	# of Boys	# of Girls
1st Grade	11	10
2nd Grade	7	12

The code for the above example is:

Required unit tests for HTML example 2

Perform the following unit test using a Web syntax analysis tool or a screen reader.

• Manually confirm that any related tabular information in the content is identified as a data table.

HTML example 3

Use id and headers attributes to associate data cells with header cells in complex data tables. Complex data tables are defined in HTML example 4 below. Complex data tables require additional markup to associate the heading explicitly with the data. In the data cells, the headers attribute is used on the <td> element to specify the heading cell, via the id attribute on the <th> element, that is associated with a specific data cell. If the data table has headers that are not located in the first row or column and does not have multiple levels of headers, you can use the scope attribute instead of using the id and headers attributes. (See HTML example 5).

The complex data table below shows the number of boys and girls in each class of an elementary school and it also shows the number of students assigned to each teacher. This is considered a complex data table because it has multiple levels of row headers (1st Grade includes both Mr. Henry and Mrs. Smith). In the example, <th> elements identify the column and row headers and cells are associated with the column and row headers using the headers attribute. However, in a complex row, such as the one beginning with 1st Grade, identifying only the row header is not enough to convey the relationships between the cells. In this example, the table needs to communicate that both Mr. Henry and Mrs. Smith are 1st grade teachers. Each has their own class of 1st grade boys and girls.

Boys and Girls in Elementary School Classes

Class	Teacher	# of Boys	# of Girls
1st Grade	Mr. Henry	5	4
	Mrs. Smith	7	9
2nd Grade	Mr. Jones	3	9
	Mr. Smith	4	3
	Mr. Kelly	6	9

The code below shows the correct markup of the 1st Grade portion of the above table. Notice that the column and row headers are marked with the id attribute and the corresponding data cells contain the headers attribute. In addition, notice that because the cell containing Mr. Henry is a header cell as well as a data cell, it contains both the id and headers attributes.

When adding id attributes to the first cell in each row and to other row cells that a user could perceive as headers for subsequent cells in the row, you make it explicit which column and row headers apply to a particular cell. In the example, it is now clear that both 1st Grade and Mr. Henry are row headers for the cell containing "5". This markup does not change the visual look of the table, yet it enables a screen reader user to better understand the relationships between the cells.

Required unit tests for HTML example 3

Perform the following unit tests using a Web syntax analysis tool or a screen reader.

• For each data table in the content, ensure data cells have associated header elements by using a Web syntax analysis tool.
• Optional test: Use an assistive technology, such as a screen reader, to confirm this technique.

HTML example 4

The summary attribute is only required for data tables that have a complex structure such as:

• Data tables that have two or more levels of row or column headers implemented using any of the following ways:

1. a table with two or more tr elements that contain only th elements
2. a tr element that contains at least one td element and two or more th elements.
3. a thead element that contains two or more tr elements
4. a table with more than one thead element

• Data tables where headers span multiple rows or columns, such as the table pictured in HTML example 3 implemented in either of the following ways:

1. a td element with a rowspan or colspan attribute
2. a td element with a headers attribute value that contains more than two IDREFs

• Data tables in which the table headers are not located in the first row or first column of the table, such as in HTML example 5.

Use the summary attribute of the <table> element to give a brief overview of data tables. Use the summary attribute to provide additional information about the structure or purpose of a data table to a screen-reader user. Unlike the caption element, the summary attribute is not visible, but it is spoken by screen readers. If a caption is also specified for the data table, ensure that the caption text does not duplicate the summary text.

For HTML example 3, an appropriate summary would be defined as follows:

Note: The table summary attribute is obsolete in HTML5. The HTML5 specification suggest describing a table with the new details and summary elements. However, browser support for these elements is poor, so if your application must be HTML5 compliant, programmatically associate a summary with a table using an aria-describedby attribute to reference a description (hiding the description text, as needed).

For additional information, refer to WCAG 2.0 examples for using the summary attribute of the table element.

Required unit tests for HTML example 4

Perform the following unit test using a Web syntax analysis tool.

• Validate that a summary attribute is provided for the data table. Most tools can automatically validate this example, so no manual test is required.

HTML example 5

Sometimes the scope attribute can be used instead of the id and headers attributes to define the scope of header cells within a data table. Whenever table headers are not located in the first row or column, and there is a single level of headers, you can apply the scope attribute to identify a cell that is a header for a row, column, group of rows or group of columns. The scope attribute is used in addition to the <th> element; it is not used in place of the <th> element.

The value of row in the scope attribute will assign the cell as the header for all cells in that row. Similarly, the value of col in the scope attribute assigns the cell as the header for all cells in that column. The scope attribute is generally quicker and easier to use than id and headers attributes for simple tables.

The HTML code below shows how the scope attribute was used to define row and column headers in the sample table.

For additional information, refer to the WCAG 2.0 examples of using scope to associate header and data cells in data tables.

Required unit test for HTML example 5

Perform the following unit test using a Web syntax analysis tool.

• For each data table in the content, confirm that the row and/or column headings are provided for each data cell.

HTML example 6

Provide a description for groups of form controls using <fieldset> and <legend> elements. Group radio buttons and other controls using the <fieldset> element. Unlike adding text above the radio buttons, the <fieldset> element programmatically associates the radio buttons with the text provided with the <legend> element. When you tab to a set of controls grouped using <fieldset>, screen readers read the legend, the <form> element label and the control status, so the user has the context of the <form> element.

In the following example, when you tab to the first radio button, the screen reader announces:

Choose your favorite ice cream flavor. Chocolate. Not pressed.

Choose your favorite ice cream flavor

Chocolate Vanilla Chocolate Mint Chip

For additional information, refer to the WCAG 2.0 examples of providing a description for groups of form controls.

As an alternative to the HTML <fieldset> and <legend> elements, the WAI-ARIA group and radiogroup roles may be used to group radio buttons and other controls. The following example uses a WAI-ARIA radiogroup role to group the same radio buttons shown in the previous example.

Refer to the WAI-ARIA Best Practices section: Providing Logical Layout Semantics using Structural Roles for more information.

Required unit tests for HTML example 6

Perform the following unit test using a Web syntax analysis tool or a screen reader.

• Validate that group labels are provided for a group of related controls.

HTML example 7

Create lists of related items using HTML markup so that screen reader users can understand the relationship. Use an <ol> element for ordered lists and a <ul> element for unordered lists. Screen readers provide the ability to navigate a Web page by lists, so it is important to use correct markup. Lists that are created using visual elements, such as a dash or asterisk, without proper markup are not identified as lists by screen readers. The list of techniques on this Web page was created using the <ol> element.

The <dl> element is used to group terms with their definitions. The <dt> element is used to define the term. The <dd> element is used to define the definition. Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the <dt> element and is restricted to inline content. The description is given with a <dd> element that contains block-level content.

The following sample code shows how to use a definition list to build a glossary of terms.

For additional information, refer to WCAG 2.0 examples for using ol, ul and dl for lists or groups of links.

Required unit tests for HTML example 7

Perform the following unit tests.

• Manually review the content to confirm that if something looks like a list in your content, it is coded with proper list elements.

HTML example 8

Because screen readers read content sequentially, you should include markup that enables users to navigate Web pages by headings. This provides an overall organization of the page and allows users to quickly navigate to specific sections. Web pages that use bold text or a larger font to indicate headings are not accessible. Because screen readers can identify heading hierarchy (<h2> versus <h3> elements) to show organization, it is important to use headings in sequence. The checkpoint pages in the IBM accessibility checklists are a good example of using headings to identify key sections of a page.

For additional information, refer to WCAG 2.0 examples for using h1-h6 to identify headings.

Required unit tests for HTML example 8

Perform the following unit tests.

• Manually review the content to confirm that if something looks like a heading, that it is coded with proper heading elements.
• Review the findings of a Web syntax analysis tool to confirm the proper use of headings where appropriate in the content.
• Optionally use a screen reader and examine the heading list.

HTML example 9

Refer to the WAI-ARIA Best Practices section: Providing Logical Layout Semantics using Structural Roles for more information.

If navigation links are present, assign a WAI-ARIA navigation role to the element containing the links or to a heading that refers to the links. The following example uses a WAI-ARIA navigation landmark to allow screen reader users to navigate directly to the navigation area. You may implement the technique by simply assigning a navigation role to a heading element.

Screen reader users navigate to landmarks using landmark navigation keys to advance sequentially through all landmarks on a page. A screen reader may also present a list of page landmarks to enable a user to jump to different areas on a page.

Required unit test for HTML example 9

Perform the following unit test.

• Confirm that a WAI-ARIA navigation landmark is used when a group of navigation links are present on the page.

HTML example 10

Refer to WAI-ARIA Best Practices section: Providing Logical Layout Semantics using Structural Roles for more information.

If a search field is present, assign a WAI-ARIA search role to the field container. The following example uses a WAI-ARIA search landmark to allow screen reader users to navigate directly to the search field. The technique may be implemented by simply assigning a search role to the field container.

Screen reader users navigate to landmarks using landmark navigation keys to advance sequentially through all landmarks on a page. A screen reader may also present a list of page landmarks to enable a user to jump to different areas on a page.

Required unit tests for HTML example 10

Perform the following unit test.

• Confirm if search links are present on the page and that a WAI-ARIA search landmark is used.

Back to top

Script examples

1. Semantic elements: Use semantic elements, such as standard HTML, and standard text formatting conventions to mark up structure.

To comply with this technique, you must implement the following example.

Script example 1

Use functions of the Document Object Model (DOM) to add content to a page.

For additional information, refer to WCAG 2.0 examples for using functions of the Document Object Model (DOM) to add content to a page

Note: While using functions of the DOM is the preferred method to add content to the page, other methods such as document.write and innerHTML are acceptable as long as the content and its semantics can be read by a screen reader.

Required unit tests for script example 1

Perform the following unit test.

• Use a screen reader to confirm the newly added contents and any semantic information are announced.

Script example 2

Do not use scripts to emulate an HTML link. Use <a href> or <area> to implement links. When a link is emulated by placing an onclick on a span or div, for example, the element doesn’t provide link semantic information to assistive technologies and does not automatically provide the keyboard accessibility as required by checkpoint 2.1a Keyboard.

HTML link markup is preferable. However, if scripting must be used, put the WAI-ARIA role="link" on the element used as a link and implement the keyboard accessibility required by checkpoint 2.1a.

Required unit tests for script example 2

Perform the following unit test using the recommended tools and assistive technologies

• Use the tool available to identify content where scripts are used to emulate links.
• For any Potential violations flagged manually confirm that the link is identified as a link by an assistive technology (you can optionally use JAWS to test this and the link is keyboard accessible.

Back to top

Text examples

1. Semantic elements: Use semantic elements, such as standard HTML, and standard text formatting conventions to mark up structure.

To comply with this technique, you must implement all of the following examples.

Plain text documents do not contain markup, but structures like paragraphs, lists and headings must still be recognized by someone using assistive technology. By using standard formatting conventions, such as indicating a list item with numbers or labels, the plain text document is accessible.

Text example 1

Use standard text formatting conventions for paragraphs (TXT). In a plain text document, the standard formatting convention for the beginning of a paragraph is either the beginning of the content or a single blank line before the paragraph text. To indicate the end of a paragraph, add one or more blank lines to the end of the paragraph text.

For additional information, refer toWCAG 2.0 examples for using standard text formatting conventions for paragraphs.

Text example 2

Use standard text formatting conventions for lists (TXT). In a plain text document, the standard formatting convention for ordered lists is either using numerals in numeric order, (1,2,3) or using alphabetic labels in order (A,B,C) for each item in the list. Unordered lists should use asterisks, dashes, or bullets.

For additional information, refer toWCAG 2.0 examples for using standard text formatting conventions for lists.

Text example 3

Use standard text formatting conventions for headings. In a plain text document, use the standard formatting convention to indicate the beginning of a heading by placing two blank lines preceding the heading text. Indicate the end of the heading with one blank line following the heading text.

For additional information, refer toWCAG 2.0 examples for using standard text formatting conventions for headings.

Text example 4

Avoid the use of tables in text documents. Rudimentary tables may be implemented in text documents using, for example, the dash ( - ) and pipe ( | ) characters. However, these tables are not accessible and should not be implemented.

Required unit tests for text development technique 1

Manually check the plain text document and ensure:

• Headings have two blank lines preceding them and one blank line after them.
• Paragraphs have a single blank line both before and after the paragraph.
• Ordered lists use numbers or letters to identify each item in the list.
• Unordered lists use asterisks, dashes or bullets to identify each item in the list.
• Tables are not included in the content.

Back to top

IBM® Lotus® Domino® examples

Semantic elements: Use semantic elements, such as standard HTML, and standard text formatting conventions to mark up structure.

To comply with this technique, you must implement all of the following examples.

Domino example 1

Use semantic elements in Domino to mark up structure. Domino uses semantic elements to mark up most structure in your forms, documents and views. In some instances, developers must add their own HTML markup, such as using the <strong> element instead of using simple bold text.

Domino example 2

Use the <strong> element in Domino when emphasizing important text. Rather than using bold, use the <strong> element to communicate the importance of the information is available to all users. In Domino, you must use pass-thru HTML.

1. Enter the beginning <strong> element for the emphasized text.
2. Enter the text that needs to emphasized.
3. Enter the ending </strong> element.
4. Select the elements and the emphasized text.
5. Go to Text > Pass-Thru HTML. Once selected, the pass-thru HTML is highlighted in gray.

You can also identify any text as pass-thru HTML by enclosing the text in square brackets. For example:

Hurricane Katrina has strengthened to a [<strong>category 4</strong>] hurricane.

Domino example 3

Use the summary attribute of the <table> element to give an overview of data tables in Domino. Domino Designer supports the summary attribute through the Table Properties box. Use the following steps to add a table summary to your data tables. Do not use the summary attribute for layout tables.

1. Create the data table.
2. Press Shift-F10 and select Table Properties.
3. Go to Table HTML tags > Other.
4. Enter the summary for the data table. For example, summary="Table with workout schedules for each athlete."

Domino example 4

Use the scope attribute to associate header cells and data cells in data tables in Domino. Domino Designer supports the summary attribute through the Table Properties box. Use the following steps to add table scope to your data tables. Do not use the scope attribute for layout tables.

1. Create the data table.
2. Identify the row / column table headers. See accessible tables in Domino for the techniques to add row and column headers.
3. Press Shift-F10 and select Table Properties.
4. Go to Cell HTML tags > Other.
5. Enter the scope for that heading. Enter scope="col" for column headings or scope="row" for row headings.

Domino example 5

Use <ol>, <ul> and <dl> elements for lists in Domino. List formatting allows screen reader users to understand the structure and relationship of the information in the list. Use the following steps to define lists in Domino Designer.

1. From the Designer menu, go to Text > List. Select the list style you want to use, for example Bullet, Number or Checkmark.
2. Enter the text for the list.

Domino example 6

Use <h1>-<h6> elements to identify headings in Domino. Headings enable blind users to quickly scan and navigate pages without listening to the entire page sequentially. The heading text displays in a larger bold font and it is identified as a heading to screen reader users. Use the following steps to define headings using pass-thru HTML.

1. Enter the beginning heading element, for example <h3>.
2. Enter text for the heading.
3. Enter the closing heading tag, for example <h3>.
4. Select the heading text and the heading elements.
5. Go to Text > Pass-Thru HTML. Once selected, the pass-thru HTML is highlighted in gray. You can also identify any text as Pass-thru HTML by enclosing the text in square brackets. For example, [<h3>My Heading<h3>].

Required unit tests for Domino examples 1-6

For Domino content rendered in a browser, refer to the required tests for HTML examples 1- 6 above.

Back to top

Recommended development techniques

Although you do not have to implement the recommended techniques in order to comply with this checkpoint, you should review them because they can improve the accessibility and usability of the application.

The following technique is recommended to comply with this checkpoint:

1. Use the optgroup attribute.

Recommended example 1

Use the optgroup attribute to group options in a drop-down list under the select element. Use optgroup when the user must choose from a long list of options. Groups of related choices are easier to grasp and remember than a single long list of options.

Note: The optgroup attribute is not supported by all browsers and screen readers.

Accessibility Options: Web Software Java Hardware

Refer to the WCAG Additional Techniques (Advisory) for Success Criterion 1.3.1 for a list of techniques and examples.

Back to top

©2013 IBM Corporation

Last updated January 1, 2013.

W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/
Copyright 1994-2009 W3C (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.

Checkpoint 1.2c	Web checklist	Checkpoint 1.3c