[EMAIL PROTECTED]">Can someone ellaborate on that last sentence. What is meant by the "embedding boundary" in this context? Is the MSAA server some daemon we implement that uses win32 apis to drive accessibility things? What would these "things" be?Judson Valeski wrote: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.
[EMAIL PROTECTED]">That's what I'm getting at. Cool, so nsIPref sounds like it will be your "this is how the global accessibilty settings are changed," solution. I'm lost WRT what there is beyond that. I guess my confusion is coming from what an MSAA server is and does.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.
[EMAIL PROTECTED]">ok, it's sounding like an MSAA server is something that provides "content" via it's server apis.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.
[EMAIL PROTECTED]">way cool!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?
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.
[EMAIL PROTECTED]">understood, just trying to feel it out.Eric can certainly fill in the details and answer any questions on MSAA if he has
time (he is critical path on this work).
[EMAIL PROTECTED]">Thank you,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.
Jud
[EMAIL PROTECTED]">
