YUI Theater — Todd Kloots: “Building Accessible Widgets with YUI 3″

November 23, 2009 at 8:39 am by Eric Miraglia | In Accessibility, YUI Theater | No Comments

YUI engineer Todd Kloots speaks at YUICONF 2009, held at the Yahoo! HQ in Sunnyvale; October 28, 2009.

We wrap up YUI Theater coverage of YUICONF 2009 with a talk from Todd Kloots (@toddkloots) on the accessibility features of YUI 3: “Building Accessible Widgets with YUI 3.” Todd covers YUI’s support for keyboard handling, focus styling and management, ARIA roles and states, and much more. (Don’t miss Todd’s other YUICONF talk, “YUI 3 Sugar,” which is a great primer on other hidden gems in the library.)

If the video embed below doesn’t show up correctly in your RSS reader of choice, be sure to click through to watch the high-resolution version of the video on YUI Theater; the downloadable version is much smaller, optimized as it is for iPods, iPhones, and other handheld devices.

The Full Roster of YUICONF 2009 Videos on YUI Theater:

Subscribing to YUI Theater:

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI’s Todd Kloots in London for Accessibility/ARIA Tech Talk on Nov. 17

September 17, 2009 at 9:16 am by Eric Miraglia | In Accessibility, Development | No Comments

Yahoo! accessibility specialist Todd Kloots will be in London in November for a tech talk hosted by Skills Matter. The talk, “More Accessible User Interfaces with ARIA,” will offer practical tips and design patterns for using ARIA to create accessible user interfaces that work across all of the various combinations of browsers and assistive technology that support ARIA.

The event is free; you can register on the Skills Matter website.

If you can’t wait until November to start diving into ARIA, Todd has you covered with a good library of blog posts and tech videos on the subject.



Todd Kloots: "Developing Accessible Widgets Using ARIA" @ Yahoo! Video

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

ARIA Made Easier With YUI 3

August 3, 2009 at 1:24 pm by Todd Kloots | In Accessibility, Development | 2 Comments

As mentioned in my talk Developing an Accessible Web 2.0 Widget Framework, one of the goals of YUI 3 is to make it easier for developers to build accessible user interfaces. To that end we’ve taken accessibility into consideration from the very start while building YUI 3, and the recent YUI 3.0.0 beta 1 release introduces several new additions that make it easier for developers to build ARIA-enabled widgets.

ARIA Attribute Support Added to Node

The Node Utility is YUI 3’s primary interface for interacting with the DOM, and it provides not only an abstraction model but built-in support for CSS Selector queries as a means of accessing HTML elements. Support for ARIA attributes has been added to the Node interface in the YUI 3.0.0 beta 1 release, allowing developers to use the expressive power of CSS Selector queries to apply and manage an element’s ARIA roles and states and properties.

Apply any of the ARIA attributes via Node’s set method. For example, to apply the role of toolbar to a <div> with an id of “toolbar”: 


YUI().use('node', function(Y) {
    var node = Y.get('#toolbar').set('role', 'toolbar');
});

In addition to Node’s built-in support for CSS selector queries, it also supports chaining and the ability to set multiple attributes on a single Node. When used together, these features of Node make it especially easy to apply the ARIA roles, states, and properties when building DHTML widgets with a large subtree.

For example, when building a menubar widget it is necessary to apply a role of menubar to the root DOM element containing the menubar, and the role of menu to the root DOM element containing each submenu. Additionally, as each submenu is hidden by default, the aria-hidden state will need to be applied to each submenu as well. The Node interface makes it possible to do all of this in one line of code: 


YUI().use('node', function(Y) {
    Y.get('#rootmenu').set('role', 'menubar').queryAll('.menu').setAttrs({ role: 'menu', 'aria-hidden': true });
});

Keyboard Support with the New Focus Manager Node Plugin

To work, ARIA requires developers provide keyboard access for widgets, since users of screen readers rely on the keyboard to navigate web sites and applications. 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 discretely 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.

The Focus Manager Node Plugin, which is available as of the YUI 3.0.0 beta 1 release, makes it easy to define a Node’s focusable descendants, define which descendant should be in the default tab flow, and define the keys that move focus among each descendant. Additionally, since the CSS pseudo class :focus is not supported on all elements in all A-Grade browsers, the Focus Manager Node Plugin provides an easy, cross-browser means of styling focus.

New ARIA Examples

For YUI 3.0.0 beta 1 we’ve also added a handful of examples that demonstrate the power of the Focus Manager Node Plugin to implement keyboard support to existing widgets and exercise Node’s new ARIA-related APIs.

Developers wishing to experience the benefits that ARIA provides can download the open-source NVDA Screen Reader and Firefox to test each example themselves. Alternatively, I’ve made screencasts of each example running with NVDA and Firefox.

YUI 3 Beta 1 ARIA Toolbar Video


YUI 3 Beta 1 ARIA Toolbar @ Yahoo! Video

YUI 3 Beta 1 ARIA Menu Button @ Yahoo! Video

YUI 3 Beta 1 ARIA Tabview Video


YUI 3 Beta 1 ARIA Tabview @ Yahoo! Video

The Road Ahead

While YUI 3 is presently composed mostly of utilities, we are hard at work polishing our widget infrastructure and will soon begin building out widgets. With YUI 3 our goal is to make it as easy as possible to build accessible user interfaces, whether you are building a widget from scratch, or implementing one of ours. We think we’re off to a good start with ARIA support incorporated into the Node interface and the Focus Manager Node Plugin. So, I want to encourage developers to start using these interfaces, and to let us know what’s missing, what’s not working, and what it is.

Additional Resources

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

More Accessible YUI Grids Layouts with ARIA Landmark Roles

March 5, 2009 at 4:09 pm by Todd Kloots | In Accessibility, Development | 5 Comments

YUI Grids CSS has long been an important tool for developers wishing to create more accessible layouts. Through its support of source-order independent layouts, Grids enables control of the reading order of a page, allowing developers to place the most important content higher in the markup so that it can be quickly discovered by users of screen readers. However, while the role of each section of a Grid (e.g., navigation, main content, footer, etc.) is easily perceived through visual style and layout, it is not immediately perceived by users of screen readers because <div>s are inherently structural elements with no default semantic meaning.

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:


Example Page Using YUI Grids And ARIA Landmark Roles @ Yahoo! Video

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:

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.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Improving Accessibility Through Focus Management

February 23, 2009 at 10:05 am by Todd Kloots | In Accessibility, Development | 7 Comments

A core requirement for developers using ARIA is to provide keyboard access for widgets, as users of screen readers rely on the keyboard to navigate web sites and applications. A large part of providing keyboard access is managing focus of a widget’s descendants (e.g., buttons in a toolbar, tabs in a tablist, menuitems in a menu, etc.), and the W3C guidelines provide two different approaches for doing so. This article explains both approaches and provides some practical advice for choosing between them.

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: Screen capture of the focus menu from the second example running in Opera 9.6
  • 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.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

WebAIM Survey Shines Light on Screen Reader Usage

February 12, 2009 at 5:35 pm by Victor Tsaran | In Accessibility, Development | 2 Comments

“What you hear is what you see”

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.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Configuring Your Machine For Testing With A Screen Reader

December 30, 2008 at 4:32 pm by Todd Kloots | In Accessibility, Development | 13 Comments

When developing using the WAI-ARIA Roles and States, you need to test your code in a screen reader to ensure everything is working as you expect. As a follow up to my presentation on Developing Accessible Widgets with ARIA and in the interest of helping other developers test their code, I thought I would provide some tips on how to configure your development environment for screen reader testing.

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. Screen shot of the JAWS 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. Screen shot of the Keyboard Manager dialog in JAWS .
  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. Screen shot of the Change Keystroke dialog in JAWS.
  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. Screen shot of the JAWS menubar.
  2. In the “Basic Settings” dialog, make sure the checkbox labeled “Automatically start JAWS” in not checked. Screen shot of the Basic Settings dialog in JAWS.

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. Screen shot of the Window-Eyes menubar.
  2. In the “Browse Mode Hot Key Definitions” dialog, scroll down to the item named “Browse Mode” in the scrollable “Keys” list. Screen shot of the Browse Mode Hot Key Definitions dialog in Window-Eyes.
  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. Screen shot of the Window-Eyes 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. Screen shot of the Window-Eyes menubar.
  2. Select the “Off” item. Screen shot of Mouse Voice dialog in 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. Screen shot of the Window-Eyes menubar.
Disabling Window-Eyes From Starting Automatically
  1. Open the “Startup Options” dialog by selecting “File” -> “Starup Options…” in the Window-Eyes application menubar. Screen shot of the Window-Eyes 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”.
    Screen shot of the Startup Options dialog in 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. Screen shot of the Window-Eyes 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 Screen shot of the NVDA welcome dialog
  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. Screen shot of the NVDA system tray context menu.
    2. In the “General settings” dialog, uncheck the checkbox labeled “Warn before exiting NVDA”. Screen shot of the General settings dialog in NVDA.
    3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu. Screen shot of the NVDA system tray 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. Screen shot of the NVDA system tray context menu.
  2. In the “Mouse settings” dialog, uncheck both “Report text under the mouse” and “play audio coordinates when the mouse moves”. Screen shot of the Mouse settings dialog in NVDA.
  3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu. Screen shot of the NVDA system tray 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”. Screen capture of the contents of the appModules directory.
  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

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Next Page »
Hosted by Yahoo!

Copyright © 2006-2010 Yahoo! Inc. All rights reserved. Privacy Policy - Terms of Service

Powered by WordPress on Yahoo! Web Hosting.