Accessibility/Planning: Difference between revisions
Jump to navigation
Jump to search
DavidBolter (talk | contribs) mNo edit summary |
DavidBolter (talk | contribs) mNo edit summary |
||
| Line 3: | Line 3: | ||
# Provide accessibility support for existing and new HTML5 input controls | # Provide accessibility support for existing and new HTML5 input controls | ||
# Detect accessibility support requirements at run-time to inform dynamic performance decisions. | # Detect accessibility support requirements at run-time to inform dynamic performance decisions. | ||
# Improve life cycle management of our | # Improve life cycle management of our (node and frame based) accessible objects. | ||
Revision as of 14:49, 17 June 2010
Q3 goals:
- Provide accessibility support for existing and new HTML5 input controls
- Detect accessibility support requirements at run-time to inform dynamic performance decisions.
- Improve life cycle management of our (node and frame based) accessible objects.
Measuring:
- Mochitest coverage + Marco screen reader testing. Controls added in the last two weeks will not be officially measured.
- Primarily we want to know when our more expensive accessibility support is required. Filtering this support should be doable in this quarter if we can get the primary goal right. Hopefully we can do this goal early.
- This goal is really about core accessibility work that Alexander is planning to work on. We can create a meta bug for this work. Scoping this goal is tricky.