Jump to: navigation, search

Difference between revisions of "Planning Council/Cross Project Teams/Accessibility"

(initial content)
 
(Statement of Problem)
Line 1: Line 1:
 
 
= Accessibility Team =
 
= Accessibility Team =
  
Line 15: Line 14:
 
The "proof" often comes in the form of conducting certain tests and checks and completing a checklist, for long term documentation of what was done to ensure the software is accessible.  
 
The "proof" often comes in the form of conducting certain tests and checks and completing a checklist, for long term documentation of what was done to ensure the software is accessible.  
  
Currently, many Eclipse members have their own process and checklists for this accessibility work, but it would be simpler if there was one "Eclipse Accessibility Checklist" which would set the expectation for all Eclipse Projects ... at least all Eclipse Projects participating in the yearly, simultaneous release.
+
Currently, many Eclipse members have their own process and checklists for this accessibility work, but it would be simpler if there was one "Eclipse Accessibility Checklist" which would set the expectation for all Eclipse Projects ... at least all Eclipse Projects participating in the yearly, simultaneous release. And, of course, this "required item" for the yearly release can not be too burdensome for the Eclipse projects.
 +
 
 +
Our "required" item for Galileo simultaneous release was a 'should do' item, and stated as simply as "... should design and test for accessibility". So another way to state the problem, is whether or not there is a stronger requirement that would lead to a stronger, more demonstrable or measured statement about accessibility compliance.
 +
 
 +
== Meetings and Notes ===
 +
 
 +
 
 +
== Recommendation to Planning Council ==

Revision as of 11:39, 6 October 2009

Accessibility Team

Members

Tammy Cornell, IBM
Kentarou Fukuda, ACTF Project
Neil Hauge, Oracle
Kaloyan Raev, SAP

Statement of Problem

Currently, many Eclipse Members have a business need to make sure software they consume from Eclipse meets certain Accessibility requirements. Besides just being a nice thing to do, it is often required to "prove" software is accessibility, in order to sell to certain markets or bid on certain contracts.

The "proof" often comes in the form of conducting certain tests and checks and completing a checklist, for long term documentation of what was done to ensure the software is accessible.

Currently, many Eclipse members have their own process and checklists for this accessibility work, but it would be simpler if there was one "Eclipse Accessibility Checklist" which would set the expectation for all Eclipse Projects ... at least all Eclipse Projects participating in the yearly, simultaneous release. And, of course, this "required item" for the yearly release can not be too burdensome for the Eclipse projects.

Our "required" item for Galileo simultaneous release was a 'should do' item, and stated as simply as "... should design and test for accessibility". So another way to state the problem, is whether or not there is a stronger requirement that would lead to a stronger, more demonstrable or measured statement about accessibility compliance.

Meetings and Notes =

Recommendation to Planning Council