Accessibility + YUI – creating accessible forms

This presentation was created for the YUI Conference, November 2013 by Sarbbottam and Ted Drake. Sample code is available at GitHub Bruce Lee toy photos courtesy [CC] images by Shaun Wong on Flickr. Watch the full presentation (includes closed captions):


You can also view the slides:

Accessibility + YUI

Sarbbottam | Ted Drake YUI Conf 2013

“Mistakes are always forgivable, if one has the courage to admit them.”
― Bruce Lee

1:6 Medicom Bruce Lee Inaccessible web sites are usually caused by ignorance rather than bad intentions. This presentation will introduce what is needed for accessibility and how Sarbbottam used ARIA, JavaScript, Progressive Enhancement, and semantic HTML to create a truly accessible and dynamic form. This will help you with your projects as well.

  • Perceivable
  • Operable
  • Understandable
  • Robust

The WCAG 2.0 accessibility specifications focus on the user’s experience. It distills this to 4 key factors. Essentially, the user needs to know:

  • what is on the page
  • be able to focus on the content
  • interact with the objects
  • the product should work with all combinations of browsers, devices, and assistive technology.

ARIA Today

Action

Now that we have the basics for accessibility, let’s look at how Sarbottam created a visually dynamic form that provides ample feedback for screen reader users. This form includes:

  • Progressive enhancement (works without javascript)
  • Everything is keyboard accessible
  • Works in multi-language/direction/keyboard

Let’s look at how a screen reader interprets our sample form. Watch for the following elements in this video:

  • Each form input has clearly defined label, state, and properties, i.e required.
  • The screen reader lets the user know how to interact with dropdown components
  • Screen changes are announced to the user.

Drop Down

This drop down button uses background images for the flag and triangle. The only text node is the country code value. But is this enough for a user? The drop down updates the button’s aria-label to let the user know the button’s intention. Further, after the user has chosen a country, the aria-label is updated to show it’s selected value.

country code dropdown buttonWhat is this button?

This button includes a flag, a triangle, and the text “+852”. The flag and triangle are using spans with background images. What does the +852 mean? How can the user know exactly what this will do?

<a
    href="#foo"
    role="button"
    aria-haspopup="true"
    aria-label="Hong Kong (+852) Country Code for optional recovery phone number">
        <span class="flag-hk"></span>&nbsp;
        <span class="drop-down-arrow-container">
            <span class="drop-down-arrow"></span>
        </span>
        &nbsp;+852
</a>

Many times people assume their background image is providing enough information. However, background images provide no context for the screen reader or voice recognition user. This drop down button is clearly labeled with the country name, the phone number extension, and the context (optional phone number). Further, the user knows this will generate a menu via the aria-haspopup=”true” attribute. The aria-label attribute is updated when the user selects a new value.

This video shows how the drop down button is announced as a pupup button with the full information. This interaction uses onkeydown to grab the arrow keys. onkeypress was exact character code of the key pressed. This was a problem with international keyboards. Escape key closes the drop down and is announced as the help text. See the aria practices: #focus_tabindex

Live Regions

ARIA live regions trigger screen readers to announce content when it changes on the screen. This could be when an object is given display:block, when content is inserted via innerHTML, or similar moments.

<p
    id="password-validation-message"
    aria-live="polite"
    aria-atomic="false"
    aria-relevant="all">
</p>

The password field connects to a paragraph that displays the password’s strength with aria-live=”polite”. This paragraph is empty when the page loads, but content will be inserted via JavaScript as the user creates their password. This means the new content will be announced after the user stops typing. Use assertive to interrupt the user. Nothing is announced while it is empty.

<p
    id="password-validation-message"
    aria-live="polite"
    aria-atomic="false"
    aria-relevant="all">
        Password must contain 8 characters.
</p>

The paragraph now includes text. This will be announced when the user pauses. ARIA live regions can be triggered via innerHTML content changes.

<p
    id="password-validation-message"
    aria-live="polite"
    aria-atomic="false"
    aria-relevant="all">
        Not bad, but you can make it better.
</p>

Every time the content changes, the user will be notified. You are already doing the presentation changes, the ARIA attributes just surface that content to the assistive technology.

This video shows how the password strength indicator is announced as the user enters their password.

Username Suggestions

autofill suggestions for user name

The username suggestions drop down uses ARIA to define the label and possible error messages. The suggestions have the menu role. Using live regions, a hidden div is used to surface suggested usernames as the user arrows through the choices.

<input
    type="text"
    id="user-name"
    autocomplete="off"
    aria-required="true"
    aria-describedby="validation"
    placeholder="Username"
    aria-labelledby="user-name-label">

The username text input turns off HTML5 autocomplete, uses aria-required for required status, aria-describedby points to potential error message, and aria-labelledby points to the label.

<p class="clipped"
    id="suggestions-read-out-container"
    aria-live="polite"
    aria-atomic="false"
    aria-relevant="all"></p>

The class hides this paragraph visually. aria-live forces the changes to be announced immediately, aria-atomic announces changed content, not the entire paragraph each time, aria-relevant announces all additions and removals.

This JS snippet shows how the content is inserted into the live region via innerHTML.

highlightSuggestion : function(suggestion) {       
    var readOutText = suggestion.get('innerHTML');       
    suggestion && suggestion.addClass('suggestions-hovered');  
     
    if(this.selectedIndex === this.list.length - 1) {         
        readOutText += this.endOfsuggestionsMessage;       
    }  
     
    this.suggestionsReadOutContainer.set('innerHTML', readOutText);     
},
<p
    class="clipped"
    id="suggestions-read-out-container"
    aria-live="polite"
    aria-atomic="false"
    aria-relevant="all">
        bruce.ninjamaster.lee
    </p>

This video shows how the username suggestions give the user information on available options and how to navigate

Validation

This form includes some basic form validation. When an input has been defined as invalid, we will add the aria-invalid=”true” attribute

<input
    type="text"
    aria-required="true"
    aria-describedby="name-message"
    placeholder="First name"
    aria-labelledby="first-name-label">
<p
    id="name-message"
    aria-live="polite"
    aria-atomic="false"
    aria-relevant="all">
    </p>

The input is connected to the error message container via aria-describedby. The paragraph container has aria-live=”assertive” to announce the error message when it is populated.

<input
    type="text"
    aria-required="true"
    aria-describedby="name-message"
    placeholder="First name"
    aria-invalid= "true"
    aria-labelledby="first-name-label">
<p
    id="name-message"
    aria-live="polite"
    aria-atomic="false"
    aria-relevant="all">
        Enter Name
</p>

Add aria-invalid=”true” to the input when it is defined as invalid. The error message will be announced as soon as it is populated due to the aria-live attribute. The error message will also be announced when the user places focus in the input.

This video shows the First and last name inputs. The initial focus announces the placeholder, label, and the required state. It also shows the error state inputs are announced as invalid and the error message is read as the help text. NVDA and JAWS on windows will announce the error message without the delay.

Yahoo User Interface Library

Accessibility is built into all YUI widgets. All YUI widgets include ARIA, Keyboard accessibility, and HTML best practices. Use these with confidence. Please note: 3rd party components within the gallery may not be accessible.

Yahoo! to downgrade IE6 in 2011

Yahoo User Interface LibraryYahoo! introduced the Graded Browser Support grid years ago to give developers a guideline on what browsers deserved the greatest amount of resources for debugging, hacking, and development. This has been well received amongst the developer community as a justification for not dwelling on obscure browsers, such as IE5.5 for mac. This has made our code cleaner and easier to maintain as the browser-specific hacks are no longer needed.

Yahoo just announced the GBS change we’ve all been waiting for. IE6 will be downgraded to a C-status browser in Q1, 2011. This means I can finally upgrade my own laptop to IE8! This means we can focus on building for the future and not the past. Excuse me as I hyperventilate over the joy.

Internet Explorer 6: We are forecasting the transition of Internet Explorer 6 from A-grade to C-grade in the next GBS update. The calculus here is simple: The proliferation of devices and browsers on the leading edge (including mobile) requires an increase in testing and attention. That testing and attention should come from shifting resources away from the trailing edge. By moving IE6 to the C-grade, we ensure a consistent baseline experience for those users while freeing up cycles to invest in richer experiences for millions of users coming to the internet today on modern, capable browsers. Note: This forecast should not be taken as an indication that IE6 users will see an abrupt change in their experience of Yahoo! websites in Q1 2011; the change in philosophy toward IE6 will be reflected in new development and products and applied in ways that make sense based on product needs.
Graded Browser Support Update: Q4 2010 – Eric Miraglia and Matt Sweeney, Yahoo! Developer Network

ARIA support with the YUI library

AJAX and DHTML have made web sites more interactive and easier to use. At least for visitors who are not using a screen reader. Screen reader users have to struggle with pages that lose focus, change without prompting the user of new data, and much more. However, there are many developers working on solutions to this problem.

Todd Kloots, of the Yahoo User Interface group was one of the first to develop accessible javascript libraries with the YUI menu package. He just published a blog post on the YUI web site about adding ARIA support to the YUI tab package. This information could also help you add this functionality to your existing YUI-based applications.

Here’s how Todd describes the goal

The YUI TabView Control is built on a strong
foundation of semantic markup that provides users with some basic accessibility. But while TabView looks like a desktop tab control, screen readers don’t present it as an atomic
widget, leaving users to figure out how the various HTML elements that compose a TabView relate to each other. However, through the application of the WAI-ARIA Roles and States, it is possible to enhance TabView’s accessibility such that users of screen readers perceive it as a desktop tab control.

Enhancing TabView Accessibility with WAI-ARIA Roles and States – Todd Kloots

The following video shows how this approach works with Firefox and a screen reader.

Related articles