Welcome to the XUL Accessibility Guidelines. By following these principles and practises, you will be able to write you XUL application in such a way that all individuals, including those with physical, sensory, or communicative disabilities, with be able to use and enjoy them. Accessibility is not difficult, but does require a basic understanding of the different types of disabilities, commonly used assistive technologies, and special accesssibility features built into the XUL languages. Most of all, accessibility requires a concious effort on your part, and a desire to include everyone.
It is hoped that these guidelines will be sufficiently clear and detialed that everyone--even someone with no previous background in accessibility--can understand them. However, these is an active community of accessibility developers within the Mozilla Project that will be happy to help you with any converns or questions you have in regards to making your XUL fully accessible.
|Accessibility||Platform Features||Mozilla Community|
|Software Accessibility - Where Are We Today? Intro to accessibility, assistive technologies, and Mozilla resources.
Introduction to Web Accessibility. Overview of web accessibility from WebAIM.
Dive Into Accessibility. Downloadable book on web accessibility with tips and character sketches.Technology Compatibility. List of popular assistive technologies and their respective compatibility levels with XUL.
|Apple Accessibility. Portal to Apple accessibility.
LARS (Linux Accessibility Resource Site). Portal for general Linux accessibility.Microsoft Accessibility. Portal for Microsoft accessibility.
|Accessibility - MDC. Accessibility hub on the Mozilla Developer Center.
mozilla.support.accessibility. Mozilla accessibility newsgroup.#accessibility. Accessibility channel on mozilla's IRC server.
Keyboard access is important to users who can't use a mouse. Many screen reader users and those with physical disabilities rely on the keyboard as their primary input tool. These users require easy, predictable, and well documented keyboard control.
Provide a logical tab order and ensure that users can navigate all content using a keyboard. By default, the tab order is determined by the reading order of the underlying code. It can also be set programmatically with the tabindex attribute if needed, but the tabindex should be used sparingly and pages that used the tabindex should be tested thoroughly. The navigation order should be logical in order, generally left to right, top to bottom. Navigation order may vary depending on the nature of the application or the reading direction of the language.
Ensure that tab order is logical and all interactive elements can be accessed simply without the use of a mouse. You should be able to perform all functionality either directly in the application or through menu items or the context menu.
Provide alternative functionality for inaccessible operations. The column picker and column headers in XUL trees are not keyboard accessible, consistent with the standard tree behavior on most contemporary operating systems. It is therefore necessary to provide a keyboard accessible alternative for accessing this functionality.
The Firefox "Bookmarks Manager" provides an example of how to make trees more accessible. The bookmark manager allows users to sort bookmarks by a particular column of information and choose which columns to display. Because column headers and the column picker, in the upper right hand corner of the tree, can not receive focus, they are not operable with a keyboard. In the bookmark manager this functionality is available under the view menu which is accessible to a keyboard user.
Toolbar buttons cannot receive focus with a keyboard. Functionality associated with a toolbar should be duplicated elsewhere in the application, such as in a menu item or context menu. In cases where duplication of functionality is not possible (such as a window without a menubar), toolbar buttons can be made focusable by adding class="tabbable" or with the special CSS rule -moz-user-focus: normal; this should only in extreme cases, and should be consistent within the window or application (meaning that either all toolbar buttons are tabbable or none of them are, but not an arbitrary mixture of both).