community accessibility testing
Community testing of accessibility during the development cycle. During most cycles, testing can not be started until the last month or later of the cycle. Testing needs to start as close to the cycle start as possible, with Alpha2 as the latest date to be able to test it.
Blueprint information
- Status:
- Not started
- Approver:
- Penelope Stowe
- Priority:
- Medium
- Drafter:
- Charlie Kravetz
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Drafting
- Series goal:
- Accepted for quantal
- Implementation:
-
Unknown
- Milestone target:
-
ubuntu-12.10
- Started by
- Completed by
Whiteboard
1012-09-13 didrocks: postponed some WI, those can still be done independently of any target, please feel free to continue working on them.
2012/02/23 KS: asked and got input from Alan Bell and charlie-tca about the bugs they cared about getting in for beta 1 (added them to the list, and they got fixed) - so altering work item to reflect what actually happened and marking it done - not sure it makes sense as written at this point.
Discussion:
Accessibility is very important to the success of Ubuntu. Users should be able to use screen-reader, magnifier, text zooming, onscreen-keyboards, and other a11y items without them failing.
During the Ubuntu 11.10 development cycle, accessibility was broken throughout much of the cycle.
The accessible installation was not ready until Beta2 milestone, and testing was not able to be done until beta2.
Accessibility testing needs to be done for each milestone, to identify the issues that need to be fixed and to determine the actual state of a11y in the release. Limiting the time to test and identify bugs does not allow thorough and reliable testing.
Developers should be aware of changes made that break a11y. Those changes should be examined rapidly to determine if the break can be fixed rapidly.
Coming this cycle:
ability to tag managers, etc. on bugs
shouldn't be as many changes
Release team meetings should give better warnings for making documentation of testing easier to update
Fear of Gnome3 and Unity with community - wanting to stay with Gnome2 with user base.
Creating hearing impaired profile - allerts and flashing? another test case?
Importance of not breaking a11y with automated testing
Getting people to actually test
Ubuntuone for QT - need to start thinking about this.
pitti, 2012-03-28: Moving whole blueprint to Q, as it's not even approved and not started yet.
Work Items
Work items:
[kate.stewart] get input from usability team about key bugs they want fixed for beta 1, and add important ones to rls-mgr-p-tracking and help with lobbying for them to be milestoned in rls-p-tracking: DONE
[charlie-tca] blind/VI & hearing impaired test cases: TODO
[pendulum] mobility impairment test cases: TODO
[charlie-tca] give Pendulum time/day for a11y testing classes for Classroom: TODO
[pendulum] Schedule a11y testing classes in Classroom: BLOCKED
[ubuntu-
[themuso] Needs to document his expectations when he tests in Unity and his expectations.: POSTPONED
[themuso] Publish progress reports then decide if need possible weekly meeting?: POSTPONED
[ubuntu-
[charlie-tca] Add to bug filing documentation, check that a11y tag is there, and explain why its needed.: TODO
[pendulum] work with Charline & Dan to start to figure out how to do Usability testing: INPROGRESS
[pendulum] Start Usability testing: POSTPONED
[charlie-tca] create "how to test accessibility session.: TODO
[maco] Create Tutorial on how to develop for accessibility (working with Rodrigo): TODO
Dependency tree
* Blueprints in grey have been implemented.
