Added by Armin Krauss, last edited by Jan Richards on Feb 12, 2010  (view change)

Labels:

accessibility accessibility Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
This is a document in development. Please use with care and do not use it as a reference yet!

Goal

This document will provide 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 )

What is accessibility?

For the Fluid community, accessibility is the ability of the system to accommodate the needs of the user. Disability is the mismatch between the user and the interface provided. We all experience disability. Accessible software = better software

Clement and Shade (1998) mention that we have to ask three questions in regard to access. Access to what, access for whom, and access for what purpose.
Fluid is a JavaScript toolkit, which builds on top of the jQuery toolkit, and the questions of access to what and for what purpose can be answered as 'the content offered to the user and the data generated through the user'. More important in the Fluid context it the question of access for whom.

Access for whom

Within Fluid we are designing tools that are flexible and accessible for all users. We try to achieve this by following W3C accessibility standards and allowing our tools to be customized to fit the needs of individual users.

Disability and accessibility

To understand and define accessibility it is helpful to start with a definition of the term disability. We understand disability as a mismatch between the user and the environment (in our case the interface). This description is very helpful since it emphasizes that disability, and as a result accessibility, is not a static feature rather than depending on an interaction.
The definition also 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.

While the mentioned accessibility barriers are inconvenient, the barriers are temporary in nature. So our main focus lies on the accessibility of the web for users with various conditions that disable them in most usage contexts.

Within the Fluid project we understand accessibility as the ability of the system to accommodate the needs of the user. 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 make it accessible to users with various disabilities.

In the context of Fluid, access means to allow users to complete their task no matter what their requirements and circumstances are. We try to make our components flexible so they can bridge the gap between the restrictions of the user and the task to be completed.

Why does accessibility matter?

First of all this is an ethical question. We have the tools and means to make information accessible for a wide range of users and we should not discriminate against a certain group of users.

Accessibility is also more and more becoming an legal responsibility. Countries are starting to have legislations that require buildings, services, transportation, and the Internet to be accessible. In the United States this is governed by Section 508 of the Disability Act. In Canada the province Ontario created the "Accessibility for Ontarians with Disability" act (AODA). The goal is to make the Province accessible by 2025.

Furthermore, there is an economical argument for accessibility. Blocking users from using a service excludes them also as a potential customer. By making a service accessible a company is able to offer a service to a larger number of people. In an ageing society this is important since more and more citizen will experience accessibility problems (e.g. decreasing hearing and sight).

We should not exclude people with disabilities from developing and using their talents and potentials. Stephen Hawking is a well known physicist and author suffering from neuro-muscular dystrophy. Without assistive technology he would be unable to write books, give talks, and do his research. Making the environment and information accessible enables everybody to improve and use their knowledge.

Everyone can experiences different levels of disability, therefore it is important to create accessible software. Ultimately this software will be better software for a wider range of users needs.

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.

Accessibility by Component

This list does not point to any accessibility description yet. However, these are the "Production" components that will have a description at first

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

  • Accessibility design features:
    • Keyboard Access: @@
    • ARIA: N/A
  • Current accessibility issues:
    • @@

Progress

  • 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

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 standard

Validators

Colour contrast tools

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 Future