Hi Jamie, Sorry I left this thread hanging.
James Teh wrote: > 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 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. >>> >> Yeah. There are a few things we can do to make this more graceful. We >> can detect some AT and versions (looking at the modules loaded into the >> application process) and make good guesses to avoid regressing users of >> older AT. >> > Just FYI, we don't set dll version info for NVDA in-process dlls at present. > > Please start. >> In the absence of this detection, we could still default to >> full support unless someone calls this new API, after which we provide >> the union of the requested support and any other requested support calls >> during the running of the application. >> > I thought you were trying to solve the issue of clients (such as tablet > software) enabling a11y and degrading performance. In that case, this > solution doesn't actually solve anything, as full a11y has to be enabled > anyway. > Ideally there would be some way to detect Tablet PC usage. Note to list (since I know Jamie knows): we are trying to solve that problem and the general problem that accessibility support (especially events) is an all or nothing deal == wasteful. > >> Then the worst case scenario is a user of an undetected AT "foo" also >> has a tool that requests minimal accessibility and has no other tool >> running which requests the functionality needed by "foo". We could maybe >> solve this by offering a free download of a tool that just requests >> functionality. >> > Having downloadable tools to do x and y for a11y is really ugly. As a > user, I don't want to have to mess around with this. It makes the > software highly unattractive to me. > > Btw, there's also the case of multiple ATs running simultaneously. A > user shouldn't use multiple ATs of the same type, but they might well > use multiple different types of AT, all with differing requirements. > Some might know about this new API, others might not. Those that don't > might break when those that do disable features that are required by the > former. > The way I see this working, nothing would break (see my previous message about the 'union' of requested support). cheers, David _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
