Platform/2009-Accessibility-Goals

WARNING: please see https://wiki.mozilla.org/Platform#Platform_Team_Goals for up to date accessibility platform 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 [p3], higher is [p1].
• [name1, name2, name3] - person names assigned to particular task, names are listed in order of role decreasing, if the name is not listed somewhere then it doesn't mean the person won't pay an attention for this at all, it means this person may not pay an attention.
• [bug link1, bug link2, ...] - links to related bugs.

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 thorough 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], [marcoz, surkov, davidb], [417472, 428950, 462313].

Architecture/Code refactoring

• Incorrect support of AT APIs. [100] [p1], [surkov, MarcoZ], [472809, 461768, 340809, 368895, 475297, 459353].

• Refactor and redesign code where it is necessary so that features can be properly completed, for example, harmonizing tree grid implementation. [50], [p2], [surkov, davidb, MarcoZ], [376943].

• Missed features or markup languages. [20], [p2], [surkov, MarcoZ], [368880].

• Code clean up. [30], [p3], [surkov, davidb], [389800].

New work

• WAI-ARIA 1.0 completeness [p1][davidb, surkov, MarcoZ], [343213]
  • additional events [30]
  • additional semantics [15]
  • spec changes [20]
  • normative changes as other browsers implement ARIA [10]
• HTML 5 (need to update tracker bug 368880) [davidb, surkov, MarcoZ]
  • drag and drop [p2][4]
  • <canvas> [p2][0-20]
  • <video> [p2][?] Need [report] from Silvia.
• SVG [davidb, surkov, MarcoZ]
  • focus, keyboard navigation, bug [409404] [p2][10]
• Mac OS X [p1][davidb, surkov, MarcoZ]
  • performance tracker bug [454202] [20]
  • architecture bug [342989] [20]
  • improvements tracker [336306] [50]
• Mobile [davidb, surkov, MarcoZ]
  • First priority is Symbian support, since the most widely used mobile platform by blind users. Windows Mobile is next, Linux on mobile is far behind in terms of doability and devices that blind people can actually use. Much of this may slip to 2010.
• Performance testing and profiling [p2][davidb, surkov, MarcoZ]
  • Windows [?]
  • Linux [5]
    • run valgrind-like tools and analyze places to optimize.
  • Mac [10] 454202]
    • Shark, Spin Control, Instruments, MallocDebug

Permanent work

• Regression fixes [20] [surkov, davidb, MarcoZ]
• Crashes, Stability [30] [surkov, davidb, MarcoZ]
• Triage [20] [marcoz, davidb]
• Manual testing [20] [marcoz]
• Documentation [20] [surkov, marcoz, davidb]

Community Collaboration

• Standards
  • W3C WAI-ARIA user agent implementor guide. [p1], [davidb, surkov].
    • 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.
  • MathML. [10], [p2], [surkov].
  • SVG. [10], [p2], [davidb, surkov]
• 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. [5], [p2], [davidb, surkov, marcoz].
      • responsiveness to questions on #accessibility. [20], [p1], [marcoz, davidb, surkov].
      • Pursue resources from companies that benefit from FF's accessibility. [2], [p2], [davidb, marcoz].
  • Work with Assistive Tech folks (NVDA, Orca, FS etc)
    • bug triage [10], [p1], [marcoz, surkov, davidb]
• 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], [p2], [marcoz, davidb, surkov].

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?