The Benefit of Landmark Roles

ARIA Landmark Roles improve the content parsability of Grids for users of screen readers. By allowing developers to declare the intended purpose of each section of a layout, Landmark Roles provide semantic meaning to each section of a Grid, giving users of screen readers a high-level summary of how a page is organized. In addition, Landmark Roles significantly improves a Grid’s navigability. For example, the JAWS screen reader will announce all of the Landmarks when a page is loaded and allows users to quickly jump between them by pressing the semicolon key:

Using Landmark Roles

Of all the roles defined in the ARIA Specification, the Landmark Roles are among the easiest to implement since they don’t require JavaScript for keyboard support or state management. Landmark Roles are applied to an element using the role attribute and can be used to improve the semantics of any section of a Grid. For example, to declare a section of a Grid as navigation, simply set the role attribute to a value of “navigation”:

<div class="yui-b" role="navigation">

Presently the ARIA Specification defines seven different Landmark Roles:

• application
• banner
• complementary
• contentinfo
• main
• navigation
• search

Getting Started Is Easy

Since ARIA Landmark Roles are such a perfect complement to Grids, we’ve added built-in support to YUI Grids Builder, added a new section on using Landmarks to the Grids user guide, and created a new example to highlight usage of Landmarks Roles within YUI Grids CSS. Developers who are currently using Grids should definitely consider adding ARIA Landmark Roles to their markup to easily improve the accessibility of existing layouts.

The Benefit of Focus Management

As outlined in the ARIA specification and corresponding Best Practices document, providing keyboard access requires, in part, that each widget has one tab stop by default and is responsible for discreetly managing focus for its descendants. Following these guidelines enables users to quickly navigate a page or application by using the tab key to move between widgets. Once a user has tabbed into a widget, they can then use other keys (the arrow keys for example) to move focus amongst the widget’s descendants.

Two Approaches

When it comes to managing focus, the WAI-ARIA Best Practices document provides two different techniques for developers: the Roaming TabIndex Technique and use of the activedescendant property.

Using the Roaming TabIndex Technique

The Roaming TabIndex Technique requires each of a widget’s descendants be focusable, either through the use of natively focusable HTML elements, or by making an element focusable using the tabIndex attribute. To use this technique, begin by setting the tabIndex attribute of a widget’s first descendant to a value that is equal to or greater than 0. (A value of 0 will result in the tab order of the widget being relative to its position in the page. Use a value greater than 0 to precisely control a widget’s tab order.) Next, set the tabIndex attribute of all remaining descendants to -1. (A value of -1 removes an element from the default tab flow, while preserving its ability to be focused via JavaScript.) This ensures that all of a widget’s descendants are focusable via JavaScript, but only one is in the default tab flow of its containing page or application, and therefore focusable by the user.

With these tabIndex values, use a keydown event handler to manage focus of the descendants once the widget is focused by the user. As the user presses the arrow keys, call the focus method to activate the appropriate descendant and update the tabIndex of the remaining descendants so that the currently focused element is the only one that is natively focusable.

The following menu button example illustrates how to use the Roaming TabIndex Technique to create a widget that is both keyboard and screen-reader accessible. To test this example yourself, you can use the free NVDA Screen Reader and Firefox 3. Alternatively, you can watch the screen cast of the example running in Firefox 3 using the NVDA screen reader.

Roaming TabIndex Example

Test Menu Roaming TabIndex Example

Roaming TabIndex Example Screen Cast

Menu Button Using Roaming TabIndex Technique @ Yahoo! Video

The Roaming TabIndex Technique Best Practices

Having studied the WAI-ARIA Best Practices document, as well as having used the Roaming TabIndex Technique in several widget implementations, I have distilled several best practices for using this approach:

• I prefer using natively focusable elements instead of using the tabIndex attribute to make non-focusable HTML elements focusable, for better backward compatibility in browsers that don’t support the tabIndex attribute on all elements.
• Use the keydown event when binding handlers used to manage focus since it is not possible to handle non-alphanumeric keys using the keypress event in IE.
• In most cases it is necessary to prevent the browser’s default behavior when handling key events.
• When setting the tabIndex attribute, avoid using the setAttribute method, to prevent case-sensitivity mistakes in IE. Setting the tabIndex attribute using the camel-case DOM property is both the most compact and most compatible syntax across browsers. For example: myElement.tabIndex = -1;
• When updating the tabIndex attribute of a widget’s descendants, set the attribute’s value to 0 before calling the focus method to ensure that the element’s default focus outline is rendered in IE.
• When styling a descendant’s focused state, work with or augment the browser’s default rendering of focus rather than suppress it. The default rendering of focus is familiar to the user and, in many cases, consistent with the browser’s host OS. Working with the default focus model improves the learnability of the widget. If you suppress the browser’s default rendering of focus, be sure to provide a focus model that is consistent across your entire site or application so that the user only has to recognize and learn one focus model within a single context.
• Set focus to HTML elements using both the setTimeout method and a try/catch block. Using setTimeout can help screen readers keep up while the focus is being changed. I have found this to be true when testing on VoiceOver for the Mac. A try/catch block can help suppress unwanted XUL-related errors logged to the console when focusing elements in Firefox.

Using the activedescendant Property

Unlike the Roaming TabIndex Technique, use of the activedescendant property doesn’t require any of a widget’s descendants to be focusable. Instead, this technique requires only that the widget’s root element be made focusable via the tabIndex attribute. (Note: this technique doesn’t work in the current version of Safari as it doesn’t support the tabIndex attribute on all HTML elements.) Using this approach, the activedescendant property is applied to the widget’s root element, and as the user presses the arrow keys, the value of the property is set to the id of the element that represents the user’s current selection. Since this approach doesn’t rely on focusing a widget’s descendants via the focus method, the browser will not provide any default rendering of the user’s current selection. Therefore, when using the activedescendant property the developer is responsible for rendering focus for the widget’s currently active descendant via CSS.

activedescendant Example

The following example adapts the previous example to illustrate how to use the activedescendant property.

Test activedescendant Example

activedescendant Example Screen Cast

Menu Button Using The "activedescendant" Property @ Yahoo! Video

As illustrated in the screen cast, the activedescendant property can provide a user experience that is identical to the Roaming TabIndex technique.

Best Practices for Using the activedescendant Property

• Depending on the browser and the attribute’s value, setting the tabIndex attribute on a widget’s root element can result in a focus outline being drawn around the widget. For widgets with descendants, having a focus outline surround an entire control is both unfamiliar to the user (not something you’ll see on the desktop), as well as ugly. So when using the activedescendant property, it is best to suppress the focus outline. This can be accomplished by setting the outline CSS property in Firefox and IE 8, and using the hideFocus attribute for IE 6 and 7. Unfortunately it is not possible to suppress the focus outline in the current version of Opera.
• Use CSS to render focus for a widget’s descendants in a way that is consistent with, and/or builds on, the default browser focus, or is consistent within the scope of the site or application.

Choosing a Technique

Having evaluated both the Roaming TabIndex Technique and the use of the activedescendant property, the Roaming TabIndex Technique is the better choice, because it is a solution that works “with the grain”. As such, it is more forward and backward compatible — especially when you are trying to support a wide array of browsers like we are at Yahoo!. Using the activedescendant property requires more effort for less overall benefit and compatibility. Here are the downsides to using the activedescendant property:

• Requires browser support of the tabIndex attribute on all elements. Currently this not supported in Safari.
• Suppressing the default focus outline drawn around a widget’s containing element is a slight pain in that it requires different techniques for different browsers. It turns into a bigger pain in Opera, where it is not only currently impossible but also exacerbated by Opera’s egregious focus model, illustrated in the following screen capture:
• Loss of the default, familiar focus outline drawn around a widget’s descendants. The focus outline can be restored via CSS. However, developers get the focus outline for free when using the Roaming TabIndex Technique.
• Since descendants aren’t focusable they cannot be clicked by pressing the enter key or space bar. This requires that developers listen explicitly for these key events and route the code responsible for handling the click event accordingly. When using the Roaming TabIndex technique, developers can simply listen for the click event.
• Every descendant needs a unique id.

Unlike the activedescendant property, the Roaming TabIndex Technique allows widgets to be both keyboard accessible and screen-reader accessible in browsers that don’t support ARIA and don’t support the tabIndex attribute on all elements. For example, if a widget’s descendants are built using the set of natively focusable HTML elements, users of screen readers will still perceive them as actionable/clickable elements. Consider the following screen cast of our first example running in IE 7 (a browser without ARIA support) using JAWS 10.

Screen reader accessible Menu Button @ Yahoo! Video

In this example, while the user doesn’t perceive the button’s menu as a menu, the screen reader does announce each button in the menu as it is focused — letting the user know that each item is actionable/clickable. Additionally, since the button’s menu is built using the natively focusable <button> element, this widget will be keyboard accessible to all A-Grade browsers, not just those that support the tabIndex attribute on all elements.

I suspect that the activedescendant property was developed as an alternative to the Roaming TabIndex Technique in part because the focus and blur events don’t bubble like other DOM events. This was a problem since developers need to listen for these events in order to customize how focus is drawn in a way that works cross browser, and attaching individual focus and blur event handlers to each of a widget’s focusable descendants has consequences for performance — especially for large composite widgets like trees and menus. That said, since we now have an easy way of listening for focus and blur in a performance-conscious way, I feel like there are currently more downsides than upsides to using the activedescendant property.

For many developers, the screen reader is still a misunderstood assistive technology. Using a screen reader can be compared to looking at a web page through a straw because you need to explore (hear) many items in chunks and then piece them in your memory or imagination. The user knows that an item is present on the screen only after they’ve heard their screen reader announce it. A different approach needs to be applied in order to successfully code for this type of technology. We shouldn’t stop at using visual cues to attract user attention, but visual attributes alone cannot be relied on when communicating important information to the user. The recent WebAIM screen reader survey of 1121 screen reader users is a great step towards understanding how blind, deaf-blind, or visually impaired users *actually* interact with the web.

Use Headings (<Hn> tags)

The survey results are pretty clear on this one: 90% of respondents use headings to navigate web pages “sometimes”, “often”, or “whenever they’re available”. WebAIM says, “It is clear that providing a heading structure is important to screen reader users….” Most screen readers provide one or more mechanisms for a user to jump between HTML headings on the page, either through a set of shortcut keys or through a custom list of headings. Because reading with a screen reader happens in a linear fashion, headings provide a way to jump between sections of a web page in a quick and efficient way. This not only enables the user to skip over repetitive navigation menus and unwanted content, but also helps them to learn about the structure and the order of the content on the page. Proper usage of HTML headings is semantic, easy, and most of all indispensible to screen reader users.

Access Keys

The access key is an HTML attribute that enables any focusable element on the page to become reachable via a shortcut key. Of survey respondents, 88% use access keys “sometimes”, “often”, or “whenever they’re available”. I’ve always assumed that access keys are of more use to advanced users, but the survey results actually suggest that beginners will tend to use access keys more often than their advanced counterparts.

Here are a couple of points to keep in mind when implementing access keys:

• Shortcut keys are not implemented across all browsers consistently: Internet Explorer uses the ALT key as a modifier, Firefox uses ALT+SHIFT, and Safari uses CONTROL.
• Access keys may potentially conflict with the particular browser’s built-in shortcut keys: “F” for “File” menu, “E” for “Edit” menu, etc.
• Access keys have to be appropriate to the user’s locale in order to make them intuitive. For example, the first letter for the English word “Search” would be different than for the same word in French. And what about languages that use the Cyrilic alphabet?
• Using numbers instead of letters for access keys makes them less intuitive because number-based shortcut keys are harder to associate with particular words.

This is not to suggest that access keys should not be used at all, rather that they should be used sparingly and thoughtfully. Screen reader applications provide a lot of ways for users to reach various HTML elements on the page, so these types of users may not end up using your access keys if they are too difficult to remember. If you do implement access keys, please take care to account for the different languages of your audience as well as check for possible conflicts with browser built-in keystrokes.

“Skip” links

66% of survey respondents say they use “skip to content” or “skip navigation” links “sometimes”, “often”, or “whenever they’re available”. These are internal anchor links that point to different content areas. Many screen reader applications provide a native “skip to text” feature which attempts to skip navigational links and place focus on the first text string on the page. You can not always rely on this feature because the first text on the page is not necessarily relevant content. Therefore, HTML-based “skip” links, that are embedded directly in the page, provide an extremely valuable convenience that links to the place where actual main content or content of interest begins. When deciding to implement “skip” links, keep the following points in mind:

• Implement “skip” links because they are quite useful for keyboard users to save excessive tabbing through repetitive menus by providing a way to quickly jump to another part of the page, e.g., the beginning of the main content.
• Do not be ashamed of “skip” links and do not hide them off-screen. They are useful for people with motor disabilities or repetitive strain injuries, and for keyboard users in general, enabling anyone to quickly skip to the main content using their keyboard.
• Name “skip” links to clearly indicate where you are sending users when the link is activated. Good examples are “Skip to main content” or “Skip to navigation menus”.
• Please remember to localize “skip” links as well; they are now a part of your content.
• Last but not least, ensure that the “skip” links actually work. (Yes, I have seen a lot of sites where they don’t.) Tab to the “skip” link and activate it, making sure that the focus moves to the intended place on the page.

Know Your Audience

One of the conclusions of the recently conducted WebAIM screen reader survey is the fact that there is no one way that screen reader users interact with the web. Too often, developers, product managers, and designers tend to assume the preferences, likes, and dislikes of screen reader users without ever asking them directly for their input.

Screen reader applications are used by blind, deaf-blind, or visually impaired users, as well as developers who test the accessibility of their web sites, teachers who instruct their students with visual impairments, and individuals who want to simply listen to the content on the screen. They are novice and advanced users of the software, who have made many configurations or left the default preferences alone. What they have in common is that they will use known techniques to navigate web pages such as:

• using headings to move between different parts of the page
• reading the whole content of the page before interacting with it
• navigating between focusable elements (links, form fields, etc.) on the page with a TAB and SHIFT+TAB key
• using the “find” feature of the browser or a screen reader to search for particular keywords on the page

It is vitally important to know your audience and how they interact with the web in order to write more usable code. Adopting these best practices will go a long way towards making your web pages more accessible for everyone.

Step 1: Install A Virtual Machine

Before I install and configure screen readers I start by installing a virtual machine. (This is mostly out of necessity because I use a Mac and the most-popular screen readers run on Windows.) Using a virtual machine provides a couple of benefits when testing with a screen reader: To start, a virtual machine provides a sandboxed environment, so I am protected if anything goes awry when I am installing and configuring each screen reader. (So as not to give the impression that screen readers are unstable pieces of software, this is definitely the exception more than the rule.)

The second benefit to using a virtual machine is that they allow you to save and restore state. This is an especially helpful feature for efficiently testing and re-testing specific pieces or states of complex web applications. So, using a virtual machine can help save you time when testing.

Which virtual machine to use? If you use Windows, you can download and install Microsoft Virtual PC for free. As a Mac user, I have found both VMware Fusion and Parallels Desktop work well.

Step 2: Install Browsers

It is important to remember that to work, ARIA requires a team effort between the browser and the screen reader. To test ARIA you’ll need to install browsers that both support ARIA and are supported by screen readers that also support ARIA. For example, Opera has support for ARIA, but is not supported by screen readers. Currently only Internet Explorer 8 and Firefox 3 have support for ARIA, and are supported by several screen readers for Windows that also offer support for ARIA.

After installing each browser, be sure to save the state of the virtual machine. That way you’ll be able to quickly revert back to a clean, working state should anything go wrong during the screen reader installation.

Step 3: Install & Configure Screen Readers

With the browsers installed the next step is to install and configure each screen reader. The two most-popular screen readers for Windows, JAWS and Window-Eyes support ARIA and work with both Internet Explorer 8 and Firefox 3. Free, trial versions of both products are available for download from Freedom Scientific’s and GW Micro’s websites. The open-source screen reader NVDA also has excellent ARIA support and currently works with Firefox 3. Knowing that most visually impaired users use more than one screen reader, I recommend installing all three for testing.

As a sighted person I disable a couple of features of each screen reader and change some configurations so that I can test more efficiently. For example, most screen readers are configured to startup automatically when you start your computer. This is obviously not desirable when you have multiple screen readers installed, so I turn off that feature. Additionally, every screen reader uses a different keyboard shortcut for toggling the virtual buffer on and off. To avoid having to remember the keyboard shortcut for each screen reader, I configure them all to be the same: Ctrl + Shift + Space. (For more on the virtual buffer, read Making Ajax Work with Screen Readers.)

The following sections provide step-by-step instructions for configuring JAWS, Window-Eyes and NVDA.

Configuring JAWS

Changing The Virtual Buffer Toggle Keyboard Shortcut

1. Open the “Keyboard Manager” dialog by selecting “Utilities” -> “Keyboard Manager” in the JAWS application menubar.
2. Select the “default” profile in the left, “Profile” pane.
3. In the right pane, sort by the “Script Name” column, then find and select the item named “VirtualPCCursorToggle”.
4. Open the “Change Keystroke” dialog by either right clicking on the “VirtualPCCursorToggle” item, or by pressing Ctrl + H.
5. In the “Change Keystroke” dialog, choose the new keystroke by pressing the desired keys. (I use Ctrl + Shift + Space.) JAWS will warn you if the keystroke you choose in already in use.
6. Press the “OK” button to close the dialog.

Disabling JAWS From Starting Automatically

1. Open the “Basic Settings” dialog by selecting “Options” -> “Basics” in the JAWS application menubar.
2. In the “Basic Settings” dialog, make sure the checkbox labeled “Automatically start JAWS” in not checked.

Configuring Window-Eyes

Changing The Virtual Buffer Toggle Keyboard Shortcut

1. Open the “Browse Mode Hot Key Definitions” dialog by selecting “Hotkeys” -> “Browse Mode…” in the Window-Eyes application menubar.
2. In the “Browse Mode Hot Key Definitions” dialog, scroll down to the item named “Browse Mode” in the scrollable “Keys” list.
3. Select the “Browse Mode” item and then press the “Capture Key” button.
4. Press the keyboard combination you want to use. (I use Ctrl + Shift + Space.)
5. Press the “OK” button to close the dialog.
6. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar.

Disabling The Mouse Voice

By default Window-Eyes will speak in response to some mouse gestures. For example, when you press the left mouse button, Window-Eyes will say “left”. As a sighted person I find this feature unnecessary, so I disable this feature.

1. Open the “Mouse Voice” dialog by selecting “Mouse” -> “Voice” in the Window-Eyes application menubar.
2. Select the “Off” item.
3. Press the “OK” button to close the dialog.
4. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar.

Disabling Window-Eyes From Starting Automatically

1. Open the “Startup Options” dialog by selecting “File” -> “Starup Options…” in the Window-Eyes application menubar.
2. In the “Startup Options” dialog:
   • Uncheck the checkbox labeled “Run Window-Eyes at the Login Screen”.
   • Uncheck the checkbox labeled “Run Window-Eyes after login for all users”.
   • Select the radio button labeled “Never” under “After login for Current User, Run Window-Eyes”.

   

3. Press the “OK” button to close the dialog.
4. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar.

Configuring NVDA

General Settings For Efficiency

1. Uncheck the checkbox labeled “Show this dialog when NVDA starts” that pops up the first time NVDA starts
2. Disable the confirmation dialog that pops up when you exit the application:
   1. Open the “General settings” dialog by right clicking on the NVDA system tray icon and selecting to “Preferences” -> “General settings” in the context menu.
   2. In the “General settings” dialog, uncheck the checkbox labeled “Warn before exiting NVDA”.
   3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu.

Disabling the Mouse Voice

Like Window-Eyes, by default NVDA will speak in response to some mouse gestures. For example, when you move the mouse NVDA will play tones to help the user track the position of the mouse. As a sighted person I find this feature unnecessary, so I disable this feature.

1. Open the “Mouse settings” dialog by right clicking on the NVDA icon in the system tray and selecting “Preferences” -> “Mouse settings” from the context menu.
2. In the “Mouse settings” dialog, uncheck both “Report text under the mouse” and “play audio coordinates when the mouse moves”.
3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu.

Changing The Virtual Buffer Toggle Keyboard Shortcut

1. Shut down NVDA – right click on the system track icon and choose “Exit” from the context menu.
2. Navigate to the path “C:\Program Files\NVDA\appModules”.
3. Open the file named “_default_desktop.kbd”.
4. Find the line: “NVDA+space=toggleVirtualBufferPassThrough”.
5. Change to: “Control+Shift+space=toggleVirtualBufferPassThrough”.
6. Save the file.
7. Restart NVDA.

Step 4: Restart Windows & Save State

With all of the screen readers installed and configured, restart Windows. Once Windows is restarted, take another snapshot of the virtual machine’s state. If you are using the free, trial versions of JAWS and Window-Eyes they will require you to restart Windows after using either product for ~30 minutes. Using the virtual machine, you can revert back to using JAWS and Window-Eyes more quickly than you would if you had to restart Windows.

Steps Summary

That’s it. The steps for configuring your development environment for testing using a screen reader can be summarized as follows:

1. Install virtualization software
2. Install browsers & take a snapshot of that state
3. Install and configure screen readers
4. Restart the virtual machine & take a snapshot of that state

Resources & Further Reader

• Developing Accessible Widgets with ARIA
• An Introduction to Screen Readers
• Roles for Accessible Rich Internet Applications (WAI-ARIA Roles) Version 1.0
• States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties) Version 1.0

We liked PPK’s solution and decided to answer his call and be, in his words, “…one of those frightfully clever JavaScript librar[ies to] use this technique…”. So for version 2.6 we’ve rolled PPK’s solution into two methods of the Event Utility: addFocusListener and addBlurListener (or onFocus and onBlur for short). These two new methods encapsulate the nitty gritty of supporting this technique in all our A-Grade browsers, while delivering the sugar you’ve come to expect from the addListener method of the Event Utility. The signatures of these new methods are as follows:

onFocus(el, fn, obj, override)
oBlur(el, fn, obj, override)

The arguments for both methods are as follows:

el

An id, an element reference, or a collection of ids and/or elements to assign the listener to.

fn

The method the event invokes.

obj

An arbitrary object that will be passed as a parameter to the handler.

override

override If true, the obj passed in becomes the execution scope of the listener. If an object, this object becomes the execution scope.

Using onFocus and onBlur

Here are several ways we’ve made use of the new onFocus and onBlur methods in YUI 2.6:

Improving Performance of Modal Dialogs

To support modality, a Dialog widget needs to direct focus back to itself when an element that is not one of its children receives focus. Previously this was accomplished by registering focus event listeners on every focusable element in the document when a modal Dialog was made visible, and removing those listeners when it has was hidden, a process that proved to be expensive and slow. Using PPK’s technique we’ve been able to boost the time it takes to initially display a modal Dialog by over 50% in most browsers, and boost the time it takes to hide a modal Dialog by over 90%. To test, we used a page with 250 focusable elements. Here is how the numbers break out for each browser:

Improving Menu Keyboard Accessibility

In keeping with the WAI-ARIA Best Practices for Menus, the Menu widget uses the new onFocus method to listen for focus at the document level, so that when a popup Menu is hidden focus can be restored to the element in the DOM that had focus before it was made visible.

Providing Focus Feedback in Carousel

The new Carousel widget skins its next and previous buttons by wrapping each <input type="button"> elements in a <span>. The <input> elements are then positioned off screen and a background image is applied to each <span>. While this technique allows the next and previous buttons to remain accessible to users of screen readers, with the actual next and previous buttons hidden off screen, sighted users don’t receive any feedback from the UI when either button is focused. To fix this problem, Carousel uses the onFocus method to apply a class to the next and previous buttons that highlights focused buttons with an outline.

Of course, these are just a few places where we’ve used onFocus and onBlur — we think it will prove so useful in YUI and in YUI-based applications that we’ve added it to our Core, making it available to any application you build on top of YUI’s Event Utility.

Tags: onfocus, onblur, wai-aria, ppk

Using the ARIA Plugins

Using the YUI ARIA Plugins is easy. Simply include the source file(s) for the ARIA plugin after the
widget source file(s) as indicated on the widget’s landing page. That’s it. Currently, the source
files for each plugin are available in the
YUI 2.6 package on SourceForge, and can
also be downloaded from the YUI blog
sandbox. In a future release of YUI, the plugins will be served from our CDN.

Browser Support

All YUI ARIA Plugins require the user’s browser and AT support the WAI-ARIA Roles and States.
Currently only Firefox 3 and
Internet Explorer
8 have support for ARIA and are supported by several screen readers for
Windows that also offer ARIA support. Opera also has support for ARIA as of version 9.5, but
unfortunately isn’t supported by any screen readers. For this reason the YUI ARIA Plugins are only
enabled by default for Firefox 3 and IE 8. To enable the ARIA plugin for other browsers, simply the set
the usearia configuration property to true. For example:

var oMenu = new YAHOO.widget.Menu("menu-1", { usearia: true });

Why Plugins?

Rather than integrate ARIA directly into a widget, we chose to deliver this functionality as a
plugin for two main reasons:

• Performance: We’ve got many extremely byte-conscious users. And while we certainly
  don’t want users opting out of a more accessible interface, we need to be respectful of those
  developers that need to make tough choices on KB weight.
• The right fit: For most widgets (like Menu) there is an ARIA role that is a perfect match.
  For some, like Carousel, or AccordionView, there either isn’t a clear match, or there are several
  different roles that could work depending on the circumstances. For widgets that fall into this
  category we can offer several different ARIA plugins that meet the desired use case.

Widgets with ARIA Plugin Support

The following table illustrates which YUI widgets currently have an ARIA plugin, along with their
corresponding WAI-ARIA Roles.

Screen Reader Testing

We’d love the community to help us test these plugins, find bugs and suggest enhancements. As mentioned above, each plugin requires AT that supports ARIA. Two of the leading screen readers for Windows, JAWS and Window-Eyes, support ARIA. Free, trial versions of both are available for download, but require Windows be restarted every 40 minutes. For that reason, the open-source NVDA Screen Reader is the best option for developers looking to test the YUI ARIA Plugins as it is both free and provides excellent support for ARIA.

This is why I thought of writing a small script that can be used as a bookmarklet to cover the screen with a dark overlay and only shows a few lines at a time. That way you can concentrate on the bit you are reading at the moment and the rest of the screen does not bother you too much.

Following are two screenshots of the same site with and without reading blinds:

So how to build that?

The task of building a tool like that is actually pretty easy:

• create two DIVs with black background and 85% opacity
• position them fixed to the top and the bottom of the screen
• set their height to 10% and 70% to leave a gap

Then I thought that I should be able to move the highlight on the page. For this I needed a bit more sophistication:

• Detect the mouse cursor position
• Make the top div span from the current top of the document to a few pixels above the cursor position
• Make the bottom div span from a few pixels below the current cursor position to the bottom of the viewport

I could have had a go at it myself, but I don’t want to end in browser inconsistency hell, hence I use YUI.

Here’s the code:

var readingblinds = function(){
  var visible = true;
  var y,top,bottom;
  var info = true;
  var size = 70;
  function generate(){
    top = document.createElement('div');
    bottom = document.createElement('div');
    document.body.appendChild(top);
    document.body.appendChild(bottom);
    styleTopBottom();
    var message = document.createElement('div');
    var note = document.createTextNode(
      'Reading Blinds - ' +
      'move mouse to highlight section to read. '
    );
    message.appendChild(note);
    top.appendChild(message);
    styleMessage(message);
    YAHOO.util.Event.on(document, "mousemove", move);
  };
  function move(e){
    y = YAHOO.util.Event.getXY(e);
    if(y[1] > size){
      render(y);
    }
  };
  function render(y){
    var real = y[1]-YAHOO.util.Dom.getDocumentScrollTop();
    YAHOO.util.Dom.setStyle(top,'height',real-size+'px');
    var h = YAHOO.util.Dom.getViewportHeight()-real+size;
    YAHOO.util.Dom.setStyle(bottom,'top',real+size+'px');
    YAHOO.util.Dom.setStyle(bottom,'height',h + 'px');
  };
  function styleMessage(message){
    YAHOO.util.Dom.setStyle(message,'font-size','80%');
    YAHOO.util.Dom.setStyle(message,'text-align','right');
    YAHOO.util.Dom.setStyle(message,'padding','5px');
    YAHOO.util.Dom.setStyle(message,'font-family','verdana,sans-serif');
    YAHOO.util.Dom.setStyle(message,'color','white');
  }
  function styleTopBottom(){
    YAHOO.util.Dom.batch([top,bottom],function(o){
      YAHOO.util.Dom.setStyle(o,'background','#000');
      YAHOO.util.Dom.setStyle(o,'width','100%');
      YAHOO.util.Dom.setStyle(o,'position','fixed');
      YAHOO.util.Dom.setStyle(o,'left','0');
      YAHOO.util.Dom.setStyle(o,'height','10%');
      YAHOO.util.Dom.setStyle(o,'opacity','.85');
      YAHOO.util.Dom.setStyle(o,'overflow','hidden');
    });
    YAHOO.util.Dom.setStyle(top,'top','0');
    YAHOO.util.Dom.setStyle(bottom,'bottom',0);
    YAHOO.util.Dom.setStyle(bottom,'height','70%');
  };
  return{
    init:generate
  }
}();
readingblinds.init();

The interesting methods are move() and render(); the rest is more or less run-of-the-mill DOM scripting.

The move() method is an event handler that gets called by any mousemove event on the document. YUI’s Dom Collection then makes it easy for me to get the current mouse cursor position with getXY() and I just need to make sure that the mouse is low enough in the browser window to not cause a negative height on the top div.

The render() method then sets the appropriate heights. I determine the upper border of the browser with getDocumentScrollTop() and substract that one from the cursor position. To determine where to end the bottom div I use getViewPortHeight().

Addding dazzle with keyboard controls

This was cool enough, but I wanted to be able to turn the blinds on and off and change the size of the visible part with the keyboard, too. For this, I needed to use the keylistener utility some tool methods to resize the gap or show and hide both of the cover divs. The resizing methods needed to get some boundaries to avoid div overlap or the whole viewport to be uncovered.

var readingblinds = function(){
  var visible = true;
  var y,top,bottom;
  var info = true;
  var size = 70;
  function generate(){
    top = document.createElement('div');
    bottom = document.createElement('div');
    document.body.appendChild(top);
    document.body.appendChild(bottom);
    styleTopBottom();
    var message = document.createElement('div');
    var note = document.createTextNode(
      'Reading Blinds - ' +
      'move mouse to highlight section to read. ' +
      'Press "b" to show and hide, "s" to decrease size,' +
      ' "l" to increase size'
    );
    message.appendChild(note);
    top.appendChild(message);
    styleMessage(message);
    var keyspy = new YAHOO.util.KeyListener(
      document,
      { keys:66 },
      { fn:peekaboo }
    );
    keyspy.enable();
    var keyspy2 = new YAHOO.util.KeyListener(
      document,
      { keys:83 },
      { fn:smaller }
    );
    keyspy2.enable();
    var keyspy3 = new YAHOO.util.KeyListener(
      document,
      { keys:76 },
      { fn:larger }
    );
    keyspy3.enable();
    YAHOO.util.Event.on(document, "mousemove", move);
  };
  function move(e){
    y = YAHOO.util.Event.getXY(e);
    if(y[1] > size){
      render(y);
    }
  };
  function render(y){
    var real = y[1]-YAHOO.util.Dom.getDocumentScrollTop();
    YAHOO.util.Dom.setStyle(top,'height',real-size+'px');
    YAHOO.util.Dom.setStyle(bottom,'top',real+size+'px');
    var h = YAHOO.util.Dom.getViewportHeight()-real+size;
    YAHOO.util.Dom.setStyle(bottom,'height',h + 'px');
  };
  function styleMessage(message){
    YAHOO.util.Dom.setStyle(message,'font-size','80%');
    YAHOO.util.Dom.setStyle(message,'text-align','right');
    YAHOO.util.Dom.setStyle(message,'padding','5px');
    YAHOO.util.Dom.setStyle(message,'font-family','verdana,sans-serif');
    YAHOO.util.Dom.setStyle(message,'color','white');
  }
  function styleTopBottom(){
    YAHOO.util.Dom.batch([top,bottom],function(o){
      YAHOO.util.Dom.setStyle(o,'background','#000');
      YAHOO.util.Dom.setStyle(o,'width','100%');
      YAHOO.util.Dom.setStyle(o,'position','fixed');
      YAHOO.util.Dom.setStyle(o,'left','0');
      YAHOO.util.Dom.setStyle(o,'height','10%');
      YAHOO.util.Dom.setStyle(o,'opacity','.85');
      YAHOO.util.Dom.setStyle(o,'overflow','hidden');
    });
    YAHOO.util.Dom.setStyle(top,'top','0');
    YAHOO.util.Dom.setStyle(bottom,'bottom',0);
    YAHOO.util.Dom.setStyle(bottom,'height','70%');
  };
  function peekaboo(){
    if(visible === true){
      YAHOO.util.Dom.setStyle(top,'display','none');
      YAHOO.util.Dom.setStyle(bottom,'display','none');
      visible = false;
    } else {
      YAHOO.util.Dom.setStyle(top,'display','block');
      YAHOO.util.Dom.setStyle(bottom,'display','block');
      visible = true;
    }
  };
  function smaller(){
    if(size > 10){
      size -= 5;
      render(y);
    }
  };
  function larger(){
    if(size <  YAHOO.util.Dom.getViewportHeight()/2){
      size += 5;
      render(y);
    }
  };
  return{
    init:generate
  }
}();
readingblinds.init();

That was pretty cool already, but as I wanted to make reading blinds a single script include or bookmarklet I had the problem of relying on the YUI. Well, there is a trick to conjure YUI from thin air by using the YAHOO_config object with the listener method creating a script node to get the YUI Loader.

So instead of calling readingblinds.init() directly, I used the following magic YUI trick:

if(typeof YAHOO=="undefined"||!YAHOO){
  YAHOO_config = function(){
    var s = document.createElement('script');
    s.setAttribute('type','text/javascript');
    s.setAttribute('src','http://yui.yahooapis.com/2.5.2/'+
                   'build/yuiloader/yuiloader-beta-min.js');
    document.getElementsByTagName('head')[0].appendChild(s);
    return{
      listener:function(o){
        if(o.name === 'get'){
          window.setTimeout(YAHOO_config.ready,1);
        }
      },
      ready:function(){
        var loader = new YAHOO.util.YUILoader();
        var dependencies = ['yahoo','dom','event'];
        loader.require(dependencies);
        loader.loadOptional = true;
        loader.insert({
          onSuccess:function(){
            readingblinds.init();
          }
        });
      }
    };
  }();
} else {
  readingblinds.init();
}

That’s the lot. You can download readingblinds.js
and include it in your site, or you can drag the following link to your links toolbar: Reading Blinds.

WAI-ARIA Roles and States, it is possible to enhance
TabView’s accessibility such that users of screen readers perceive it as a desktop tab control.

A complete
example of TabView using the WAI-ARIA Roles and States is available in the YUI Sandbox.
Watch a screen cast of the example
running in Firefox 3 with the NVDA screen reader, or
download the latest development snapshot of
NVDA and try it yourself.

Applying the WAI-ARIA Roles and States to TabView

Step 1: Getting Started

To start working with the WAI-ARIA Roles and States you’ll need both a browser and screen
reader that support ARIA. Both Firefox 3 and
Internet Explorer
8 Beta 1 have ARIA support. Trial versions of the leading
JAWS and

Window-Eyes screen readers are available for
free download. However, the open-source NVDA Screen
Reader is the best option for developers as it is both free and provides excellent support
for ARIA.

Step 2: Adding Enhanced Keyboard Support

Out of the box, TabView provides basic keyboard support. Each Tab in a TabView is represented by
an <A> element whose href attribute is set to the id of an

<DIV> element that contains its content. In IE and Firefox,
<A> elements are automatically placed in the browser’s default tab index,
enabling the user to toggle between Tabs by pressing the tab key, and select a Tab by
pressing enter. (In Safari and Opera, <A> elements are not in the tab index
by default. Safari users can change this by going to the Safari Menu, Selecting “Preferences”,
then choose the “Advanced” tab and check the “Press Tab to highlight each item on a
webpage” checkbox.)

Having all of the Tabs in a TabView in the browser’s default tab index is a mixed blessing:
it provides basic keyboard accessibility, but can also make navigating more tedious in that users
navigating via the tab key have to tab through every Tab’s <A> as well as the
content of the active Tab’s correpsonding TabPanel in order to skip past the control. This problem
can be solved by setting the tabindex attribute of the <A> element
of the active Tab to a value of 0, and the inactive Tabs to -1. Setting an element’s

tabindex attribute to a value of -1 removes it from the browser’s default tab order,
while maintaining its focusability via JavaScript. Therefore, with this change in place it will be
easier for the user to skip over a TabView widget while navigating with the keyboard.

Mac vs. Windows

With only one Tab now in the browser’s default tab index, it will be necessary to supplement the
TabView with support for the arrow keys to enable the user to navigate between Tabs as they would
on the desktop. There are two different models for arrow key support for tabbed-content controls
in operating systems: Mac OS X and Windows.
On Windows, pressing the left or right arrow key moves focus to the next Tab and immediately
displays its corresponding TabPanel. On the Mac, with VoiceOver enabled, the arrow keys only
move focus between each Tab, and the user must press the space bar to load the content of the Tab’s
corresponding TabPanel. Of the two, the Mac’s model might be considered better for a DHTML TabView.
For example, if each Tab’s content is loaded via XHR, the Mac’s more intentional Tab selection
model could help prevent the user from making requests for data he/she is not interested
in consuming.

Supporting Multiple Orientations

The orientation
attribute of the TabView is used to render the Tabs on any of the widget’s four sides. To provide
arrow key support that will work regardless of the orientation of the Tabs, the left and up keys
will move the focus to the previous Tab, while the right and down arrow keys will move the focus to
the next Tab. As an additional convenience to the user, we’ll take another cue from the Mac’s
tab control implementation so that focus is automatically moved to the first or last Tab when the
user has reached the beginning or end of a list of Tabs.

To apply these keyboard enhancements to TabView, we’ll define a new prototype method named
enhanceAccessibility. This new method is designed to provide consistent keyboard
support for TabView across all of the A-Grade
browsers. It will work regardless of how the TabView is constructed (from existing markup, or
from script), its orientation, or if its content is static or loaded via XHR.

YAHOO.widget.TabView.prototype.enhanceAccessibility = function () {

	var Dom = YAHOO.util.Dom,
		Event = YAHOO.util.Event,
		UA = YAHOO.env.ua,

		oTabViewEl = this.get("element"),
		oTabList = Dom.getChildren(oTabViewEl)[0],
		aTabListItems = Dom.getChildren(oTabList),
		aTabs = this.get("tabs"),
		oTabIndexMap = {},
		oTab,
		oTabEl,
		oTabAnchor,
		oTabContentEl,
		oFocusedTabAnchor,
		sTabId,
		oActiveTab;

	//	Set the "tabIndex" attribute of each Tab's <A> element: The
	//	"tabIndex" of the active Tab's <A> element is set to 0, the others to -1.
	//	This improves the keyboard accessibility of the TabView by placing
	//	only one Tab in the browser's tab index by default, allowing the user
	//	to easily skip over the control when navigating the page with the tab key.

	Dom.batch(oTabList.getElementsByTagName("A"), function (element) {
		element.tabIndex = -1;
	});

	oActiveTab = this.get("activeTab");

	if (oActiveTab) {
		Dom.getFirstChild(oActiveTab.get("element")).tabIndex = 0;
	}

	//	Returns the <A> element representing each Tab in the TabView.

	var getTabAnchor = function (element) {

		var oTabAnchor;

		if (Dom.getAncestorByClassName(element, "yui-nav")) {

			if (element.nodeName.toUpperCase() === "A") {
				oTabAnchor = element;
			}
			else {
				oTabAnchor = Dom.getAncestorByTagName(element, "A");
			}

		}

		return oTabAnchor;

	};

	//	Keydown event listener for the TabView that provides support for
	//	using the arrow keys to move focus between each Tab.

	this.on("keydown", function (event) {

		var oCurrentTabAnchor = getTabAnchor(Event.getTarget(event)),
			oCurrentTabLI,
			oNextTabLI,
			oNextTabAnchor;

		if (oCurrentTabAnchor) {

			oCurrentTabLI = oCurrentTabAnchor.parentNode;

			switch (Event.getCharCode(event)) {

				case 37:	// Left
				case 38:	// Up

					oNextTabLI = Dom.getPreviousSibling(oCurrentTabLI);

					if (!oNextTabLI) {
						oNextTabLI = aTabListItems[aTabListItems.length-1];
					}

				break;

				case 39:	// Right
				case 40:	// Down

					oNextTabLI = Dom.getNextSibling(oCurrentTabLI);

					if (!oNextTabLI) {
						oNextTabLI = aTabListItems[0];
					}

				break;

			}

			oNextTabAnchor = Dom.getChildren(oNextTabLI)[0];

			if (!oFocusedTabAnchor) {
				oFocusedTabAnchor = oCurrentTabAnchor;
			}

			oFocusedTabAnchor.tabIndex = -1;
			oNextTabAnchor.tabIndex = 0;

			oNextTabAnchor.focus();

			oFocusedTabAnchor = oNextTabAnchor;

		}

	});

};

Step 3: Adding the WAI-ARIA Roles and States

With the keyboard functionality in place, we’ll proceed with the application of the WAI-ARIA Roles
and States. Once applied, assistive technologies (AT) such as a screen reader will no longer
announce the HTML elements that compose the TabView as HTML elements, but as a tab control. In
this way the relationship between the WAI-ARIA Roles and States and HTML is similar to that of CSS:
both enable the developer to change the presentation of markup. And since the WAI-ARIA Roles and
States enable the TabView to be presented to the user as a desktop tab control, it makes the
previous work of applying desktop-like keyboard behavior all the more critical. If users of AT are
going to preceive the TabView as a desktop tab control, it needs to fulfill that expectation from a
keyboard perspective.

As a best practice, apply the WAI-ARIA Roles and States via JavaScript. Since the WAI-ARIA Roles
and States depend on JavaScript-based keyboard functionality, it follows that the attributes
representing the WAI-ARIA Roles and States only be applied via JavaScript. This
Progressive Enhancement
strategy ensures the best possible user experience by only applying WAI-ARIA Roles and States when
the browser technologies required to support them (in this case, CSS and JavaScript) are available.

Roles and states are added to a TabView’s DOM elements via the
setAttribute
method. At present only two browsers have WAI-ARIA support:
Firefox 3 and
Internet Explorer 8 Beta 1.
(The changelog for Opera 9.5
mentions support for screen readers, MSAA, and ARIA, but in my testing in Opera I didn’t
find ARIA to work.) Therefore, we’ll make use of YUI’s browser detection
(YAHOO.env.ua) and
only apply the Roles and States to browsers that support them. The role of
tab will be applied to each Tab’s

<A> element, and the role of
tablist to their parent
<UL>. Finally, each Tab’s content element (<DIV>) will
receive the role of tabpanel and
an aria-labelledby attribute
with a value of the id of the <A> representing its corresponding Tab instance.
The aria-labelledby attribute enables the screen reader to announce the label of the
Tab for each TabPanel when the first element in a TabPanel receives focus, providing the user with
some context as to where they are. The following example illustrates how the ARIA roles and
properties are applied to each of the HTML elements that compose a TabView:

<div class="yui-navset">
	<ul role="tablist">
		<li>
			<a href="..." id="tab-1" role="tab">tab label</a>

		</li>
	</ul>
	<div clas="yui-content">
		<div role="tabpanel" aria-labelledby="tab-1">tab content</div>

	</div>
</div>

Screen-Reader Specific Tweaks

The implementation of the WAI-ARIA Roles and States is slightly different across screen readers, so
it is necessary to make some additional tweaks. A role of
presentation will need to be
applied to the parent <LI> element of each <A>, so that
the Window-Eyes screen reader recognizes that each Tab belongs to the same TabList. For JAWS it is
necessary to remove the href attribute of each Tab’s <A> element
to prevent it from announcing the attribute’s value when focused. Ideally JAWS would behave like
NVDA and Window-Eyes and allow the applied role attribute of

tab to take precedence over the
default role of the <A> element. The following illustrates the updated
markup for a TabView with the screen reader tweaks applied:

<div class="yui-navset">
	<ul role="tablist">
		<li role="presentation">

			<a id="tab-1" role="tab">tab label</a>
		</li>
	</ul>
	<div clas="yui-content">
		<div role="tabpanel" aria-labelledby="tab-1">tab content</div>

	</div>
</div>

With this strategy for applying the WAI-ARIA Roles and States to TabView, we can update the
enhanceAccessibility method:

YAHOO.widget.TabView.prototype.enhanceAccessibility = function () {

	var Dom = YAHOO.util.Dom,
		Event = YAHOO.util.Event,
		UA = YAHOO.env.ua,

		oTabViewEl = this.get("element"),
		oTabList = Dom.getChildren(oTabViewEl)[0],
		aTabListItems = Dom.getChildren(oTabList),
		aTabs = this.get("tabs"),
		oTabIndexMap = {},
		oTab,
		oTabEl,
		oTabAnchor,
		oTabContentEl,
		oFocusedTabAnchor,
		sTabId,
		oActiveTab;

	//	Set the "tabIndex" attribute of each Tab's <A> element: The
	//	"tabIndex" of the active Tab's <A> element is set to 0, the others to -1.
	//	This improves the keyboard accessibility of the TabView by placing
	//	only one Tab in the browser's tab index by default, allowing the user
	//	to easily skip over the control when navigating the page with the tab key.

	Dom.batch(oTabList.getElementsByTagName("A"), function (element) {
		element.tabIndex = -1;
	});

	oActiveTab = this.get("activeTab");

	if (oActiveTab) {
		Dom.getFirstChild(oActiveTab.get("element")).tabIndex = 0;
	}

	//	Returns the <A> element representing each Tab in the TabView.

	var getTabAnchor = function (element) {

		var oTabAnchor;

		if (Dom.getAncestorByClassName(element, "yui-nav")) {

			if (element.nodeName.toUpperCase() === "A") {
				oTabAnchor = element;
			}
			else {
				oTabAnchor = Dom.getAncestorByTagName(element, "A");
			}

		}

		return oTabAnchor;

	};

	//	Keydown event listener for the TabView that provides support for
	//	using the arrow keys to move focus between each Tab.

	this.on("keydown", function (event) {

		var oCurrentTabAnchor = getTabAnchor(Event.getTarget(event)),
			oCurrentTabLI,
			oNextTabLI,
			oNextTabAnchor;

		if (oCurrentTabAnchor) {

			oCurrentTabLI = oCurrentTabAnchor.parentNode;

			switch (Event.getCharCode(event)) {

				case 37:	// Left
				case 38:	// Up

					oNextTabLI = Dom.getPreviousSibling(oCurrentTabLI);

					if (!oNextTabLI) {
						oNextTabLI = aTabListItems[aTabListItems.length-1];
					}

				break;

				case 39:	// Right
				case 40:	// Down

					oNextTabLI = Dom.getNextSibling(oCurrentTabLI);

					if (!oNextTabLI) {
						oNextTabLI = aTabListItems[0];
					}

				break;

			}

			oNextTabAnchor = Dom.getChildren(oNextTabLI)[0];

			if (!oFocusedTabAnchor) {
				oFocusedTabAnchor = oCurrentTabAnchor;
			}

			oFocusedTabAnchor.tabIndex = -1;
			oNextTabAnchor.tabIndex = 0;

			oNextTabAnchor.focus();

			oFocusedTabAnchor = oNextTabAnchor;

		}

	});

	//	Only apply the WAI-ARIA Roles and States for FF 3 and IE 8 since those
	//	are the only browsers that currently support ARIA.

	if ((UA.gecko && UA.gecko >= 1.9) || (UA.ie && UA.ie >= 8)) {

		//	Set the "role" attribute of the <UL> encapsulating the Tabs to "tablist"

		oTabList.setAttribute("role", "tablist");

		for (var i = 0, nLength = aTabs.length; i < nLength; i++) {

			oTab = aTabs[i];
			oTabEl = oTab.get("element");
			oTabAnchor = Dom.getChildren(oTabEl)[0];

			//	Create a map that links the ids of each Tab's <A> element to
			//	the Tab's "index" attribute to make it possible to retrieve a Tab
			//	instance reference by id.

			sTabId = oTabAnchor.id;

			if (!sTabId) {
				sTabId = Dom.generateId();
				oTabAnchor.id = sTabId;
			}

			oTabIndexMap[sTabId] = i;

			//	Need to set the "role" attribute of each Tab's <LI> element to
			//  "presentation" so that Window-Eyes recognizes that each Tab belongs to
			//	the same TabList. Without this, Window-Eyes will announce each Tab as
			//	being "1 of 1" as opposed to "1 of 3," or "2 of 3".

			oTabEl.setAttribute("role", "presentation");

			oTabAnchor.setAttribute("role", "tab");

			//	JAWS announces the value of the "href" attribute of each Tab's <A>
			//	element when it recieves focus.  Ideally JAWS would allow the
			//	applied "role" attribute of "tab" to take precedence over the default
			//  role of the <A> element like NVDA and Window-Eyes do.  It is
			//	possible to fix this problem by removing the "href" attribute from
			//	the <A>.

			oTabAnchor.removeAttribute("href");

			oTabContentEl = oTab.get("contentEl");

			oTabContentEl.setAttribute("role", "tabpanel");

			//	Set the "aria-labelledby" attribute for the TabPanel <LI> element to
			//	the id of its corresponding Tab's <A> element.  Doing so enables the
			//	screen reader to announce the label of the Tab for each TabPanel when
			//	the first element in a TabPanel receives focus, providing the user
			//	with some context as to where they are.

			oTabContentEl.setAttribute("aria-labelledby", sTabId);

		}

		//	Add a keypress listener that toggles the active Tab instance when the user
		//	presses the Enter key.  This is necessary because the removal of the "href"
		//	attribute from each Tab's <A> element (for JAWS support) causes the
		//	TabView's default Enter key support to stop working.  Support for the Space
		//	Bar is also added as an additional convience for the user.

		this.on("keypress", function (event) {

			var oTabAnchor = getTabAnchor(Event.getTarget(event)),
				nCharCode = Event.getCharCode(event);

			if (oTabAnchor &&
				(nCharCode === 13 || nCharCode === 32) &&
				(oTabAnchor.parentNode !== this.get("activeTab").get("element"))) {

					this.set("activeIndex", oTabIndexMap[oTabAnchor.id]);

			}

		});

	}

};

Step 4: Putting It All Together

To test the new enhanceAccessibility method, we'll use the
Getting Content from an
External Source example from the existing TabView examples gallery as a starting point.
Once the TabView instance has been appended to the page, we'll call the new
enhanceAccessibility method. Next we'll use some additional WAI-ARIA Roles and States
to make some example-specific tweaks. First we'll, use the
describedby

property to provide some helpful instructional text that will be announced to the user
when the TabView initially receives focus. Since each Tab's content is loaded asynchronously, we'll
also leverage
WAI-ARIA Live Regions to
message users when a Tab's content is both being loaded and has finished loading.
(Note: The describedby property and Live Regions are currently only supported in the
latest development snapshots of NVDA.)
The following code snippet illustrates how it all comes together:

(function() {

	var oTabView = new YAHOO.widget.TabView();

	oTabView.addTab( new YAHOO.widget.Tab({
		label: "Opera",
		content: "<p>Please wait.  Content loading.</p>",
		dataSrc: "news.php?query=opera+browser",
		cacheData: true,
		active: true
	}));

	oTabView.addTab( new YAHOO.widget.Tab({
		label: "Firefox",
		content: "<p>Please wait.  Content loading.</p>",
		dataSrc: "news.php?query=firefox+browser",
		cacheData: true
	}));

	oTabView.addTab( new YAHOO.widget.Tab({
		label: "Explorer",
		content: "<p>Please wait.  Content loading.</p>",
		dataSrc: "news.php?query=microsoft+explorer+browser",
		cacheData: true
	}));

	oTabView.addTab( new YAHOO.widget.Tab({
		label: "Safari",
		content: "<p>Please wait.  Content loading.</p>",
		dataSrc: "news.php?query=apple+safari+browser",
		cacheData: true
	}));

	oTabView.appendTo("container");
	oTabView.enhanceAccessibility();

	var Dom = YAHOO.util.Dom,
		UA = YAHOO.env.ua,
		oActiveTab,
		oTitle,
		oTabViewEl,
		oLog,
		sInstructionalText;

	//	Only apply the WAI-ARIA Roles and States for FF 3 and IE 8 since those
	//	are the only browsers that currently support ARIA.

	if ((UA.gecko && UA.gecko >= 1.9) || (UA.ie && UA.ie >= 8)) {

		oActiveTab = oTabView.get("activeTab");

		//	Append some instructional text to the <H2>

		oTitle = Dom.get("tabview-title");

		sInstructionalText = oTitle.innerHTML;

		oTitle.innerHTML = (sInstructionalText + "<em id=\"tabview-description\">Press the space bar or enter key to load the content of each tab.</em>");

		//	Set the "aria-describedby" attribute of the <UL> with the role of "tablist"
		//	to the id of the <EM> inside the <H2>.  This will trigger the screen reader
		//	to read the text of the <EM> when the TabView is initially focused,
		//	providing some additional instructional text to the user.  (Currently this
		//	only works with the NVDA screen reader.)

		Dom.getChildren(oTabView.get("element"))[0].setAttribute("aria-describedby", "tabview-description");

		//	Append a live region to the TabView's root element that will be used to
		//	message users about the status of the TabView.

		oTabViewEl = oTabView.get("element");
		oLog = oTabViewEl.ownerDocument.createElement("div");

		oLog.setAttribute("role", "log");
		oLog.setAttribute("aria-live", "polite");

		oTabViewEl.appendChild(oLog);

		//	"activeTabChange" event handler used to notify the screen reader that
		//	the content of the Tab is loading.

		oTabView.on("activeTabChange", function (event) {

			var oTabEl = this.get("activeTab").get("element"),
				sTabLabel = oTabEl.textContent || oTabEl.innerText,
				oCurrentMessage = Dom.getFirstChild(oLog),
				oMessage = oLog.ownerDocument.createElement("p");

			oMessage.innerHTML = "Please wait.  Content loading for " + sTabLabel + " property page.";

			if (oCurrentMessage) {
				oLog.replaceChild(oMessage, oCurrentMessage);
			}
			else {
				oLog.appendChild(oMessage);
			}

		});	

		//	"dataLoadedChange" event handler used to notify the screen reader that
		//	the content of the Tab has finished loading.

		var onDataLoadedChange = function (event) {

			var oTabEl = this.get("element"),
				sTabLabel = oTabEl.textContent || oTabEl.innerText,
				oCurrentMessage = Dom.getFirstChild(oLog),
				oMessage = oLog.ownerDocument.createElement("p");

			oMessage.innerHTML = "Content loaded for " + sTabLabel + " property page.";

			if (oCurrentMessage) {
				oLog.replaceChild(oMessage, oCurrentMessage);
			}
			else {
				oLog.appendChild(oMessage);
			}

		};

		oTabView.getTab(0).on("dataLoadedChange", onDataLoadedChange);
		oTabView.getTab(1).on("dataLoadedChange", onDataLoadedChange);
		oTabView.getTab(2).on("dataLoadedChange", onDataLoadedChange);
		oTabView.getTab(3).on("dataLoadedChange", onDataLoadedChange);

	}

})();

Further Reading and Resources

• Using WAI-ARIA Roles and States with the YUI Menu Control
• Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 W3C Specification
• WAI-ARIA Best Practices
• ARIA: Accessible Rich Internet Applications/Relationship to HTML FAQ
• Accessible DHTML
• Key-navigable custom DHTML widgets
• Firefox 3
• Internet Explorer 8 Beta 1
• NVDA Screen Reader
• Freedom Scientific JAWS Screen Reader
• GW Micro Window-Eyes Screen Reader
• An Introduction to Screen Readers
• Making Ajax Work with Screen Readers

Background

Although the capabilities of the browser have evolved significantly in recent years, the user’s perception of the browser hasn’t necessarily evolved with it. After the launch of Yahoo! Photos 3.0, I remember a friend of mine emailing me because she was having trouble viewing the large version of her photos. She was repeatedly clicking on each thumbnail without success. Eventually she figured out that she needed to double click on the thumbnails to view the full size image. Double clicking to open a folder or a file is, of course, a natural interaction on the desktop, but for years users were trained not to expect this interaction in the context of web applications.

Some users still don’t expect desktop-like interaction from web applications. I remember logging into my Yahoo! Mail not long ago and seeing checkboxes next to each message. I paused. What were these checkboxes, these artifacts of Web 1.0, doing in my Web 2.0 application? I had been using the new DHTML, Outlook-like version of Yahoo! Mail since its early beta and had become used to dragging and dropping in order to move and delete messages. But the reappearance of these checkboxes was another sign that not every user’s expectations had evolved with the capabilities of the browser.

As the browser has matured it has evolved it into a platform for rich application development, making it possible to deliver applications with a level of interactivity and visual fidelity of those found on the desktop. And while the browser is now a platform, it also continues to play its original Web 1.0 role of an application, a content viewer that enables users to surf all of the news sites, blogs, etc. scattered across the eclectic Web. But as the browser now plays these dual roles of being an application and an application development and delivery platform, how does this duality impact the user in terms of usability and accessibility? And what user-centric features and functionality can consumers expect of a browser, especially one battling with duality? I suspect that Opera’s answer to these questions is that not all users understand the modern browser’s dual role, and that is it necessary to render some fundamental things consistently across experiences within the browser.

Context Menus

Consider context menu functionality. By not implementing the contextmenu event, Opera does not allow frontend engineers to override the
default context menu provided by the browser; all other A-Grade browsers support this feature. What benefit could there be to not implementing the contextmenu event?

If some users perceive everything inside the scope of the browser as a web page, that influences the user’s expectation of what functionality will be surfaced in a context menu. Over the years many users have come to expect that raising a context menu in the scope of a browser will surface browser-centric functionality relative to HTML content (i.e. “Open Link in New Window”), rather than functionality of the web application running within the browser. Therefore, providing a custom context menu for a web application might not be expected or seen as helpful for users who have come to rely on functionality in the browser’s context menu.

The downside is that, by not allowing the developer to provide custom context menu implementations (such as those provided by the YUI Menu Control), Opera is in a small way preventing the user from understanding the browser as a platform for rich application development.

Focus

Focus could be considered as sacred as the context menu. Knowing what element has focus is fundamental to keyboard accessibility. And while most modern browsers support customization of the rendering of focus, is it a good idea to do so? The presentation and behavior is of HTML is now so completely customizable via CSS and JavaScript that the user experience can differ drastically across sites and applications on the web. Keeping something as fundamental as focus consistent means one less thing the user has to re-learn when navigating the across the web. Consider the following example:

Example 1: Anchor Elements (The Good)

	Focused anchor in Opera 9.5 (Mac)
	Focused anchor styled as a button in Opera 9.5 (Mac)

This example illustrates how the focused state of an anchor element is rendered consistently in Opera regardless of how it is styled. This consistency can be considered helpful to the user in that the familiarity of the focus outline conveys the element’s role. Therefore, the user knows what to expect when the element is clicked regardless of how it is styled. However, as illustrated in the following example, this benefit breaks down a little as the focus model for buttons isn’t the same as it is for anchor elements.

Example 2: Buttons (The Bad)

	Focused, unstyled button in Opera 9.5 (Mac)
	Focused, styled button in Opera 9.5 (Mac)

This example illustrates a potential flaw in Opera’s rendering of focus in version 9.5: unlike anchor elements, unstyled and styled buttons get two different renderings of focus, both of which are completely different, and different from the focus style applied to anchor elements. So, in Opera 9.5 there are three different focus implementations for the user to learn: the system default, the Wii-style focus and the dotted border. Compare Opera’s focus implementation to that of Safari or Internet Explorer, where by default focus is rendered consistently across elements of various types.

Opera	Safari	Description
		Focused, unstyled acnhor
		Focused anchor styled as a button
		Focused, unstyled button
		Focused, styled button

Since the default implementation of focus can be customized in other browsers, perhaps Opera users still fair better since learning Opera’s three, fixed focus models is ultimately better than having to learn potentially infinitely more. That said, if Opera is going to prevent customization of focus in the interest of usability and accessibility, they could further improve the user experience by providing a consistent implementation of focus across elements. As it stands in Opera 9.5, the following mixed styles can appear together, presenting a confusing set of visual cues:

Example 3: Mixed types together (The Ugly)

	Focused anchor styled as a button in Opera 9.5 (Mac)
	Focused, styled button in Opera 9.5 (Mac)

As illustrated by the first and second examples, Opera has three different, yet fixed implementations of focus. While Opera’s implementation of focus can be considered good insofar as the user only has a limited number of focus models to learn, it might also be considered bad in that it makes it harder to provide a consistent user experience within a single site or web application. For example, if you wanted to place an anchor and button next to each other in a toolbar, but style them consistently so that they both look like buttons, each would still render focus differently in Opera, leaving the user to wonder how the difference is significant.

Conclusion

In Opera designers and developers lose a degree of customization, but the user gains a slightly more consistent browsing experience. In some ways this consistency benefits the user in that fundamental interactions like focus and context menus remain the same regardless of the site or web application in use. However, by limiting certain types of customization designers and developers will find it just a bit harder to provide a consistent user experience within their site or application and to train the user to expect more from Web 2.0.

Chad at 2tbsp.com wrote up a nice tutorial last week outlining some practical fundamentals with respect to writing "unobtrusive JavaScript." His example implements a standard rollover, beginning with bad-old-days obtrusive scripting, migrating to unobtrusive scripting, and concluding with an unobtrusive script that leverages YUI’s Event Utility for event attachment and the Dom Collection’s getElementsByClassName, addClass and removeClass for class management.

Click through for his functioning example.

Of course, Chad just means this as an example of some of the practical points involved in unobtrusive scripting. Others have looked at the problem more encyclopedically — for a more ambitious (and not YUI-related) analysis of the paradigm, check out Christian Heilmann’s "The seven rules of Unobtrusive JavaScript".