Accessibility/CustomWidgets

From MozillaWiki
< Accessibility
Revision as of 13:57, 24 April 2008 by Surkov.alexander (talk | contribs) (New page: <small><< Back to Accessibility Home Page</small> =Problem= ==New XML dialects== Gecko provides powerful way to add support for new XML dialects which is based on XTF ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

<< Back to Accessibility Home Page

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 often are interactive, i.e. they have behaviour and can be changed in time. Therefore the widget needs to 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?

What can we do