Thanks Jamie, That may be a problem for the case where the app has multiple threads and a secondary thread needs to be called by the window proc to participate in the building of the accessibility tree. Is it acceptable to block the UI thread? -Pete
James Teh wrote: > On 25/05/2010 4:26 AM, Pete Brunet wrote: >> It seems there was talk at one time of a "screen reader present" flag, >> or more correctly an "assistive technology present" flag. Was this ever >> implemented? > There has been a system screen reader flag in Windows for a long time > now. See the SPI_GETSCREENREADER and SPI_SETSCREENREADER values for > uiAction in the SystemParametersInfo function: > http://msdn.microsoft.com/en-us/library/ms724947%28VS.85%29.aspx > > However, this flag is trouble and should not be relied upon. (Some > applications such as Skype do rely on it and we've had all sorts of > trouble as a result.) The problem is that it is a system wide flag and > it is not intelligently tracked in any way. A screen reader sets it on > startup and clears it on termination. If the screen reader doesn't > terminate gracefully, it remains set. If you start two screen readers > and then exit one, it will be cleared, even though there's still > another screen reader running. From a principle standpoint, it > encourages developers to do silly things such as drastically changing > their visual UI when a "screen reader" is detected, rather than > implementing correct, unobtrusive accessibility. > > The better solution is to watch for WM_GETOBJECT and enable > accessibility APIs dynamically. > > Jamie > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
