r9 - 07 Feb 2006 - 15:25:16 - LisaDusseaultYou are here: OSAF >  Projects Web  >  DevelopmentHome > AccessibilityProject

Chandler Accessibility Project

Making Chandler accessible means making it usable to people with disablities, who may use alternate input and output methods. Accessible software is typically easy to use for everyone. And at least in the US, making software accessible is a legal requirement (at least in some cases).

A rule of thumb: everything should be doable using keyboard only.


  • HeikkiToivonen

Voluntary Product Accessibility Template

Section 1194.21 Software Applications and Operating Systems - Detail Voluntary Product Accessibility Template

Criteria Supporting Features Remarks and explanations
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. . First goal, many bugs
(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. . Does making edit controls into static text violate this?
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that Assistive Technology can track focus and focus changes. . Many bugs, probably also in wxWidgets
(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to Assistive Technology. When an image represents a program element, the information conveyed by the image must also be available in text. . I think there is at least one case where we do not support this: grouping (or whatever the terminology is) sidebar collections changes the icon, but there is no textual information what this means.
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance. . .
(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes. . There are bugs at least with non-visible caret, maybe other issues as well
(g) Applications shall not override user selected contrast and color selections and other individual display attributes. . Not sure how that applies to us, or if we are honoring system settings
(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user. . .
(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Supports with Exceptions Overlaying several calendars distinguishes them by color only.
(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided. Supports The only place where color settings can be made is with calendar colors, and the default selection of colors is suitable for color blind people.
(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. Supports with Exceptions Cursor blinks, but at a rate the user can customize (or the OS defines). In theory it might be possible to create image animations that are shared or acquired via email that could produce harmful blinking effects.
(l) When electronic forms are used, the form shall allow people using Assistive Technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. . Problems for example in the detail view, especially with static text that dynamically changes to edit text on mouse click

Accessibility Bugs

We are tentatively aiming to have Chandler usable by keyboard in 0.6 timeframe. Other accessibility bugs are definitely out of scope for now.

List of current accessibility bugs.


  • wxWidgets accessibility tips: http://www.wxwidgets.org/technote/wxaccesstips.htm
  • Mozilla Accessibility Project: http://www.mozilla.org/access/
    • Information for non-Mozilla developers: http://www.mozilla.org/access/external-developers
    • Accessible Toolkit Checklist: http://www.mozilla.org/access/toolkit-checklist
  • Section 508: http://www.section508.gov/
  • UAAG 1.0: http://www.w3.org/TR/WAI-USERAGENT/

  • Sun's Accessibility Architect on Open Document and accessibility: http://blogs.sun.com/roller/page/korn/20051113

  • Inspiring read: http://newsletter.mozdev.org/archive/links023.html#community
PageType DevDocPage
MaintainedBy none
PageStatus Work in progress -- this page is still being drafted?
Trash.CommentsWelcome2 Feel free to contribute comments?, either by adding to the Comments Welcome section of this page, or by posting to the dev list, or by sending mail directly to the person listed as maintaining the page.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r9 < r8 < r7 < r6 < r5 | More topic actions
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.