I agree with Jamie. An application shouldn't special case anything wrt it's accessibility API implementation depending on such a "screen reader present" flag.
It doesn't matter who is asking for the information for what ever reason. Someone asks for information, so he should get it. When we started to implement the accessibility API in OpenOffice.org, we also thought that it would be helpful to figure out whether or not AT is running - to avoid some expensive stuff. Nowadays I think the implementation shouldn't be so "expensive" when objects are created on demand only. I don't know how the reality in OOo really looks like now, but in theory it should be this way: - If nobody asks for the root accessible, is doesn't need to be created. - If someone asks, create it - but only that one object - When asked for children, create objects on demand - If some object's state change, see if a corresponding accessible object exists, otherwise don't create the information needed for notifications. So in the end - if no one asks you to generate the tree, it's up to you to do the time consuming and memory extensive stuff on demand only. That's only my theory of this - I guess it doesn't look so in OOo now, but it probably could. The main reason that we still have an "enable AT support" option in OOo on Windows is that we don't have MSAA/IA2 yet, and still use JAA. So in case of AT support we fake to be a Java application, and only for that reason we need to launch a JavaVM in startup, which is too time consuming to do it for everybody. The "enable AT support" probably also is helpful for us on GNOME, because our UAA/ATK bridge would probably result in creating the full hierarchy and events even if no screen reader asks for information, because the bridge would then be listener on all objects. But even that could probably be optimized, so the bridge could do this also on demand only... One situation where I somewhat agree with Andres's argument "can involve extra GUI": Some GUI actually might change, e.g. check boxes add the text "(on/off)". But I don't think that it's helpful to change the GUI in this way when a Screen Reader is present. The screen reader will read the state anyway, so adding the text to the GUI string might make it even more difficult, because the screen reader needs to ignore it. So while I think such kind of GUI changes might be reasonable for other situations/needs, a "screen reader present" flag is not the best choice here. And if the application has some complex custom GUI, which needs to be different for screen reader users, they should use some application or system setting (like AT support), but not rely on whether on not a screen reader is active. If the screen reader is started after the application, that doesn't work anyway. And the complex GUI might also be unusable to screen magnification or mouse/keyboard replacement users... So I think it's can be reasonable to have a flag for AT support on/off, but then you shouldn't need an other one to determine if a screen reader is running - which is only one of many possible AT anyway... Just my two cents (well, it's a large mail, so maybe 2 EUR), Malte. James Teh wrote, On 05/26/10 00:01: > On 25/05/2010 11:46 PM, Andres Gonzalez wrote: >> WM_GETOBJECT is NOT a reliable way of detecting AT either, since it may >> be triggered by apps and even device drivers that don't have anything to >> do with AT > If an app sends WM_GETOBJECT, it clearly wants accessible or native > objects, otherwise it wouldn't send the message. Regardless of whether > it is an AT, it is requesting the info for a reason. The accessibility > hierarchy is not supposed to be specific to any particular type of AT; > it should just expose objects according to the spec. > > Jamie > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
