Building Accessible Web Applications:
Challenges, Solutions, and the Future

Introduction

The Paciello Group, TPG Europe

• Accessibility Consultancy
• Software
• Web sites
• Web applications

Steve Faulkner

Technical Director: sfaulkner@paciellogroup.com

Hans Hillen

Accessibility Consultant: hhillen@paciellogroup.com

This course is divided in the following sections, grouped by the type of accessibility problems common to web application:

• Section 1: Introduction
• Section 2: Keyboard Accessibility
• Section 3: Labeling of controls
• Section 4: Dynamic Content
• Section 5: Custom Controls

• In order to achieve keyboard accessibility for your interface, all interactive controls must be perceivable, understandable and operable through the keyboard. This means:
  1. The controls must be able to receive uninterrupted focus.
  2. The controls must be part of a logical order, or easily reachable through the keyboard.
  3. The control must respond to the appropriate keystrokes.

• CSS can be used to automatically style focused elements

  a:hover, a:focus, a:active {
  
  color: white;
  
  background-color: black;	}
  
  

• Poorly supported in IE:
  • Need to use :active pseudo style.
  • Only works consistently for links.
  • If The focus pseudo styles don't work, use JavaScript instead:

    element.onfocus = highlightFocus;
    
    element.onblur= unHighlightFocus;
    
    ...
    
    addClassName(element, 'highlighted');
    
    removeClassName(element, 'highlighted');
    
    

• The "Tabindex" attribute makes the non-focusable focusable:
  • tabindex="0": Element becomes part of the tab order.
  • tabindex="-1": Element is focusable through scripting or mouse clicks (Example).
  • Advantages (using -1):
    • No cluttering of source or tab order: Event handles can deal with "sub focus".
    • Can force screen reader to announce relevant content.
  • Disadvantages:
    • Screen readers will not necessarily perceive element as interactive.
    • Default actions won't be mentioned.
    • Native key handlers won't work (e.g. Enter, Arrow keys).
    • Technically illegal (but supported by all major browsers).
  • Example: Sample Application Mockup.

• Key events
  • Have to be assigned for custom controls.
  • Must be consistent with desktop interfaces.
  • Make the control operable for keyboard users (including most AT users).
  • Have to provide the same functionality as the mouse event handlers do.
  • Must not conflict with existing browser keystrokes
    • For example, don't use the alt key, this is also used to open the browser's main menu.
    • Often difficult, as web apps are basically 'applications running inside an application (the browser)'.
• Always inform the user about your custom keyboard interface.

• Does every control need a label?
• Label Placement
• Implicit versus Explicit Association
• Use of the label element and title attribute
• Use of the first option element within a select element
• Multiple labels for a control
• Error messages
• controls within data tables
• form control groups
• custom controls

• • <input type="text" name="searchtext" />
    
    <input type="submit" name="mail" value="search mail" />
    
    <input type="submit" name="web" value="search the web" />
    
    

• Recommended

  • <input type="text" name="searchtext" title="Search mail or web" />
    
    <input type="submit" name="mail" value="search mail" />
    
    <input type="submit" name="web" value="search the web"
    
    title="search the web: opens in a new window" />
    
    

• Implicit Labels

  • label: <input type="text" size="30" name="uname" />
    
    <label></strong>label: <input type="text" size="30" name="uname" /></label>
    
    

• Explicit - Recommended

  • <label for="uname">label:</label>
    
    <input type="text" size="30" id="uname" name="uname">
    
    

• Hybrid

  • <label for="uname">label:
    
    <input type="text" size="30" id="uname" name="uname">
    
    </label>
    
    

• City choose a city Birmingham London Recommended

  • <label for="city">City</label>
    
    <select name="city" id="city">
    
    <option value="-1">choose a city</option>
    
    <option value="1">Birmingham</option>
    
    <option value="2">London</option>
    
    </select>
    
    

• name first name optional

  • <label for="multi3">name</label>
    
    <input type="text" id="multi3" name="multi">
    
    <label for="multi3">first name optional</label>
    
    

• name (first name optional) Recommended

  • <label
    
    for="multi4">name (first name optional)
    
    </label>
    
    <input type="text" id="multi4" name="multi">
    
    

• search criteria
• search criteria

  • .hidden {
    
    position: absolute;
    
    left: 0;
    
    top: -999em;
    
    width: 1em;
    
    height: 1em;
    
    overflow: hidden;
    
    }
    
    

• Recommended

  • <input type="text" id="search3" name="search3" title="search criteria">
    
    <input type="submit"  value="Search">
    
    

• over 35
  clickable area is 400px
• over 65
  clickable area is 1293px
• I agree
• I agree

<fieldset>

<legend>Search This Site</legend>

<label for="searchfor">Search for</label>

<input id="searchfor" name="searchfor" type="text">

<fieldset>

<legend>filter by</legend>

<input type="radio" id="a" value="1"> <label for="a">television</label>

<input type="radio" id="b" value="2"> <label for="b">radio</label>

<input type="radio" id="c" value="3"> <label for="c">cinema</label>

</fieldset><input type="submit" value="search">

</fieldset> 

• Prompt labelling
• Providing role and state information
• Collabsable panel

• <div id="slide">
  
  <input
  
  style="background: url(closefocus.gif) #ccc no-repeat 0px 50%; height: 216px"
  
  type="image" alt="close panel" src="transparent.gif">
  
  </div>
  
  

• Prompt labelling
• Providing role and state information
• tree control

• <li class="firstclosed"><a class="branchnode collapse" href="#">
  
  <img alt="collapse folder" src="node.png"></a>
  
  <input class="treecheck branchcheck" id="tr1"
  
  title="select all children of item1" type="checkbox">
  
  <img class="branchicon" alt="opened folder" src="folder.png"> item1
  
  

• Browse Mode (virtual buffer):
  • User are provided with a large range of functionality to navigate page content:
    • By paragraph, form control, heading, link (visited, unvisited) list, list items, frames, tables, They can interrogate relationships between data and headers in tables, expanded forms of abbreviations and much more...
    • The user can activate links and some form controls (differs between Window Eyes and JAWS).
    • What the user cannot do is input characters into text inputs or text areas, and interact with select elements.

• This Independent Update Example contains content which is updated to a single heading element a few seconds after the page loads.
  • Older screen readers will not update their buffer: instead they will keep reading the "stale" content that is no longer there.
  • A screen reader buffer update can be triggered by user input. JAWS (pre 7.1) and Window Eyes update the virtual buffer in response to the user pressing a key when interacting with a control or link. If the control or link has some scripting associated with it that changes content on the page and that change occurs before the buffer update finishes, then the changed content will be available to the user.
  • Newer versions of JAWS (7.1 and higher) are more successful in in detecting changes without depending on user input.
    

1. The dynamic update is not implemented in an accessible way.
2. Users are not aware of the update
   • Screen reader users
   • Screen magnifier users
   • Inexperienced users
   • Solution: Inform the user about what to expect.
3. Users that do realize the change has changed may not be able to locate the updated region or navigate to it.
   • Keyboard users cannot reach the changed content because of a too long or incorrect focus order.
   • Screen reader and magnifier users may not know in which direction to move.
   • Solution: provide a clear alternative path to the updated content or an alternative format.

• Examples of a "change of Context" are:
  • A page refresh or a different page being loaded.
  • Loss or change of focus to a different element.
• This must never happen when:
  • The user needs time to make a selection or read content.
  • Content changes using timeouts or intervals.
• Because:
  • The user will lose focus, and therefore control over the current control.
  • the control will have to be relocated to continue interaction: frustrating and confusing.

• Only allow a change of context to occur as a result of an affirmative user action
  • e.g. when submitting a form or clicking on a link.
  • A page refresh is often the expected behavior. If instead the current page is updated with new content, notify or guide the user (more about this later).
  • Always use a separate activation element rather than an onChange handler.
• When using timed updates, make sure the current focus stays intact.
  • How will you notify your user? This will be covered later.

• Place updated content correctly in the document structure.
  • Custom Pop up windows and alerts must be inserted after the control that triggered them, rather than at the end of the document structure.
  • The updated content ideally follows the form control that triggers it, in the tab order.
• Adjust focus (without being disruptive) to either the updated content itself, or to an alternative path leading to it (such as a skip link).
• For screen reader users, make sure the udpated content can be easily reached through the heading structure.
• Optionally allow the user to view the updated content in an alternative format.

Custom Controls

• Controls that are not provided by the browsers.
• Built by developer, or imported as moduralized components (e.g. DOJO)
• A custom control usually is a collection of the following:
  • Low level HTML controls, to provide structure (e.g. <span>, <div>, <p>, <li>).
  • JavaScript, to provide behavior (e.g. event handlers, DOM scripting).
  • CSS, to provide presentation (e.g. background images, visual styles).

• Problem: Web applications pretend to be desktop applications, but are in fact HTML pages.
• Available elements in HTML are not sufficient for rich interfaces, as there are no treeviews, toolbars, menus, tab panels, tri-state checkboxes, etc. in HTML.
• Rich controls are often put together using focusable controls, CSS, JS and images.
  • It looks like a treeview.
  • If done correctly, it can feel like a treeview.
  • For a screen reader, it will never be a treeview
  • The role and state information is not programmatically perceivable by AT.

• The developer applies "role" and "state" attributes to cutom widgets
  • One element generally has one role, can have multiple state values
• Role / state information is mapped by the browser to the operating system's Accessibility API (e.g. MSAA, ATK, Iaccessible2)
  • The AT perceives the widget as if it were a desktop widget, providing all necessary cues and state updates.
• For ARIA to work as intended:
  • The control must be focusable and keyboard accessible. This can be achieved by setting tabindex to -1.
  • The ARIA compliant browser will make sure the AT perceives the element in a semantically correct manner.
• The AT should run in non-virtual mode: it should not consume keystrokes.

• Create a custom control using scripting, CSS and HTML controls.
• Add 'Role' and 'State' attributes to (sub) elements, according to the ARIA specification.
  • For example:

    <span role="checkbox" aria-checked="true" />
    
    

  • Use scripting to dynamically change the ARIA state attributes when appplicable.
  • Use tools to verify role and state info is correctly exposed.

• <p id="flickrSliderLbl" role="label">Number of results to display: </p> <input type="image" role="button" alt="Decrease slider value" src="images/slider/left.png" tabindex="-1" />
  
  
  <div id="flickrSlider" role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuetext="0 pictures" aria-valuenow="0" aria-labelledby="flickrSliderLbl" tabindex="0">
  
  
  <input class="sliderThumb" type="image" role="button" id="sliderThumb" src="images/slider/thumb.png" alt="Slider handle" tabindex="-1" />
  
  

labelledby:

Tells AT which elements identifies the current element.

Required, Invalid:

Provides information about a form control's status.

 

• Web based chat
• Live auction sites
• Webmail applciations

off (default)

Do not speak this region

polite

Speak this region when the user is idle

assertive

Speak this region as soon as possible

rude

Speak this region RIGHT NOW

Levels can be overridden by the user

• additions (default)
  • Nodes added to the region are important and should be spoken
• removals
  • Nodes removed from the region are important and should be
    spoken
• text (default)
  • Nodes changed in the region are important and should be
    spoken

• Questions?
• This presentation and examples will be available next week on http://www.paciellogroup.com/techshare07
• Please contact us
  • sfaulkner@paciellogroup.com
  • hhillen@paciellogroup.com
  • Website: www.paciellogroup.com