Perhaps a general description regarding the approach to "accessibility"
you're taking is in order. My understanding (which is less than minimal)
is that there are 3rd party accessibility products in the marketplace.
These products traditionally "hook-into" an application, on windows at
least, using win32 apis to manipulate text size, color... perhaps they
make text in a dialog audible, etc? That would imply to me that if we
want to support these kinds of products, that we would need to provide a
win32 wrapper around our widgets. Are we doing this? Or is our angle of
approach to provide the ability to get at these settings (dialog
contents, fonts, colors, etc) via a public accessibility type API, which
someone else (an embeddor for example) would drive. This approach would
basically put the onus on the embeddor to decide what to expose/support
(assuming we have the underlying support of course).
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.?"
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.
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?
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)?
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?
Eric Vaughan wrote:
> Judson Valeski wrote:
>
>> We discussed
>> <http://www.mozilla.org/projects/embedding/apiReviewNotes.html#Accessibility>,
>> briefly, accessibility at the API review meeting today. We used
>> Aaron's posting to .embedding/.porkjockeys as a starting point.
>>
>> Some questions:
>> 1. Is the general approach that all accessibility functionality
>> occur's application wide (across all windows)? Or are there certain
>> things that need to be changed/toggled on a top-level window basis?
>>
> I believe accessibility must work across all top level windows.
Excellent! This makes our lives easier in general :-).
> My current implementation already supports this.
What have you put together? Just curious.
>> 2. Any frame level accessibility needs?
>>
> Most accessibility needs can be implemented with XBL. However some
> frames will need to implement accessibility directly. One example is
> Rod's combo box. It should return an accessible tree that looks like
> Explorer's combo box.
Hmm, so it sounds like you're putting an architecture together which
exposes "accessible" objects in tree form. Is the idea that I would get
the root accessible interface from a document, and manipulate it's
subobjects (or the root itself) using some defined accessible api?
Thanks,
Jud
