Accessibility/Whitelist
From MozillaWiki
Contents
Problem
Our accessibilty module is intended as a solution for assistive technology (AT). Tools that are not AT invoke our engine, but need only a portion of what we provide (incurring performance cost).We do not want to regress our solution for AT at all. We don't want to completely break non-AT. We want to improve peformance for all cases but this topic is specifically about keeping known AT safe from any risky performance improvements.
Proposal
- Develop a list of AT that we can detect, and a method of detecting them.
- Figure out what baseline accessibility is required by non-AT.
- Manage expectations; put the word out there (blog etc)
Implementation
Baseline Features
Non-AT tools: anti-spyware, auto form tools, tablet pc...
We need to figure out the list of requirements for these tools:
| Required Feature | Confirmed? | Notes |
|---|---|---|
| focus events | yes | we just know this (e.g. 521973) |
| value change events | |
|
| IAccessibleText (!) | |
Lingspeak3 (contact nick: RaZiel) |
| |
|
|
And things we know they don't need:
| Unused Feature | Confirmed? | Notes |
|---|---|---|
| text events | |
bypassing should help perf |
| mutation events | |
bypassing should help perf |
| |
|
|
| |
|
|
Additional Implementation Ideas
Investigate a lossy throttle for our event queueing and firing, for non-AT only.
