Yahoo! User Interface Blog (YUIBlog) » Accessibility

Making Search Direct Accessible

Caridy Patino — Tue, 09 Aug 2011 04:44:01 +0000

A few months ago we launched the first beta release of Search Direct. This new product explores the concept of real-time feedback, instantly delivering answers to the user with each keystroke. Given the diversity of Yahoo!’s audience, we wanted to make Search Direct as accessible as possible. Initially, we believed that this would be an easy task since this product would be based on YUI 3, a JavaScript library with accessibility baked into its DNA. Contrary to my expectations as an engineer, this task turned out to be more difficult than we anticipated.

Introducing Search Direct

Although Search Direct is built from the ground up using YUI’s component infrastructure, its most visibly prominent interface is based on the YUI AutoComplete widget which includes many accessibility features right out of the box. Suggestions related to a particular query are displayed in this autocomplete implementation. Search Direct also features a content panel, a.k.a. the rich panel, where suggestion-related content is displayed. The intention of the rich panel is to provide a direct answer to the user when a suggestion from the autocomplete list is selected.

A new set of suggestions is displayed in the list on every keystroke, and the first suggestion is selected by default. This default selection is called a soft selection. Soft selections and subsequent interactions with the suggestion list dictate the content that is rendered into the rich panel. In reality, things are a bit more complicated (performance optimizations, additional cache layers, etc), but for the sake of simplicity we can assume that this is the common workflow.

Accessibility features

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

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

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

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

Searchbox
Submit button
Suggestion list
Rich panel

Sounds like a breeze, right? Well, let’s take a step back.

The problem

What we have here are two asynchronous processes — one of them for updating the suggestion set and the other one for retrieving corresponding answers — and they’re both really fast. We’re talking about 250ms end to end. Since the interface is changing at such a rapid pace, keeping track of everything can be difficult for a screen reader user. It gets an order of magnitude more complicated when updates happen in an asynchronous, near real-time manner. Because the screen reader was being notified of every change in the interface, the resulting chatter made it difficult to make sense of what was going on.

Lacking an acceptable solution, we started collaborating with Yahoo!’s resident accessibility guru, Victor Tsaran (@vick08) to try and come up with something better.

The first time we watched Victor interact with Search Direct, it was immediately clear to me that a majority of his focus was on the rich panel instead of the suggestion list. This was a surprise for me, as we viewed the list as the “source of truth”. During one of our sessions, we had a stroke of luck when we happened to disable all the accessibility features of the list. As soon as the noise introduced by the list was cut out, Search Direct started to make sense to Victor!

How users of screen readers perceive Search Direct

After realizing that we were trying to solve the wrong problem, we went back to the original user story: “As a user, I can get an answer as I type”. Getting the answer across to the user was the priority. After redefining the problem, we concentrated our accessibility efforts on an implementation where the screen reader prioritized the rich panel content over the suggestion list.

For example, if the user types "miami wea", the screen reader will tell them two things:

10 suggestions.
WEATHER MIAMI, FL. TODAY, Scattered Thunderstorms, 89°F 77°F. TOMORROW, Isolated Thunderstorms, 90°F 74°F…

It will then continue reading out the rest of the rich panel content. The user doesn’t need to know all 10 suggestions up front, every time the list updates. If they do want to know, the information is readily accessible via keyboard navigation.

To ensure that the suggestion list is adding value to the experience, we make sure that the first phrase in the rich panel is closely related to its corresponding suggestion. For instance, based on the previous example, "weather miami" is the first phrase in the rich panel for the suggestion: “miami weather”.

Victor Tsaran, of the Yahoo! Accessibility Lab, shows how it works on FireFox with the NVDA screen reader:

The screen reader experience for our application is easier to follow since we now only focus on the following two visual components:

Searchbox
Rich panel

Changes to the autocomplete list as a whole are no longer tracked, and the submit button is ignored since the user can always hit enter for the current query or use a keyboard shortcut (tilda access key: [control, alt or shift] + ~) to switch between the input element and the rich panel. These keyboard navigation options are revealed to the user when the searchbox is acknowledged by the screen reader.

From an engineering perspective, this change greatly simplified things. The amount of DOM manipulation in the most active component was drastically reduced, improving the overall performance of Search Direct. Here is an example of the implementation:

function SDAAria () {
    var node = this._liveRegion = Y.Node.create('');
    // Create the ARIA live region...
    Y.one('body').append(node);
    // listening for aria:live messages to update the live region
    this.on('aria:live', this._handlerMsg, this);
    // listening for gossip:refresh to announce how many suggestions
    this.on('gossip:refresh', this._handleGossipRefresh, this);
}
SDAAria.ATTRS = {
     strings: {
         valueFn: function () {
             return Y.Intl.get('sd-aria');
         }
     }
};
SDAAria.prototype = {
    _ariaSay: function (stringId, subs) {
        var message = this.get('strings.' + stringId) || '';
        this._liveRegion.setContent( subs ? Y.Lang.sub(message, subs) : message );
    },
    _handlerMsg: function (e) {
        if (e.id) {
            this._ariaSay(e.id, e.subs);
        }
    },
    _handleGossipRefresh: function () {
        var size = this.get('suggestions').size();
        this._ariaSay( (size > 0 ? 'SUGGESTIONS' : 'NO_SUGGESTIONS'), {
            n: size
        });
    }
};

Lessons learned

When creating an accessible interface, it’s important to ask the right questions. Making every bit of your application accessible may not be the right approach.

Request early feedback from users of screen readers — don’t assume that you have your bases covered until you get some user feedback. Utilizing every tool and feature at your disposal may not have the intended effect.

Users of screen readers may have difficulty keeping track of real-time updates, especially if screen readers are bombarded with notifications. In these scenarios, less can be more. Identify and focus on what is important for the user instead of trying to replicate the raw experience of the application for the screen reader.

About the author: Caridy Patiño, Principal Frontend for Yahoo! Search Direct. He has been a longtime YUI Contributor and creator of Bubbling Library YUI Extension, as well as guest blogger at YUIBlog.com sharing some of his extensive experience building high performance web applications. Loading strategies, event-driven architectures and SSJS are some of the subjects where Caridy spends most of his time these days.

Developing an Accessible Star Ratings Widget

Thierry Koblentz — Tue, 24 Aug 2010 17:00:41 +0000

In a hurry? Skip to the demo page.

Many ecommerce sites, social networking services, and online communities include rating or assessment features. Soliciting people’s opinion has even become a business model; there are now sites dedicated to rating products, services, businesses, and more.

The most common interface used to display votes is the “star rating system,” in which a particular number of points (often expressed as stars) is assigned to an item by each reviewer. We find this model on many sites, from Amazon to Yelp.

Figure A. Star rating examples from Amazon and Yelp.

As Figure A shows, both visual interfaces are similar, but what makes these two solutions interesting is their markup base. One relies on , the other on .

You might think that most rating systems would be based on some markup proven to be semantic and "operational" across many User Agents — that is, that rating systems would be based on a specific set of HTML elements and attributes to which one applies behavior and style via JS and CSS. That would make sense, but it is far from the truth. When it comes to markup, authors try just about everything:

and more…

The case of Microformats

Before presenting a few image-based techniques to mark up ratings, I think it is worth mentioning a basic and straightforward approach (from Microformats) that uses characters:

***

Pros: It is straightforward and semantic.; The markup is minimal.; The method is not reliant on CSS.; The method is not reliant on images.; There is no HTTP request.
Cons: It is impossible to represent half values (i.e. 3.5 stars); It "works" only with asterisks ("star rating").; Screen-readers, by default, do not expand abbreviations (which may not be a big deal in this case).

Note: I use "*" rather than ★ (★) because screen-readers (at least JAWS and NVDA) seem to ignore html entities.

Markup to display image-based ratings

When it comes to display images, authors have many options.

One image per rating

Using a single image:

One star
Two stars
Three stars
Four stars
Five stars

Pros: Using one image per rating is straightforward and semantic.; The method is not reliant on CSS.; Minimal markup.
Cons: It creates many HTTP requests as there are many different images.; On top of the performance issue, it can be a maintenance nightmare as authors have to deal with more assets (images to create, to push to a CDN, to modify when site colors change, etc.).; Text selection is not possible in Opera (at least in version 9.52) as the alternate text is ignored

One image per unit

From the whatwg‘s working draft:

One star
Two stars
Three stars
Four stars
Five stars

Pros: Using two img elements per rating diminishes the number of HTTP requests.; The method is not reliant on CSS.
Cons: In Opera, when images are disabled, alternate text is not selectable, and (in small-screen view) that text is rendered with a border which makes it less legible.

Note that this is taken from a controversial working draft. In my opinion, this method is not acceptable because the alternate text does not describe the image accurately and succinctly. Besides, if the basis of this approach is that these images represent content, then why leave some of them with no alt text?

On Ajaxian, for example, the author is using alternate text with every single image, which makes a lot of sense if he considers that each one is content:

In any case, using as many images as there are stars versus using a single element (an img or something else) has the main advantage of facilitating voting mechanisms – where a user selects one of the stars to cast his vote. So we should keep this in mind…

A sprite for background images

The following technique is a adaptation of a strategy originally implemented by developers at Yahoo! Music:

Markup

1 of 5
2 of 5
3 of 5
4 of 5
5 of 5

CSS

.stars {
  background: transparent url(img/sprite.png) no-repeat;
}
.rating {
  font-size: 0;
  height: 19px;
  overflow: hidden;
  vertical-align: middle;
  width: 96px;
  display: block;
}
.r1 { background-position: -385px 0; }
.r2 { background-position: -288px 0; }
.r3 { background-position: -192px 0; }
.r4 { background-position: -96px 0; }

One star: 1 of 5
Two stars: 2 of 5
Three stars: 3 of 5
Four stars: 4 of 5
Five stars: 5 of 5

Pros: This method requires a single HTTP request as it relies on a single sprite image.; Minimal "foot print".
Cons: Content is not revealed with images off.; Nothing shows when the page is printed (a print stylesheet could take care of this issue).; In Opera, the high contrast stylesheet makes all the stars disappear; the same is true in High Contrast Mode Optimization.; Text selection is possible, but it’s not obvious (via highlighting).

A sprite in the markup

This approach is based on the TIP method, which uses a sprite image as an element rather than a background image:

Markup

1 out of 5
2 out of 5
3 out of 5
4 out of 5
5 out of 5

CSS

.rating {
  position: relative;
  height: 1.6em;
  width: 8.1em;
  overflow: hidden;
  vertical-align: middle;
  display: block;
}
.rating img {
  position: absolute;
  width: 40.5em;
  height: 1.55em;
  top: 0;
  border: 1px solid #fff;
}
.r1 img { right: 0; }
.r2 img { left: -24.4em; }
.r3 img { left: -16.2em; }
.r4 img { left: -8.1em; }

One star: 1 out of 5
Two stars: 2 out of 5
Three stars: 3 out of 5
Four stars: 4 out of 5
Five stars: 5 out of 5

Pros: This method requires a single HTTP request.; This technique is the only one of the four methods above that reveals content when Firefox users select "hide images" or "make images invisible" (from the developer’s toolbar).; When images are unavailable a red "x" appears only in the highest rating (i.e. 5 out of 5) instead of in each one as it is the case with other solutions that rely on img elements.
Cons: The display of images is reliant on CSS.

It is worth noting that unlike other Image Replacement techniques, this method allows:

images to scale depending on text-size settings.
images to be printed.
alternate text to be easily selected as the whole image appears highlighted (Firefox).
the image to not disappear in a high-contrast setting/stylesheet.
alternate text selection in Opera (when images are disabled).
borderless alternate text in Opera’s small screen view.

Markup to cast votes

Starting with a native mechanism

To cast votes, we need a low-level voting mechanism that allows simple user selection and submission. For this, we can rely on using a form with labels and controls:

Markup


  Rating
  1/5
  2/5
  3/5
  4/5
  5/5

Result

Adding breaks and whitespace

For better legibility, we add and whitespace.

Markup

  Rating
   1/5

   2/5

   3/5

   4/5

   5/5

Result

Introducing the sprite image in the markup

For this solution, we are using a smaller sprite than the one in the example above. It is now composed of two single stars (“on” and “off”).

We place img elements inside the labels. We assume they will have no value without CSS support, thus we "hide" them by setting specific dimensions via their width and height attributes. Note that using 0 with both attributes would show a broken image in some UAs.

Note that with the above markup, we can expect (in most browsers) field selection via label selection.

Considering Accessibility

Unfortunately, as is, this markup creates issues in at least two screen-readers: JAWS and NVDA (see test case for these bugs). The problem is related to the use of a title attribute and an empty string for alternate text.

The workaround to not confuse screen-reader users is to use "stars" as alternate text (alt) and use JavaScript to insert title on mouseover.

Better Markup

  Rating
   1/5

   2/5

   3/5

   4/5

   5/5

Result

Styling

Giving dimensions to the image via CSS

We use em to allow the image to grow or shrink depending on font-size.

Markup

Unchanged

CSS

img {
  width:2.8em;
  height:1.4em;
}

Result

As you can see already, clicking on an image selects the corresponding radio button. There is no need for scripting as implicit labeling produces this behavior (except in IE).

Removing the image from the flow

Styling the label with position:relative and the image with position:absolute with top/left values is enough to hide input and text inside the labels.

Markup

Unchanged

CSS

label {
  position:relative;
}
img {
  width:2.8em;
  height:1.4em;
  position:absolute;
  top:0;
  left:0;
}

Result

Displaying one star per label

We style the label so its dimensions match the height and width of a single star.

Markup

Unchanged

CSS

label {
  position:relative;
  height:1.4em;
  width:1.4em;
  overflow:hidden;
  display:block;
}
img {
  width:2.8em;
  height:1.4em;
  position:absolute;
  top:0;
  left:0;
}

Result

Displaying the stars horizontally

We remove the brs and we float the labels.

Markup

Unchanged

CSS

br {
  display:none;
}
label {
  position:relative;
  height:1.4em;
  width:1.4em;
  overflow:hidden;
  display:block;
  float:left;
}
img {
  width:2.8em;
  height:1.4em;
  position:absolute;
  top:0;
  left:0;
}

Result

Displaying the sprite image depending on rating

To set a "3 out of 5" rating, we apply the same class to the last two labels. This class will shift the position of the image inside the label.

Markup


Rating
 1/5

 2/5

 3/5

class="no_star"> 4/5

class="no_star"> 5/5

CSS

br {
  display:none;
}
label {
  position:relative;
  height:1.4em;
  width:1.4em;
  overflow:hidden;
  float:left;
}
img {
  width:2.8em;
  height:1.4em;
  position:absolute;
  top:0;
  left:0;
}
.no_star img {
  left:-1.4em;
}

Result

Not relying on image alone to display information

It’s important to offer an alternative to the display of stars in case images are not available. This is because labels and radio buttons are styled to be on top of each other. A simple solution is to move input and text off-screen (i.e. using text-indent:-999em) and apply a background color to the labels.

Markup

No change

CSS

br {
  display:none;
}
label {
  position:relative;
  height:1.4em;
  width:1.4em;
  overflow:hidden;
  float:left;
  background:teal;
  margin-right:1px;
  text-indent:-999em;
}
img {
  width:2.8em;
  height:1.4em;
  position:absolute;
  top:0;
  left:0;
}
.no_star {
  background:#ccc;
}
.no_star img {
  left:-1.4em;
}

Note:

text-indent also fixes a upwards jump of the image each time the controls get focus.
the right margin is to make sure background colors create squares and not rectangles (which would happen with adjacent labels sharing the same background color).

Result

Finishing touch

We use the pseudo-class :hover to create some rollover effect,
We hide the fieldset border,
We hide the legend,
We style the cursor.

Markup

Unchanged

CSS

br {
  display:none;
}
label {
  position:relative;
  height:1.4em;
  width:1.4em;
  overflow:hidden;
  float:left;
  background:teal;
  margin-right:1px;
  text-indent:-999em;
}
input {
  position:absolute;
  left:-999em;
  top:.5em;
}
img {
  width:2.8em;
  height:1.4em;
  position:absolute;
  top:0;
  left:0;
  cursor: pointer;
}
.no_star {
  background:#ccc;
}
.no_star img {
  left:-1.4em;
}
label:hover {
  opacity:.5;
  filter:alpha(opacity=50);
}
fieldset {
  border:0;
}
legend {
  text-indent:-999em;
}

Note: label:hover is ignored by IE6 and in Opera the background color bleeds through the images. In the demo page, instead of using opacity, I am using a different sprite that shows four states.

Result

Displaying the ratings without allowing user interaction

We can make the ratings "read-only" by adding disabled and checked attributes in the appropriate input fields.

Markup


  Rating
  disabled> 1/5

  disabled> 2/5

   3/5

  disabled> 4/5

  disabled> 5/5

CSS

The rule using :hover has been removed

h4>Result

Giving more thought to the process

At this point, it is possible to cast votes without script support, but sighted users have no clue about their selection. So we use JavaScript to:

give feedback to the user regarding his selection,
give keyboard users a visual clue while they navigate through the radio buttons.

At the same time, we take advantage of using a script to insert title attributes that will create "tooltips" when users hover over the labels/stars.

Because of the lack of feedback regarding selection without JavaScript, we style labels and form controls only if there is script support. To do so we use JavaScript to set a flag on the html element and then we create a rule based on descendant selectors containing that hook. If the flag is missing, that rule does not apply and elements are not styled.

This is the demo page, the final product. To see how this solution behaves according to various settings, you may want to use your favorite developer tools to increase text-size, break image paths, disable JavaScript, turn CSS off, and more…

Wrap up

Coming up with a "acceptable" solution requires to identify users’ needs, User Agents’ peculiarities, User Agents’ settings and more – which means extensive testing.

In this process, users’ feedback is essential because following best practices is not always a sure thing. For example, as mentioned earlier, setting no value for the alt attribute of the images within the labels seem to be the safe thing to do, but it turns out that it creates issues with at least two screenreaders (see test case).

Also, feedback from assistive devices’ users allows to ignore some validation error messages – as the one that the Firefox Accessibility Toolbar reports (according to http://bestpractices.cita.uiuc.edu/html/nav/form/).

The goal here was not to fix everything, though. Being able to cast votes without a pointing device was one of my priorities, but improving the look and feel of the solution in Opera when images are disabled is not something I consider essential.

The most interesting part of this "journey" was to make the solution accessible to many users under various conditions, addressing issues such as:

images off,
javascript off,
CSS off,
a combination of the above.

It is also nice to know that this technique relies on img elements rather than background images, which allows the stars to:

resize themselves according to the user’s settings,
show in high contrast mode,
be printed by default (unlike background images).

All of this comes without sacrificing performance, as this solution relies on this single sprite:

Late finding

I recently discovered the system Amazon has built for its voting page. It is quite interesting as they serve a different solution depending on script support. If there is script support, they use an image (interesting approach), if there is no script support they use radio buttons. In both cases, the solution is accessible to keyboard users, and this helps to maximize access to a feature that is a core differentiator for the Amazon platform.

Note that they do not use JavaScript to replace the radio buttons with a image ; instead, they use noscript elements in which table markup contains radio buttons.

"Out of the box" solutions

Dreamweaver^®: Spry Rating Widget
YUI: Star Rating Script for YUI; Star Rating script with YUI
JQuery: Half-Star Rating Plugin; jQuery Ajax Rater; Simple Star Rating System; 5 star rating system in PHP, MySQL and jQuery
WordPress: GD Star Rating System for WordPress; GD Star Rating; Star Rating for Reviews
Flash: 5 Star rating system component
Misc.: How a star rating should be; Starry widget 2

Special thanks

Special thanks to Victor Tsaran and Todd Kloots for their valuable feedback.

YUI Theater — Nicholas Zakas and Victor Tsaran: “Accessibility on the Yahoo Homepage (58 min.)”

Allen Rabinovich — Mon, 16 Aug 2010 20:53:52 +0000

In June, Yahoo! hosted a BayJax meetup dedicated to web accessibility. Nicholas Zakas, Yahoo! homepage developer, and Victor Tsaran, Yahoo! senior accessibility program manager, gave a talk on the process of making Yahoo!’s homepage highly accessible.

We apologize for the uneven audio levels: there were technical issues with the microphones that we unfortunately were only able to adjust towards the second half of the talk.

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.

YUI Theater — Dennis Lembree: “Making JavaScript Accessible (26 min.)”

Allen Rabinovich — Mon, 16 Aug 2010 20:46:09 +0000

In June, at the BayJax meetup on web accessibility hosted by Yahoo!, the accessibility expert Dennis Lembree gave a talk on the challenges of making JavaScript-enabled websites accessible.

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.

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

Eric Miraglia — Mon, 23 Nov 2009 16:39:23 +0000

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:

Douglas Crockford: The State and Future of JavaScript — Yahoo! JavaScript Architect Douglas Crockford discusses the recent ECMA5 development process and efforts to improve the language in the future.
Brendan Eich: ECMA Harmony and the Future of JavaScript — Brendan Eich, the creator of the world’s most popular programming language, talks about the struggle over the ES4 proposal and how it resulted in a specific set of proposals for ES5.
Luke Smith: Events Evolved — YUI engineer Luke Smith provides a deep introduction to the YUI 3 event system including its support for DOM events, event delegation, synthetic events, and custom events.
Todd Kloots: YUI 3 Sugar — YUI engineer Todd Kloots presents an indispensable introduction to YUI 3′s powerful suite of tools.
Isaac Schlueter: Solving Problems with YUI 3 — YUI engineer Isaac Schlueter works through a real-world use case of building YUI 3′s forthcoming AutoComplete widget.
Dav Glass: Contributing to YUI — YUI engineer Dav Glass introduces you to the YUI Gallery and steps through the process of making contributions to the YUI project.
Allen Rabinovich: YUI 3 Infographics — YUI engineer Allen Rabinovich discusses the YUI 3 Charts implementation, currently under development.
Reid Burke: Building YAP Applications with YUI — YUI engineer Reid Burke discusses the Yahoo! Application Platform and how you can use it, along with YUI, to reach Yahoo!’s vast audience.
Matt Sweeney: YUI 3 Performance — YUI architect Matt Sweeney reviews principles of high-performance web development and looks at how best to implement those principles in YUI 3-based projects.
Satyen Desai: A Widget Walkthrough — YUI engineer Satyen Desai provides a detailed tour of the YUI 3 widget subsystem.
Todd Kloots: Building Accessible Widgets with YUI 3 — YUI engineer Todd Kloots demonstrates the accessibility toolkit built into YUI 3.
Chad Auld: Introducing PHP Loader — Chad Auld of Yahoo! introduces the YUI PHP Loader, a flexible tool for loading modular JavaScript and CSS projects.
Eric Ferraiuolo: Web App Development with YUI 3 — Eric Ferraiuolo of Oddnut Software talks about the nuances of deploying real-world web applications using YUI 3.
Ron Adams: Automated Integration Testing with YUI Test, Selenium and Hudson — Yahoo! engineer Ron Adams discusses the creation of automated QA workflows that combine YUI Test, Selenium and Hudson to automate JavaScript unit tests.
Stephen Woods: Creating Beautiful Documentation with YUI Doc — Yahoo! frontend engineer Stephen Woods provides a guided tour to YUI’s documentation engine, YUI Doc. YUI Doc is language-agnostic and can be used to document a variety of project styles.
Matt Snider: Introducing the YUI 2.8.0 Storage Utility — Matt Snider, the lead frontend engineer for Mint.com (recently acquired by Intuit), contributed the YUI Storage Utility in the 2.8.0 release. In this session, he provides an overview of the Storage Utility’s features and the nuances of the various storage backends.
Luke Smith: Debugging in YUI 3 — YUI engineer Luke Smith discusses the fine art of debugging web applications, looking at general tools and techniques and providing a few specific hints about debugging in YUI 3.

Subscribing to YUI Theater:

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

Eric Miraglia — Thu, 17 Sep 2009 17:16:10 +0000

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

ARIA Made Easier With YUI 3

Todd Kloots — Mon, 03 Aug 2009 21:24:22 +0000

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 @ 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

More Accessible YUI Grids Layouts with ARIA Landmark Roles

Todd Kloots — Fri, 06 Mar 2009 00:09:43 +0000

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

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”:

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.

Improving Accessibility Through Focus Management

Todd Kloots — Mon, 23 Feb 2009 18:05:01 +0000

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:
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

WebAIM Survey Shines Light on Screen Reader Usage

Victor Tsaran — Fri, 13 Feb 2009 01:35:53 +0000

“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 ( 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.

Yahoo! User Interface Blog (YUIBlog) » Accessibility

Making Search Direct Accessible

Introducing Search Direct

Accessibility features

The problem

How users of screen readers perceive Search Direct

Lessons learned

Developing an Accessible Star Ratings Widget

The case of Microformats

Markup to display image-based ratings

One image per rating

One image per unit

A sprite for background images

Markup

CSS

A sprite in the markup

Markup

CSS

Markup to cast votes

Starting with a native mechanism

Markup

Result

Adding breaks and whitespace

Markup

Result

Introducing the sprite image in the markup

Considering Accessibility

Better Markup

Result

Styling

Giving dimensions to the image via CSS

Markup

CSS

Result

Removing the image from the flow

Markup

CSS

Result

Displaying one star per label

Markup

CSS

Result

Displaying the stars horizontally

Markup

CSS

Result

Displaying the sprite image depending on rating

Markup

CSS

Result

Not relying on image alone to display information

Markup

CSS

Result

Finishing touch

Markup

CSS

Result

Displaying the ratings without allowing user interaction

Markup

CSS

Giving more thought to the process

Wrap up

Late finding

"Out of the box" solutions

Special thanks

YUI Theater — Nicholas Zakas and Victor Tsaran: “Accessibility on the Yahoo Homepage (58 min.)”

Other Recent YUI Theater Videos:

YUI Theater — Dennis Lembree: “Making JavaScript Accessible (26 min.)”

Other Recent YUI Theater Videos:

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

The Full Roster of YUICONF 2009 Videos on YUI Theater:

Subscribing to YUI Theater:

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

ARIA Made Easier With YUI 3

ARIA Attribute Support Added to Node

Keyboard Support with the New Focus Manager Node Plugin

New ARIA Examples

YUI 3 Beta 1 ARIA Toolbar Video

YUI 3 Beta 1 Menu Button Video

Using the `activedescendant` Property

`activedescendant` Example

`activedescendant` Example Screen Cast

Best Practices for Using the `activedescendant` Property