Platform/2009-Accessibility-Goals: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(created)
 
No edit summary
 
(65 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=== What is this? ===
<div class="warning">WARNING: please see https://wiki.mozilla.org/Platform#Platform_Team_Goals for up to date accessibility platform goals. </div>


Let's try and capture on this page the work and goals we have for 2009.


=== Gecko ===
== What is this? ==


* Bugfixing of course.
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.
* WAI-ARIA 1.0 completeness
* HTML 5 related accessibility
* Performance testing and profiling
* Code refactoring
** Maybe best to do in small iterations, as we go.
* Get Mac accessibility to point where we it is included in default builds.
** Is lazy instantiation easy on Mac?


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


* W3C work: WAI-ARIA user agent implementor
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], [[https://bugzilla.mozilla.org/show_bug.cgi?id=417472 417472], [https://bugzilla.mozilla.org/show_bug.cgi?id=428950 428950], [https://bugzilla.mozilla.org/show_bug.cgi?id=462313 462313]].
 
==== Architecture/Code refactoring ====
 
* Incorrect support of AT APIs. [100] [p1], [surkov, MarcoZ], [[https://bugzilla.mozilla.org/show_bug.cgi?id=472809 472809], [https://bugzilla.mozilla.org/show_bug.cgi?id=461768 461768], [https://bugzilla.mozilla.org/show_bug.cgi?id=340809 340809], [https://bugzilla.mozilla.org/show_bug.cgi?id=368895 368895], [https://bugzilla.mozilla.org/show_bug.cgi?id=475297 475297], [https://bugzilla.mozilla.org/show_bug.cgi?id=459353 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], [[https://bugzilla.mozilla.org/show_bug.cgi?id=376943 376943]].
 
* Missed features or markup languages. [20], [p2], [surkov, MarcoZ], [[https://bugzilla.mozilla.org/show_bug.cgi?id=368880 368880]].
 
* Code clean up. [30], [p3], [surkov, davidb], [[https://bugzilla.mozilla.org/show_bug.cgi?id=389800 389800]].
 
==== New work ====
* WAI-ARIA 1.0 completeness [p1][davidb, surkov, MarcoZ], [[https://bugzilla.mozilla.org/show_bug.cgi?id=343213 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=368880 368880]) [davidb, surkov, MarcoZ]
** drag and drop [p2][4]
** &lt;canvas&gt; [p2][0-20]
** &lt;video&gt; [p2][?] Need [[https://wiki.mozilla.org/Accessibility/Video_Accessibility report]] from Silvia.
* SVG [davidb, surkov, MarcoZ]
** focus, keyboard navigation, bug [[https://bugzilla.mozilla.org/show_bug.cgi?id=409404 409404]] [p2][10]
* Mac OS X [p1][davidb, surkov, MarcoZ]
** performance tracker bug [[https://bugzilla.mozilla.org/show_bug.cgi?id=454202 454202]] [20]
** architecture bug [[https://bugzilla.mozilla.org/show_bug.cgi?id=342989 342989]] [20]
** improvements tracker [[https://bugzilla.mozilla.org/show_bug.cgi?id=336306 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] [https://bugzilla.mozilla.org/show_bug.cgi?id=454202 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
* Evangelism
** mothering #accessibility
** Cultivate patch contributors
** work with Assistive Tech folks (NVDA, Orca, FS etc)
*** To provide our users with a good web experience we need a larger team. The proven way to do this is via a combination
*** help triage GNOME FF bugs
**** Foundation mini grants. [5], [p2], [davidb, surkov, marcoz].
* Cultivate patch contributors
**** 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 ===
== 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?
* What is the current state of the art for mozilla perf testing? Do we have boxes doing this on cron jobs?
Line 29: Line 89:
* Assist Foundation with grants/giving?
* Assist Foundation with grants/giving?
* Provide domain expertise to other groups? Mobile? Labs?
* 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?
* How do the high level Mozilla values and goals prioritize our work and focus, in accessibility? How can we be most effective?
* SVG, MathML, <video> ...
* &lt;video&gt;
** follow-on implementation of ideas explored in [http://blog.gingertech.net/ Silvia Pfeiffer]'s work
* SVG, MathML
* &lt;canvas&gt;
* Firebug Accessibility
** Accessibility support of FB itself
** [http://wiki.codetalks.org/wiki/index.php/Firebug_Accessibility_Roadmap Accessiblity testing support]
* xforms -- priority?

Latest revision as of 15:38, 14 September 2009

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

  • 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>
  • SVG, MathML
  • <canvas>
  • Firebug Accessibility
  • xforms -- priority?
Retrieved from "https://wiki.mozilla.org/index.php?title=Platform/2009-Accessibility-Goals&oldid=168166"