Documentation for a historical release of Infusion: 1.3
Please view the Infusion Documentation site for the latest documentation.
If you're looking for Fluid Project coordination, design, communication, etc, try the Fluid Project Wiki.

Fluid accessibility

Owned by Armin Krauss
Last updated: Mar 30, 2010 by Alison BenjaminVersion comment
2 min read

This is a document in development. Please use with care and do not use it as a reference yet!

Goal

This document provides the Fluid community and users with a starting point for information about accessibility within the Fluid project. This will include a framework for understanding accessibility, information about the accessibility features of the Fluid components, and accessibility resources that may be useful for Fluid community members. (the end result could be something similar to the Google accessibility page )

Accessibility by Component

To view open accessibility issues for each component, search for "a11y" in our issue tracker. We are currently working towards incorporating WCAG Level AA testing into our suite of QA tests. QA plans enhanced with WCAG are listed below from component to component.

Simple Text Inline Edit

Reorderer

There are several variations of the Reorderer which are handled in a separate section

List Reorderer
  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: includes aria-role, aria-selected, aria-disabled, aria-dropeffect, aria-dragged<!-- @page
      Unknown macro: { margin}
      P
      Unknown macro: { margin-bottom}
      -->
  • Current accessibility issues:
    • @@
Grid Reorderer
  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: includes aria-role, aria-selected, aria-disabled, aria-dropeffect, aria-dragged
  • Current accessibility issues:
    • @@
Image Reorderer
  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: includes aria-role, aria-selected, aria-disabled, aria-dropeffect, aria-dragged
  • Current accessibility issues:
    • @@
Layout Reorderer
  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: includes aria-role, aria-selected, aria-disabled, aria-dropeffect, aria-dragged
  • Current accessibility issues:
    • @@

Uploader

  • Current QA test plan [Uploader QA Test Plan|fluid:Uploader
    QA Test Plan]
  • Possible future QA test plan including WCAG compliance tests [Uploader QA test plan with WCAG]
  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: N/A - but uses Progress component.
  • Current accessibility issues:
    • @@

Pager

  • Current QA test plan Pager QA Test Plan
  • Possible future QA test plan including WCAG compliance tests [Pager QA Test Plan with WCAG]
  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: N/A
  • Current accessibility issues:
    • @@

Progress

  • Current QA test plan Progress QA Test Plan
  • Possible future QA test plan including WCAG compliance tests Progress QA Test Plan with WCAG
  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: Includes role, aria-valuemin, aria-valuemax, aria-valuenow, aria-busy, and aria-valuetext
  • Current accessibility issues:
    • Not read by NVDA (Jan), @@

User Interface Options

Interface Options]

What is accessibility?

For the Fluid community, accessibility is the ability of the system to accommodate the needs of the user. We understand disability in an online context as is the mismatch between the user and the interface provided. This description emphasizes that disability, and as a result accessibility, is not a static feature but rather depends on an interaction. It implies that everyone can be disabled depending on the environment. An English speaker will be disabled in a Chinese environment as will be a user on a Flash-based website if this user does not have a Flash capable browser.

We do not try to create a 'one size fits all' design. Rather we try to allow the interface to be changed and customized in order to meet the preferences of users. In the context of Fluid, access means to allow users to complete their task no matter what their requirements and circumstances are. We accomplish this through our pervasively accessible, open, and interoperable architechture and inclusive approach to user experience design.

Which problems does Fluid intend to solve and how

The short answer is by complying to the WCAG 2.0 standard. We are currently updating our test plans and show case examples. The goal is to have examples that are compliant with WCAG 2.0 (Level A and AA).

The test plans will be updated to test for WCAG 2.0 compliance. There are 4 principles of accessibility that are important to better understand WCAG compliance. These four principles are (as defined by W3C):

  • Perceivable
    • Information and user interface components must be presentable to users in ways they can perceive.
    • This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)
  • Operable
    • User interface components and navigation must be operable.
    • This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)
  • Understandable
    • Information and the operation of user interface must be understandable.
    • This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)
  • Robust
    • Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
    • This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

We used the WebAIM website as a starting point since this website captures the parts that are most relevant to web developers in one check list. WebAIM's check list can be used by everyone to evaluate a website for WCAG 2.0 compliance very quickly (see also the template in the Attachments). Using this check list we created a spread sheet for each component to identify areas where we have to improve the WCAG compliance in the component and the example page. Furthermore, we integrated WCAG compliance test into our QA test plans to ensure that WCAG compliance is tested and is not broken by further development and bug fixing.

In the following section we will link to information about each component, the demo page of each component, the test plan of each component, and the chart used to identify WCAG compliance tasks.

Helpful tools and validators to evaluate accessibility and WCAG compliance issues

Creating WCAG compliant and accessible page can be complicated. However, there are many tools available to help developers, testers, and everyone else interested to evaluate websites. A few of this tools will be linked here.

The guideline

Validators

Colour contrast tools

Colour blindness checker

Tools

Other Wiki pages that deal with accessibility

  • This wiki page has many links to resources that discuss accessibility.

Presentations about accessibility

  • Presentation by Colin Clark, Fluid Project Technical Lead, Adaptive Technology Resource Centre, University of Toronto Accessibility

Resources

Clement & Shade. (1998). The Access Rainbow: Conceptualizing Universal Access to the Information/ Communication Infrastructure.

Brian Kelly & Liddy Nevile: Web Accessibility 3.0: Learning From The Past, Planning For The Futureop