Accessibility/CustomWidgets
<< Back to Accessibility Home Page
Contents
Introduction
The article is aimed to draw an approach how to make custom widgets accessible. This is early draft version and it's not finished yet.
Problem
New XML dialects
Gecko provides powerful way to add support for new XML dialects which is based on XTF and XBL usage. The great example of this is XForms distributed as Firefox extension. Even some XForms code is integrated with Gecko but it doesn't mean the extension approach to introduce new XML dialects won't work in general. In order to make XForms accessible we had been forced to integrate the XForms support into accessibility module of Gecko so that we introduced new C++ classes and put them into class hierarchy. It means we have not easy way to make accessible new XML dialects especially if XML dialect is provided by 3d party.
XUL extensions
Often Mozilla-based application developers introduce new XUL elements for specific proposes of their applications. The main approach to make new XUL elements is to use XBL. Currently all they have is to use ARIA to make their widgets accessible.
How can ARIA help
ARIA provides attributes set to give a hint to the browser how to expose specific element to AT. Custom widgets are often interactive, i.e. they have behaviour and can be changed in time. Therefore the widget can operate with ARIA attributes dynamically to reflect the current state is to. This requirements fits with XBL very well. The widget can watch for events and change attributes.
Why isn't ARIA enough?
Widget may want to have full control over accessible object which is created for. The following scenarios show possible usecases where ARIA can't be used:
Control accessible operations
For example, xforms:trigger (analogue of button in HTML and XUL) provides click action and xforms:item (may be analogue of HMTL option element) provides selectaction. Here we could use ARIA to set up role on the widget and add some code into accessibility code to expose specific actions to AT for the chosen role but we don't know what events we should listen to fire proper events to AT. So that HTML uses click, XUL uses command and XForms uses DOMActivate. We can't be sure what events can be used for the specific widget.
Control the accessible tree
Some widgets may want to control the accessible tree underneath them. For example, xul:textbox doesn't expose html:input element that is used as a base for xul:textbox. Another example is xul:select@apperatance="compact" (analogue of html:select) which can have hierarchical DOM sturcture but it is exposed to AT as linear structure. So custom widgets should have control over its tree and decide which accessible should be created, which not.
Complex rules to calculate accessible properties
For example, any XForms control element has associated label when the xforms:label element is placed as direct child of that control. XUL provides the support of labels by placing control attribute on the element that points to the xul:label element. So every XML dialect provides own rules to calculate accessibility properties. It's not the task for ARIA.
What can we do
The one possible approach is to extend XBL specification in order to put there an ability to control accessible properties. For example, it can require to introduce new XBL tags like:
<binding id="">
<content>
</content>
<implementation>
</implementation>
<accessible implements="accessible, accessibleText">
<property name="actionCount" readonly="true">
return 1;
</property>
<method name="actionName">
<body>
return "click";
</body>
</method>
</accessible>
</binding>
