Judson Valeski wrote:
> Perhaps a general description regarding the approach to "accessibility"
> you're taking is in order.
We are initially adding accessibility support to Gecko by writing an MSAA server for
it. MSAA is the widely accepted accessibility API for Windows, the only OS platform
that has such an API. (Java has one, and other OS platforms may have one, but they
don't seem to have been widely accepted.) Third-party accessibility aids use MSAA
clients to get the information they need, and to navigate and control the app. Some
aids have custom support for products like IE, or use other proprietary APIs, but we
will not be addressing this initially.
> This also raises the issue of dialogs. We currently have some embedding
> customers which do not use our dialogs at all. In that case, persumably
> they're responsible for making whatever dialogs they provide "accessible.?"
Yes, any UI they pose, they would be responsible for making accessible. We have
already verified that our MSAA server solution works seamlessly across the embedding
boundary.
> So if we break what needs to be "accessible" into two categories (is
> this categorization accurate?); dialogs, and content. I suspect we're
> putting most steam behind making the content "accessible?" As the
> UI/dialog stuff is up to the embeddor.
Yes, we are concentrating on making Gecko accessible; the chrome will have to wait,
although much of the infrastructure will be used by the chrome as well.
> If that's the case, then it's largely a matter of providing programmatic
> (via nsIPref most likely) access to the prefs which change our "content"
> to meet accessibility needs. Am I on the right path?
I don't know, I may be lost here :-) The pref APIs do figure into our solution, for
changing font attributes, suppressing image display, etc., but I'm not sure if that's
what you mean.
> What about providing content (the document text for example) to the
> outside world (a screen reader/translator which takes text and *reads*
> it to the user)?
Covered by the MSAA server; screen readers are MSAA clients.
> Similair question on the input side. What if I'm blind and have some
> other form of input device other than a mouse? Are we persuing
> programmatic input mechanisms?
This should all just work, as long as we are using standard Win32 APIs for accessing
input devices.
The MSAA work is the bulk of our accessibility solution, but there are other issues,
in keyboard access and navigation for instance, that will also be addressed, mostly
in the current development cycle. Making the chrome accessible is a very large task
that will have to wait for the next cycle. Beyond that, we are hoping to foster a
standards-based, platform-independent API for accessibility.
Eric can certainly fill in the details and answer any questions on MSAA if he has
time (he is critical path on this work). For general accessibility development
issues, I'm very happy to be able to refer you all to Aaron Leventhal, Netscape's
brand-new Accessibility Lead.
Peter
