Platform/2009-Accessibility-Goals

What is this?

Mozilla users deserve first class accessibility. Every thing exposed by Mozilla must be accessible for people with disabilities and it doesn't matter if this thing is popular and is used by millions or it is targeted to small groups only. Following this concept we make Mozilla products humane and robust in terms of usability by every man. All this brings additional and well-earned popularity for Mozilla products. Mozilla accessibility team defines its goals in the light of this concept. On one hand it's stability and correctness of Mozilla accessibility code which makes Mozilla products to work well with assistive technologies. On another hand it's accessibility support of existing features of Mozilla products as well it's spread of Mozilla products on new platforms which allows to envelop new applied areas and involve new user groups.

This is a list of accessibility goals to prioritize, estimate, and assign resources to.

Legend:

• [#] - The number of person days estimated for this issue.
• [p#] - Priority, lower is higher.
• [name1, name2, name3] - person names assigned to particular task

Gecko Workplan

Automated tests

Create a11y mochitests framework which is presented by number of js files and supposed for easy testing of accessibility interfaces. Create complex tests for throughout testing of certain method or property of accessibility interfaces. Extend these complex tests (or write new small specific mochitests if complex tests aren't suitable) for every newly fixed bug which is able to be tested by mochitests. [100], [p1], [surkov, marcoz].

Permanent work

• Regression fixes [100] [surkov, davidb]
• Triage [20] [marcoz]
• Manual testing [20] [marcoz]

Architecture/Code refactoring

• Implement new features that doesn't fit well into current code organization. Get rid the code presented by heap of specific cases, replace it by general rules. Get more robust and complete code for partially implemented features. [p2], [surkov]

• Missed features or markup languages [p2], [surkov]

• Incorrect support of AT APIs [p1], [surkov]

• Code clean up [bug 389800], [30], [p3], [surkov]

• Perf optimization. Slow means unusable, unusable means inaccessible [30], [p2], [surkov, davidb]

New work

• WAI-ARIA 1.0 completeness (bug 343213)
  • additional events [30] [davidb, surkov]
  • additional semantics [15] [davidb, surkov]
  • spec changes [20] [davidb, surkov]
  • normative changes as other browsers implement ARIA [10] [davidb, surkov]
• HTML 5 (need to update tracker bug 389237)
  • drag and drop [4] [davidb, surkov]
  • <canvas> [0-20] [davidb, surkov]
  • <video> [?] Need report from Silvia. [davidb, surkov]
• SVG
  • focus, keyboard navigation (bug 409404) [10] [davidb, surkov]
• Mac OS X
  • performance tracker bug 454202 [20] [davidb, surkov]
  • architecture bug 342989 [20] [davidb, surkov]
  • improvements tracker 336306 [50] [davidb, surkov]
• Mobile
  • TODO [?] [davidb, surkov]
• MathML specification work [0-20]
• Performance testing and profiling
  • Windows [?] [surkov, davidb]
  • Linux [5] [davidb, surkov]
    • run valgrind-like tools and analyze places to optimize.
  • Mac [10] [davidb, surkov]
    • Shark, Spin Control, Instruments, MallocDebug

Community Collaboration

• Standards
  • W3C WAI-ARIA user agent implementor guide
    • edits [15]
    • meetings [15]
      • Note: this group is being formed soon to make sure that implementations don't delta too much. This is vital for DHTML a11y to work in any practical sense.
• Evangelism
  • Cultivate patch contributors
    • To provide our users with a good web experience we need a larger team. The proven way to do this is via a combination
      • Foundation mini grants [2]
      • responsiveness to questions on #accessibility [20]
      • Pursue resources from companies that benefit from FF's accessibility [2]
  • Work with Assistive Tech folks (NVDA, Orca, FS etc)
    • bug triage [10]
• Labs
  • We need to be part of the early discussions in labs projects, so that more informed technical decisions can be made. In this way we might help with things like the Bespin/canvas a11y issues. [5]

Rough Notes, Ideas, Questions

• What is the current state of the art for mozilla perf testing? Do we have boxes doing this on cron jobs?
• How shall we organize the work?
• Assist Foundation with grants/giving?
• Provide domain expertise to other groups? Mobile? Labs?
  • Bespin, canvas a11y?
• How do the high level Mozilla values and goals prioritize our work and focus, in accessibility? How can we be most effective?
• <video>
  • follow-on implementation of ideas explored in Silvia Pfeiffer's work
• SVG, MathML
• <canvas>
• Firebug Accessibility
  • Accessibility support of FB itself
  • Accessiblity testing support
• xforms -- priority?