How Can I Ensure Accessibility in HTML Web Pages?

All web pages should have HTML that is accessible: 

Skip to main content link

Have a skip-to main content link hidden in the top header. Once tab is pressed twice, it should send the user to the main navigation area if selected to allow them to skip the main navigation via keyboard and go right to the content. https://webaim.org/techniques/skipnav/

Navigation

The main navigation on your site needs to be visible to assistive technology and operable using the keyboard only. Most CSS menus are technically accessible, although sighted keyboard users will not see submenu items when tabbing through a CSS menu, and fly-out and drop-down menus are not activated on keyboard focus. Navigation menus based on DHTML or Flash are rarely accessible. Workarounds must be used with DHTML, and Flash requires expertise to make it accessible. If you do decide to code advanced menu features, use progressive enhancement in designing your menus, which in a nutshell entails making the menu work for the most basic browser configurations while allowing for more complicated interaction that is supported by external CSS and javascript files. The Yahoo! Finance page is a good example of a navigation bar that works well with the keyboard, employing a full-tab approach.

View more information on accessible dynamic menus»

One aspect of CSS rollover menus that should be emphasized is that a screen reader user may, depending on how the menus are coded, access all of the nested items in the unordered list, not just the top-level items. Depending how “heavy” the fly-outs or drop-downs are, the total number of links on a page could become onerous. Consider using fewer menu picks and a slightly “deeper” site organization. It is better to engineer two easy clicks to get to a destination than one arduous click with a lot of “cognitive overhead.”

Also, complex drop-down or fly-out menus, e.g., with multiple columns, not only can have unfortunate consequences for screen reader users, they also can have a negative impact on those with cognitive, low vision, and dexterity impairments. Multicolumn menus hold a great attraction when designing sites with complex information architectures, but they introduce significant accessibility and usability issues.

Content

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible).

• Validate your code so that it works reliably with assistive technology. Use the W3C Validator or an equivalent.
• Follow the HTML/XHTML specifications and use forms, form labels, frame titles, etc., appropriately.
• Use semantic markup to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc.
• Use tables for tabular data. Associate data cells with their headers. Use captions and summaries where appropriate.
• Associate text labels with form input elements. Relate form elements with a fieldset and legend.
• Use the coding order to ensure that the reading and navigation order is logical and intuitive.
• Do not reference sound, shape, size, or visual location in instructions.

Headings and Labels

A primary navigational aid on a web page for a screen reader is the <h1> header, which should both uniquely identify the page in the website and should be placed directly in front of the main content of the page. The <h1> header should also match at least a subset of the the page <title>. Screen readers can produce a list of headings on a page, from which the user can select and jump to that location on the page. So, a correctly positioned <h1> tag allows an assistive tech user to get right to the business end of the page. Note that this technique provides similar functionality to the “skip nav” link for a screen reader user (but not a sighted user, unless s/he is using Opera keyboard navigation). Do not simply format text as large and bold to make a heading.

It is also important to make sure that your headings are properly nested, i.e., the <h2> tags follow the <h1> tag, the <h3> tags follow the <h2> tags, etc. Don’t select heading levels for their default size—use CSS to style your headings. Properly nesting your headings will convey the page organization to the assistive tech user. The following is an example of proper nesting:

• <h1>
  • <h2>
  • <h2>
    • <h3>
    • <h3>
  • <h2>

back to top

An exception can be made in the case of using headings, visible or off-page, to indicate a navigation menu. Use <h2>s for these headings. Don’t worry if they precede the first <h1>, as they commonly do in the coding order.

Tables

Most data tables are accessible to the visually impaired as long as you follow a few simple rules:

 

• Provide a table summary
• Use table headings
• Use the scope attribute

Table Summary

Provide a summary for your table to convey the context or conclusion of the table data (what is the table demonstrating?) to assistive tech users. This is accomplished by adding a summary attribute to the table tag:

  <table summary="Tensile strength of structural materials " border="1">

Table headings and scope attribute

Use the <th> tag to designate the table headings. The scope attribute is used to further define the row and column headings for your data table, greatly assisting in the navigation of a table. When a screen reader user moves to a particular table cell, the screen reader can announce to the user what row and column headings are associated with that cell. The following example illustrates how to correctly define table headings:

 

<table summary="Cardinals are larger and more colorful than sparrows" border="1">
 
	<tr>
 
		<th scope="col">Bird</th>
 
		<th scope="col">Size</th>
 
		<th scope="col">Color</th>
 
	</tr>
 
	<tr>
 
		<th scope="row">Cardinal</th>
 
		<td>21 cm</td>
 
		<td>vibrant red</td>
 
	</tr>
 
	<tr>
 
		<th scope="row">Sparrow</th>
 
		<td>16 cm</td>
 
		<td>dull brown</td>
 
	</tr>
 
</table>

 

The code above displays the following table:

 

While it is possible to code more complex data tables that are still technically accessible, you cannot be sure that all screen readers will parse them correctly. The safest plan is to stick to one- or two-dimensional tables, avoiding coding tables with more than two Levels of row and column headers and avoiding spanning rows or columns. Simple table layouts also benefit low-vision users and those with cognitive disabilities. Simple table layouts also benefit able-bodied users—the truth is that tables are difficult for all of us to read on the web.

View more information about creating accessible tables»

Links

Screen readers can produce a list of links found on a web page, in similar fashion to providing a list of headings. This can be a useful way to navigate a webpage—as long as the descriptions for the links are meaningful. If a page is littered with “click here” and “more” links, the screen reader user will have no clue what these links mean when they are presented in a list of links or when the user tabs through site from link to link. Likewise, using a URL as a link description can baffle a screen reader user because the screen reader will attempt to pronounce the URL as if it were a word and the description will sound like gibberish.

Aria Tags / Roles

ARIA is just a specification using HTML to tell the browser what the content on the page is. It's simply a tag in the HTML that tells us if it's the main content, side or secondary content, navigation, etc.

Document landmark roles are an ARIA specification that alert a screen reader user to the overall geographic regions on a web page:

• Banner
• Navigation
• Search
• Main content
• Auxiliary content
• Posted content
• Footer information

The code for landmark roles is easy to add to your web page—simply add a role attribute to a <div>tag (e.g., <div id="maincontent" role="main"></div>). Note that at this time the W3C validator will not recognize the role attribute, but using this attribute will not adversely affect your code in any way, and landmark roles are of great benefit to screenreader users. See more information about landmark roles »

Use of Color

Color contrast is an important but often overlooked aspect of web accessibility. Many more people are visually impaired or color blind than are legally blind. So by ignoring the color contrast of your page, you will be affecting a significant portion of your audience. During the design phase, you will want to check your web templates’ color contrast and adjust it accordingly. Although you can sense when a page has poor contrast, there are tools that can quantify the contrast between text and its background based on the style sheet and return a result in the form of a ratio. Websites that satisfy WCAG 2.0 must have a contrast ratio of 4.5:1 or higher.

See this site’s page on evaluating color contrast to learn how to determine if your web pages have sufficient contrast.