Revision Content

Introduction

Welcome to the XUL Accessibility Guidelines. By following these principles and practices, you will be able to write your XUL applications 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 accessibility
features built into the XUL languages. Most of all, accessibility requires a conscious effort on your part, and a desire to include everyone.

It is hoped that these guidelines will be sufficiently clear and detailed 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 concerns or questions you have in regards to making your XUL applications fully accessible.

Guidelines

Keyboard Access

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.

Tab order

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 order of the elements in the underlying code. It can also be set programmatically with the tabindex attribute if needed, but this should be done sparingly and thoroughly tested whenever it is used. The navigation order should be logical, 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.

Trees

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.

Toolbarbuttons

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).

Keyboard shortcuts

Keyboard shortcuts are very useful to users needing keyboard access. There are many ways to provide keyboard shortcuts. They are well documented in the XUL Tutorial:Keyboard Shortcuts.

Careful attention should be taken when setting keyboard shortcuts. When creating an extension (for Firefox or another XUL application), make sure the keyboard shortcuts you assign do not interfere with those already defined by the base application. Refer to the following resources when setting keyboard shortcuts.

Context menus

The context menu is the small menu activated with a right mouse click on a content area or element (or with Shift+F10 or VK_APPS (located between Right Alt and Right Shift) on the keyboard). Use the oncontextmenu event handler to create context menus. Do not specifically code them to open on a click of the right mouse button. The oncontextmenu event fires on the correct platform-specific context menu triggers, including the keyboard button and appropriate mouse clicks.

Mouse dependent scripting

Functionality associated with mouse events such as onclick, onmousein, and ondrag are can only be activated with the use of the mouse. Provide keyboard-accessible alternative access point for this functionality. Consider using context menu items or other XUL elements along with keyboard shortcuts.

Scrolling

Ensure that scrolling is keyboard accessible. Many XUL elements can be set to scroll using CSS. Other elements, such as arrowscrollbox and listbox, are made to scroll automatically. As a general rule, elements set to scroll are inaccessible if the user cannot scroll to all the content using the keyboard. The arrowscrollbox, for example, is a non-focusable element and cannot be scrolled using a keyboard. A listbox, however, can receive focus so its contents can scroll. Almost any XUL element can be set to scroll by setting a style to "overflow: auto" or "overflow: scrolling". This flexibility should be used carefully.

Maintaining focus

Disabling, hiding, or destroying the focus element (or any ancestor of the focus element) can cause a loss of focus. To prevent this, move the focus to the next element before disabling, hiding, or destroying the focus element.

The following example shows a JacaScript function that can be called before destroying an element to check for focus and move it if necessary.

Changing focus unexpectedly can confuse or disorient users. A common example of this occurrence in the US is with phone number form fields. US phone numbers are often displayed on the web in two main formats XXX-XXX-XXXX or (XXX) XXX-XXXX. To enforce this pattern some forms provide three form fields. The problem occurs when a developer decides to add functionality that jumps the user to the second form field once 3 digits have been entered into the first form field. This behavior is then repeated for the next form field. Users who are used to navigating form fields themselves often end up repeating the jump operation and thereby skipping ahead one form field.

Testing keyboard access

To test keyboard accessibility, simply unplug or disable your mouse and attempt to use your application with only your keyboard. Verify that the tab order is logical. Make sure you have access to all functionality either directly or through alternative means such as menu items or context menus. Ensure that the user can read all content and that accesskeys do not interfere with assistive technologies.

Assistive information

Users of assistive technologies often require additional markup to understand meanings and associations that may be intuitive to visual users. This additional markup is what is known as assistive information. Providing the additional information is easy, but is often forgotten because it yields little or no visual change.

Alternative text

Provide alternative text for meaningful images. Alternative text is not needed when an image serves a purely decorative function. Use the "alt" attribute to describe HTML images and use the "tooltiptext" attribute on XUL elements that use images (i.e. image elements, buttons with images). For toolbar buttons with images it is recommended to use both a text label in the label attribute and image alt text in the tooltiptext attribute. View the code examples below.

Title

Provide unique titles to window container elements such as windows, wizards, and dialogs. Titles provide users the most basic information about the application. The title is often the first thing spoken by a screen reader when an application is opened or activated. Users can also refer back to the title to get a sense of where they are located. Titles are displayed in the top bar of an application. View code examples below.

Form labels

Labels are not automatically associated to form elements. Use the control attribute to bind a text label (from a label or description element) to a form element. Screen readers will then read aloud the label when entering a form field.

Complex forms are difficult to layout and structure. While there are many ways to visually structure forms, always provide a text label for every form element. Form elements should not be used to label other form elements.

When form elements are encapsulated in a groupbox with a caption, assistive technologies such as screen readers will read the caption along with the label to the form element. For example, under the privacy section of preferences there are three groupboxes captioned: History, Cookies, and Private Data. If the user were to tab to the "Exceptions.." button they would hear "cookies {pause} exceptions {pause} button." The next tab would read "cookies {pause} keep until {pause} they expire {pause} one of three {pause} combobox." If the screen reader only read the label, then the user would have to guess what the "exceptions button" or the "keep until" combobox was referring to.

Groupboxes are essential for radiogroups or groups of checkboxes with a similar theme (e.g. check all that apply). If you find nested groupboxes visually unappealing, use CSS to hide the border of the inner groupbox so that it can remain in the code to benefit users of assistive technologies.

Testing assistive information

Testing with a screen reader is in many ways the best test, because both the keyboard navigation and underlying semantics/structure of the UI can be tested at the same time. It is an excellent indicator regarding the accessibility of a user interface, but is by no means a complete test. Ultimately, for applications that must be completely accessible, it is best to have the application tested by a variety of end users with different software and assistive technology configurations.

If you don't access to screen reader software (and don't know anyone who does), your best option is to throughly check the source code to make sure that all of the above guidelines have been met, and then ensure that end users have a way to provide you with feedback on the accessibility (and other aspects) of your application.

Display

It is often said that "presentation is everything." While it is true that presentation is essential, documents should also be structured so that the user can invoke display preferences that may be necessary for accessibility. Presentation should also be flexible to window and font resizing. Cooperative applications adapt well to the user's environment.

System defaults

Maintain system defaults. Many users set their computers to use larger than normal fonts and/or specific color themes. By default, XUL menus, labels, and other widgets get their font, size, and color settings from the user settings specified in the operating system. Respect these defaults unless you have a specific and unavoidable reason to change them. If you must change them, use CSS to size elements relative to the default sizes (e.g., use % or em rather than specific point or pixel sizes).

Color

Color is an important tool. Different colors can give different meanings to objects and text. However, color alone is inadequate for conveying meaning or information to the user. Some users, mainly those who are colorblind or blind, will not be able to discern certain colors. Some users may override the default color scheme of your application. Color should only be used to enhance the meaning of an object or text after that meaning is also communicated another way.

Flexible sizing

One of the great things about XUL is that visual layout is easy to control. On the web, visual design is often contained to a specific size. With XUL you can allow elements to flex with the resizing of the application window. Use the flex attribute to provide this functionality. Similar functionality is found in CSS positioning, but should be avoided.

Testing display

Verify that your application is functional and pleasant looking using user-defined font and color settings. Do this by changing system display settings to an accessible theme (such as the high-contract theme on windows, available via Left-alt + Left-shift + Printscreen). Confirm that text is emphasized correctly and that color is not used as a sole means to convey meaning. Ensure that when windows are resized, the application adjusts gracefully.

Human computer interaction

As you use an application you expect a certain amount of control and feedback. Provide users with clear instruction and feedback, and allow users to correct errors. Some users with disabilities have difficulties with quick responses. Allow users adequate time to perform tasks.

Instruction

Provide users with help documentation. Even simple applications should include a help document or manual for user reference. Describe keyboard shortcuts and any other accessibility considerations. Users should be able to reference a complete description of all major functionality of an application. Also provide details on how to use long or complex help documentation.

Alerts

Provide accessible alerts for presenting important information to the user. Use scripting or the notificationbox element to flag alerts.

Avoid using audio or visual alerts alone to signal urgent events. Users who have audio turned down or off and users who are deaf or hard of hearing may not be able to recognize audio only alerts. Users with visual disabilities will not be able to observe alerts that are purely visual.

Interactive Elements

Avoid small targets, which are difficult to see and click on. Verify that the layout and contrast is sufficient to distinguish interactive elements one from another and from static portions of the application.

Error recovery

When the user causes an error in an application allow for graceful recovery. For example, if the user provides letters where numbers are required in a form, this should not break the application. The user should be alerted to the problem and allowed to fix the error.

Response time

When appropriate, alert the user to time limits and allow the user to adjust a time limit or request more time. One of the miracles of modern technology is that it allows people with even the most severe physical limitations to use computers. Some users use mouth sticks or movement detection devices such as eye tracking to type. This process can be slow. Other users need time to cognitively process what is happening in the application.

Testing human computer interaction

Ensure that help documentation is up to date. Verify that alerts are displayed through appropriate XUL elements. Ensure the user is informed of any user based errors and that instruction and opportunity for reperforming error causing actions is allowed. Ensure that users have control of response time.

Media

Audio

Informative audio files such as podcasts can be made accessible by supplying a word-for-word transcript. Transcripts should identify the speakers and describe other relevant sounds such as laughing or singing. Transcripts can be time consuming to generate, but is the only way to make audio content accessible.

Video

A video file can be made accessible by adding synchronized captions. Most media delivery formats provide a means for displaying captions. Video should also have descriptive transcripts. Usually captioning and transcribing go hand in hand, once you have one its easy to produce the other.

Animation

Animation, movement, and audio can all be distracting to some users with attention disorders. Provide a mechanism for turning media and movement on and off.

Flickering or flashing is not only just annoying to everyone, but at a rate more than 3 cycles per second it can cause a seizure in users with Photosensitive Epilepsy. If flickering or flashing is necessary then warn the user before it is displayed.

Testing Media

Ensure that media alternatives are available in an accessible format.

Other issues

Custom widgets

Avoid re-creating functionality that already exists. Ensure that custom components are built with accessibility in mind. Use CSS system colors to ensure that new widgets interact well with other widgets and with user-defined colors and themes.

XUL accessibility checklist

Use the following checklist to quickly verify the accessibility of a new XUL application, or as a starting point for fixing accessibility problems in an existing one.

Keyboard access

Checkpoint

Pass

Fail

Tab order

Logical tab order is provided.

Tab order jumps around unexpectedly.

Trees

Keyboard functionality is provided for inaccessible features such as the column picker or added features such as column sorting.

Keyboard functionality is not provided for column picker and other features.

Toolbarbuttons

Keyboard alternatives are provided for toolbarbutton functionality.

Keyboard alternatives are not provided for toolbarbutton functionality.

Keyboard shortcuts

Keyboard shortcuts are present for important functionality

Keyboard shortcuts are not provided.

Mouse dependent scripting

All mouse operations have keyboard accessible equivalents.

Operations exist that can only be performed with a mouse.

Scrolling

All scrollable elements are controllable with the keyboard.

Scrolling cannot be performed with a keyboard.

Focus

Keyboard focus is maintained and does not move unexpectedly.

Focus moves or is disabled unexpectedly.

Assistive information

Checkpoint

Pass

Fail

Alternative text

Alternative text is provided for meaningful images.

Alternative text is missing on meaningful images, or it is inappropriate for the function of an image.

Title

All windows, including dialogs and wizards, have a descriptive title.

Windows lack a title or have a incorrect title.

Form labels

Every form element has an associated label and radiobuttons are encapsulated in a groupbox.

Form elements are missing labels or the labels are not programmatically connected or radiobuttons are not contained in a groupbox.

Display

Checkpoint

Pass

Fail

System defaults

System settings are maintained.

System settings are not maintained.

Color

Color alone is not used to convey meaning and sufficient contrast exists between font color and background color.

Color alone is used to convey meaning, or font and background color do not provide sufficient contrast.

Flex

Visual elements and containers resize gracefully.

Visual elements and containers do not resize gracefully.

Human computer interaction

Checkpoint

Pass

Fail

Instruction

Help documentation is provided including a description of keyboard shortcuts.

Help documentation is not provided or is incomplete.

Alerts

Alerts are displayed using the alert scripting function or the notificationbox element.

Alerts are conveyed visually or audibly, or use a method other than the alert scripting function or the notificationbox element.

Error recovery

Alerts are presented when the user initiates an error. The user has the opportunity and instruction to fix the error.

No error alerts exist, or inadequate instruction is provided.

Response time

User is informed of time limits and has control of response time when appropriate.

User is not notified of time limits and/or has no control over response time when appropriate.

Media

Checkpoint

Pass

Fail

Audio

Transcripts are provided for audio tracks.

No transcript provided.

Video

Video is captioned and a transcript is provided.

No captions and/or transcripts provided.

Animation

User has control over animation and is warned about flashing content.

No control over animation or warnings about flashing exist.

Other

Checkpoint

Pass

Fail

Custom widgets

Custom widgets provide accessible functionality.

Custom widgets are inaccessible.

Revision Source

<p>
</p><p><br>
</p>
<h2 name="Introduction">Introduction</h2>
<p>Welcome to the XUL Accessibility Guidelines. By following these principles and practices, you will be able to write your XUL applications 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 accessibility
features built into the XUL languages. Most of all, accessibility requires a conscious effort on your part, and a desire to include everyone.
</p><p>It is hoped that these guidelines will be sufficiently clear and detailed 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 concerns or questions you have in regards to making your XUL applications fully accessible.
</p>
<table class="standard-table">
<caption>Learn More</caption>
<tbody><tr>
<th width="33%">Accessibility</th>
<th width="33%">Platform Features</th>
<th width="33%">Mozilla Community</th>
</tr>
<tr>
<td><a class="external" href="http://www.mozilla.org/access/today">Software Accessibility - Where Are We Today?</a> Intro to accessibility, assistive technologies, and Mozilla resources.
<p><a class="external" href="http://webaim.org/intro/">Introduction to Web Accessibility</a>. Overview of web accessibility from WebAIM.
</p><p><a class="external" href="http://diveintoaccessibility.org/">Dive Into Accessibility</a>. Downloadable book on web accessibility with tips and character sketches.
</p>
<a class="external" href="http://kb.mozillazine.org/Assistive_technology_compatibility|Assistive">Technology Compatibility</a>. List of popular assistive technologies and their respective compatibility levels with XUL.</td>
<td><a class="external" href="http://www.apple.com/accessibility/">Apple Accessibility</a>. Portal to Apple accessibility.
<p><a class="external" href="http://larswiki.atrc.utoronto.ca/wiki">LARS (Linux Accessibility Resource Site)</a>. Portal for general Linux accessibility.
</p>
<a class="external" href="http://www.microsoft.com/enable/">Microsoft Accessibility</a>. Portal for Microsoft accessibility.</td>
<td><a href="en/Accessibility">Accessibility - MDC</a>. Accessibility hub on the Mozilla Developer Center.
<p><a class="external" href="http://groups.google.com/group/mozilla.support.accessibility">mozilla.support.accessibility</a>. Mozilla accessibility newsgroup.
</p>
<a class="external" href="irc://irc.mozilla.org/#accessibility">#accessibility</a>. Accessibility channel on mozilla's IRC server.</td>
</tr>
</tbody></table>
<p><br>
</p><p><br>
</p>
<h2 name="Guidelines">Guidelines</h2>
<h3 name="Keyboard_Access">Keyboard Access</h3>
<p>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.
</p>
<h4 name="Tab_order">Tab order</h4>
<p><b>Provide a logical tab order</b> and ensure that users can navigate all content using a keyboard. By default, the tab order is determined by the order of the elements in the underlying code. It can also be set programmatically with the tabindex attribute if needed, but this should be done sparingly and thoroughly tested whenever it is used. The navigation order should be logical, 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.
</p><p>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.
</p>
<h4 name="Trees">Trees</h4>
<p><b>Provide alternative functionality for inaccessible operations</b>. 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.
</p>
<div class="float-right"><img alt="Screenshot of the View in the Firefox bookmarks manager." src="File:en/Media_Gallery/XUL_a11y_treesort.png"></div>
<p>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.
</p><p><br>
</p>
<h4 name="Toolbarbuttons">Toolbarbuttons</h4>
<p>Toolbar buttons cannot receive focus with a keyboard. <b>Functionality associated with a toolbar should be duplicated elsewhere in the application</b>, 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 <i>class="tabbable"</i> or with the special CSS rule <i>-moz-user-focus: normal</i>; 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).
</p>
<h4 name="Keyboard_shortcuts">Keyboard shortcuts</h4>
<p>Keyboard shortcuts are very useful to users needing keyboard access. There are many ways to provide keyboard shortcuts. They are well documented in the <a href="en/XUL_Tutorial/Keyboard_Shortcuts">XUL Tutorial:Keyboard Shortcuts</a>.
</p><p><b>Careful attention should be taken when setting keyboard shortcuts.</b> When creating an extension (for Firefox or another XUL application), make sure the keyboard shortcuts you assign do not interfere with those already defined by the base application. Refer to the following resources when setting keyboard shortcuts.
</p>
<div style="max-width: 35em;">
<table class="standard-table">
<caption>Learn More</caption>
<tbody><tr>
<th>Keyboard Shortcuts and Accesskeys</th>
</tr>
<tr>
<td><a class="external" href="http://www.mozilla.org/access/keyboard/">Mozilla Keyboard Planning FAQ and Cross Reference</a>. An excellent guide for determining unused key combinations and cross platform issues.
<p><a class="external" href="http://www.mozilla.org/docs/end-user/moz_shortcuts.html">Mozilla Keyboard Shortcuts</a>. A full list of keyboard shortcuts for the various Mozilla applications.
</p>
<a class="external" href="http://www.mozilla.org/access/keyboard/accesskey">Mozilla's accesskey FAQ</a>. A short reference for using the accesskey attribute.</td>
</tr>
</tbody></table>
</div>
<h4 name="Context_menus">Context menus</h4>
<p>The context menu is the small menu activated with a right mouse click on a content area or element (or with Shift+F10 or VK_APPS (located between Right Alt and Right Shift) on the keyboard). <b>Use the <i>oncontextmenu</i> event handler to create context menus.</b> Do not specifically code them to open on a click of the right mouse button. The oncontextmenu event fires on the correct platform-specific context menu triggers, including the keyboard button and appropriate mouse clicks.
</p>
<h4 name="Mouse_dependent_scripting">Mouse dependent scripting</h4>
<p>Functionality associated with mouse events such as <i>onclick</i>, <i>onmousein</i>, and <i>ondrag</i> are can only be activated with the use of the mouse. Provide keyboard-accessible alternative access point for this functionality. Consider using context menu items or other XUL elements along with keyboard shortcuts.
</p>
<h4 name="Scrolling">Scrolling</h4>
<p><b>Ensure that scrolling is keyboard accessible.</b> Many XUL elements can be set to scroll using CSS. Other elements, such as arrowscrollbox and listbox, are made to scroll automatically. As a general rule, elements set to scroll are inaccessible if the user cannot scroll to all the content using the keyboard. The arrowscrollbox, for example, is a non-focusable element and cannot be scrolled using a keyboard. A listbox, however, can receive focus so its contents can scroll. Almost any XUL element can be set to scroll by setting a style to "overflow: auto" or "overflow: scrolling". This flexibility should be used carefully.
</p>
<h4 name="Maintaining_focus">Maintaining focus</h4>
<p>Disabling, hiding, or destroying the focus element (or any ancestor of the focus element) can cause a loss of focus. To prevent this, <b>move the focus to the next element before disabling, hiding, or destroying the focus element</b>.
</p><p>The following example shows a JacaScript function that can be called before destroying an element to check for focus and move it if necessary.
</p>
<pre>function moveFocus(element)
{
if(element == document.commandDispatcher.focusedElement)
{
document.commandDispatcher.advanceFocus();
return true;
}
return false;
}
</pre>
<p><br>
Changing focus unexpectedly can confuse or disorient users. A common example of this occurrence in the US is with phone number form fields. US phone numbers are often displayed on the web in two main formats XXX-XXX-XXXX or (XXX) XXX-XXXX. To enforce this pattern some forms provide three form fields. The problem occurs when a developer decides to add functionality that jumps the user to the second form field once 3 digits have been entered into the first form field. This behavior is then repeated for the next form field. Users who are used to navigating form fields themselves often end up repeating the jump operation and thereby skipping ahead one form field.
</p>
<h4 name="Testing_keyboard_access">Testing keyboard access</h4>
<p>To test keyboard accessibility, simply <b>unplug or disable your mouse</b> and attempt to use your application with only your keyboard. Verify that the tab order is logical. Make sure you have access to all functionality either directly or through alternative means such as menu items or context menus. Ensure that the user can read all content and that accesskeys do not interfere with assistive technologies.
</p>
<h3 name="Assistive_information">Assistive information</h3>
<p>Users of assistive technologies often require additional markup to understand meanings and associations that may be intuitive to visual users. This additional markup is what is known as <i>assistive information.</i> Providing the additional information is easy, but is often forgotten because it yields little or no visual change.
</p>
<h4 name="Alternative_text">Alternative text</h4>
<p><b>Provide alternative text for meaningful images</b>. Alternative text is not needed when an image serves a purely decorative function. Use the "alt" attribute to describe HTML images and use the "tooltiptext" attribute on XUL elements that use images (i.e. image elements, buttons with images). For toolbar buttons with images it is recommended to use both a text label in the <i>label</i> attribute and image alt text in the <i>tooltiptext</i> attribute. View the code examples below.
</p>
<pre>&lt;image src="stop.png" tooltiptext="Stop" /&gt;
&lt;html:img src="stop.jpg" alt="Stop" /&gt;
&lt;html:img src="decorative_image.jpg" alt="" /&gt; &lt;!-- In HTML the alt attribute is required. --&gt;
&lt;toolbarbutton label="Stop" image="stop.png tooltiptext="Stop loading the page" /&gt;
</pre>
<h4 name="Title">Title</h4>
<p><b>Provide unique titles</b> to window container elements such as windows, wizards, and dialogs. Titles provide users the most basic information about the application. The title is often the first thing spoken by a screen reader when an application is opened or activated. Users can also refer back to the title to get a sense of where they are located. Titles are displayed in the top bar of an application. View code examples below.
</p>
<pre>&lt;dialog id="print_dialog" title="Print" ...&gt;
&lt;window id="mywindow" title="My Application" ...&gt;
&lt;wizard id="reg_window" title="Register your software" ...&gt;
</pre>
<h4 name="Form_labels">Form labels</h4>
<p>Labels are not automatically associated to form elements. <b>Use the control attribute</b> to bind a text label (from a label or description element) to a form element. Screen readers will then read aloud the label when entering a form field.
</p>
<pre>&lt;label control="login-username" value="Username:"/&gt;
&lt;textbox id="login-username"/&gt;
&lt;description control="login-password"&gt;Password:&lt;/description&gt;
&lt;textbox id="login-password" type="password"/&gt;
</pre>
<p>Complex forms are difficult to layout and structure. While there are many ways to visually structure forms, always <b>provide a text label for every form element</b>. Form elements should not be used to label other form elements.
</p>
<div class="float-right"><img alt="Screenshot of privacy panel in Firefox options dialog." src="File:en/Media_Gallery/XUL_a11y_privacy.png"></div>
<p>When form elements are encapsulated in a groupbox with a caption, assistive technologies such as screen readers will read the caption along with the label to the form element. For example, under the privacy section of preferences there are three groupboxes captioned: History, Cookies, and Private Data. If the user were to tab to the "Exceptions.." button they would hear "cookies {pause} exceptions {pause} button." The next tab would read "cookies {pause} keep until {pause} they expire {pause} one of three {pause} combobox." If the screen reader only read the label, then the user would have to guess what the "exceptions button" or the "keep until" combobox was referring to.
</p><p>Groupboxes are essential for radiogroups or groups of checkboxes with a similar theme (e.g. check all that apply). If you find nested groupboxes visually unappealing, use CSS to hide the border of the inner groupbox so that it can remain in the code to benefit users of assistive technologies.
</p>
<h4 name="Testing_assistive_information">Testing assistive information</h4>
<p>Testing with a screen reader is in many ways the best test, because both the keyboard navigation and underlying semantics/structure of the UI can be tested at the same time. It is an excellent indicator regarding the accessibility of a user interface, but is by no means a complete test. Ultimately, for applications that must be completely accessible, it is best to have the application tested by a variety of end users with different software and assistive technology configurations.
</p><p>If you don't access to screen reader software (and don't know anyone who does), your best option is to throughly check the source code to make sure that all of the above guidelines have been met, and then ensure that end users have a way to provide you with feedback on the accessibility (and other aspects) of your application.
</p>
<h3 name="Display">Display</h3>
<p>It is often said that "presentation is everything." While it is true that presentation is essential, documents should also be structured so that the user can invoke display preferences that may be necessary for accessibility. Presentation should also be flexible to window and font resizing. Cooperative applications adapt well to the user's environment.
</p>
<h4 name="System_defaults">System defaults</h4>
<p><b>Maintain system defaults</b>. Many users set their computers to use larger than normal fonts and/or specific color themes. By default, XUL menus, labels, and other widgets get their font, size, and color settings from the user settings specified in the operating system. Respect these defaults unless you have a specific and unavoidable reason to change them. If you must change them, use CSS to size elements relative to the default sizes (e.g., use % or em rather than specific point or pixel sizes).
</p>
<h4 name="Color">Color</h4>
<p>Color is an important tool. Different colors can give different meanings to objects and text. However, <b>color alone is inadequate</b> for conveying meaning or information to the user. Some users, mainly those who are colorblind or blind, will not be able to discern certain colors. Some users may override the default color scheme of your application. Color should only be used to enhance the meaning of an object or text after that meaning is also communicated another way.
</p>
<h4 name="Flexible_sizing">Flexible sizing</h4>
<p>One of the great things about XUL is that visual layout is easy to control. On the web, visual design is often contained to a specific size. With XUL you can allow elements to flex with the resizing of the application window. Use the flex attribute to provide this functionality. Similar functionality is found in CSS positioning, but should be avoided.
</p>
<h4 name="Testing_display">Testing display</h4>
<p>Verify that your application is functional and pleasant looking using user-defined font and color settings. Do this by changing system display settings to an accessible theme (such as the high-contract theme on windows, available via Left-alt + Left-shift + Printscreen). Confirm that text is emphasized correctly and that color is not used as a sole means to convey meaning. Ensure that when windows are resized, the application adjusts gracefully.
</p>
<h3 name="Human_computer_interaction">Human computer interaction</h3>
<p>As you use an application you expect a certain amount of control and feedback. Provide users with clear instruction and feedback, and allow users to correct errors. Some users with disabilities have difficulties with quick responses. Allow users adequate time to perform tasks.
</p>
<h4 name="Instruction">Instruction</h4>
<p>Provide users with help documentation. Even simple applications should include a help document or manual for user reference. Describe keyboard shortcuts and any other accessibility considerations. Users should be able to reference a complete description of all major functionality of an application. Also provide details on how to use long or complex help documentation.
</p>
<h4 name="Alerts">Alerts</h4>
<p>Provide accessible alerts for presenting important information to the user. Use scripting or the <a class="external" href="http://wiki.mozilla.org/XUL:NotificationBox">notificationbox element</a> to flag alerts.
</p><p>Avoid using audio or visual alerts alone to signal urgent events. Users who have audio turned down or off and users who are deaf or hard of hearing may not be able to recognize audio only alerts. Users with visual disabilities will not be able to observe alerts that are purely visual.
</p>
<h4 name="Interactive_Elements">Interactive Elements</h4>
<p><b>Avoid small targets</b>, which are difficult to see and click on. Verify that the layout and contrast is sufficient to distinguish interactive elements one from another and from static portions of the application.
</p>
<h4 name="Error_recovery">Error recovery</h4>
<p>When the user causes an error in an application <b>allow for graceful recovery</b>. For example, if the user provides letters where numbers are required in a form, this should not break the application. The user should be alerted to the problem and allowed to fix the error.
</p>
<h4 name="Response_time">Response time</h4>
<p>When appropriate, <b>alert the user to time limits</b> and allow the user to adjust a time limit or request more time. One of the miracles of modern technology is that it allows people with even the most severe physical limitations to use computers. Some users use mouth sticks or movement detection devices such as eye tracking to type. This process can be slow. Other users need time to cognitively process what is happening in the application.
</p>
<h4 name="Testing_human_computer_interaction">Testing human computer interaction</h4>
<p>Ensure that help documentation is up to date. Verify that alerts are displayed through appropriate XUL elements. Ensure the user is informed of any user based errors and that instruction and opportunity for reperforming error causing actions is allowed. Ensure that users have control of response time.
</p>
<h3 name="Media">Media</h3>
<h4 name="Audio">Audio</h4>
<p>Informative audio files such as podcasts can be made accessible by supplying a word-for-word transcript. Transcripts should identify the speakers and describe other relevant sounds such as laughing or singing. Transcripts can be time consuming to generate, but is the only way to make audio content accessible.
</p>
<h4 name="Video">Video</h4>
<p>A video file can be made accessible by adding synchronized captions. Most media delivery formats provide a means for displaying captions. Video should also have descriptive transcripts. Usually captioning and transcribing go hand in hand, once you have one its easy to produce the other.
</p>
<table class="standard-table">
<caption>Learn More</caption>
<tbody><tr>
<th>Captioning</th>
</tr>
<tr>
<td><a class="external" href="http://webaim.org/techniques/captions/">WebAIM article: Web Captioning Overview</a>
<br><br><a class="external" href="http://webaim.org/resources/captioning/">WebAIM resource: Captioning Resources</a></td>
</tr>
</tbody></table>
<h4 name="Animation">Animation</h4>
<p>Animation, movement, and audio can all be distracting to some users with attention disorders. Provide a mechanism for turning media and movement on and off.
</p><p>Flickering or flashing is not only just annoying to everyone, but at a rate more than 3 cycles per second it can cause a seizure in users with Photosensitive Epilepsy. If flickering or flashing is necessary then warn the user before it is displayed.
</p>
<h4 name="Testing_Media">Testing Media</h4>
<p>Ensure that media alternatives are available in an accessible format.
</p>
<h3 name="Other_issues">Other issues</h3>
<h4 name="Custom_widgets">Custom widgets</h4>
<p>Avoid re-creating functionality that already exists. Ensure that custom components are built with accessibility in mind. Use <a class="external" href="http://www.w3.org/TR/CSS21/ui.html#system-colors">CSS system colors</a> to ensure that new widgets interact well with other widgets and with user-defined colors and themes.
</p>
<table class="standard-table">
<caption>Learn More</caption>
<tbody><tr>
<th>Accessible Custom Widgets</th>
</tr>
<tr>
<td><a href="en/Accessible_DHTML">Accessible DHTML</a>
<br><br><a href="en/Building_accessible_custom_components_in_XUL">Building accessible custom components in XUL</a></td>
</tr>
</tbody></table>
<p><br>
</p>
<h2 name="XUL_accessibility_checklist">XUL accessibility checklist</h2>
<p>Use the following checklist to quickly verify the accessibility of a new XUL application, or as a starting point for fixing accessibility problems in an existing one.
</p>
<h3 name="Keyboard_access">Keyboard access</h3>
<table class="standard-table">
<tbody><tr>
<th scope="col">Checkpoint</th>
<th scope="col" width="40%">Pass</th>
<th scope="col" width="40%">Fail</th>
</tr>
<tr>
<th scope="row">Tab order </th>
<td>Logical tab order is provided. </td>
<td>Tab order jumps around unexpectedly.</td>
</tr>
<tr>
<th scope="row">Trees</th>
<td>Keyboard functionality is provided for inaccessible features such as the column picker or added features such as column sorting. </td>
<td>Keyboard functionality is not provided for column picker and other features.</td>
</tr>
<tr>
<th scope="row">Toolbarbuttons</th>
<td>Keyboard alternatives are provided for toolbarbutton functionality. </td>
<td>Keyboard alternatives are not provided for toolbarbutton functionality.</td>
</tr>
<tr>
<th scope="row">Keyboard shortcuts </th>
<td>Keyboard shortcuts are present for important functionality </td>
<td>Keyboard shortcuts are not provided.
</td>
</tr>
<tr>
<th scope="row">Mouse dependent scripting </th>
<td>All mouse operations have keyboard accessible equivalents. </td>
<td>Operations exist that can only be performed with a mouse.</td>
</tr>
<tr>
<th scope="row">Scrolling</th>
<td>All scrollable elements are controllable with the keyboard. </td>
<td>Scrolling cannot be performed with a keyboard. </td>
</tr>
<tr>
<th scope="row">Focus</th>
<td>Keyboard focus is maintained and does not move unexpectedly. </td>
<td>Focus moves or is disabled unexpectedly. </td>
</tr>
</tbody></table>
<h3 name="Assistive_information_2">Assistive information</h3>
<table class="standard-table">
<tbody><tr>
<th scope="col">Checkpoint</th>
<th scope="col" width="40%">Pass</th>
<th scope="col" width="40%">Fail</th>
</tr>
<tr>
<th scope="row"> Alternative text</th>
<td>Alternative text is provided for meaningful images. </td>
<td>Alternative text is missing on meaningful images, or it is inappropriate for the function of an image. </td>
</tr>
<tr>
<th scope="row">Title</th>
<td>All windows, including dialogs and wizards, have a descriptive title. </td>
<td>Windows lack a title or have a incorrect title. </td>
</tr>
<tr>
<th scope="row">Form labels</th>
<td>Every form element has an associated label and radiobuttons are encapsulated in a groupbox. </td>
<td>Form elements are missing labels or the labels are not programmatically connected or radiobuttons are not contained in a groupbox. </td>
</tr>
</tbody></table>
<h3 name="Display_2">Display</h3>
<table class="standard-table">
<tbody><tr>
<th scope="col">Checkpoint</th>
<th scope="col" width="40%">Pass</th>
<th scope="col" width="40%">Fail</th>
</tr>
<tr>
<th scope="row">System defaults </th>
<td>System settings are maintained. </td>
<td>System settings are not maintained. </td>
</tr>
<tr>
<th scope="row">Color</th>
<td>Color alone is not used to convey meaning and sufficient contrast exists between font color and background color. </td>
<td>Color alone is used to convey meaning, or font and background color do not provide sufficient contrast. </td>
</tr>
<tr>
<th scope="row">Flex </th>
<td>Visual elements and containers resize gracefully. </td>
<td>Visual elements and containers do not resize gracefully. </td>
</tr>
</tbody></table>
<h3 name="Human_computer_interaction_2">Human computer interaction</h3>
<table class="standard-table">
<tbody><tr>
<th scope="col">Checkpoint</th>
<th scope="col" width="40%">Pass</th>
<th scope="col" width="40%">Fail</th>
</tr>
<tr>
<th scope="row">Instruction</th>
<td>Help documentation is provided including a description of keyboard shortcuts. </td>
<td>Help documentation is not provided or is incomplete. </td>
</tr>
<tr>
<th scope="row">Alerts</th>
<td>Alerts are displayed using the alert scripting function or the notificationbox element.</td>
<td>Alerts are conveyed visually or audibly, or use a method other than the alert scripting function or the notificationbox element.</td>
</tr>
<tr>
<th scope="row">Error recovery </th>
<td>Alerts are presented when the user initiates an error. The user has the opportunity and instruction to fix the error. </td>
<td>No error alerts exist, or inadequate instruction is provided. </td>
</tr>
<tr>
<th scope="row">Response time </th>
<td>User is informed of time limits and has control of response time when appropriate.</td>
<td>User is not notified of time limits and/or has no control over response time when appropriate. </td>
</tr>
</tbody></table>
<h3 name="Media_2">Media</h3>
<table class="standard-table">
<tbody><tr>
<th scope="col">Checkpoint</th>
<th scope="col" width="40%">Pass</th>
<th scope="col" width="40%">Fail</th>
</tr>
<tr>
<th scope="row">Audio </th>
<td>Transcripts are provided for audio tracks. </td>
<td>No transcript provided. </td>
</tr>
<tr>
<th scope="row">Video</th>
<td>Video is captioned and a transcript is provided. </td>
<td>No captions and/or transcripts provided. </td>
</tr>
<tr>
<th scope="row">Animation</th>
<td>User has control over animation and is warned about flashing content. </td>
<td>No control over animation or warnings about flashing exist. </td>
</tr>
</tbody></table>
<h3 name="Other">Other</h3>
<table class="fullwidth-table">
<tbody><tr>
<th scope="col">Checkpoint</th>
<th scope="col" width="40%">Pass</th>
<th scope="col" width="40%">Fail</th>
</tr>
<tr>
<th scope="row">Custom widgets </th>
<td>Custom widgets provide accessible functionality. </td>
<td>Custom widgets are inaccessible. </td>
</tr>
</tbody></table>