The standard method for hiding text visually to retain a clean design but provide context for screen reader users is to use the CSS clip technique. Due to browser bugs with the clip property, other declarations are used to make this technique work correctly across different browsers.

Two of the properties used in the additional declarations for the clip technique are position and overflowbug with Firefox, when these two properties are used together in a rule applied to the label element (regardless of property value), they cause the label text to not be exposed as the accessible name for the corresponding form control. The position and overflow properties are also used in other techniques for hiding text visually, but this bug means the accessible name will not be available for screen reader users when applied to a label element.

Providing context

There are times when things make sense visually, but context would be useful for screen reader users. For example, "read more" links might make sense visually, but when tabbing through content with a screen reader, the user needs to investigate the surrounding content to get the context for each "read more" link; whereas, "read more about The Beatles" provides the context within the link phrase. To avoid disrupting a clean design, accessibility aware developers provide the context so that it's available for screen readers, but hidden visually. The following markup example provides the context for a "read more" link in a span element.

<a href="beatles.php">
  read more
  <span class="context"> about The Beatles</span>
</a>

The span element in the above example can then be targeted with CSS so that it isn't visually displayed, but announced to screen reader users for context.

Techniques for hiding text visually

There have been several techniques used to hide content so that it is still available for screen reader users, but the clip technique is generally agreed to be the best solution as it satisfies the requirements of hiding the text while ensuring the text is still readable with a screen reader, and works with left-to-right and right-to-left languages. If browser support for CSS was implemented correctly across browsers, the following CSS rule would be all that's required to hide content visually.

.context {
  position: absolute !important;
  clip: rect(1px, 1px, 1px, 1px);
}

Unfortunately, other CSS properties are needed to overcome rendering bugs in some browsers. For example, Safari, Chrome, and Opera sometimes introduce scrollbars depending on the size of the element and its position on the page. IE6 and IE7 do not support the correct syntax for the clip property. The following is an example of the CSS rule with other declarations to ensure it works correctly across browsers.

.context {
  position: static !important;
  clip: rect(1px 1px 1px 1px); /* for IE6 and IE7 */
  clip: rect(1px, 1px, 1px, 1px);
  padding: 0 !important;
  border: 0 !important;
  height: 1px !important;
  width: 1px !important;
  overflow: inherit;
}

Firefox label bug

When the CSS properties position and overflow are used together in a rule that is applied to the label element with any valid property value, the label text isn't exposed as the accessible name for the corresponding form control in Firefox; even if the values are the default values for the property (position: static and overflow: visibleNVDAJAWS, but the label isn't exposed as the accessible name for the form control as it should be.

bug with Firefox last year, but the bug hasn't been assigned to anyone yet. As the position and overflow properties are used together in several techniques for providing invisible context for accessibility purposes, it is important developers are aware of this bug and that it is fixed soon in Firefox.

Workarounds

We generally recommend the titlearia-label attribute if there is no visible label at all (such as checkboxes arranged in grids that make sense visually). We only recommend using the CSS clip technique when the rule is applied to some of the label, rather than the entire label. Until this bug is addressed in Firefox, using the title attribute or aria-label attribute are the recommended techniques for providing a programmatic label for form controls that do not have a visible label.

<input type="checkbox" title="Personal bank account" ⋯>

<input type="checkbox" aria-label="Personal bank account" ⋯>

If the label approach must be used and then visually hidden, apply the CSS rule to a span element within the label element, as the bug is only triggered when the rule is applied to the label element.

<input type="checkbox" id="pba" ⋯>
<label for="pba"><span class="context">Personal bank account</span></label>

Icon fonts are vector graphics that are included in the content using the CSS content property on a before or after pseudo-class selector. As with regular fonts, icon fonts are scalable and can be styled using CSS, unlike images. They also have the benefit that they remain visible in high contrast on Windows, unlike CSS background images. The biggest drawback from an accessibility point of view is that they won't work if a user's user-defined style sheet overrides the font-family property.

Icon fonts

IcoMoonaria-hidden attribute should be used on the element to ensure it is not revealed to assistive technologies.

<div class="icon-star" aria-hidden="true"></div>

If the icon is used to convey information, then it should contain a text alternative that may be hidden visually if required, but available for assistive technologies.

<div class="icon-mail"><span class="context">Mail</span></div>

The text that provides the context for the icon can then be hidden visually with CSS so that it's still available to screen reader users.

.context {
  position: absolute !important;
  clip: rect(1px, 1px, 1px, 1px);
  padding: 0 !important;
  border: 0 !important;
  height: 1px !important;
  width: 1px !important;
  overflow: hidden;
}

To work, icon fonts depend on the font-family property in CSS. If the icon is purely decorative, being overridden by the user's style sheet isn't an issue. When an icon font is used to convey information, such as the graphic for a button element, it means the visual representation will be missing, which is a serious issue.

User-defined style sheets

David Sloanunderstanding users' text requirements that analyses 203 user-defined style sheets from 25 people.

For readability, it seems reasonable to assume that the font-family property is likely to be overridden. The study shows that font-family is the fourth most common global property, and the second most common element-level property to be overridden in the user's style sheet. Although the number of people using user-defined style sheets for accessibility might be small, they shouldn't be overlooked.

Determining if font-family is honoured

One solution to the problem is to use a script to determine if font-family is honoured. If the property is honoured, then use icon fonts; otherwise, only use them if they're decorative, and use an alternative method where they provide visual information to ensure it's usable by someone using a user-defined style sheet. The following is an example of a function that could be used to check if the font is honoured:

Update: Federico Brigantetechnique that could be used to detect whether a font is available.

function checkFont(strFamily) {
  var objDiv = document.createElement('div');

  objDiv.style.fontFamily = strFamily;
  objDiv.appendChild(document.createTextNode('FONT TEST'));

  if (window.getComputedStyle) {
      return window.getComputedStyle(objDiv, null).getPropertyValue('font-family') === strFamily;
  }

  return objDiv.currentStyle.fontFamily === strFamily;
}

The function can then be called with the appropriate font-family property:

var bHonoured = checkFont('icomoon');

Adopting this technique means the page gets the benefit of using icon fonts, but also ensures that people using user-defined style sheets to improve readability for accessibility also get the information.

Useful resources

• Using icon fonts
• Icon fonts are awesome
• Creating a custom icon font using IcoMoon

JAWS' implementation of the HTML5 outline algorithm is incorrect with IE and Firefox when the author explicitly specifies the heading levels. Fortunately, there is a relatively simple fix until JAWS finally fixes the bug.

The HTML5 outline algorithm and JAWS

HTML5 outline algorithm should automatically expose the correct heading level depending on the structure of sectioning elements. The following section elements influence the outline algorithm:

• article
• aside
• h1-h6 (within a section)
• nav
• section

The following example is marked up using just level-1 heading elements, and is reported correctly by JAWS using IE and Firefox.

<h1>Main page title</h1>
<nav>
  <h1>Site navigation</h1>
  <ul>
    <li>Home</li>
    <li><a href="⋯">Quality Assurance</a></li>
    <li><a href="⋯">Articles Archive</a></li>
  </ul>
</nav>
<section>
  <h1>Recent Posts</h1>
  <article>
    <h1>HTML5 outline algorithm and headings</h1>
    <p>
      How to fix the bug with JAWS and the HTML5
      outline algorithm.
    </p>
    <aside>
      <h1>Publish date</h1>
      <time datetime="2013-05-10T14:59Z">
        Friday, 10th May 2013
      </time>
    </aside>
  </article>
  <article>
    <h1>Handling erratic behaviour with AT</h1>
    <p>
      Difficulties testing with erratic AT, 
      such as when outline algorithms go bad.
    </p>
    <aside>
      <h1>Views</h1>
      <p>This article has been viewed 3.7 times</p>
    </aside>
  </article>
</section>

Using JAWS with IE and Firefox, the heading levels are announced as:

• Main page title - heading level 1
• Site navigation - heading level 2
• Recent posts - heading level 2
• HTML5 Outline Algorithm and Headings - heading level 3
• Publish date - heading level 4
• Handling erratic behaviour with AT - heading level 3
• Views - heading level 4

With screen readers that do not yet support the HTML5 outline algorithm, such as NVDA and VoiceOver, all of the headings are announced as level-1 headings. The HTML5 outline algorithm allows authors to explicitly specify the heading levels so that they're supported by older user agents.

<h1>Main page title</h1>
<nav>
  <h2>Site navigation</h2>
  <ul>
    <li>Home</li>
    <li><a href="⋯">Quality Assurance</a></li>
    <li><a href="⋯">Articles Archive</a></li>
  </ul>
</nav>
<section>
  <h2>Recent Posts</h2>
  <article>
    <h3>HTML5 outline algorithm and headings</h3>
    <p>
      How to fix the bug with JAWS and the HTML5
      outline algorithm.
    </p>
    <aside>
      <h4>Publish date</h4>
      <time datetime="2013-05-10T14:59Z">
        Friday, 10th May 2013
      </time>
    </aside>
  </article>
  <article>
    <h3>Handling erratic behaviour with AT</h3>
    <p>
      Difficulties testing with erratic AT, 
      such as when outline algorithms go bad.
    </p>
    <aside>
      <h4>Views</h4>
      <p>This article has been viewed 3.7 times</p>
    </aside>
  </article>
</section>

This example now correctly reports the heading levels in screen readers that do not support the HTML5 outline algorithm, but are now reported incorrectly by JAWS. JAWS announces the level implied by the outline added to the explicitly specified level. The headings in this example are now announced by JAWS as:

• Main page title - heading level 1
• Site navigation - heading level 3
• Recent posts - heading level 3
• HTML5 Outline Algorithm and Headings - heading level 5
• Publish date - heading level 2 (Firefox only; not recognised as a heading in IE)
• Handling erratic behaviour with AT - heading level 5
• Views - heading level 2 (Firefox only; not recognised as a heading in IE)

JAWS calculates all heading levels within a section by adding the explicit heading level to the heading level calculated from the outline. This works if all headings within a section start with a level-1 heading, and then used in order without skipping a level in the section, but breaks if the levels are not reset for each section. If a level-3 heading element is defined in the first section element, JAWS announces it as a level-4 heading:

<section>
  <h2>Recent Posts</h2>
⋯
  <h3>Sub-heading</h3>
⋯
</section>

Similarly, if a level is skipped, JAWS just adds that level to the current outline calculation. So a level-4 element in the first section element would be announced as a level-5 heading:

<section>
  <h2>Recent Posts</h2>
⋯
  <h4>Sub-heading</h4>
⋯
</section>

Fixing the JAWS bug

WAI-ARIAheadingaria-level attribute on the heading elements that are reported incorrectly.

<h1>Main page title</h1>
<nav>
  <h2 role="heading" aria-level="2">
    Site navigation
  </h2>
  <ul>
    <li>Home</li>
    <li><a href="⋯">Quality Assurance</a></li>
    <li><a href="⋯">Articles Archive</a></li>
  </ul>
</nav>
<section>
  <h2 role="heading" aria-level="2">
    Recent Posts
  </h2>
  <article>
    <h3 role="heading" aria-level="3">
      HTML5 outline algorithm and headings
    </h3>
    <p>
      How to fix the bug with JAWS and the HTML5
      outline algorithm.
    </p>
    <aside>
      <h4 role="heading" aria-level="4">
        Publish date
      </h4>
      <time datetime="2013-05-10T14:59Z">
        Friday, 10th May 2013
      </time>
    </aside>
  </article>
  <article>
    <h3 role="heading" aria-level="3">
      Handling erratic behaviour with AT
    </h3>
    <p>
      Difficulties testing with erratic AT, 
      such as when outline algorithms go bad.
    </p>
    <aside>
      <h4 role="heading" aria-level="4">
        Views
      </h4>
      <p>This article has been viewed 3.7 times</p>
    </aside>
  </article>
</section>

The heading elements are now announced correctly by all screen readers, including JAWS.

aria-controlstabstree views, and similar relationships where one element controls another. The attribute defines the relationship so that assistive technology users can navigate to the content effected by the controlling element; for example, from a tab to the associated tab panel.

Considering the importance of being able to define these relatively simple relationships, the aria-controls attribute has surprisingly poor support. The only browser/assistive technology combination that I'm aware of that supports this relationship at the moment is Firefox/JAWS.

Simple tab control design pattern

A simple tab control design pattern will illustrate this issue, and is fairly common in web applications.

WAI-ARIA roles and use properties to ensure they are understandable to assistive technologies. The unordered list (ultablistpresentation so the semantics of list items are not conveyed to assistive technologies. The rest of this discussion assumes an anchor element will be used within a list item, as that's the best approach for progressive enhancement and seems to be the most common design pattern deployed for tabs.

tab, and the following attributes should be set for each anchor element:

• aria-selected - indicates whether this tab is the currently selected tab in the tab list.
• aria-controls - identifies the id attribute value of the panel that is displayed when this tab is selected. This is the relationship that should allow assistive technologies to navigate to the panel.
• tabindex - A value of 0 means that the element is included in the tab order where it is in the source, and a value of -1 means that it is not included in the keyboard tab order, but can receive programmatic focus with JavaScript (objTab.focus();). Only the currently selected item in the tab should have a tabindex attribute value of 0, so the user can skip the group of links pressing TAB. Using the cursor keys should change the TAB selection (the keyboard keystrokes provided at the end of this section).

tabpanel, and the following attributes should be set on each panel:

• aria-hidden - Indicates whether the element is visible or not.
• aria-expanded - Indicates whether the element is currently expanded or collapsed.
• aria-labelledby - Identifies the tab that labels this panel.

Consider the following example with 4 tabs.

The following is the markup to produce the 4 tabs so they are exposed correctly to assistive technologies using the design pattern outlined above. In this example, the second tab, "Review Terms", is the currently selected tab.

<ul role="tablist">
  <li role="presentation">
    <a href="#" 
       role="tab" 
       aria-controls="panel1" 
       aria-selected="false" 
       tabindex="-1" 
       id="tab1">Account overview</a>
  </li>
  <li role="presentation">
    <a href="#" 
       role="tab" 
       aria-controls="panel2"
       aria-selected="true" 
       tabindex="0" 
       id="tab2">Review terms</a>
  </li>
  <li role="presentation">
    <a href="#" 
       role="tab" 
       aria-controls="panel3"
       aria-selected="false" 
       tabindex="-1" 
       id="tab3">Manage contract</a>
  </li>
  <li role="presentation">
    <a href="#" 
       role="tab" 
       aria-controls="panel4"
       aria-selected="false" 
       tabindex="-1" 
       id="tab4">View history</a>
  </li>
</ul>

<div id="panel1" 
     role="tabpanel"
     aria-hidden="true"
     aria-expanded="false"
     aria-labelledby="tab1">
  <h2>Account overview</h2>
  ⋯
</div>

<div id="panel2"
     role="tabpanel"
     aria-hidden="false"
     aria-expanded="true"
     aria-labelledby="tab2">
  <h2>Review terms</h2>
  ⋯
</div>

⋯

<div id="panel4"
     role="tabpanel"
     aria-hidden="true"
     aria-expanded="false"
     aria-labelledby="tab4">
  <h2>View history</h2>
  ⋯
</div>

The following keystrokes should be supported by the tab control.

Hans Hillen'sjQuery components demonstration that uses a tab control for each of the components.

Usage issues

There must be a way for assistive technology users to navigate from the tabs to the tab panels. Cursor keys are usually used as reading keys, but the cursor keys are being used to control the tabs so are no longer available for this purpose. This is where the aria-controls attribute should help, as the relationship is defined, so there just needs to be a way for the user to navigate to the associated panel.

Firefox with JAWS does this by announcing, "Press JAWS key + ALT + M to move to controlled element". When those keys are pressed, JAWS announces, "Moved to controlled element". The user can then navigate the panel using regular keystrokes. Unfortunately, all other browser/assistive technology combinations I tried did not provide a mechanism to navigate to the controlled element. Chrome/JAWS consistently announces, "Failed to move to controlled element" when using JAWS key + ALT + M, so it could be they plan to implement something soon with JAWS.

There are obviously ways of navigating into the panel, but not acceptable equivalents of certainly knowing that you're at the top of the panel. For example, in JAWS, a user could toggle the virtual cursor on and off to break the cursor navigation with tabs and then navigate to the panel. Or the user could tab to the next focusable interface element (if there is one, which may or may not be in the tab panel), and then navigate backwards to try and find the tab. But these are clumsy recovery techniques that users will have to use if these kinds of widgets are deployed without user agent support. The only solution I can think of now is for developers to designate a keystroke that allows navigation to the panel, and ensure it's documented, until there is better support.

Hans HillenTPGJAWS, and has kindly allowed me to post it here, as this is useful information.

What techniques do you use to handle strange behaviour in JAWS and other assistive technologies?

Dealing with JAWS Quirks

The following is the standard approach to dealing with JAWS Quirks (follow in order until the issue is fixed):

1. Use Ins + Esc to refresh the virtual buffer. This sometimes causes JAWS to properly trigger virtual mode.
2. Alt + Tab to a different application and then back to the browser. This sometimes causes JAWS to properly trigger virtual mode.
3. Restart the browser. Specifically with Firefox, JAWS support is better if JAWS is already running when Firefox starts up. There was a time where this was required for Firefox to expose accessibility information, but this doesn't always seem to be the case anymore. Even so, in some cases this will fix the issue.
4. Restart JAWS. Sometimes JAWS just needs to be restarted for it to behave properly.

Virtual mode stops working

The virtual mode has stopped working when the keystrokes to navigate the virtual buffer have stopped working. For example, H for heading navigation doesn't work anymore. When requesting a virtual list (e.g. a link list), JAWS will announce, "this feature is only available in a virtual document". The website is essentially being navigated in forms/application mode, although JAWS seems to provide less information than usual. When pressing certain virtual navigation keys, JAWS will be quiet, but if you press tab it will announce the keys as if you had typed them into a document (e.g. "H H H"). When tabbing between elements, JAWS may just say "TAB" or it may announce the focused element. Using the arrow keys will scroll the page rather than navigate virtually.

Virtual mode solutions

1. Ensure that focus has been moved into the actual web page. If your focus is elsewhere in the browser, such as on the address bar, JAWS will consider it a desktop application that does not support virtual mode. Moving focus into the page should fix this (for example, by tabbing, clicking on the page with the mouse, or using the Ctrl + F6 shortcut).
2. dealing with JAWS quirks.

Jaws announces the same element when tabbing through the page

aViewer or Inspect32, the browser does in fact expose the correct information for the focused element, but JAWS still announces something else.

Same element solutions

1. Press INS + Tab. This causes JAWS to announce the focused element again, and sometimes this causes the currently focused element to be announced correctly.
2. Turn off virtual mode using INS + Z (repeat twice to make the switch stick). This issue seems to be most common when tabbing between elements while virtual mode is active. It seems to increase specifically for elements that trigger auto forms mode. Manually switching to forms mode or application mode causes JAWS to announce the actual exposed accessibility information.
3. dealing with JAWS quirks.

Broken table navigation

When navigating a data table (Ctrl + Alt + Arrow Keys), JAWS will sometimes act like there are no cells in a row or column. When navigating to an adjacent cell, it will announce "beginning/end of row/column", as though the actual cells in the data table do not exist.

Broken data table solutions

1. dealing with JAWS quirks.

JAWS can't find elements

When navigating to tables, headings, lists, and so on, JAWS announces that there are no elements of this type on the page, even though there clearly are.

Missing element solutions

1. Use Ins + Esc to refresh the virtual buffer, sometimes this cases JAWS to properly trigger virtual mode.
2. Move (virtual) focus to the start of the page using Ctrl + Home. Sometimes JAWS seems to perform a shortcut within a specific scope, which is not always the actual page loaded in the browser. For example, if (virtual) focus is placed near the start of the document, the M key will list all frames in the loaded page. If you move inside one of those frames though, JAWS will only look inside that frame and it's not possible to find the other frames in the main document (until you move focus back to that scope).

Opening virtual HTML Features list

When using the INS + F3 shortcut for opening the Virtual HTML features list, JAWS will sometimes display the "JAWS virtual find" search dialog instead.

Virtual HTML features list solutions

1. This also seems to be caused by the scope JAWS is currently in. It seems the (virtual) focus really needs to be inside the web content before you can use INS + F3 for the virtual HTML Features list. Anywhere else, and you get the Virtual Find dialog.

Other techniques

The intention of this article is to gather other recovery techniques for all assistive technologies. What techniques do you use to handle strange behaviour in JAWS and other assistive technologies?

Custom-built dialogs are common in web-based applications, but many are not accessible. Most of them are not announced to assistive technologies, and so screen reader users are not made aware that a dialog has been launched. Many are also not focused when they are launched, and so keyboard-only users are still focused on elements in the background, and might have to navigate through the content in order to reach the dialog.

WAI-ARIA specification defines roles and attributes that help ensure dialogs are announced correctly to assistive technology users, and provides guidance on ensuring they are keyboard accessible.

WAI-ARIA Dialogs

dialogalertdialog roles to define dialogs. The dialog role is used when the user is expected to provide data, and the alertdialog role is used to announce the contents of a dialog to the user.

The container element for both dialog and alertdialogaria-labelledbyaria-label attribute may be used if there is no heading in the dialog, but all dialogs should contain a visible heading.

Using the alertdialog role

aria-describedby attribute to identify the message of an alertdialog. When the dialog is displayed, focus should be placed on an active element within the dialog, such as an OK button.

Consider a simple dialog with a list of instructions for shutting down a system.

The container for the dialog should have a role of alertdialog, with the aria-labelledby attribute containing a value that matches the id attribute value for the heading, and the aria-describedby attribute containing a value that matches the id attribute value for the description.

<div role="alertdialog"
     aria-labelledby="dlgtitle"
     aria-describedby="instructions">
  <h1 id="dlgtitle">Shutdown instructions</h1>
  <ol id="instructions">
    <li>Open timesheet</li>
    <li>Enter time for today</li>
    <li>Close all open applications</li>
    <li>Shut down system</li>
  </ol>
  <div>
    <input type="button" value="OK">
  </div>
</div>

Using the dialog role

When a role of dialog is used, some screen readers will automatically go in to application mode. This shouldn't be a problem, as the dialog role should be used for getting data from the user, and screen readers usually automatically go into forms mode when interacting with form controls. Consider a dialog for the user to signup to a newsletter. As with the alertdialog example, focus should be placed on an active element within the dialog; in this case, the "Email" edit box.

The container for the dialog should have a role of dialog, with the aria-labelledby attribute containing a value that matches the id attribute value for the heading.

<div role="dialog" aria-labelledby="dlgtitle">
  <h1 id="dlgtitle">Sign up to Newsletter</h1>
  <div>
    <label for="email">Email: </label>
    <input type="text" id="email" name="email">
    <input type="button" value="Sign up">
  </div>
</div>

aria-describedby attribute.

The following example includes instructions, which are programmatically associated to the "Email" edit box using aria-describedby.

The email address now requires the aria-describedby attribute containing a value that matches the id attribute value for the description.

<div role="dialog" aria-labelledby="dlgtitle">
  <h1 id="dlgtitle">Sign up to Newsletter</h1>
  <ol id="instructions">
    <li>Enter email address</li>
    <li>Press the 'Sign up' button</li>
    <li>You're all signed up!</li>
  </ol>
  <div>
    <label for="email">Email: </label>
    <input type="text" 
           id="email"
           name="email"
           aria-describedby="instructions">
    <input type="button" value="Sign up">
  </div>
</div>

There shouldn't really be a scenario where a screen reader user would need to interact with content in a dialogdocument. For example, if the dialog contains a data table, then the data table should be in a container with a role of document so that screen reader users can use their table reading keys to interact with the table.

Modal and non-modal dialogs

A modal dialog is a dialog that retains focus until the dialog is closed or dismissed. It should not be possible for keyboard-only users to accidentally tab into the background content when either a modal or non-modal dialog is displayed. With a modal and non-modal dialog, the user should either explicitly dismiss the dialog (for example, selecting "Cancel" or pressing ESC) or close it by taking a positive action, such as selecting "OK" or "Submit". With a non-modal dialog, the user should also be able to use the F6 key to switch between the dialog and the main content.

Further reading

• WAI-ARIA Authoring practice design pattern for a modal dialog
• WAI-ARIA Authoring practice design pattern for a non-modal dialog
• Hans Hillen's dialog widget example

WAI-ARIA to fix the accessibility issues of the more popular techniques.

Current techniques

Ideally, this problem should be solved using just CSS by specifying the height, overflow, and display properties on the body of the table (tbodyPure CSS Scrollable Table with Fixed Header is an old but good example of a CSS version that works in most browsers and screen readers, but doesn't render properly in IE9.

jQuery Plugin for Fixed Header Tables is a good example of this technique, but there are plenty of other examples that essentially do the same. This technique is popular, because it's easier to get to work cross-browser. The accessibility of this solution is not so good, as it results in a separate table just for the headers. Most of the solutions that attempt to remain accessible duplicate the headers in the scrolling table and hide them visually so they are still available to screen readers; but there is still a redundant table in the content containing just the headers.

WAI-ARIA as a repair technique

As having two tables seems to be the most reliable in terms of portability, one solution would be to repair the technique so that it appears as a single table to assistive technologies. Consider a data table that determines calories burned depending on the weight and pace of a runner with the headers in a completely different table so that the main body can be set to scroll, as most approaches appear to use this or a variation on this technique.

<table>
<tr>
  <th>Pace</th>
  <th>59KG</th>
  <th>74KG</th>
  <th>86KG</th>
</tr>
</table>

<table>
⋯
<tr>
  <th>12 min/mile</th>
  <td>472 cal/hour</td>
  <td>582 cal/hour</td>
  <td>691 cal/hour</td>
</tr>
<tr>
  <th>11 min/mile</th>
  <td>532 cal/hour</td>
  <td>655 cal/hour</td>
  <td>734 cal/hour</td>
</tr>
<tr>
  <th>10 min/mile</th>
  <td>591 cal/hour</td>
  <td>727 cal/hour</td>
  <td>864 cal/hour</td>
</tr>
⋯
</table>

The process to repair and merge the table with WAI-ARIA is outlined below:

• grid.
• presentation so they are ignored by assistive technologies.
• Remove hidden headers from the main data table if they have been provided.
• rowcolumnheaderrowheadergridcell to create the structure of a single table.
• aria-labelledby to create an association between the table and the table's header, so that the table is announced with the context of a heading, similar to a native HTML data table having a caption.
• aria-readonly attribute should be used to indicate that it's a read-only data table.

The following is the resulting structure:

<h2 id="calburn">Calorie burn by pace and weight</h2>
<div role="grid"
     aria-labelledby="calburn"
     aria-readonly="true">
  <table role="presentation">
  <tr role="row">
    <th role="columnheader">Pace</th>
    <th role="columnheader">59KG</th>
    <th role="columnheader">74KG</th>
    <th role="columnheader">86KG</th>
  </tr>
  </table>

  <table role="presentation">
⋯
  <tr role="row">
    <th role="rowheader">12 min/mile</th>
    <td role="gridcell">472 cal/hour</td>
    <td role="gridcell">582 cal/hour</td>
    <td role="gridcell">691 cal/hour</td>
  </tr>
  <tr role="row">
    <th role="rowheader">11 min/mile</th>
    <td role="gridcell">532 cal/hour</td>
    <td role="gridcell">655 cal/hour</td>
    <td role="gridcell">734 cal/hour</td>
  </tr>
  <tr role="row">
    <th role="rowheader">10 min/mile</th>
    <td role="gridcell">591 cal/hour</td>
    <td role="gridcell">727 cal/hour</td>
    <td role="gridcell">864 cal/hour</td>
  </tr>
⋯
  </table>
</div>

Alternatively, the structure could be defined with WAI-ARIA removing the HTML tables completely, as it's far easier to control the div elements with CSS than the tables.

<h2 id="calburn">Calorie burn by pace and weight</h2>
<div role="grid"
     aria-labelledby="calburn"
     aria-readonly="true">
  <div role="row">
    <span role="columnheader">Pace</span>
    <span role="columnheader">59KG</span>
    <span role="columnheader">74KG</span>
    <span role="columnheader">86KG</span>
  </div>
  <div id="scrolling">
⋯
    <div role="row">
      <span role="rowheader">12 min/mile</span>
      <span role="gridcell">472 cal/hour</span>
      <span role="gridcell">582 cal/hour</span>
      <span role="gridcell">691 cal/hour</span>
    </div>
    <div role="row">
      <span role="rowheader">11 min/mile</span>
      <span role="gridcell">532 cal/hour</span>
      <span role="gridcell">655 cal/hour</span>
      <span role="gridcell">734 cal/hour</span>
    </div>
    <div role="row">
      <span role="rowheader">10 min/mile</span>
      <span role="gridcell">591 cal/hour</span>
      <span role="gridcell">727 cal/hour</span>
      <span role="gridcell">864 cal/hour</span>
    </div>
⋯
  </div>
</div>

Accessibility of this solution

This solution works well using JAWS. Unfortunately, it does not work well with VoiceOver on an iPad iOS6 or on a Mac. VoiceOver recognises the table as a single table, but does not map the columnheader or rowheaderSteve Faulkner for testing these roles on a Mac with VoiceOver).

W3C validator currently reports an error for columnheader and rowheader roles contained in a rowa bug has been filed and it is expected that this issue will be resolved shortly.

Conclusion

The best solution would be to use CSS to scroll the main body while leaving the headers static, but there doesn't appear to be an accessible solution that works cross-browser. If anyone knows of a solution, please post in the comments. As the most popular technique to have static headers in a data table is to put the headers and the table content in two different tables, then this repair technique seems reasonable (or defining the structure with WAI-ARIA alone). It's a shame the WAI-ARIA columnheader and rowheader roles are not better supported in VoiceOver, but support is likely to improve.

mobile accessibility survey. The survey will be available until the end of the month. If you have not taken or shared the survey, please do soon, as your input is valuable and we do not want to miss it.

The survey is a simple 15 question survey that takes just a few moments to complete, and we're looking for input from people with disabilities or people using assistive technologies on a mobile device. The more information we can gather on usage patterns, the better accessibility practitioners will be able to help mobile developers deliver accessible experiences.

Tabulated findings will be made public when the survey is complete to help mobile authors and accessibility professionals better serve the mobile accessibility community.

I wrote about the W3CWeb Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA)'s live region properties 6 years ago, but the WAI-ARIA specification has changed significantly in that time, and the details in that article are now outdated. The examples in the original article used XHTML namespaces, which are irrelevant now that WAI-ARIA is supported in HTML5.

The original out-of-date article now redirects to this entry, which provides more information on live regions and how to use them, along with roles that have implied live regions.

Rich Internet Applications

When developers first built rich internet applications using a combination of HTML, CSS, and JavaScript, people with disabilities were left behind because those applications failed to provide the semantics required to be understood by assistive technologies. Sadly, not much has changed over the years, but that doesn't need to be the case. WAI-ARIA is capable of providing sufficient semantics to ensure rich internet applications can be understood, and is now relatively well supported.

A significant issue that the WAI-ARIA specification addresses is where parts of the page are updated without informing assistive technology users, using live regions.

Live Regions

example of an auto-complete widget, along with instructions to use the cursor keys to navigate through the list, as support for autocomplete isn't that good without this context at the moment. The following properties are used to define a live region.

The aria-live property

aria-live property indicates a section within the content that is live and the verbosity in which changes shall be announced. The following values may be used to determine the verbosity.

aria-live="off"

The default value that indicates that a region is not live, and changes will not be announced.

aria-live="polite"

The update should be announced at the next graceful interval, such as when the user stops typing.

aria-live="assertive"

The update is announced to the user immediately. As this is obtrusive, a value of assertive should only be used when the update is important and the user should be informed immediately.

In the following example, text changes or additions to the unordered list, they will be announced to the user.

<ul aria-live="polite">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>item 3</li>
</ul>

The aria-atomic property

aria-atomic property is an optional property that can have the values true or falsearia-relevant property. If the aria-atomic property is set to true, assistive technologies should present the entire region as a whole depending on the aria-relevant property; otherwise, the part of the region that changed might be announced on its own.

Sometimes, updates make sense on their own, such as a new line arriving in a chat application. Other times, changes in the content may not make sense without the context of other parts of the region. In these cases, aria-atomic="true" should be set on the relevant container so the region is presented as a whole. In the following example, if a change is made anywhere in the div element, the whole content is announced to the user.

<div aria-live="polite" 
    aria-atomic="true">
  <h3>Currently playing</h3>
  <p>Jake Bugg - Lightening Bolt</p>
</div>

The aria-relevant property

aria-relevant property is an optional property used to indicate the type of update that should be announced within a region. The aria-relevant property accepts a space separated list of the following property values:

aria-relevant="additions"

Announcements are made when elements are added to the DOM within the region

aria-relevant="removals"

Announcements are made when elements are removed from the DOM within the region

aria-relevant="text"

Announcements are made when text is added or removed from the DOM

aria-relevant="all"

All of the above (additions, removals, text) apply to this region

In the absence of an explicit aria-relevant property, the default is to assume there are text changes and additions (aria-relevant="text additions"). In the following example, only additions to the unordered list will be announced to the user.

<ul aria-live="polite" 
    aria-relevant="additions">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>item 3</li>
</ul>

The aria-busy property

aria-busy property should be used when the region is busily being updated, and stops updates being announced before they are complete. Setting aria-busy="true" on the region suppresses announcements until the attribute is removed, or the value changed to false. Assistive technologies collate the changes, and announce them when the region is no longer busy. In the following example, nothing is announced while the list items for the unordered list are being gathered. When the developer set aria-busy="false" or removes the aria-busy attribute, the unordered list will be announced.

<ol aria-live="polite" 
    aria-busy="true">
⋯
</ol>

Roles with live regions

WAI-ARIA also defines some roles that have live regions.

The alert role

alert role is used to provide important information immediately to the user. A role of alert is an assertive live region, meaning the message will be delivered to the user immediately.

<div role="alert">
  Maximum amount reached.
</div>

The status role

status role is used to provide advisory information to the user that isn't important enough for an alert. A role of status has an implicit aria-live value of polite, but this doesn't necessarily mean it will be announced to the user. Authors can use the aria-live property on the region to override how it's usually handled by assistive technologies.

<div role="status">
  3 new messages in inbox.
</div>

The timer role

timer role marks a region that contains a counter that represents either elapsed or remaining time that are updated as time changes until the timer is paused or completes the time count. A role of timer is a live region with an implied aria-live value of off.

<div role="timer">
  29
</div>

The marquee role

marquee role is used when non-essential information changes regularly. A role of marquee is a live region with an implied aria-live value of off. If you use marquees, ensure you provide a simple provision to stop it scrolling and updating, as they can be distracting and annoying.

<div role="marquee">
  Marquee text.
</div>

The log role

log role is used for regions where new messages are added at the end of the log, and older messages may disappear from the log, such as a chat log or messages in an error console. A role of log has an implicit aria-live value of polite. If a text area is used to send updates to the region with a role of logaria-controls attribute should be used to define the relationship.

<div role="log" id="chatarea">
  <span class="name">Dave: </span> What time will you be finished?
</div>
⋯
<div>
  <label for="chat">Chat: </label>
  <input aria-controls="chatarea"
         type="text" 
         size="40" 
         name="chat" 
         id="chat">
</div>

managing dynamic changes.

Tables shouldn't be used for layout, as they can result in redundant information being announced as the user navigates through the document using a screen reader, such as "table with 3 columns and 4 rows column 1 row 2 ⋯". When nested tables are used, other redundant information is announced, such as "table nesting level 3 column 2 row 1 ⋯".

presentation role can be used to remove the table semantics so the table information is no longer announced when the user navigates the page.

<table role="presentation">
⋯
</table>

When controls are grouped in a fieldset element with a legend, the content of the legend element is announced by screen readers to provide context for the individual controls in the fieldset. This is particularly useful for controls like radio buttons where the group needs a label, as the individual labels for each radio button may not make sense on their own; for example, if the label is just "Yes" or "No". Unfortunately, if the form controls in the fieldset are in a layout table, then the legend is not announced as a label for the group in JAWS, even if the table has role="presentation".

Layout tables

Although using role="presentation" stops redundant table information being announced to screen reader users, form controls within a fieldset are not reliably announced by JAWS with the context of the legend element to provide a label for the group. In the following example, when a JAWS user navigates through the radio buttons, they hear something like, "radio button not checked maybe 1 of 3", "radio button not checked yes 2 of 3", and "radio button not checked no 3 of 3" without the context of "Attending" (Firefox with JAWS provides the context when navigating forwards to a radio button in the group, but not when navigating backwards to a radio button in the group. IE with JAWS completely ignores the context provided by the legend element).

<fieldset>
<legend>Attending?</legend>
<table role="presentation">
<tr>
  <td>
    <input type="radio" 
           id="att1" 
           name="att" 
           value="maybe">
  </td>
  <td><label for="att1">Maybe</label></td>
</tr>
<tr>
  <td>
    <input type="radio" 
           id="att2" 
           name="att" 
           value="yes">
  </td>
  <td><label for="att2">Yes</label></td>
</tr>
<tr>
  <td>
    <input type="radio" 
           id="att3" 
           name="att" 
           value="no">
  </td>
  <td><label for="att3">No</label></td>
</tr>
</table>
</fieldset>

If the layout table isn't included, a JAWS user hears "Attending" as the context for the radio button in the group that receives focus. Continuing to navigate through the radio buttons in the group only announces the radio button information, as the context has already been provided.

Repair techniques

When form controls are in a layout table within fieldset/legend elements, the context information is lost in JAWS, even when the table semantics are removed with role="presentation"aria-describedby attribute. To do this, add an id attribute to the legend element, and use aria-describedby on the radio buttons that references the id attribute set on the legend element.

<fieldset>
<legend id="attleg">Attending?</legend>
<table role="presentation">
<tr>
  <td>
    <input type="radio" 
           id="att1" 
           name="att" 
           value="maybe" 
           aria-describedby="attleg">
  </td>
  <td><label for="att1">Maybe</label></td>
</tr>
<tr>
  <td>
    <input type="radio" 
           id="att2" 
           name="att" value="yes" 
           aria-describedby="attleg">
  </td>
  <td><label for="att2">Yes</label></td>
</tr>
<tr>
  <td>
    <input type="radio"
           id="att3" 
           name="att" 
           value="no" 
           aria-describedby="attleg">
  </td>
  <td><label for="att3">No</label></td>
</tr>
</table>
</fieldset>

This technique works with JAWS, but requires using aria-describedby for each element in the fieldset. This approach also has the undesirable effect of announcing the context after the radio button information, rather than before the radio button, as the user would be used to with regular elements within a fieldset/legend section. It also means that screen readers that do announce the group label provided by the legend element also announce the description afterwards, which is overly verbose.

groupregion if the section is significantly important) on the table element instead of the presentationaria-labelledbySteve Faulkner pointed out that child element roles are unaffected by a parent role of group, so the table semantics are still present and need overriding with role="presentation". This should result in the same relationship as fieldset/legend without the layout table.

<fieldset>
<legend id="attleg">Attending?</legend>
<table role="group" aria-labelledby="attleg">
<tbody role="presentation">
<tr role="presentation">
  <td role="presentation">
    <input type="radio" 
           id="att1"
           name="att"
           value="maybe">
  </td>
  <td role="presentation">
    <label for="att1">Maybe</label>
  </td>
</tr>
<tr role="presentation">
  <td role="presentation">
    <input type="radio" 
           id="att2" 
           name="att" 
           value="yes">
  </td>
  <td role="presentation">
    <label for="att2">Yes</label>
  </td>
</tr>
<tr role="presentation">
  <td role="presentation">
    <input type="radio" 
           id="att3" 
           name="att" 
           value="no">
  </td>
  <td role="presentation">
    <label for="att3">No</label>
  </td>
</tr>
</tbody>
</table>
</fieldset>

This arrangement works in Firefox, and ensures that the context is reliably provided before the radio button information just once when the group is visited forwards or backwards, in the same way as when the layout table isn't present with fieldset/legend. Unfortunately, it is completely ignored in IE with JAWS, and announced twice in browsers that do announce the legend content as a label for the group.

As this attempt used lots of role="presentation" markup, I decided to wrap the table in a div element and moved the role="group" and aria-labelledby markup to the containing div element, and put the table role back to role="presentation". This arrangement didn't work either. After further discussion with Steve Faulkner, he pointed out that IE doesn't suppress the semantics of table cell elements when role="presentation" is used on the table element (it should do). I added role="presentation" to each of the table cells, and it finally worked as expected.

<fieldset>
<legend id="attleg">Attending?</legend>
<div role="group" aria-labelledby="attleg">
  <table role="presentation">
  <tr>
    <td role="presentation">
      <input type="radio" 
             id="att1"
             name="att"
             value="maybe">
    </td>
    <td role="presentation">
      <label for="att1">Maybe</label>
    </td>
  </tr>
  <tr>
    <td role="presentation">
      <input type="radio" 
             id="att2" 
             name="att" 
             value="yes">
    </td>
    <td role="presentation">
      <label for="att2">Yes</label>
    </td>
  </tr>
  <tr>
    <td role="presentation">
      <input type="radio" 
             id="att3" 
             name="att" 
             value="no">
    </td>
    <td role="presentation">
      <label for="att3">No</label>
    </td>
  </tr>
  </table>
</div>
</fieldset>

Conclusion

The table element should only be used for describing data tables, rather than using tables for layout purposes. If layout tables absolutely cannot be avoided, then using role="presentation" is effective at ensuring that redundant table information isn't announced to screen reader users. However, this can't be relied on alone when form controls within fieldset/legend elements are in layout tables for JAWS users.

If it's impossible to avoid layout tables for the whole website, at least avoid using tables for layout within fieldset/legend elements. If this isn't possible, then the repair technique is to wrap the table in an element with role="group" and an aria-labelledby attribute that identifies the group label (the legend), and the table element and each table cell must be overridden with role="presentation".

The repair technique for ensuring that form controls in a layout table within fieldset/legend elements is probably more complicated than not using layout tables in the first place, and duplicates the group label for assistive technologies that correctly ignore layout tables with role="presentation". Sometimes, it's difficult to find a repair technique that works in all situations, but using the most semantically appropriate elements will always result in a more accessible experience.