December 2012

Volume 27 Number 12

Building HTML5 Applications - Designing Accessibility with HTML5

By Rajesh Lal | December 2012

If you’re truly interested in reaching a broad audience, you’ll want to design your Web site for accessibility. Accessibility is about making Web pages easier to access, easier to use and available to everyone. In general, using the latest technologies makes accessibility easier to accomplish. Today, that means using HTML5.

To be accessible, your content needs to be available on a broad range of devices, such as ordinary computers using a keyboard or mouse, screen readers, audio browsers, devices with limited bandwidth, old browsers and computers, and mobile phones and touch devices. Moreover, it should be reachable by the widest variety of people, including those with disabilities and senior citizens, as well as people with low literacy levels or temporary illness, or who prefer using only a keyboard or mouse.

The four key areas disability accessibility seeks to address are:

  • Hearing
  • Mobility
  • Cognitive
  • Visual

Hearing issues mean a user may not be able to hear any sound on the Web site. The solution is to make the content perceivable by using a text alternative for all non-text content, such as sub­titles and closed captions. Include transcribed speech and sign languages, if possible.

Mobility problems in this case mean the inability to use the mouse or keyboard. The solution for mobility on the Web is to make the content operable; that is, to make all functionality accessible from the keyboard alone, as well as with joysticks, voice recognition and audio feedback, when possible. Allow navigation with proper use of headings and anchors and give users the ability to stop time-based content. Don’t allow any auto-refresh on the page.

Cognitive difficulties impact the content itself, for example with the size of text and images or with color contrast. Flashy graphics and font types can also cause problems for some users. The solution is to make the content understandable. Use easy-to-read sans serif fonts and allow font resizing. Use high color contrast between foreground and background. Avoid auto-refresh, flickering images and auto play of media and animation. Use multiple visual cues and standard icons to make the content easy to grasp.

Visual problems can range from an inability to distinguish color to no ability to see the content at all. The solution for such issues is to make the content robust so that it can be reliably interpreted by user agents, and easily accessed with screen readers. Use semantic HTML and follow standards. Use syntactically correct HTML and validate your page. Use lang attribute and abbr tags wherever applicable.

In short, to be accessible, content for the Web needs to be made perceivable, operable, understandable and robust. Together, these attributes comprise the World Wide Web Consortium (W3C) POUR model, which mandates that the information and UI elements being presented to users must be perceivable to their senses; that there must be a way for them to operate the UI; that they must be able to understand the information and how to use the interface elements; and that the content be robust enough so they can access it using a variety of user agents, including assistive technologies (ATs).

Now that you understand the fundamentals of accessibility, let’s take a look at two very important concepts related to accessible Web design: progressive enhancement and accessible rich Internet applications (ARIAs).

Progressive Enhancement and ARIA

Progressive enhancement is an approach to Web design that promotes accessibility using semantic HTML, stylesheets and scripting. The idea is to create a Web site where basic content is available to everyone while more advanced content and functionality are accessible to those with more capability, more bandwidth or more advanced tools. When you create a site, you concentrate first on displaying the content in the simplest manner. You design your page using semantically structured HTML. All presentation elements that modify the visual content (such as bold or italics) go in an external stylesheet.

Semantic HTML means the HTML tags in a page should describe the content in a way that has to do with its meaning rather than its presentation. Any information about the decoration of the content should go in a CSS file, while the logic and the client-side behavior of the Web page should be added via externally linked JavaScript after the page is loaded and the stylesheet parsed and applied. Progressive enhancement ensures that if there’s an error in the JavaScript file, the page still loads with proper styles. And if the CSS file is ignored (for example, by screen readers), the HTML page still has all the content. 

All modern OSes have their own accessibility APIs, each of which is a set of open methods and interfaces exposed by the browser for reading and parsing text. The Microsoft version is Microsoft Active Accessibility (MSAA), a part of UI Automation (UIA) for Windows; Linux has IAccessible2; and Apple relies on the Mac OS X Accessibility Protocol—but they all follow the ARIA standard as defined by the W3C ( Figure 1 shows how a user might interact with an accessible Web page using an AT device such as a screen reader. Such devices use the accessibility APIs to access Web pages.

How a User Accesses a Web Page Using Assistive Technology
Figure 1 How a User Accesses a Web Page Using Assistive Technology

ARIA is part of the W3C Web Accessibility Initiative (WAI), and it defines a way to make Web content and Web applications more accessible. ARIA is used to improve the accessibility of dynamic content and advanced UI controls developed with HTML, CSS, JavaScript, AJAX and related technologies. ARIA is now officially a part of the HTML5 specification and is also embedded in popular JavaScript libraries such as JQuery, Dojo and YUI. See for more information.

ARIA uses a set of roles, states and properties to expose a Web page to the accessibility APIs. These roles, states and properties are assigned on a page’s elements, which are exposed to the ATs. Most current AT tools—including JAWS, NVDA and VoiceOver—support ARIA. Let’s take a take a closer look at ARIA.

ARIA Roles

Roles indicate the type of element in a meaningful way. Suppose a screen reader comes across an HTML element on a page that includes role=navigation. The screen reader will know this HTML element is for navigation, and the user will be able to access navigation directly instead of tabbing through all the links.

ARIA role attributes are applied to HTML elements like this:

<div role="XXX"> </div>

Here “XXX” is a value that depends on the type of the HTML element and its role on the page. It can take a number of values—such as a form, navigation, search or article—based on the content it represents. There are three types of roles:

  • Landmark roles act as navigational landmarks.
  • Structural roles define the document’s structure and help organize content.
  • Widget roles consist of standalone UI widgets as well as composite widgets that are containers of two or more standalone widgets.

Figure 2 shows all the role values available in ARIA. There are eight landmark roles, 18 structural roles, 25 standalone interface widget roles and nine composite UI widget roles in ARIA. You’ll find more information at

Figure 2 ARIA Role Values

Landmark Roles Structural Roles Widget Roles
      Standalone Widgets Composite Widgets
application article region alert progressbar combobox
banner columnheader row alertdialog radio grid
complementary definition rowheader button scrollbar listbox
contentinfo directory separator checkbox slider menu
form document toolbar dialog spinbutton menubar
main group   gridcell status radiogroup
navigation heading   link tab tablist
search img   log tabpanel tree
  list   marquee textbox treegrid
  listitem   menuitem timer  
  math   menuitemcheckbox tooltip  
  note   menuitemradio treeitem  
  presentation   option    

Unlike roles, ARIA states and properties are attributes that can be set for each HTML element.

ARIA States

An ARIA state is a dynamic property of an HTML element that represents data associated with the object but doesn’t affect the essential nature of the element. There are two types of ARIA states—global and widget—as shown in Figure 3. Global states can be applied to any element regardless of whether a role has been applied to the element. Widget states are attributes of UI widgets that require user interaction.

The following shows the attribute aria-hidden:

<div aria-hidden="true">
  <p>Paragraph text here </p>

This code will hide the paragraph from a screen reader.

ARIA Properties

ARIA properties are similar to ARIA states but are relatively static on the page and act as additional properties of the HTML element. Widget properties are analogous to widget states but the value doesn’t change within the scope of the page. There are 11 global properties and 14 widget properties (see Figure 3).

Figure 3 ARIA States and Properties

Attribute Type Global Widget
ARIA States















ARIA Properties


























Here’s an example of the widget property aria-required:

<label for="username">User name:</label>
<input id="username" type="text" aria-required="true">

This makes a form’s input field required.

Figure 3 summarizes all of the ARIA states and properties. Visit for more information.

Now that you have some familiarity with ARIA and its roles, states and properties, you’ll be able to use it to create a progressively enhanced accessible Web site.

Creating an Accessible Web Site

A typical Web site contains a number of components. Let’s take a look at how to create each of the following, keeping accessibility in mind and using HTML5 and ARIA:

  1. Homepage
  2. Header area with logo
    • Navigation menu
    • Main graphics
    • Main content
    • Blocks of information
    • Contact form
  3. FAQ page
  4. About page with video

Figure 4 shows the basic structure of the site I’ll create.

Sitemap for Web Site Example
Figure 4 Sitemap for Web Site Example

Figure 5 shows a typical homepage layout for a product- or service-based site. To create it, I’ll first use HTML5 with progressive enhancement and then make it accessible to AT devices.

Standard Layout for a Homepage
Figure 5 Standard Layout for a Homepage

As you can see, I’ve identified a number of elements in the page: header, navigation, call to action, main graphics, welcome message with brief content, blocks of information and footer.

Following progressive enhancement principles, I create a sequential HTML5 page to accommodate these elements, using the elements <header>, <nav>, <figure>, <article>, <section>, <aside> and <footer>, as shown in Figure 6.

Figure 6 HTML5 Homepage

<!doctype html>
<html lang="en">
<head><title>HTML5 Home Page</title></head>
  <header><!-- header -->
  <a href="/"><img src="images/logo.png"></a>
<nav><!-- navigation -->
  <li><a href="/">Home</a></li>
  <li><a href="/contact">Contact</a></li>
  <li><a href="/faq">FAQ</a></li>
  <li><a href="/about">About</a></li>
<div><!-- main content -->
  <figure><img src="images/maingraphics.png">
  <figcaption>Welcome image. More help on image<a href="#/">Help</a></figcaption>
  <h2><a href="Action" target="_blank">Subscribe</a></h2>
  <p><strong>Lorem Ipsum </strong>is simply dummy text of the printing and … </p>
<aside><!-- info blocks -->
<footer><!-- footer -->
  <div>Copyright © 2012</div>
  <div><a href="">Privacy Policy</div>

This code is supported in most current browsers, and any HTML5 element not supported defaults to a <div> element. For example, if the <header> element isn’t supported, the browser would substitute a <div>, like so:

<header><!-- header -->
<a href="/"><img src="images/logo.png"></a>
<div><!-- header -->
<a href="/"><img src="images/logo.png"></a>

To allow AT tools to recognize the navigational landmarks and structural parts of the document, I add the following roles to each element, as shown in Figure 7:

  • header role=banner
  • nav role=navigation
  • maincontent role=main
  • section role=region
  • article role=article
  • aside role=complementary
  • footer role=contentinfo

Figure 7 Adding Roles

<!doctype html>
<html lang="en">
<head><title> Accessible HTML5 Home Page</title></head>
  <header role="banner"><!-- header -->
  <a href="/"><img src="images/logo.png"></a>
<nav role="navigation"><!-- navigation -->
  <li><a href="/">Home</a></li>
  <li><a href="/contact">Contact</a></li>
  <li><a href="/faq">FAQ</a></li>
  <li><a href="/about">About</a></li>
<div id="maincontent" role="main"><!-- main content -->
 <figure><img src="images/maingraphics.png">
 <figcaption>Welcome image. More help on image<a href="#/">Help</a></figcaption>
<section role="region">
  <h2><a href="Action" target="_blank">Subscribe</a></h2>
  <article role="article">
  <p><strong>Lorem Ipsum </strong>is simply dummy text of the printing and … </p>
<aside role="complementary"><!-- info blocks -->
<footer role="contentinfo"><!-- footer -->
  <div>Copyright © 2012</div>
  <div><a href="">Privacy Policy</div>

To apply styles for all browsers, the first step is to make all of the HTML5 elements block-level elements in the stylesheet, like this:


I include the ARIA roles so the styles are applied for each particular element:

  header[role="banner"]{/* Styles for banner */}
  header{/* Styles for other headers */}
  #maincontent[role="main"]{ /* Styles for main content */}
  nav[role="navigation"]{/* Styles for navigation */}
  section[role="group"]{/* Styles for section */}
  article[role="article"]{/* Styles for article */}
  aside[role="complementary"]{/* Styles for info blocks */}
  footer[role="contentinfo"]{/* Styles */}

Because the HTML page is parsed sequentially, the best place to put the JavaScript file is at the bottom of the page, after the footer. This lets the site be completely independent of JavaScript—the Java­Script function is instantiated only after the document is ready and fully loaded. The following code shows the script file inserted in my example:

<footer role="contentinfo"><!-- ><!-- footer -->

  <div>Copyright © 2012</div>

  <div><a href="">Privacy Policy</div>


  <script type="text/javascript" src="jquery.min.js"></script>

  <script type="text/javascript" src="main.js"></script>



Creating an Accessible Contact Form

Forms are an integral part of Web-based interaction, and HTML5 has a number of new input types and attributes that aid accessibility. Figure 8 lists the ones related to HTML5 forms.

Figure 8 Form Input Types and Attributes

Input Type

input type=datetime

input type=datetime-local

input type=date

input type=month

input type=time

input type=week

input type=number

input type=range

input type=email

input type=url

input type=search

input type=tel

input type=color
















For accessibility, a form should be restricted to a single purpose. A contact page should contain only the contact form and no other distraction. This makes it much easier for people using AT devices.

It’s also important to use the proper input type. This improves the UX for devices that support that attribute. For example, input type=number can show a numeric keypad for mobile devices while input type=url displays a special “.com” button in the virtual keyboard of many smartphones.

You use the for attribute in a label along with the id attribute in the input element, as follows:

<label for="useremail">Your E-mail:</label>
<input id="useremail" name="useremail" type="email" value=""/>

This maps the label to the input element in the assistive device. You could also do this in a more descriptive way using the aria-describedby attribute. For example, if you have some help text for each input field, you can wire it up with the input text:

<label for="useremail">Your E-mail:</label>
<input id="useremail" type="email" value="" aria-describedby="helpemail"/>
<p id="helpemail">Your email address will be used for further communication</p>

The next step is adding the placeholder and required HTML5 attributes (with aria-required=“true”). The placeholder attribute lets you show what valid input looks like and the required attribute makes the input box a required field:

<label for="useremail">Your E-mail:</label>
<input id="useremail" type="email" placeholder="" required
aria-required="true" value="" aria-describedby="helpemail"/>
<p id="helpemail">Your email address will be used for further communication</p>

Note that placeholder is not a label. And keep in mind that if you use an asterisk with the text to indicate a required field, the asterisk is read by screen readers with every field, providing a poor UX for the visually impaired. Instead, use the aria-required field attribute, which tells the AT device the field is required, and use a background color or image rather than the asterisk to indicate that to the user.

You can also add the autofocus attribute, which helpfully sets the focus to the first element of the form.

Figure 9 shows code that creates an accessible HTML5 contact form, and Figure 10 displays the contact form.

Figure 9 Creating an HTML5 Contact Form

<div id="contact" role="main"><!-- main content -->
  <!-- content -->
    <section id="content">
        <h2>Contact <span>Form</span></h2>
        <form id="contacts-form" action="" method="post">
            <div class="field">
              <label for="name" >Name </label>
              <input id="name" placeholder="John Smith" autofocus required
                aria-required="true" type="text" value="" />
            <div class="field">
              <label for="email">E-mail</label>
              <input id="email" placeholder="" type="email" required
                aria-required="true" value=""/>
            <div class="field">
              <label for="website">Website</label>
              <input id="website" placeholder=""
                type="url" />
            <div class="field">
              <label for="message">Message</label>
              <textarea id="message"
                placeholder="Write your message Here!" required
                aria-required="true" ></textarea>
            <div><a href="#" onclick="submit()">Send Your Message!</a></div>

The Contact Form Page in the Browser
Figure 10 The Contact Form Page in the Browser

Updates can be difficult for people with disabilities, but live regions can make assistive devices aware of updates when you use the aria-live attribute along with the role attributes of status, log and alert:

  • aria-live=“off”: updates are not announced (the region is not live)
  • aria-live=“polite”: updates are announced when the user is idle
  • aria-live=“assertive”: higher priority, but updates aren’t necessarily announced immediately
  • role=“log”, role=“status” and role=“alert” for different types of messages

Here’s a simple way to integrate this into the HTML code:

<div id="liveregion" role="log" aria-live="polite">

Now let’s look at a FAQ page with accessible content.

Creating an Accessible FAQ Page with Images

FAQ pages are among the most visited pages of many Web sites. Your FAQ may contain text, tables, links, images and titles, and these all should be accessible. Let’s see how you can accomplish this. First, the HTML content should contain only semantic HTML tags, and any decoration elements should go in the stylesheet. So, instead of:


you use:


and instead of:


you use:


Note that these elements add meaning to the content and are interpreted differently by screen readers. For example, some screen readers will change the tone for the <strong> element but not for <b> elements.

It’s also important to properly use title-related heading elements such as <h1>, <h2> and so on. Ideally, you should use one <h1> heading in a page and multiple subheadings as required. Make sure you have closing tags for each HTML element. Also be sure to close all the Ordered and Unordered lists correctly. Standard practice also suggests you lowercase all tags and nest them correctly. Figure 11 gives an example.

Figure 11 Markup for a FAQ Page

  <h2>List of frequently asked questions</h2>
    <li><a href="#q1">Accessible Text</a></li>
    <li><a href="#q2">Accessible Tables</a></li>
    <li><a href="#q3">Accessible Links</a></li>
    <li><a href="#q4">Accessible Images</a></li>
    <li><a href="#q5">Accessible Titles</a></li>
  <h2 id="q1">Accessible Text</h2>
    <h3>Semantic HTML</h3>
    <h3>Proper hierarchy</h3>
    <h3>Localized content</h3>
  <h2 id="q2">Accessible Table</h2>
  <h2 id="q3">Accessible Links</h2>
  <h2 id="q4">Accessible Images</h2>
  <h2 id="q5">Accessible Titles</h2>

To create localized content, you set the language of the page using the lang attribute in the global <html> element:

<html lang="en">

For content in a different language, use lang within <p> or <span> elements, like this:

<p><span lang="la">Carpe diem </span>(seize the day)</p>

And use the abbr tag for abbreviations:

<p>The <abbr title="World Wide Web Consortium">W3C</abbr> was founded in 1994.</p>

The font size of your content should always be relative. Never use absolute or fixed sizes, as this restricts the browser’s font-scaling functionality. Use one of the following to increase or decrease the font size from the browser’s default:

  • percentage (%)
  • em (relative to the size of the capital M)
  • ex (relative to the size of the capital X) 
  • Keywords (small, medium, larger, smaller, larger and so forth) 

Here’s an example:


Color should be used as a visual aid to the content and should not be used alone for presenting infor­mation. A high color contrast between foreground and background is important to make the page accessible. The W3C recommends a contrast ratio of 4.5 to 1 for normal text and 3 to 1 for larger text.

For form validation, individual input elements may show the background as colored to indicate an error, which might not be visible to a color-blind user. Make sure you have multiple cues for the same information, such as a label to indicate an error.

When you’re using a color in a stylesheet, set the background-color element to use a complementary color. Some people can read more easily with a black background, so allow change of page color to a darker theme. Here’s an example:

body {
  font-family:Arial, Helvetica, sans-serif;

Standard tables generally have a header row and possibly a footer row, but distinguishing these isn’t possible with simple table tags. HTML5, however, brings a number of helpful new tags:

  • <caption> is the title of the table
  • <details> shows additional details a user can view or hide on demand
  • <summary> is announced before the real table data is read by a screen reader
  • <thead> indicates the table header row
  • <tfoot> indicates the table footer row

Figure 12 shows code for a sample HTML table that’s accessible to AT devices.

Figure 12 An Accessible Table

<h4>Table with Caption, Summary and Details</h4>
    <strong>Lorem Ipsum.</strong>
      <p><strong>Lorem Ipsum </strong>is simply dummy text of the printing and </p>
      <th>Table header column 1</th>
      <th>Table header column 2</th>
      <th>Table header column 3</th>
      <td>Table footer column 1</td>
      <td>Table footer column 2</td>
      <td>Table footer column 3</td>
      <td>Table data column 1</td>
      <td>Table data column 2</td>
      <td>Table data column 3</td>

When creating links, avoid using generic “click here” and “see more” links. Use the title attribute and meaningful anchor text. Here’s a correct way to add links:

<p> has an article on accessibility. See the <a title="click for more information at the Design & Method Web site" href="">Big picture at Design and Method</a></p>

Be careful about using ASCII symbols. When you have multiple pages, avoid using the greater-than and less-than symbols (> and <) to go forward and back to the next set of items. Instead, use clear text, such as “Next 10 items” and “Previous 10 items.” Note that it may seem logical to use the greater-than symbol in breadcrumb navigation but, unfortunately, the screen reader will read “Next >>” as “Next, greater than, greater than,” which is not useful. Use a CSS background image if your design requires a “>.”

Finally, links should be underlined. This helps a color-blind user to determine that the text is a link. You can do this in the stylesheet using decoration:

  text-decoration: underline;
  border-bottom:1px solid #000;

To make images accessible, start with a meaningful alt attribute and use a blank alt (alt=“”) for decorative images. Be sure to include the title attribute—it shows up as a tool tip and is checked by screen readers if the alt attribute is not available. If neither the alt nor title attributes are found, the AT device will announce the name of the image, so be sure to give the image a meaningful name.

Use role=presentation for an image or for any element that’s not relevant to AT devices. If you’re including image maps, use alt for each area. You can also use the figure and figcaption tags for images. Keep animated images to a minimum; they can cause seizures for people with epilepsy.

The following example shows how to make an image accessible:

<figure><img src="images/maingraphics.png" alt="Example screen shot" title="main graphics showing screenshot example"><figcaption>Image with caption.</figcaption></figure>

Here’s the code for an image map:

<area shape=rect coords=0,0,10,10 href="example.htm" alt="example">

The last point on creating accessible content is to include relevant keywords at the beginning of titles. Having concise titles with relevant keywords at the beginning helps visually impaired users skim through them faster.

In the following example, having redundant “How to make” in each title seems more readable, but a screen reader would repeat those first three words for every title, making it difficult for users to skim the content quickly. Using precise and relevant keywords at the beginning of the title makes it more accessible:

<a href="#q1"><!--How to make content Accessible-->Accessible Content</a>
<a href="#q2"><!--How to make links Accessible-->Accessible Links</a>
<a href="#q3"><!--How to make images Accessible-->Accessible Image</a>
<a href="#q4"><!--How to make titles Accessible-->Accessible Titles</a>

Now let’s take a quick look at adding an About page to the accessible Web site—one that contains audio and video. Let’s see what I need to make audio and video elements accessible.

An Accessible About Page with Audio and Video

Suppose I want my About page to contain a video that explains the founding of my Web site. The <audio> and <video> tags in HTML5 make it easy to embed multimedia content in a Web page, but doing so creates challenges with respect to accessing content for those who are non-native speakers, deaf or hard of hearing, blind, or for anyone who may have broken speakers or be in a loud environment. There are specific guidelines to follow for each of these challenges. Here are some ways to make audio and video content accessible:

  • Include text transcripts for the audio or video in HTML format.
  • Include alternative content for browsers that don’t support media tags.
  • Controls should, at minimum, have an On/Off button.
  • Media should not auto-start but should be user-initiated.
  • Provide a link to download the media file.
  • Provide captioning (closed captions or subtitles) using a video/audio track.

Subtitles are typically a time-aligned transcription of the spoken words in a video, which can help users to understand the content. For deaf users, captions are a better solution because they include transcriptions of noises, sound effects, music and the like, along with spoken words.

Right now we have caption and subtitle support using the track element along with the following formats: 

  • WebVTT for captioning video content
  • SMPTE-TT, a timed-text format for subtitling
  • SRT, for subtitle files

Note that accessibility support for video is still a work in progress, but here’s an example:

<video controls>
<source src="video-file.mp4" type="video/mp4"/>
<track src="en.vtt" kind="subtitles" srclang="en"
label="English p subtitles" default/>
<track src="en.ttml" kind="captions" srclang="en"
label="English p captions" default/>

Although there isn’t granular control over media, HTML5 has a controls attribute that displays controls for the media element. These controls are accessible by keyboard:

  • The space bar toggles between play and pause.
  • The left and right arrows wind the video forward and back by 5 seconds.
  • CTRL+left arrow or right arrow winds the video forward or back by 60 seconds.
  • HOME+left arrow or right arrow jumps to the beginning or end of the video.
  • If the volume button has focus, the up and down arrows increase and decrease the volume.

Accessibility Support in Visual Studio 2012

You’ll be happy to know that Visual Studio 2012 makes accessibility easier. There’s now IntelliSense for ARIA roles, attributes and properties in HTML elements, as shown in Figure 13 and Figure 14.

IntelliSense Support for ARIA Roles in Visual Studio 2012
Figure 13 IntelliSense Support for ARIA Roles in Visual Studio 2012

ARIA Properties Are Supported in IntelliSense
Figure 14 ARIA Properties Are Supported in IntelliSense

After you create an accessible Web page, you’ll want to check to make sure it actually meets accessibility requirements. With Visual Studio 2012, you can do so easily by right-clicking on a page and selecting Check Accessibility, as shown in Figure 15.

You Can Check Accessibility of a Web Page in Visual Studio 2012
Figure 15 You Can Check Accessibility of a Web Page in Visual Studio 2012

You then choose the Web Content Accessibility Guidelines, or WCAG, level you want to check against: Priority 1 or Priority 2 (see You can also check against Access Board Section 508, which refers to standards defined by the United States government in Section 508 of the Rehabilitation Act ( Once you’ve selected the guidelines, Visual Studio 2012 checks all the HTML elements and displays a detailed report on any errors or warnings in the page, as shown in Figure 16.

Web Content Accessibility Report in Visual Studio 2012
Figure 16 Web Content Accessibility Report in Visual Studio 2012

You’ve now learned how to create an accessible Web site using HTML5, and you’ve seen how some Visual Studio 2012 accessibility features can help. These should be useful additions to your toolbox as you explore the accessible Web.

Rajesh Lal works at Nokia and is passionate about HTML5 and Web technologies. He has written multiple books on Windows gadgets, Web widgets, the mobile Web and Silverlight technologies. To discuss accessibility in software design and method, visit

Thanks to the following technical experts for reviewing this article: Art Barstow, Lakshmi C. Chava and Dennis Lembrée