Web 2.0 and Screen Readers:
Challenges, Solutions, and the Future

Introductions

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

• Spin control referenced on Slide 32
• Collabsable panel referenced on Slide 33
• Slider referenced on Slide 34
• tree control referenced on Slide 35
• Independent Update Example referenced on Slide 39

Keyboard Accessibility

• Programmatic focus
  • Using natively focusable controls
  • Using the tabindex attribute and scripting
• Event handling
  • Dealing with native event handlers
  • Attaching custom key handlers
• Preventing disruptive changes of context

• CSS can be used to automatically style focused elements (code example)

  1: a:hover, a:focus, a:active {
  
  2: color: white;
  
  3: 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:

    1: element.onfocus = highlightFocus;
    
    2: element.onblur= unHighlightFocus;
    
    3: ...
    
    4: addClassName(element, 'highlighted');
    
    5: 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
    • Very well suited for ARIA
  • 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)

• Through Inline scripting:
  • Bulky code, though sometimes more intuitive to read.

    2: <li class="cmd_newMsg" onkeyup="handleKeyUp(this, event)"> New Message</li>
    
    

• Unobtrusive scripting
  • Cleaner, easier to provide fallback mechanisms, but inactive until the page load is complete and costly for large applications.

    2: <li class="cmd_newMsg menuItem">New Message</li>
    
    3: JS Pseudocode:
    
    5: Find all elements that contain a particular class name
    
    6: for each found element, attach an appropriate event handler
    
    

• Automated page refreshes to keep content up to date.
• Timed AJAX calls that replace focus to newly added content or remove the currently focused element.
• Disruptive onChange handlers (Mostly a problem on I.E.):
  • Keyboard users make a selection one item at a time.
  • Pressing the 'alt' key first solves the problem, but this is not really logical is not commonly known.

Role, State and labeling of controls

• Role, state and labeling
  • Native controls
  • Custom controls
• Providing labeling for interactive controls (including prompts, hints and validation results).
• Providing descriptive information for (custom) controls, explaining their interface and expected behavior.
• ARIA to be discussed later.

• 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

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

• Recommended

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

• Implicit Labels

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

• Explicit - Recommended

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

• Hybrid

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

• City choose a city Birmingham London Recommended

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

• name first name optional

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

• name (first name optional) Recommended

  • 1: <label
    
    2: for="multi4">name (first name optional)
    
    3: </label>
    
    4: <input type="text" id="multi4" name="multi">
    
    

• search criteria
• search criteria

  • 1: .hidden {
    
    2: position: absolute;
    
    3: left: 0;
    
    4: top: -999em;
    
    5: width: 1em;
    
    6: height: 1em;
    
    7: overflow: hidden;
    
    8: }
    
    

• Recommended

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

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

1: <fieldset>

2: <legend>Search This Site</legend>

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

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

6: <fieldset>

7: <legend>filter by</legend>

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

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

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

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

13: </fieldset> 

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

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

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

• 1: <li class="firstclosed"><a class="branchnode collapse" href="#">
  
  2: <img alt="collapse folder" src="node.png"></a>
  
  3: <input class="treecheck branchcheck" id="tr1"
  
  5: title="select all children of item1" type="checkbox">
  
  6: <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.
    

• Current methods to provide access to dynamic content are limited by the AT
  • Provide alternatives: Stock Prices Example
  • "Live Regions" will most likely provide an acceptable solution, and are covered in the next section.

Accessible Rich Internet Applications: ARIA

• 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 has to be described manually, and 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 Can be achieved by setting tabindex to -1.
  • ARIA 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.

• 'Role' and 'State' Attributes can be added in both XHTML and HTML files.
  • FF3 supports built in attributes.
  • Older versions require namespaced attributes, meaning:
    • The document has to be served as valid XHTML, and the namespaces have to be defined:

      2: <html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"
      
      3: xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
      
      4: xmlns:aaa="http://www.w3.org/2005/07/aaa">
      
      

    • The namespaced attributes have to applied in the DOM after page load. (look for classnames, apply attribute, using setAttributeNS().

• The developer tells the AT which parts of the content are likely to change, either over time or as a result of a user action.
• This is done by specifying the following ARIA properties:
  • 'live': Whether the element is a live region, as well as the level of 'politeness' the AT should use when announcing the change.
  • 'atomic': Whether the whole region should be announced, or just the part that changed.
  • 'controls', 'labelledby' and 'describedby' describe the relationships between a live region and its trigger

• ARIA
  • Roadmap for ARIA
  • ARIA Roles W3C working draft
  • ARIA States and Poperties W3C working draft
  • ARIA / relationship to HTML FAQ
  • Mozilla Developer Center ARIA page
  • How to embed ARIA in HTML documents
  • A List Apart article on ARIA
  • JuicyStudio Article on ARIA
• Live Regions
  • Mozilla Developer Center Live Region page
  • JuicyStudio article on Live Regions
  • Live Region test cases on CLC world
  • Download Firevox