It was impossible to read a news article with VoiceOver enabled. It worked fine with VoiceOver disabled and I could read the article in Safari. However, the article within MarketDash was a black hole.

The Finance engineers added confusion by responding with "we needed to remove the accessibility setting." In other words, they made it more accessible by removing accessibility. Perhaps you’ve had a similarly confusing experience.

What is isAccessibilityElement?

This article introduces isAccessibilityElement, how it determines what elements are interactive, and how it can easily create accessibility problems. Fortunately, this is an easy concept to understand and fix in your applications.

To understand isAccessibility, imagine playing with some Russian matryoshka dolls. The largest doll contains a set of nested dolls that progressively get smaller. When you close the larger doll, you are not able to play with the smaller dolls. When you open a larger doll, you are able to access and play with a smaller doll. This is true until you get down to the smallest, most granular doll.

isAccessibility determines what element can be focused when VoiceOver is enabled. Placing it too high, i.e. the parent, blocks focus on the child elements. The article page on MarketDash uses a custom view that contains a web view. Originally the custom view had isAccessibiltyElement set to YES, which made it impossible to read the web view. The solution was to set isAccessibilityElement on the custom view to NO and set the web view to YES.

The parent container has isAccessibility in this illustration

This illustration shows the web view and control bar with Accessibility enabled

This problem is also seen frequently on Table Views. The thumbnail view in the Flickr application is a good example. We want the user to access the individual images, which sit inside a UITableViewCell, which sits inside a UITableView. The solution is to set isAccessibilityElement to NO on the table and cell. You’ll also need to set the thumbnails to YES.

Setting Accessibility on parent makes it impossible to select a row or thumbnail

The row has Accessibility, which makes it impossible to select a thumbnail

placing Accessibility on thumbnail makes it interactive

Setting isAccessibilityElement

There is a default setting for isAccessibilityElement and you’ll only need to set this in special circumstances.

The default value for this property is NO unless the receiver is a standard UIKit control, in which case the value is YES.

Assistive applications can get only information about objects that are represented by accessibility elements. Therefore, if you implement a custom control or view that should be accessible to users with disabilities, you should set this property to YES. The only exception to this practice is a view that merely serves as a container for other items that should be accessible. Such a view should implement the UIAccessibilityContainer protocol and set this property to NO.

UIAccessibility Protocol Reference – Apple

Setting isAccessibilityElement via Interface Builder

The thumbnail in this TableViewCell has Accessibility enabled in Interface Builder

Open the Accessibility group in the inspector panel of XCode. Highlight the object that needs to be modified and select the Accessibility Enabled option.

Setting isAccessibilityElement in Objective C

You will often need to set the accessibility dynamically. Apple’s sample application Formulaic includes various accessibility settings. In this example, the code turns off isAccessibilityElement within the implementation specifications. There are only two options for this setting “YES” or “NO”.

You can also set this during instantiation. This example comes from a lecture given by Chris Fleizach, available on Stanford University’s iTunesU – Developing Apps for iOS 2010 (look for lecture #18).

Resources

• Improving Accessibility Support In HotelTonight For iOS
• Increase iOS Accessibility with Accessibility Hints
• Accessibility for iPhone and iPad apps by Matt Gemmell
• Apple’s Accessibility Programming Guide for iOS
• UIAccessibility Protocol Reference
• UIAccessibilityContainer Protocol Reference
• UIAccessibilityElement Protocol Reference

Feature image: Matryoshka: Some rights reserved by dreamwhile

The Problem

Many apps will use graphic icons to suggest available functionality. Unfortunately, these icons are not always made accessible to VoiceOver users. Other interactions take advantage of the natural reactions to swipe and pull on items. As VoiceOver users tend to explore by dragging their finger over the screen or using a single finger swipe to “tab” through the page, these interactions may not be discovered.

For instance, a list of items may be refreshed by pulling down, a button may list a selection title and provide a drop down to select an alternate, images can be scrolled, and text can be tapped to trigger playing music.

The Solution

Fortunately iOS provides a convenient solution: accessibilityHint. Ron Nicholson described UIAccessibiltyHint usage in his company’s iPhone apps:

If you had a short help document for your app, it might show a picture of your app, with arrows pointing at the elements, and a small bubble caption on each of those arrows saying stuff like "Stops playing annoying fart sounds" and "Changes fart loudness from silent to ear shatteringly gross". These would be your helpful "hints".

iOS accessibility: label vs hint – Stack Overflow

Developers need to carefully consider when an accessibilityHint is needed. Further, the hint should be short, declare the purpose, and not mention the gesture or type of object the user is interacting with. Apple’s Accessibility Programming Guide suggests using a hint “only when the results of an action are not obvious from the element’s label”. Matt Gemmell summarizes the art of creating good hints:

A good accessibility hint should describe the outcome of interacting with the control. It should not describe the actual means of interaction (like tapping or swiping), because there are multiple ways for a VoiceOver user to interact with your control, and you can’t predict which they’ll use. Hints should begin with a plural verb, if at all possible; for example, “Deletes the event”. Do not use a singular verb (such as “Delete the event”), because this will sound like an imperative (a command or instruction to the user).
Accessibility for iPhone and iPad apps – Matt Gemmell

accessibilityHint Examples

The following iPhone applications use accessibilityHint effectively.

Hanging with Friends – Zynga

Hanging with Friends provides updates on other games you are playing. The button’s label includes the game’s name: “Play Words”. The button’s accessibilityHint lets you know it will either switch applications or install the game: “Switches to or intalls the game Words.”.

Yahoo! Search for iPhone

The Yahoo! Search app has a scrolling view to choose various categories. While there are arrow icons that prompt the user to swipe for more options, they’ve also added accessibilityHint. In this case, the developers included the swipe action to make sure users know how to navigate. The accessibilityHint is “Swipe to get more categories.”.

Yahoo! Finance for iPhone

The Major Indices table on the Yahoo! Finance app lists the vaue and price on markets and stocks. The individual cells have an accessibilityLabel that compiles the displayed information into a useful string of text: “Nasdaq 3,065.27 down 13.05 or 0.42%”. The accessibilityHint lets the user know they will find more information about this market: “Displays more details.”.

Implementing the accessibilityHint

There are several options for adding an accessibilityHint via Interface Builder or in the .m file.

Using Interface Builder

The accessibility panel is located within the Identity Inspector column of XCode. This panel lets you set the various accessibility traits of objects inserted within the .xib or .storyboard files. This works best for static hints.

Apple’s sample app Formulaic has a button with Label="Show table". We can add an accessibilityHint to let the user know the table will display the results of the equation: Hint="View equation results in tabular format.".

Inserting at viewDidLoad

Many developers will add accessibility attributes at the viewDidLoad stage. viewDidLoad is called after instantiation and outlet-setting, . Paul Hegarty explains this is "an exceptionally good place to put a lot of setup code" in his discussion of view life cycles (Stanford iTunesU: iPad and iPhone Application Development – Lecture 8). The previously mentioned Formulaic app sets an accessibilityHint on the stopwatch button at this stage.

Set accessibilityHint at Initialization

Another option for adding an accessibilityHint is during initialization of an object. This example comes from a lecture given by Chris Fleizach, also available on Stanford University’s iTunesU – Developing Apps for iOS 2010 (look for lecture #18).

This code also shows how you can localize your labels and hints using NSLocalizedString.

Action Items

The majority of iOS apps can easily be made accessible by using a combination of accessibility attributes. Accessibility hints avoid vague interactions and make the application easier to understand and navigate. For more information, visit the following resources:

• Accessibility Programming Guide for iOS
• Formulaic – accessible app tutorial from Apple
• UIAccessibility Protocol Reference
• UIAccessibilityElement Class reference
• How TipToe was fixed

Please note: Some of the links in this article require an Apple ID or lead to pages that will trigger iTunes.

Windows: Mac:

The focus outline is important in that it both directs the users attention, and serves as a cursor for users who navigate using the keyboard (most commonly by pressing Tab or Shift + Tab). Often the focus outline is removed using CSS, making navigation impossible for keyboard users.

The Problem

The focus outline is removed when either the outline-style and/or the outline-width properties are set to "0" or "none", or the outline-color is set to "none" or "transparent." Here's some examples of common uses of the outline found while grepping Yahoo! CSS files.

The Cause

That's how outline is being removed, but why? Some common reasons:

1. Reset stylesheets

Often outline is set to "none" or "0" by reset stylesheets.

2. To fix broken or awkward focus outlines

Sometimes the focus outline is hidden to prevent the user from seeing it rendered broken, often the result of overflow:hidden on one of the container elements. In the following example from Yahoo! News, the clipped focus outline on the Mac makes it difficult to determine which menu item in the drop down actually has focus.

The focus outline is also often hidden to prevent the user from seeing an oddly shaped outline resulting from CSS image replacement techniques. For more, see Patrick H. Lauke's article Don't Lose Your :focus.

Solutions

1. Don't Remove It

The easiest way to avoid the problem is to not remove the focus outline.

2. Replace It

When replacing the outline for a given module or widget, don't use a global selector as this will remove focus for the entire page or application. The more mindful you are of the specificity of the selector(s) used to remove the browser's default focus style, the less likely you are to unintentionally remove the browser's default focus outline from other elements. Here's some examples of common, problematic selectors:

When replacing the browser's default focus styles, the goal should be to create rules specific enough to target just the control/element AND state you are looking to address. This will result in code that is less error prone, and more self-documenting.

When replacing the focus outline, consider using one (or more) of the following properties. These work well as they don't affect the box model and cause the surrounding content to reflow when the element receives focus:

• text-decoration
• color
• background-color
• box-shadow

Limitations in IE

Custom focus styling is limited in IE depending on the browser version. Prior to 8, IE did provide custom focus styling, but only for links via the :active pseudo class. Further, removing the focus outlined required use of the hidefocus attribute or setting the element's tabIndex to -1. For all these reasons, consider custom focus styles a Progressive Enhancement.

Should you need custom focus styling on controls other than links for older versions of IE, you could leverage JavaScript to create a delegated focus and blur event listener that add/removes a class in response to focus and blur. Here's two examples using YUI and jQuery.

Using YUI

Using jQuery

Related Reading and Resources

• Removing The Dotted Outline by Chris Coyier
• Don't Lose Your :focus by Patrick H. Lauke
• CSS Lint—Use to guard against use of outline:none
• Disallow outline:none
• outlinenone.com (That's right, someone registered that domain!)

The goal is to train developers how to think about ARIA widgets such that using ARIA feels familiar and natural—something all developers can feel confident using and making part of their everyday toolkit.

In the interest of being as concise and straightforward as possible, without being overly pedantic this article will be limited in scope to the markup and styling for ARIA widgets. Keyboard access for ARIA widgets, while an important topic, has been intentionally left out since it is a broader topic deserving an article of its own, and the implementation guidance varies between devices (mobile and desktop) and platforms (Mac and Windows).

Widget Roles

ARIA provides additional semantics beyond what is available in current implementations of HTML. As the spec indicates, it’s a bridging technology—filling gaps between versions of the HTML specs. For example, neither HTML 4 or 5 provide a toolbar or dialog widget, but both can be declared using ARIA. Consider the following two examples:

Toolbar Example

Dialog Example

As illustrated in the examples, ARIA widgets are declared by applying the role attribute (part of HTML5) to existing elements. ARIA roles can be declared in the markup, or applied via JavaScript:

Like the <input> element’s type attribute, the ARIA role attribute can only be set to one of several predefined values. In the interest of Progressive Enhancement, when building custom widgets always start with the closest native semantics and supplement with ARIA. Consider this tree widget that uses a <ul> as its foundation:

Widget Properties

Like existing HTML widgets, ARIA widgets have properties used to configure their behavior. For example, a <textarea> can be declared read only by adding the readonly attribute. ARIA properties work exactly the same way, but they require an “aria-” prefix.
For example, the previous tree widget can be configured to support multiple selection using the aria-multiselectable attribute.

ARIA properties can also be used with existing HTML widgets. For example, to declare a button with a popup menu add the aria-haspopup attribute.

Properties can also be set using JavaScript:

The complete set of properties for each ARIA widget are listed alongside each widget role in the ARIA Specification. Click any of the widget roles in the Widget Role Reference section to reveal the widget’s corresponding properties in the ARIA Spec.

Widget States

In addition to properties, ARIA widgets have attributes used to represent states—and they work just like state attributes found in existing HTML widgets. For example, the checked state of an HTML checkbox is represented via the checked attribute:

ARIA states work exactly the same way, and like the ARIA properties, they require an “aria-” prefix. Returning to the tree widget example, tree items can be expanded and collapsed, and that state is represented using the aria-expanded attribute.

And like ARIA properties, ARIA states can also be used with existing HTML widgets. For example, add the aria-invalid attribute to indicate the user has entered an invalid value into a text field.

All of the states for each ARIA widget are listed alongside each widget role in the ARIA Specification. Click any of the widget roles in the Widget Role Reference section to reveal its corresponding states in the ARIA Spec.

Managing States and Properites

The behavior associated with the states and properties of existing HTML widgets are implemented by the browser. For example, the value of the checked attribute is changed automatically when the user checks or unchecks a checkbox.

Unlike existing HTML widgets, the behaviors associated with ARIA widget states and properties are not managed by the browser. As such, it’s necessary to implement the expected behaviors using JavaScript. To revisit the tree widget example, the initial aria-expanded state of a leaf node might be declared in the markup, but will be toggled in response to click events.

Initial State Declared in Markup

State Changes Managed Using JavaScript:

Widget Labels

The <label> element has been the tried and true method for labeling existing HTML widgets. ARIA provides several new methods of labeling widgets.

aria-label attribute

Specifies the text label inline, but isn’t visually rendered. Handy when there’s no space for a label on screen and the title attribute is already used to supply an instructional tooltip for sighted users. For example a checkbox in a table cell:

aria-labelledby attribute

Specifies the id(s) of the element(s) whose text content labels the control. Useful when the desired label text is already present in another element in the DOM. Remember, if the design doesn’t require the text label be visible, hide it in an accessible way using CSS.

Some example uses of aria-labelledby:

Labeling an alert dialog widget:

Labeling a listbox widget:

aria-describedby attribute

Specifies the id(s) of the element(s) whose text provides a description supplemental to the label. For example: an error message associated with a form field that has invalid user input.

Widget Styling

Unlike existing HTML widgets, ARIA widgets don’t provide any default presentation. However, most modern browsers support CSS Attribute Selectors, making it easy to style the various ARIA widget types by targeting the role attribute.

Styling States and Properties

Like behaviors, the style for states and properties of existing HTML widgets is automatically managed by the browser. For example, when the user checks a checkbox, a checkmark is added or removed. Disabled controls are automatically rendered grayed out when the disabled attribute is removed.

As mentioned earlier, ARIA widgets states and properties are unmanaged; developers are responsible for defining the visual style associated with widget states and properties. In most modern browsers this can be accomplished using CSS Attribute Selectors. For example, to style a button that has a popup menu:

Returning to the tree view widget, style the expanded or collapsed states:

Widget Role Reference

The ARIA role attribute can only be set to one of the following predefined values. In the interest of helping developers find the right widget role for the job, the roles have been organized into three categories. Each of the following widget roles is linked to the ARIA Spec, which details the properties and states associated with each role.

Individual Atomic Widgets

• spinbutton
• slider
• progressbar
• button
• radio
• textbox
• checkbox

Overlay Widgets

• dialog
• alertdialog
• tooltip
• menu
  • menuitem
  • menuitemcheckbox
  • menuitemradio

Composite Widgets / Managed Containers

• combobox
• grid
  • row
  • rowgroup
  • columnheader
  • gridcell
  • rowheader
• listbox
  • option
• menubar
• radiogroup
  • radio
• tablist
  • tab
  • tabpanel
• tree & treegrid
  • treeitem
  • group
• toolbar

Narayanan Ramakrishnan

Narayanan is a GeorgiaTech graduate and has a passion for creating accessible tech projects. Previous projects include an accessible map of New York City, transliteration of Facebook posts, and visual guide to Indian politics.

What is Open-Captions?

According to research, over 90% of deaf children have hearing parents who “frequently do not have fully effective means of communicating with them”. The American Sign Language (ASL) is a difficult language to learn, especially as a second language.

Open-Captions makes it easy for parents and children to learn and practice American Sign Language together while watching their favorite videos on YouTube. People can find closed captioned videos on any topic with the Open-Captions search engine. The viewer is able to select individual words in the video’s caption stream and see the American Sign Language representation of the word.

Closed captions on various television shows have been around for quite some time. They are useful for hearing impaired people and also to people whose first language is not English.
Captions have always been a steady stream of white text on black background, located either at the top or bottom of the screen. Video sites like YouTube and Hulu , have adopted the same style from television.
Open-Captions, changes the way users watch videos by making the captions more interactive.

• The viewer can pause the video, select a word and watch an ASL representation.
• The viewer can review earlier captions with the “Previous Caption” button.

The American Sign Language representations are shown from the SmartSign dictionary maintained by Georgia Institute of Technology’s Center for Accessible Technology in Sign (CATS).

How did Open-Captions come about?

My interest in building Assistive Technologies has been one of the main motivating forces behind getting a graduate degree in Computer Science.

I built a web based widget platform for Interactive TV as a graduate student researcher at GeorgiaTech. In the process I worked on developing functionality that would allow widget developers to access the closed captions associated with the currently playing content.
Harley Hamilton, a researcher at CATS, was interested in leveraging this ability of accessing closed captions and we ended up building a rough prototype. Subsequently, I learnt more about hearing impaired children from Harley and wrote a small tool using which one can select any word on a webpage and see the American Sign Language representation of the word. This would be very useful for parents who want to learn ASL.

In September this year, I signed up for the HackdayTV weekend hackathon and ended up building the first version of Open-Captions, which is the mashup of the earlier ideas I had worked on related to ASL.

What happens behind the scenes in Open-Captions?

Disclaimer: Technical content ahead
The entire source code for the project can be found on GitHub

YouTube has extensive documentation on how to use their APIs for search, embedding and controlling videos on your site. The search and results page are based on the PHP library of the YouTube search API. The page on which the video plays is the one that gets interesting. There are 2 parts to it -

• Getting the closed captions of the video and synchronizing it to show correctly
• Handling the mouse clicks on the individual words to show the ASL representation

I used Firebug to see what requests YouTube sends whenever you click on the “Interactive Transcript” icon under the video. I removed parameters that were not mandatory (i.e. I would still get the same result if I removed them) and made a PHP curl request for the trimmed URL to get the captions formatted as XML. For this YouTube video the URL for the captions would be

and the result will be of the form

As far as I understood, not all YouTube videos with captions could be accessed with the above API call because their caption files had names. Then, I came across this user script which is useful if you want to download the captions file. The author had a snippet of code for retrieving the name of the captions file –

this returned an XML with the name of the captions file. I used that to extend my API call to

Then using JavaScript setTimeout function and the values of the start and duration of the captions, I do the synchronization of the captions and the video.

Now, for every word in that particular line of the caption, I broke it up into span elements and attached click handlers to each. The span elements look like this

When a word is clicked on the captions, the showASL method gets called and the word string is passed as a parameter. After stripping the words of extraneous characters like !, &, ], [, ; etc and converting the word to lowercase, the method inserts an iframe on the right hand top corner whose URL points to

The pages showing the ASL have flash videos embedded, so I have styled the iframe so that the flash video is at the center of the box. Some of the pages have just images and some may have both. Hence, I added the “Full Page View” button under the ASL box, so that viewers could see the entire page if they wanted to.

The SmartSign website covers around 25000 words and hence there will be words in the captions for which the ASL representation do not exist. For such cases, I get an image from Bing to substitute for the ASL.
The source code is undergoing constant refactoring, and would love to get more ideas on how to design a better solution.

What lies ahead for Open-Captions?

Currently, I am gathering feedback from hearing impaired users about Open-Captions and also getting thoughts on what additional features they would like. Harley, the researcher at CATS, is excited about this project too and reaching out to more people for feedback.
Another idea is to build Open-Captions as the “Khan Academy” of ASL, by having videos that enable different levels of learning of ASL.

Full Keyboard Access Explained

In the context of browsers on the Mac, the various “full keyboard access” preferences affect the behavior of the Tab key. With the default settings applied (full keyboard access disabled), the Tab key moves focus between a subset of controls. This subset varies between browsers on the Mac:

Enabling On the Fly

Given the default settings on the Mac, how do keyboard users navigate and interact with controls that aren’t in the default Tab flow?

Safari provides the Option key as a modifier for Tab. Pressing Option + Tab will extend access to include links. Additionally, Mac OS provides the global Ctrl + F7 keyboard shortcut which toggles the ability to access to all controls via the Tab key. Together these shortcuts can provide a nice usability affordance; they give keyboard users more options with respect to how to navigate a page or application.

For users of Firefox, switching the behavior of the Tab key is as easy as it is for Safari. Unlike Safari, Firefox provides access to all controls but links by default. The Ctrl + F7 shortcut can be used to extend access to include links.

Chrome follows Firefox providing access to all controls but links by default, but doesn’t honor Ctrl + F7. To modify the behavior of the Tab key, the user has to navigate into preferences.

Enabling via Preferences

Rather than change full keyboard access on the fly, it is possible to make full keyboard access the default.

Firefox

Firefox relies on the Keyboard settings in System Preferences. Changing these preferences enables full keyboard access to not just Firefox, but all applications.

1. Go to Keyboard in System Preferences in OS X
2. Find the “Full Keyboard Access” section at the bottom of the dialog
3. Check the “All Controls” radio button

You can also press Ctrl + F7 to change this preference.

Safari

1. Go to Safari > Preferences > Advanced
2. Check the “Press Tab to highlight each item on a webpage” checkbox

Google Chrome

1. Go to Chrome > Preferences > Under the Hood
2. Check the “Pressing Tab on a webpage highlights links, as well as form fields” checkbox

Here is how the toolbar renders when High Contrast mode is enabled.

As illustrated, use of CSS background images can result in information loss for users when High Contrast mode is enabled, especially in the following use cases:

• An image is the only visual label for a UI control (e.g. a button, menuitem, etc.)
• An image conveys state (e.g. selected, checked, etc.) or other supplemental information (e.g. a message has an attachment)

This is especially problematic considering High Contrast mode is designed to make the UI easier to see. Fortunately there are several alternatives to background images that work in High Contrast mode.

Understanding High Contrast Mode

First, what is High Contrast mode, and more importantly, who benefits?

In High Contrast mode Windows will change the foreground colors (used for text, borders, etc.) and background colors to create a greater contrast. The font size is often increased as well. These adjustments make it easier for users with visual impairments to see the screen.

Some examples of the types of users who benefit from High Contrast mode are:

• Users who have low vision; anyone with a visual impairment that can’t be corrected with glasses, but is not in the range of legal blindness. Users with low vision may use screen magnification, bigger screens, larger fonts, high contrast, screen reading, or other assistive technology. Users with low vision can perceive light, so more contrast can make it easier to see the screen.
• Users with color vision deficiencies (also known as color blindness)
• Users who’s eyes are sensitive to light. Users can turn on low contrast theme or darker themes as their eyes are very sensitive to light.

Solutions

There are several alternatives to using background images, each with benefits and drawbacks. As with all accessibility solutions, there’s no silver bullet. Consider each solution relative to the constraints or demands of the web site or application and choose the solution that works best.

Use the content property

Steve Faulkner, Nicolas Gallagher, Thierry Koblentz, have all authored articles on using the content property to create icons that work in High Contrast mode.

Here’s how it works. Consider the following HTML for a toolbar:

To add an icon to each button:

1. Give the button a fixed height and width, and set the overflow property to “hidden”.
   .toolbar button {
     border: 1px solid #333;
     background: #bbb;
     padding: 0;
     margin: 0 3px 0 0;
     width: 36px;
     height: 36px;
     overflow: hidden;
   }
2. Use the :before pseudo element and the content property to add the image to the button.
   .toolbar button:before {
     display: inline-block;
     content: url(‘http://findicons.com/files/icons/2340/preview/toolbar_icon_set_full.png’);
   }
3. Use negative margins to move the image into position.
   .toolbar .prnt:before {
     margin: -73px 0 0 -37px;
   }

   .toolbar .find:before {
     margin: -145px 0 0 -181px;
   }

   .toolbar .save:before {
     margin: -73px 0 0 -145px;
   }

   .toolbar .sets:before {
     margin: -109px 0 0 -73px;
   }

   .toolbar .info:before {
     margin: -145px 0 0 -145px;
   }

This CSS will inject an image before the button’s text node. With the overflow property set to “hidden,” the text will be hidden from view while still being accessible to users of screen readers.

The technique has a number of advantages, the foremost being the changes are isolated to CSS. So switching to this technique from background images doesn’t require a change to markup. Other advantages include:

• All the performance benefits of background images.
• Easy development of high contrast themes since icons are delivered via the CSS.
• The images will print.

The major disadvantage to this technique is the content property isn’t supported in IE < 8. But there are several solutions for supporting older versions of IE, the first being to consider support for High Contrast mode a Progressive Enhancement: Use content for modern browsers, fall back to background images for older versions of IE.

Here’s the CSS updated with support for IE 6 and 7.

Use LESS or Sass to make the fork for IE more manageable. Here’s an example of the previous CSS consolidated using LESS:

Here’s an example of how it all comes together: high-contrast-friendly icons using the content property and background images for IE 6 & 7.

Use <img> sprites

Rather than use the CSS content property to add an image, insert the <img> directly into the markup.

The CSS for positioning the image is virtually identical to the content property technique, the difference being the style rules address the <img> rather than the :before pseudo element.

Here’s an example: high-contrast-friendly icons using the <img> element

Credit for this technique goes to Thierry Koblenz, and Artz Studio published a good article on the subject.

This technique works in all browsers, making it a good choice when support for High Contrast mode in older versions of IE is required. There are some disadvantages to this technique, mainly:

• Harder to theme with the path to the image in the markup.
• Because negative margins are used to position the image, the alternative text won’t be displayed when images are disabled or fail to load but CSS is enabled.

Use content for modern browsers and CSS expressions for IE 6 & 7

The final solution would be to use a CSS expression to supplement the lack of support for the content property in IE 6 and 7.

The major advantage to this technique is the CSS expression provides the flexibility of the content property; the path to the image is centralized in the CSS, enabling the creation of themes. The disadvantage to this technique is CSS expressions have the potential to cause performance problems. To help mitigate slowness, this technique uses Steve Souder’s recommended one-time expressions solution.

Here’s an example of this technique: high-contrast-friendly icons using the content property and CSS expressions for IE 6 & 7.

This technique might be a good choice when support for High Contrast mode in older versions of IE is required and the given site or application doesn’t have many instances of icons. But as with all things performance, measure the performance impact of the CSS expressions before putting them into production.

Testing High Contrast Mode

Regardless of the technique, it is important to test in High Contrast mode. For more on enabling High Contrast mode, see Microsoft’s documentation:

• Enabling High Contrast mode in Windows XP
• Enabling High Contrast mode in Windows 7

Recommendation

Of the three, using the content property with background images for IE 6 and 7 seems like the preferred solution. It strikes the right balance between what is desirable for both the developer and the user. For developers it provides both an easy means of fixing icons for existing sites, while being a future-proof accessibility design pattern for the development of new sites. Although IE 6 + 7 users will be required to upgrade their browser for High Contrast mode support, it’s a solution geared toward the future, rather than browsers with declining marketshare. So, while it might not be a silver bullet today, it’s close. And it certainly will be once IE 6 and 7 are gone.

Ultimately, the choice is yours. Use the comparison table to help guide your decision, as it’s designed to clearly call out the pros and cons of each technique.

RTL Support

Vertically arrange icons in the sprite for right-to-left (RTL) language support. This will ensure the icons are positioned correctly regardless of the orientation of the screen.

Muscle Memory

Often the biggest hurdle for implementing new techniques is changing habits. While CSS background images continue to be useful for images used for decoration (e.g. gradients), consider this new technique whenever CSS is used to replace text on screen with an image. That should help put it in muscle memory.

So, in the spirit of small things that make a big difference, here's a list of fixes for common accessibility problems.

Show focus

CSS reset files often suppress default browser focus styles. As a result, developers and designers can forget to style the focused state for UI controls. Without focus styles the user is unable to navigate via keyboard.

Styling focus

Unplug the mouse and use the Tab key to move focus through the interactive controls (e.g. links, buttons, form controls, etc.) on the page. Identify the controls that lack a focus style and then update the CSS. Commonly used properties for styling focus are outline, box-shadow and background-color as they don't impact layout. For example:

button:focus {
    outline: dotted 1px #000;
}

Note: IE6 doesn't support the :focus pseudo class. It does support :active, but only on anchor elements. IE 6 will render a default focus outline around all focusable elements as long as it hasn't been disabled via the hidefocus attribute. For IE 6 best to just confirm the default browser focus is visible and consider custom focus styles a form of Progressive Enhancement.

Use the button role to make link buttons into, er… buttons

Links are often used to create buttons. When an element is focused, screen readers announce its tag name. That means users of screen readers will perceive link buttons as links. Worse, the value of the link's href may be announced. This can be especially confusing to the user if the href is set to "#" or "javascript:…".

Using the button role

For link buttons, simply add the ARIA button role.

<a role="button" href="#">Click Me</a>
<a role="button" href="javascript:callback();">Click Me</a>
<a role="button" tabindex="0">Click Me</a>

For buttons created using another element (like a <span>), add the button role. Set the tabindex to 0 to place the button into the default tab flow.

<span role="button" tabindex="0">Click Me</span>

Another solution is to simply just use a <button> for buttons.

<button type="button">Click Me</button>

This bookmarklet can help identify link buttons that could benefit from an ARIA role of button:
Show Link Buttons

Label UI Controls

UI controls sometimes go unlabeled. Screen readers announce a control's label when it receives focus, so without text labels users of screen readers are unaware of a control's purpose or function. Text labels also focus their associated form control when clicked, a nice usability affordance for smaller controls like checkboxes and radio buttons.

Labeling techniques

The following is a comprehensive list of labeling techniques for UI controls.

Inner text

Text placed between the opening and closing tags. If the design doesn't require the text label be visible, hide it in an accessible way using CSS.

<label> element

Tried and true method of labeling form controls. If the design doesn't require the text label be visible, hide it in an accessible way using CSS.

Note:Implicit labeling is broken in IE 6. In the following example clicking the label text won't focus the associated form control.

<label>First Name <input type="text" name="first-name"></label>

title attribute

Use title to label frames. Might also be a good last resort if you are constrained for space (like a form element in a table cell). Otherwise, title isn't a good choice as a labeling technique.

alt attribute

Used to label an image. There's no shortage of guidelines for writing good alt text, but here's some things to keep in mind:

• Use an empty string for decorative images, or if there's no text available.
• If the image contains text, replicate it in the alt attribute.
• Otherwise, try to be succinct.
• Under no circumstances omit the alt attribute. An empty string is better than nothing.

aria-label attribute

Specifies the text label inline, but isn't visually rendered. Handy when there's no space for label on screen and title is already used to supply an instructional tooltip for sighted users. For example a checkbox in a table cell:

<input type="checkbox" aria-label="Message 1" title="Click to select this message">

Note:aria-label is not currently supported in Internet Explorer (9).

aria-labelledby attribute

Specifies the id(s) of the element(s) whose text content labels the control. Useful when the desired label text is already present in another element in the DOM. Saves the creation of another <label> element.

aria-describedby attribute

Specifies the id(s) of the element(s) whose text provides a description supplemental to the label. For example: an error message associated with a form field that has invalid user input.

This bookmarklet can help identify UI controls without labels:
Check Labels

Add the required attribute to required fields

Required fields are often indicated using visual style, or an asterisk adjacent to the field's label. As these solutions rely either entirely, or mostly on visual style they are completely inaccessible to users who can't see the screen.

Using required

HTML5 adds a required attribute to form controls. To supplement lack of browser support for required, use it together with aria-required. When a required field is focused, the screen reader will announce that it is required. Even better, it doesn't require localization because the required message is localized by the screen reader.

<label for="first-name">First</label>
<input type="text" name="first-name" id="first-name" required aria-required="true">

Indicate invalid input using aria-invalid

Invalid user input leaves users seeing red. Unable to see the screen, users of screen readers can struggle to find the fields with errors.

Using aria-invalid

Indicate invalid user input using aria-invalid. Use aria-describedby to associate an error message with a form field.

<label for="first-name">First</label>
<input type="text" name="first-name" id="first-name" required aria-required="true" aria-invalid="true" aria-describedby="err-msg">
<p id="err-msg">Cannot be blank.</p>

Remove duplicate links, improve tab flow

Keyboard users navigate between interactive elements via the Tab key. Every anchor element creates a tab stop, so redundant links within a module can create an inefficient overall tab flow, making navigating with the Tab key a real drag for keyboard users.

Improving tab flow

Use tabindex=-1 to improve tab flow

Setting tabindex to -1 removes an element from the tab flow, while keeping it clickable for users of the mouse. This can be used to significantly improve the tab flow of a page.

Consider the following content module: The headline, image, and "More" text are all wrapped in individual links, all of which share the same URL.

This content module has three tab stops. Reduce it to one by setting the tabindex to -1 for the links wrapping the image and "more" text. This change makes a significant improvement to the tab flow when there are multiple instances of this module on a page. In this example, each section has just one tab stop (the heading) instead of three.

Use a single link

If a module contains two adjacent pieces of content and both should be linked to the same URL, wrap both inside a single link.

Consider the following example, where headlines and videos are paired together but the video and text labels are wrapped in separate links. Duplicate links are outlined in red.

Placing the video and text inside one anchor would improve the tab flow of this section. And don't forget, HTML5 enables anchor elements to contain block-level elements, making this approach valid code.

Add a description to make dupe link labels more accessible

Pages often contain many instances of links with the same label. Consider, "read more" links that follow truncated content or excerpts. Without unique labels, users of screen readers can have trouble distinguishing one link from another.

Adding a description to a link

This content module has six links with the label "More".

This screencast illustrates the user experience for browsing the links in this module using a screen reader

Use aria-describedby to give each "More" link a unique description. In this example, aria-describedby is set to the id of the other link in the module that contains a meaningful description for the "More" link.

<div class="article">
    <a id="link-1" href="http://www.viator.com/Orlando/d663-ttd">Orlando tours &amp; things to do</a>
    <div>provided by Viator guides</div>
    <div>Book Orlando tours, things to do, and day trips from Viator.com, including&nbsp;...&nbsp;
    <a aria-describedby="link-1" href="http://www.viator.com/Orlando/d663-ttd">More</a>
    </div>
</div>

This screencast illustrates how the description for each "More" link is announce to the user by the screen reader.

This bookmarklet can help identify links with duplicate labels:
Show Duplicate Link Labels

Use the presentation role to hide iframes in plain sight

Iframes are sometimes used for purposes other than serving content (e.g. shims, async requests, etc.). These iframes can be problematic for users of screen readers in that they both add an extra tab stop into the page, and can mislead users into thinking they contain content.

Using the presentation role

Apply the ARIA presentation role to hide the iframe from screen readers. Set tabindex to -1 to remove the iframe from the tab flow.

<iframe role="presentation" tabindex="-1"></iframe>

Label iframes with a title

Iframes are used to sandbox content or functionality (e.g. Like Button, Tweet Button, etc.), but frequently lack a title. This leaves users of screen readers unaware of the iframe's purpose. Worse, the user may have to listen as the screen reader announces a long URL specified by the iframe's src.

Using title

Here's a simple example illustrating how to use title to make the Facebook Like button more accessible.

<iframe title="Like this page on Facebook" src="http://www.facebook.com/plugins/activity.php?site=news.yahoo.com&width=290&height=300&header=false&colorscheme=light&font&border_color=white&recommendations=true" frameborder="0" scrolling="no" style="width:290px;height:300px;"></iframe>

Bookmarklets from this article

• Show Focus
• Show Link Buttons
• Check Labels
• Show Duplicate Link Labels

This post, however, will show how ARIA can make a dynamic form more responsive to a user. We have a contact input form for the user to add an email address type and value. We're going to use ARIA and JavaScript to give that text input a type-specific label by grabbing the information from the option previously selected. It's actually quite simple and ingenious.

Use aria-labelledby to reference the input's label

Normally a form input is referenced by a label.

The aria-labelledby attribute lets the input reference another element on the page as its label. This allows everything from headers, paragraphs, and other form elements to act as a label for the input. The following example uses a module's h3 header as the label for a search input.

Creating the dynamic labels

The JavaScript solution

JQuery variation

1. Add an id to each of the options in the select (as jQuery doesn't have the cool generateID method)
2. Add a class "labelledbyselect" to the element that should be labelled to add flexibility (it can now also be any form input type i.e. a textarea)

What you can do

• ARIA supported states and properties
• More about ARIA in the Yahoo! Accessibility Library
• YUI Library
• jQuery

Accessibility features

In the quest for making Search Direct accessible, we looked at the implementation of Search Assistant, a technology that Yahoo! pioneered a few years back, as well as the native accessibility features of YUI.

After this investigation, three primary accessibility features were proposed for Search Direct:

• Using the YUI Internationalization utility to serve localized content.
• Setting role and aria-* attributes on elements within the autocomplete widget, that need to be identified and processed by screen readers.
• Using a hidden div that represents a live region (aria-live) to notify the user when something happens. E.g., the number of available suggestions, the selected suggestion, etc.

The plan was to notify the user of any changes in the Search Direct interface, and provide a set of keyboard shortcuts to navigate the following visual components:

• Searchbox
• Submit button
• Suggestion list
• Rich panel
Making Search Direct Accessible