XUL accessibility tool

General Information

The XUL Accessibility Tool is a Firefox extension designed by Aaron Andersen of WebAIM as part of a Mozilla Foundation accessibility minigrant in the spring of 2007. It is designed to test (insofar as automated testing is possible) the guidelines and requirement for creating accessible XUL as set forth in the XUL accessibility guidelines, and to report on any problems found in tested documents. While not meant to be a comprehensive test suite (meaning that passing all included tests does not guarantee that an application is free of accessibility bugs or issues), many of the most common accessibility mistakes will be found and reported.

Availability

The XUL Accessibility Tool can currently be obtained from [http://www.xulplanet.com/aaron/files...bilitytool.xpi]. Future versions of the extension will be available from addons.mozilla.org. The version currently on XulPlanet is compatible with the following XUL applications:

  • Firefox 1.5+
  • Thunderbird 3.0a+
  • Recent Sunbird builds
  • Recent Songbird builds.

It probably also works on Seamonkey, but I haven't verified this.

Use

To launch the tool after installation, look for an entry in the Tools menu of the host application, or hit Ctrl+Alt+Shift+F12. Once the tool window has loaded, select either a local file, web url, or currently open window from the File menu to generate a XUL report for that document. Be aware that the report might take a little while to be ready depending on the complexity of the application being analyzed and the speed of your machine.


Future Work

The following things have been suggested or are planned for a future version of the tool:

  • New Tests:
    • (aaronlev) Warning: hardcoded color and pixel sizings
    • (aaronlev) Error: Duplicate accesskey in a dialog (already have this for menus)
    • (aaronlev) Error: form control without accesskey
    • (aaronlev) Warning: Accesskey as lowercase letter with descender (underlined g,j,y,q,p are hard to read, not recommended)
    • (aaronandy) List of things to check manually, such as a list oftrees in the document (make sure they have accessible column picker equivs) or a list of toolbarbuttons (make sure they have accessible alternatives).
  • New Features:
    • (aaronlev) Automatically test any new windows as they are opened.
    • (aaronandy) Highlight or blink source element in original XUL app upon click of referencing line in report.
    • (aaronlev) Compatibility with more XUL Applications. (aaronandy) Maybe an online tool to automatically generate a XUL A11y Tool compatible with a user-specified XUL app.
    • (aaronandy) Link report sections to relevant part of XUL A11y Guidelines.
    • (aaronandy) Enable tabs, context menu, and other browser extras in report window.
    • (aaronandy) XUL Runner version that can run from the command line, check a text file, and output the results somewhere.
  • Known Bugs:
    • Test for lowercase I or L as accesskey (sometimes?) flags upppercase I and L too.
    • Possible false positives in some of the other tests
    • Processing is slower than we would like.


Ideas for further work on XUL a11y

Some general ideas for using the tool and guidelines to further the accessibility cause within the Mozilla Project.

  • Add usability, i18n, security and other considerations to XUL a11y guidelines -- make them more general
  • Sprinkle the a11y techniques throughout the turorial and reference.
  • Run checking tool on Firefox, Thunderbird and other apps looking for bugs and fixing them. Improve tool along the way
  • Add checking tool to DOM Inspector or other popular XUL debugging tools. Merge with other XUL checking tools -- this doesn't need to be a11y-specific. One problem is that Mark Finkle's XUL Validator tool uses a different engine.
  • Add the tool into the addons.mozilla.org review process
  • Go through the most useful/popular extensions with tool and fix a11y issues
  • Add checker to tinderbox so that bugs are caught at checkin time

Some or all of this work could be done through grants, and a likely person to oversee the grant deliverables and milestones would be Mark Finkle. He has volunteered to take that on.