QA/Mozmill Test Automation/Accessibility Tests

Overview

Lead:	Marco Zehe
Co-workers:	Henrik Skupin
Dates:	n/a
Status:	Early stage
Repository Location:	Accessibility Tests
Tracking Bug:	bug 565200

Excerpt

The accessibility tests will exercise different UI elements and perform checks of proper XUL markup so that the underlying accessibility APIs will properly expose dialog and window content to screen readers.

Project Details

The Basics

The Mozmill tests will perform testts like requesting the accessible object for a window or dialog element, such as a checkbox, textbox or toolbar button, and ask for its accessible name and possibly other properties. The accessible name is the label for each control. On a checkbox, this is the visible text. On a textbox, this is the label associated with that textbox. On a toolbar button, this is the associated tooltip text.

The Mochitest suite exercises checks like "does the API create an accessible name for a textbox accessible object if a xul:label with a control attribute pointing to the xul:textbox element is present?".

The Mozmill tests will perform checks that make sure that the markup actually used within Firefox (and possibly other Gecko-based apps) is correct XUL markup so the UI is properly exposed to assistive technology products.

The idea of combining this with the work for localization testing

The principle is simple: Each UI element that has text needs to be checked for accessibility properties. This is true also for localization tests. So, the idea was born to use a combined API that allows both l10n and a11y test suites to walk the UI hierarchy and perform their tests. For accessibility, possibly some more elements need to be checked, for example both a label and an associated textbox, but the general principle is the same.

The final goal

The final goal, of course, is to be able to catch errors in XUL semantics within our products, to avoid having unlabelled textboxes or other similar controls. Also, changes in XUL that may break existing correct semantics will be detectable.

Detailed requirements

The controls

The test walker will start from a XUL:window or xul:dialog or other root element that constitutes an UI compound construct (like a window or dialog) and will walk the tree down into each control. For each focusable control, an accessible object is requested and its name property checked if it contains text. It does not matter which text is there, just that there is text at all.

The following controls have their own name from an embedded attribute of the element:

• button
• checkbox
• radio button
• label
• description
• menuitem
• window
• dialog
• tab
• toolbarbutton

The last two can also have the name given through inner text instead of the value attribute.

The following controls need their accessible name through a different element. Normally, this is given through the xul:label element with its control attribute pointing to the actual control's ID.

• textbox
• menulist
• listbox
• radiogroup
• slider
• tree

If no label is present, the name can also be given by means of WAI-ARIA (for example through the aria-labelledby attribute).

The actual tests

Each of the above controls must be checked for an accessible object's name property.

• If present, the test can be considered a pass.
• If not present, something is potentially wrong, and the test should be flagged as not pass.
• There may be constructs which mean there is no actual label (not even visually), for example when dealing with the URL textbox of the Media tab in the Page Info dialog. For these exceptions, a flag must be provided that tells the test run that a particular control is OK with not having a name.