Accessibility and the Calendar Code
This is a first cut at a proposal for how to deal with accessibility issues in Mozilla Calendar code (mostly focussed on Sunbird & Lightning at the time of this writing). Dates, timelines, and details are very much negotiable and dependent on the number and priorities of developer, UI, and QA folks participating in the Mozilla Calendaring effort.
After recent discussion with Mozilla's accessibility czar (Aaron Leventhal), I came away with the following basic takeaway: there are essentially two levels of accessibility for an application. In particular, there are the basic front-end and keyboard accessibility guidelines which can be followed today, and nsIAccessible/MSAA/ATK role-based accessibility, which he speculated would require perhaps a person-year's worth of work to do for a calendaring application.
The current proposal is to:
- enforce basic guidelines linked to above for all newly landing code going forward
- hold off on nsIAccessible support until a resource steps forward to do this work
- clean up existing guideline violations by versions 1.1 of Lightning & Sunbird (assuming that we converge the version numbers of those apps in the relatively near future).
This begs the question, "Why 1.1 and not something sooner?"
- The amount of cleanup seems likely to be a fair amount of work.
- Many people are unlikely to use pre-1.0 versions, and with good reason. However, it strikes me that we'll have something that is good enough to be called 1.0 and something that we'd like to distribute widely sooner rather than later.
Choosing Keyboard Shortcuts
In addition to following the guidelines linked to above, I'd like to propose that we shoot for the lowest-possible barrier to entry for people trying our software for the first time. This would suggest that we try and overlap our shortcuts with those from the software that the largest number of possible users are likely to already be familiar with: Outlook, and, to a lesser degree, iCal, Notes, etc.