[Accessibility-ia2] a11y support registry API
mick at kulgan.net
Fri Jul 30 23:34:01 PDT 2010
As noted by others in the past, this kind of thing has major
disadvantages if its not done correctly. I.e. some AT does not know yet,
or has not been updated yet, to use this registration thing.
I am interested though, does Gecko, and other Apps currently make use of the
function in the Windows API?
Granted it can sometimes give false positives, but certainly if there
was no accessibility client on the system listening to a certain event
(say IA2_EVENT_TEXT_INSERTED) IsWinEventHookInstalled would return False.
More info on IsWinEventHookInstalled can be found at:
I would feel much more comfortable knowing that this existing mechanism
was well researched (and used if possible) before we further this
On 31/07/2010 2:43 AM, Pete Brunet wrote:
> David and I chatted on the mozilla irc yesterday. Here is a summary:
> David listed these points as drivers for needing this function:
> - There is a performance problem.
> - There are some commonly installed tools, like anti-spyware that
> invokes the gecko a11y engine which degrades performance for people who
> don't need full a11y
> - It is suspected that not all msaa/ia2 is actually used by AT resulting
> in a lot of needless cpu cycles, i.e. it's a waste to internally handle
> an event and fire it if no AT is listening.
> David believes it would be helpful if some a11y features could be turned
> off, e.g.
> - some tools might only care about focus events and roles
> - some, like GOK, don't care about relations, especially reverse
> relations which are costly to compute
> What questions are needed in order to make the right decisions? Below
> are some possible candidates. These questions would have to be asked
> across a range of applications and ATs.
> - What features if disabled in a server would significantly improve
> performance in the server?
> - What would the user experience be in an AT if those features were not
> - If the AT experience would be acceptable with a feature disabled is
> adding an enablement switch needed to provide an improved UI experience?
> In a system with more than one AT the application would have to
> configure itself based on the highest combined set of demands.
> There would need to be coordination in the community so that when, for
> example, Gecko turns off its switchable features all ATs will be
> prepared to turn on the ones that are needed.
> David Bolter wrote:
>> Are we ready to define the API? Have we resolved concerns? If so, I just
>> want to say that the kind of granularity I am looking for is something like:
>> "focus show hide"
>> FOCUS | SHOW | HIDE
>> Not to suggest events are all we care about.
>> Note:I am also thinking that repeated calls to the API do not unset and
>> support features, but are cumulative.
>> Richard Schwerdtfeger wrote:
>>> suggestion below.
>>> Rich Schwerdtfeger
>>> CTO Accessibility Software Group
>>> accessibility-ia2-bounces at lists.linuxfoundation.org <mailto:accessibility-ia2-bounces at lists.linuxfoundation.org> wrote on
>>> 06/21/2010 01:00:38 PM:
>>>> From: James Teh<jamie at nvaccess.org> <mailto:jamie at nvaccess.org>
>>>> To:accessibility-ia2 at lists.linuxfoundation.org <mailto:accessibility-ia2 at lists.linuxfoundation.org>
>>>> Date: 06/21/2010 01:13 PM
>>>> Subject: Re: [Accessibility-ia2] a11y support registry API
>>>> Sent by:accessibility-ia2-bounces at lists.linuxfoundation.org <mailto:accessibility-ia2-bounces at lists.linuxfoundation.org>
>>>> On 22/06/2010 2:14 AM, David Bolter wrote:
>>>>> - setRequestedSupport([in] long supportBitflag, [out] long
>>>>> This API suggestion is just illustrative. Something like this would
>>>>> allow applications to provide needed support without wasting
>>>>> by also providing unused support. Thoughts?
>>>> This sounds okay. The problem is that in order to preserve backwards
>>>> compatibility with older ATs which don't know about this new API, apps
>>>> will have to enable everything by default anyway, which rather defeats
>>>> the purpose.
>>> Would it be better to have a generic function like this to pass a
>>> string representing the feature we are asking for?
>>> RequestFeature([in] String feature, [out] long feature);
>>> The string could be a set of features. If it were not supported in the
>>> current implementation return a -1.
>>> otherwise you return a value.
>>> Some strings:
>>> future (and I am just making things up)
>>> "filter object tree"
>>> It may be less performant but it is more flexible and gets rid of
>>> versioning problems down the road.
>>>> James Teh
>>>> Vice President
>>>> NV Access Inc, ABN 61773362390
>>>> Email:jamie at nvaccess.org <mailto:jamie at nvaccess.org>
>>>> Web site:http://www.nvaccess.org/
>> Accessibility-ia2 mailing list
>> Accessibility-ia2 at lists.linuxfoundation.org <mailto:Accessibility-ia2 at lists.linuxfoundation.org>
> *Pete Brunet*
> a11ysoft - Accessibility Architecture and Development
> (512) 238-6967 (work), (512) 689-4155 (cell)
> Skype: pete.brunet
> IM: ptbrunet (AOL, Google), ptbrunet at live.com <mailto:ptbrunet at live.com>
> Ionosphere: WS4G
> Accessibility-ia2 mailing list
> Accessibility-ia2 at lists.linuxfoundation.org
email/msn/jabber: mick at kulgan.net
More information about the Accessibility-ia2