Qt Accessibility Future Improvements

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Potential changes in the Qt Accessibility framework in Qt 5

This is just a list of points to be discussed. Nothing is set in stone yet.

• WebKit: Exposes a tree of Groups and StaticTexts, similar to QML. There are of course no QObjects. Each accessible item still needs an id. How to unify QML, QWidget, and Webkit accessibility?
  • Non-QObject id for all items. No ids can be casted to QObject. (create mapping from id <-> object internally)

' QObject id for all items. All ids can be casted to QObject (create QObjects where needed, create mapping for those) ' QObject id for some items. Some ids can be casted to QObject- What the ids are depend on the implementation: QObject, QWidget, or [WebKit thing]. Introduce qaccessibility_cast? Must make sure there are no collisions - if all ids are based on allocated memory then this is guaranteed.

• Value interface misses "minimumIncrement" function

Relations

• When we have removed navigate, we can also clean up the RelationFlag to only contain enum values that are needed for relationTo.

• Relations: there should be a getter to get all relevant relations for an accessible.

• Add a way to list all enumerations for an interface (not only the relation between two interfaces)

 virtual QList<QPair<QAccessibleInterface*, Relation> > relations() const = 0;

• Problem is that the functionality the above proposal is that its functionality overlaps with relationTo(), so the implementations must be kept in sync.
• There are also other problems (unrelated to the above suggestion) such as different QAccessibleInterface implementations must be kept in sync. For instance, QAccessibleApplication::relationTo have code to check if the "other" interface is a top level widget. If it is, then the returned relation is Ancestor. However, that implementation must be kept in sync with QAccessibleWidget::relationTo, where the "other" interface is a QAccessibleApplication. If it is, then the returned relation is Child. It should be enough to implement for instance the Child relation. The bridge can deduce Ancestor relation from that. This is also the case for Label, Labelled and Controller, Controlled. (Covers, Covered seems not to be used by any bridges, so it should be considered deprecated/removed)
• Another problem is what if I write my own QAccessibleInterface for my widget (QAccessibleMyWidget), and register that in the accessibility framework. How can QAccessibleWidget::relationTo(myWidget) know that new relation, since its only defined by QAccessibleMyWidget. Is there anything we can do in order to support this?
• Finally, the behaviour of relations() and relationTo() should (must?) sometimes be kept in sync with navigate(). If the QAccessibleWidget::relationTo() implementation returns Ancestor for myMidget, shouldn't then QAccessibleWidget::navigate(Child, entry, &iface) be able to return a QAccessibleMyWidget instance?

Maybe we can get rid of navigate totally, and just use relations?

Unique ID

• Replace uniqueId() with object(), since some implementations might not have QObjects (e.g. webkit). We could still keep object as a convenience.

 virtual void *uniqueId() const = 0;
 virtual QObject '''object() const = 0;

Or, alternatively

 /*!
 This returns a unique id. It could have a unique/registered prefix for different types of objects.
 For instance, it could return "WebKit_0x12345678" for webkit or "QObject_0x12345678" for QObject.
 */
 virtual QByteArray uniqueId() const = 0;

QAccessibleTextInterface

Consider to change

 QString attributes(int offset, int *startOffset, int *endOffset) = 0;

to something like:

 QMap<AttributeType, QString> attributes(int offset, int *startOffset, int *endOffset) = 0;

this will make it more machine-readable-friendly, and will impose no big penalty for the IA2 bridge.

Providing an IAccessible2 bridge for Windows.

Since we're now having some IAccessible2 specific interfaces implemented, it makes sense to also expose that information through IA2 in the windows-bridge. This should hopefully allow us to keep the same codebase for Linux and Windows, (right now there is a subclass for QAccessibleTable2Interface for Linux and a subclass of QAccessibleInterface for Windows).

According to this page "All major screen readers were implementing IAccessible2 support: NVDA, JAWS, SuperNova, and Window-Eyes. Additionally AccProbe and Freedom Scientific's Magic support it as well. […] Representatives from GW Micro and Freedom Scientific stated that IAccessible2 is only one tool in their arsenal to provide access. "

So it seems like IA2 has become quite common on Windows..

Accessibility model specification

We should specify an "accessibility model" that helps implementors of bridges to get the information they are looking for, and the same model should be available so that we know that implementors of UI controls actually follows the contract. This could actually be enforced by autotests. Here is a simple example: