The following is a summary of following discussion of the registry API
on a separate thread starting at:
https://lists.linux-foundation.org/pipermail/accessibility-ia2/2011-June/001334.html
Arnstein
- a feature will be disabled if you don't include it in the "features"
argument?
Alex
- Right, I think I'd like to whitelist features, this allows to keep
a11y really light.
Jamie
- this has the potential to cause major problems for multiple ATs.
- a user might use a screen reader and a magnifier.
- If one AT exits and another starts without quitting apps first, there
could be problems.
- IsWinEventHookInstalled() should definitely be investigated thoroughly
as a solution before considering an API.
Marco
- Re registry API: ref-counting is in order
- However, older ATS will not implement this new registry
- so customers not purchasing upgrades for their AT will eventually lose
access to FF and other IA2 apps
I agree with Mick and Jamie. David, Can you ask the Mozilla team to
investigate using IsWinEventHookInstalled before we proceed further?
Earlier David contacted me with some other issues...
1) There are some AT, like GOK, that don't care about relations,
especially reverse relations which are costly to compute.
- Is there a way for the Gecko code to not compute the reverse
relations until requested?
2) 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
- Is the solution we are proposing the only solution? Is this because
the anti-spyware code is causing a WM_GETOBJECT? Is this a bug that
needs to be fixed in the anti-spyware code?
Are there any other well understood performance issues for which it is
felt this proposal is the best solution for?
Pete
--
*Pete Brunet*
a11ysoft - Accessibility Architecture and Development
(512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G
On 7/31/2010 1:34 AM, Michael Curran wrote:
> 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
> IsWinEventHookInstalled
> 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:
> http://msdn.microsoft.com/en-us/library/dd318528%28VS.85%29.aspx
>
> I would feel much more comfortable knowing that this existing mechanism
> was well researched (and used if possible) before we further this
> conversation.
>
> Thanks
> Mick
>
> 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
>> available?
>> - 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.
>>
>> Pete
>>
>> 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"
>>> or
>>> 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.
>>>
>>> cheers,
>>> David
>>>
>>> Richard Schwerdtfeger wrote:
>>>
>>>> suggestion below.
>>>>
>>>>
>>>> Rich Schwerdtfeger
>>>> CTO Accessibility Software Group
>>>>
>>>> [email protected]
>>>> <mailto:[email protected]> wrote on
>>>> 06/21/2010 01:00:38 PM:
>>>>
>>>>
>>>>> From: James Teh<[email protected]> <mailto:[email protected]>
>>>>> To:[email protected]
>>>>> <mailto:[email protected]>
>>>>> Date: 06/21/2010 01:13 PM
>>>>> Subject: Re: [Accessibility-ia2] a11y support registry API
>>>>> Sent by:[email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>> On 22/06/2010 2:14 AM, David Bolter wrote:
>>>>>
>>>>>> IApplicationAccessible
>>>>>> - setRequestedSupport([in] long supportBitflag, [out] long
>>>>>> supportedBitflag);
>>>>>> This API suggestion is just illustrative. Something like this would
>>>>>> allow applications to provide needed support without wasting
>>>>>>
>>>> performance
>>>>
>>>>>> 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:
>>>>
>>>> "EnableIA2"
>>>>
>>>> future (and I am just making things up)
>>>>
>>>> "filter object tree"
>>>> "limittovisiblearea"
>>>>
>>>>
>>>>
>>>> Rich
>>>>
>>>>
>>>> It may be less performant but it is more flexible and gets rid of
>>>> versioning problems down the road.
>>>>
>>>>
>>>>> Jamie
>>>>>
>>>>> --
>>>>> James Teh
>>>>> Vice President
>>>>> NV Access Inc, ABN 61773362390
>>>>> Email:[email protected] <mailto:[email protected]>
>>>>> Web site:http://www.nvaccess.org/
>>>>> ___________
>>>>>
>>> _______________________________________________
>>> Accessibility-ia2 mailing list
>>> [email protected]
>>> <mailto:[email protected]>
>>> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>>>
>>>
>>>
>> --
>> *Pete Brunet*
>>
>> a11ysoft - Accessibility Architecture and Development
>> (512) 238-6967 (work), (512) 689-4155 (cell)
>> Skype: pete.brunet
>> IM: ptbrunet (AOL, Google), [email protected] <mailto:[email protected]>
>> (MSN)
>> http://www.a11ysoft.com/about/
>> Ionosphere: WS4G
>>
>>
>>
>> _______________________________________________
>> Accessibility-ia2 mailing list
>> [email protected]
>> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
