XUL accessibility guidelines

  • Revision slug: XUL_accessibility_guidelines
  • Revision title: XUL accessibility guidelines
  • Revision id: 99976
  • Created:
  • Creator: Aaronandy
  • Is current revision? No
  • Comment /* Color */

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.

Learn More
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.



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.

Screenshot of the View in the Firefox bookmarks manager.

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.

Learn More
Keyboard Shortcuts and Accesskeys
Mozilla Keyboard Planning FAQ and Cross Reference. An excellent guide for determining unused key combinations and cross platform issues.

Mozilla Keyboard Shortcuts. A full list of keyboard shortcuts for the various Mozilla applications.

Mozilla's accesskey FAQ. A short reference for using the accesskey attribute.

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.

function moveFocus(element)
{
    if(element == document.commandDispatcher.focusedElement)
    {
        document.commandDispatcher.advanceFocus();
        return true;
    }

    return false;
}


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.

<image src="stop.png" tooltiptext="Stop" />

<html:img src="stop.jpg" alt="Stop" />
<html:img src="decorative_image.jpg" alt="" /> <!-- In HTML the alt attribute is required. -->

<toolbarbutton label="Stop" image="stop.png tooltiptext="Stop loading the page" />

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.

<dialog id="print_dialog" title="Print"                  ...>
<window id="mywindow"     title="My Application"         ...>
<wizard id="reg_window"   title="Register your software" ...>

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.

<label control="login-username" value="Username:"/>
<textbox id="login-username"/>

<description control="login-password">Password:</description>
<textbox id="login-password" type="password"/>

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.

Screenshot of privacy panel in Firefox options dialog.

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

Testing display

Human computer interaction

Instruction

Alerts

Interactive Elements

Error recovery

Response time

Testing human computer interaction

Media

Audio

Video

Animation

Testing Media

Other issues

Custom widgets

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>
<h4 name="Testing_display">Testing display</h4>
<h3 name="Human_computer_interaction">Human computer interaction</h3>
<h4 name="Instruction">Instruction</h4>
<h4 name="Alerts">Alerts</h4>
<h4 name="Interactive_Elements">Interactive Elements</h4>
<h4 name="Error_recovery">Error recovery</h4>
<h4 name="Response_time">Response time</h4>
<h4 name="Testing_human_computer_interaction">Testing human computer interaction</h4>
<h3 name="Media">Media</h3>
<h4 name="Audio">Audio</h4>
<h4 name="Video">Video</h4>
<h4 name="Animation">Animation</h4>
<h4 name="Testing_Media">Testing Media</h4>
<h4 name="Other_issues">Other issues</h4>
<h4 name="Custom_widgets">Custom widgets</h4>
Revert to this revision