Slide 1 of 64

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

Options for this presentation:



Presented by:
Steve faulkner
Hans Hillen
TPG Europe

CSUN 2008 (This presentation can be found at: http://www.paciellogroup.com/CSUN08/webapps)

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

Introduction to Web Applications: What's different?

Differences between traditional websites and web applications
Traditional Websites Web applications
Entire page is recreated when something changes. Relevant parts of the page are updated dynamicallty.
Standard HTML controls. Custom interface controls
Content comes from one place. Modularized content comes from external locations, not always under developer's control.
Looks and feels like a website. Looks and feels like a desktop application.
All HTML is created on the server. Highly dependent on client side scripting.

Web application Examples

Yahoo Mail
Yahoo Mail web application screenshot (no alt)
Google Docs
Google Docs screenshot (no alt)

Main Accessibility Issues for Web Applications (Course Outline)

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

Keyboard Accessibility

  • Most assistive technology either operates through the keyboard or by emulating a keyboard, for example:
    • Screen readers and magnifiers
    • On-screen keyboards
    • Single switch devices, Sip and puff switches, etc.
  • For this reason, all interaction must be achievable using only a keyboard
    • Only catering for mouse users is not sufficient.
    • Used to be relatively easy, because all HTML controls were keyboard accessible by default.
    • For web apps, keyboard accessibility often has to be implemented manually.
headwand
Woman using a mouthstick to interact with her keyboard
an on-screen keyboard

Keyboard Accessibility: What is required?

  • 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.

Keyboard Accessibility, Requirement 1: Focus

  • Focus tells the user, browser and assistive technology which element the user is interacting with. This has important advantages:
    • Keyboard users won't have to guess.
    • Screen readers know which element to announce.
    • Browsers know where keystroke events should fire.
      • Also applies to native key events, e.g. the context key.
    • Screen magnifiers know which element to scroll into view.
    • Allows for enhanced visual indication.
      • e.g. Windows High Contrast mode, SuperNova, CSS styles.

Focus (Continued)

  • 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');

How to Apply Focus: Using Nativly Focusable Elements

  • Wrap components or parts in elements that are focusable by default
    • Most commonly used: links anf form controls.
      • Choose most appropriate element, e.g. <a> or <input type="img"> where possible.
    • Advantages:
      • Screen readers will perceive the element as interactive.
      • The element is placed in the tab order, making reachable by keyboard (based AT).
    • Disadvantages:
      • Focusable Element does often not make sense semantically (for example: a twisty is not a link).
      • Bulky code / tab order / link list.
    • Example: Collapsible Panel example.

Applying Focus: tabindex and Scripting

  • 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.

Keyboard Accessibility Requirement 2: Logical focus Order

  • The focus order the order in which elements receive focus sequentially.
    • Generally done using the tab key therefor also known as 'tab order'.
    • Always mark up content so that the focus order makes sense by itself.
    • If possible, try to stay away from using custom tabindex values of 1 or higher.
      • Usually difficult to maintain, an indication that your interface needs to be restructured.
    • For complex controls such as menus, often more logical to have only one tab stop.
      • Releaves the tab order, making it simpler to navigate the interface.
      • Scripted key event handlers can deal with 'sub focus', for example by using the arrow keys.
    • Sometimes controls should not be in the tab order at all.
      • E.g. menus and toolbars which can be moved to using a global keyboard shortcut.
      • More 'desktop like', but dangerous and not very backwards compatible or novice user friendly.
    • Example: Sample Application Mockup.

Keyboard Accessibility Requirement 3: Responding to keystrokes

  • 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.

Labeling of controls

  • 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.

Some Issues regarding Labels

  • 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

form control label examples - No label

A textfield with no label (Not reccommended)
  • Code:
    <input type="text" name="search" />
    <input type="submit" value="Search" />
Recommended Solution
  • Code:
    <input type="text" name="search" title="Search criteria"/>
    <input type="submit" value="Search" />

form control label examples - multiple actions

    • <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" />

The label placement

Before control; in left-to-right languages, either to the left or immediately above the control. Buttons are self-labelled labels. Check boxes and radio buttons are special types of buttons, and so the label is part of the button (increases target area), and placed immediately after the control to show the semantic difference

label Placement
Control label
text, text area, select To the left or immediately above
check box and radio buttons Immediately after the control
buttons self-labelled

Results from an eye tracking study concluded that:

Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field. But this conclusion needs to be tempered by the power of convention and remembering it is only one study.

Implicit and Explicit Association

  • 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>
Implicitly positioned labels do not work correctly in IE6 and lower, and with some screen readers (JAWS 6.2; probably others, but don't know). The for attribute in the hybrid version makes it an explicit association. Implicitly associated labels are made available through MSAA, and are legal according to the specification, making this a user agent problem. Having said that, I don't like implicit associations. Semantically, a label is associated with its form control; it doesn't make sense to say the label is the parent, and the form control is its child. It would make more sense to say that the label is part of the form control, as they are in XForms.

The Option as a label

    • <select name="city">
      <option value="-1">choose a city</option>
      <option value="1">Birmingham</option>
      <option value="2">London</option>
      </select>
  • Acceptable
    • <select name="city"  title="choose a city">
      <option value="-1">choose a city</option>
      <option value="1">Birmingham</option>
      </select>

The Option as a Label (continued)

  • 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>
When there's no default option, it's useful to make the first option a label, but it should provide context, and the control should still have an explicit label (or title attribute). Relying on the first option as a label might work in some circumstances, but it soon breaks. For example, if a mistake is made, the user's selections should be retained. They now have a drop-down box whose label is a value that might not be accurate.

Multiple labels for a control

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

Multiple labels for a control (continued)

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

Multiple labels and error messages

  • text input with multiple labels - ' input 1' and 'tip: between 1 and 4' Recommended
    • <label for="a">input 1
      <span class="formhint">tip: between 1 and 4</span>
      </label>
      <input class="range:1-4" id="a">
  • text input with multiple labels - ' input 1', 'tip: between 1 and 4' , error icon  and message  'must be between 1 and 4' Recommended
    • <label for="a">
      <img id="errorimga" height="16" alt="error" src="error.png">
      input 1
      <span class="formhint">tip: between 1 and 4</span>
      <em class="errortext" id="errortexta">must be within 1 and 4</em>
      </label>
      <input class="range:1-4" id="a">

Use of hidden labels

    • .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">

Labelling of form controls in data tables

Product order form
code item quantity price
123 pencil $1.00
124 pens $1.50
  • <td>
    <label class="hiddenlabel" for="q1">quantity of pencils</label>
    <input type="text" id="q1" name="q1" size="3" value="0"></td>
  • Recommended
    <td>
    <input type="text" name="q1" size="3" value="0" title="quantity of pens"></td>

Labels increase click area

  • over 35
    clickable area is 400px

  • clickable area is 1293px
  • I agree

Grouping: fieldset and legend elements

  • Personal Details
  • <fieldset>
    <legend>Personal Details</legend>
    <label for="t6">Title</label>
    <select name="ddlTitle">
    <option>Mr</option>
    <option>Ms</option>
    </select>
    <label for="t1"> First Name</label>
    <input type="text"id="t1" name="txtFirstName">
    <label for="t2">Middle Name</label>
    <input type="text"id="t2"cname="txtmiddleName">
    <label for="t3">Last Name</label>
    <input type="text" id="t3" name="txtlastName">
    </fieldset>

Grouping: fieldset and legend - continued

Search This Site
filter by
<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>

Spin control example

  • Prompt labelling
  • Providing role and state information
  • Spin control
  • <label for="spin">Spin:</label>
    <input id="spin" size="3" value="0" maxlength="2">
    <input id="spinup" type="image" alt="increase value" src="spintop.png">
    <input id="spindown" type="image" alt="decrease value" src="spinbot.png">

Collapsable panel example

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

Slider example

  • Prompt labelling
  • Providing role and state information
  • Slider
  • <div class="slider">
    <input id="thumb" title="effectiveness, between 0 and 500"
    type="image" alt="effectiveness" src="thumb.gif">
    <label id="lbl" for="thumb">effectiveness 
    <span id="result">0</span>
    </label></div>

tree control example

  • 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

Dynamic Content

  • Content that changes after the page has loaded without using a page refresh.
  • Dynamic Updates: user initiated and independent
    • Can the user access the updated content?
    • Is the user aware that content is updated?

Screen Reader Modes

  • 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.

Screen Reader Modes (continued)

  • Forms Mode (browse mode off):
    • When the virtual buffer is not in use the user can only navigate through a document to focusable elements via the tab key.
    • Access to text is limited to "read all' functionality.
    • Most of the advanced content navigation and interrogation functionality is unavailable.

Independent Update Example

  • 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.

Updates and latency

  • User key press: Update is initiated if content itself is updated before the buffer update occurs (e.g. 600milliseconds).
  • If the content takes too long, the buffer update will be complete before the actual content has occured: the new content will not be perceivable.
    • This issue is one of the primary reasons why AJAX is considered inaccessible.
    • latency example
    • From version 7.1 JAWS started to listen
    • Now if it detects changes in page content it updates the virtual copy
    • But it is not perfect, it does not detect all content changes
    • Examples: title and alt attribute content changes
    • The latency issue does not occur when users are not in "browse mode" as they are interacting directly with the content in the browser.
    • But users access to content is severely restricted.

Three Main Issues with Dynamic Content

  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.

Dynamic Content Issue 1A: Incorrectly Hiding and Showing Information

  • CSS is often incorrectly used to hide content that is not in use at the moment, such as errors, results or 'please wait' messages.
    • This is done through the 'display: none;' and 'visibility:hidden' styles.
  • Problem: Older Assistive technology (as well as users or user agents that do not support CSS) will not obey these styles, and will still display this incorrect information.
  • Only use CSS for hiding and if the information conveyed by the hidden content still makes sense. For example:
    • Submenus
    • Closed treebranches
    • Collapsed panels
  • If the content is incorrect, it does not belong in the document structure.
    • Remove it, re-insert it when needed using dom scripting.

Dynamic Content Issue 1B: Disruptive Change of Context

  • 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.

Common Examples of Disruptive Context Changes

  • 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.

Change of Context Recommendations

  • 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.

Dynamic Content issue 2: Making the user aware of the update

  • Traditionally, users will expect a page to reload when content changes.
  • When a section of the page is updated, assistive technology will not notify the user.
  • If nothing happens, assistive technology users may thing something went wrong, and try again.
  • The user needs to be aware of what to expect when submitting a request.
  • Provide a description at the beginning of the form, explaining that the page will not refresh on submission.
    • Make the description unobtrusive but easily accessible to everybody.
    • Describe the steps needed to access the updated content.
    • Don't be too technical, explain using simple language.
  • Better solution: LiveRegions (will be discussed later).

Dynamic Content Issue 3: Helping the User to Access updated information.

  • 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.

Further Reading on Dynamic Content

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).

Role and State Information

  • Role: what is the function of the control? Examples:
    • Checkbox
    • Text input
    • Select
  • State: what are its current "settings" or "properties"? Examples:
    • Checked
    • Disabled
    • selected
  • Role and state information tell the assistive technology how to interpret an element.
    • For example, a screen reader will announce something as a button because it has that role.

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 is not programmatically perceivable by AT.

How ARIA Solves the Problem

  • Solution: ARIA roles and states allow developer to add 'semantic sugar' to a custom widget, even if there is no semantically correct element available.
    • ARIA provides (amongst other things): Roles which describe what type of widget an element is portraying, (e.g. "menu", "treeitem", "sliders" or "progressmeter")
    • Roles that can describe the structure of a web page (e.g. "main navigation", "search", etc ).
    • Information about the widget's state (e.g. the current value of a slider, or whether a menu item has a submenu).

ARIA: How it works

  • 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.

ARIA Support

  • Browsers
    • Supported by Firefox 2 (recommend to use Firefox 3)
    • Opera is working on support
    • Internet Explorer 8 Beta
  • Assistive Technology
    • JAWS 7.X and higher: Partial support
    • Window Eyes: Partial support
    • ZoomText: compatible.

How to apply ARIA

  • 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.

Some Interesting ARIA roles:

Alert:
Generate an alert type notificication which screen readers will pick up.
Description:
Programmatically associates text to a control.
Presentation:
Hides the content from assistive technology (e.g. layout tables).
Application:
Tells screen reader to switch to non virtual mode.
Dialog:
Used for custom popup content.

Slider Example

  • <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" />

Checkbox example

  • <span tabindex="0" role="checkbox"
    aria-checked="true">Any checkbox label </span>

Some Interesting ARIA states and properties

labelledby:
Tells AT which elements identifies the current element.
Required, Invalid:
Provides information about a form control's status.
 

ARIA Live Regions: What are they?

  • Modern Solution for AJAX /DHTML update notification problem.
  • Allows developer to specify which parts of the page are expected to change dynamically, and how.
  • Should users be informed of the change, and if so, when?
    • Certain changes are trivial and should be ignored, e.g. the changing seconds in a clock.
    • Other changes are more important and should be spoken immediately or when convenient.
  • Slowly gaining support by assistive technology (mostly open source screen readers: Firevox, ORCA, NVDA).

Examples of use for LiveRegions

  • Web based chat
  • Live auction sites
  • Webmail applciations

Marking Up Live Regions

  • 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

Politeness Levels

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

Live Region Atomic attribute

  • atomic=BOOLEAN
    • true: This whole region must be spoken when any
      of its nodes are changed; the individual
      changes cannot stand on their own
    • false (default): Speak only the node that changes; there is
      enough context for the individual changes to
      make sense

LiveRegions 'Relevent' Attribute

  • 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

ARIA resources

Slide 64 of 64

Wrapping Up