When authored according to these guidelines, XUL is capable of generating accessible user interfaces. Coders, reviewers, designers and QA engineers should be familiar with these guidelines.
- Don't break the tab order: a) all interactive elements need to be in the tab order, b) the tab order should go from left to right, then top to bottom unless there is a good reason not to. Users should be able to tab into iframes if any exist.
- Ensure sensible focus behavior. The focus must always be visible. Make sure focus never gets lost when a focused element is disabled, hidden or destroyed.
- Ensure full keyboard access. Try to use the feature with the keyboard. Does it require a mouse (e.g. drag and drop)? Is it visual/random access, or is it useable by users that can only take in information sequentially (text-to-speech and braille displays).
- Don't use mouse event listening code such as onclick, onmousein and ondrag without enabling keyboard operation for the same set of features. Consider context menu items or UI widgets with accesskey mnemonics for implemenenting the keyboard functionality.
- Context menus must support the keyboard, via the
VK_APPS
key context menu key. That would also beShift+F10
on Windows,Shift+F10
on UNIX/Linux andCTRL+Space
on OS X. This should be automatically handled byoncontextmenu
-- don't handle the right click directly. - Support accesskeys (mnemonics) on interactive UI widgets. See XUL Accesskey FAQ and Policies.
- Provide global accelerators for common operations. Use the "accel" modifier for keys that should use control on Windows and Linux, and cmd on OS X. Unlike accesskeys, here is no need to localize global accelerators.
- Don't rely on toolbar buttons. Toolbar buttons aren't members of the tab navigation cycle, and they are not members of the menu system either. All toolbar buttons should have their actions duplicated elsewhere.
- Use the tooltiptext attribute on all informative or interactive images (such as buttons), so that they're spoken by screen readers run by blind users, and used by onscreen keyboards to provide lists of options.
- Don't require fast responses (physical reactions, decision making or comprehension) from the user.
- Don't rely on color alone to present information — for example, don't use different colored dots to indicate different states. Avoid low contrast cominations such as blue-green or other color combinations such as red-green that are troublesome for individuals with color-blindness (10% of men).
- Don't break theming. Ensure compatibility with system themes, such as the high contrast theme on Windows (available via Left-alt + Left-shift + Printscreen).
- Avoid small targets which are difficult to see and click on.
- Try to avoid scroll bars. A page that needs to scroll is more complex to navigate than a page (or series of pages) that doesn't need to scroll. Also, neither the scroll bars nor the XUL window or dialog are focusable, so the scroll bars cannot be fully operated with the keyboard. Tabbing will not move the visible view to places where there is nothing focusable.
- Ensure that sortable tree views have a "View -> Sort By" menu. Ensure that tree and list views have full keyboard access to the interactive icons on each line.
- Use the label element or attribute to add text labels to a XUL form control. Don't just use a text node for the label, which requires screen readers to guess where the label is.
- Don't use form controls as the only content for a label. Assistive technologies such as screen readers and onscreen keyboards require a proper label.
- The Escape key should cancel dialogs and close them without changes, acting like a click on the cancel button (if there is one). This should be handled automatically by
<xul:dialog>
. - Ensure a default button in dialogs. The xul:button element uses
default="true"
to indicate this, it should work automatically in a<xul:dialog>
.
Additional Guidelines
- For new shortcut keys, consult the Mozilla keyboard user interface plan and and talk to the accessibility module owner.
- For new widgets (e.g. via XBL or XTF), consult the accessibility module owner.
To learn more about accessibility in Mozilla, see the MDC Accessibility page.