On 22/06/2010 4:33 AM, Alexander Surkov wrote:
> In this light reverse API makes more sense - disable what you don't
> need :)
I still don't see how this solves the case you are trying to solve. As I
understand it, current ATs don't really need this feature, but
applications such as tablet softwa
suggestion below.
Rich Schwerdtfeger
CTO Accessibility Software Group
accessibility-ia2-boun...@lists.linuxfoundation.org wrote on 06/21/2010
01:00:38 PM:
> From: James Teh
> To: accessibility-ia2@lists.linuxfoundation.org
> Date: 06/21/2010 01:13 PM
> Subject: Re: [Accessibility-ia2] a11y supp
On 22/06/2010 4:42 AM, David Bolter wrote:
>>> 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 preser
In this light reverse API makes more sense - disable what you don't
need :) The problem is to decide what to enable/disable and perhaps
proper engine creation to track what was requested by AT and what
wasn't, and watch lifecycle of AT.
Alex.
On Tue, Jun 22, 2010 at 3:00 AM, James Teh wrote:
> O
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
>
I'd like to explore the topic of having a programmatic way of requesting
(client) and supporting (server) accessibility features. I'm thinking of
something like:
IApplicationAccessible
- setRequestedSupport([in] long supportBitflag, [out] long
supportedBitflag);
This API suggestion is just i
