Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Revision 190826 of Accessible XUL Authoring Guidelines

  • Revision slug: Accessible_XUL_Authoring_Guidelines
  • Revision title: Accessible XUL Authoring Guidelines
  • Revision id: 190826
  • Created:
  • Creator: Simplex
  • Is current revision? No
  • Comment add context menu key image

Revision Content

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.

  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. Context menus must support the keyboard, via the VK_APPS key
    Image:Contextmenukey.jpg
    context menu key. That would also be Shift+F10 on Windows, Shift+F10 on UNIX/Linux and CTRL+Space on OS X. This should be automatically handled by oncontextmenu -- don't handle the right click directly.
  6. Support accesskeys (mnemonics) on interactive UI widgets. See XUL Accesskey FAQ and Policies.
  7. 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.
  8. 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.
  9. 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.
  10. Don't require fast responses (physical reactions, decision making or comprehension) from the user.
  11. 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).
  12. Don't break theming. Ensure compatibility with system themes, such as the high contrast theme on Windows (available via Left-alt + Left-shift + Printscreen).
  13. Avoid small targets which are difficult to see and click on.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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>.
  19. 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

To learn more about accessibility in Mozilla, see the MDC Accessibility page.

Revision Source

 
<p>
</p><p>When authored according to these guidelines, <a href="en/XUL">XUL</a> is capable of generating accessible user interfaces. Coders, reviewers, designers and QA engineers should be familiar with these guidelines.
</p>
<ol><li> <b>Don't break the tab order</b>: 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.
</li><li> Ensure <b>sensible focus behavior</b>. The focus must always be visible. Make sure focus never gets lost when a focused element is disabled, hidden or destroyed.
</li><li> Ensure <b>full keyboard access</b>. 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).
</li><li> Don't use <b>mouse event listening code</b> 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.
</li><li> <b>Context menus</b> must support the keyboard, via the <code>VK_APPS</code> key <div class="float-right"><img alt="Image:Contextmenukey.jpg" src="File:en/Media_Gallery/Contextmenukey.jpg"></div> context menu key.  That would also be <code>Shift+F10</code> on Windows, <code>Shift+F10</code> on UNIX/Linux and <code>CTRL+Space</code> on OS X. This should be automatically handled by <code>oncontextmenu</code> -- don't handle the right click directly.
</li><li> Support <b>accesskeys</b> (mnemonics) on interactive UI widgets. See <a href="en/XUL_Accesskey_FAQ_and_Policies">XUL Accesskey FAQ and Policies</a>.
</li><li> Provide <b>global accelerators</b> 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.
</li><li> <b>Don't rely on toolbar buttons</b>. 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.
</li><li> Use the <b>tooltiptext</b> 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.
</li><li> <b>Don't require fast responses</b> (physical reactions, decision making or comprehension) from the user.
</li><li> <b>Don't rely on color alone</b> 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).
</li><li> <b>Don't break theming</b>. Ensure compatibility with system themes, such as the high contrast theme on Windows (available via Left-alt + Left-shift + Printscreen).
</li><li> <b>Avoid small targets</b> which are difficult to see and click on.
</li><li> <b>Try to avoid scroll bars</b>. 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.
</li><li> Ensure that <b>sortable tree views</b> have a "View -&gt; Sort By" menu. Ensure that tree and list views have full keyboard access to the interactive icons on each line.
</li><li> <b>Use the label element or attribute</b> 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.
</li><li> <b>Don't use form controls as the only content for a label</b>. Assistive technologies such as screen readers and onscreen keyboards require a proper label.
</li><li> The <b>Escape key should cancel dialogs</b> and close them without changes, acting like a click on the cancel button (if there is one). This should be handled automatically by <code>&lt;xul:dialog&gt;</code>.
</li><li> Ensure a <b>default button in dialogs</b>. The xul:button element uses <code>default="true"</code> to indicate this, it should work automatically in a <code>&lt;xul:dialog&gt;</code>.
</li></ol>
<h3 name="Additional_Guidelines"> Additional Guidelines </h3>
<ul><li> For <b>new shortcut keys</b>, consult the <a class="external" href="https://www.mozilla.org/access/keyboard/">Mozilla keyboard user interface plan</a> and and talk to the accessibility module owner.
</li><li> For <b>new widgets</b> (e.g. via <a href="en/XBL">XBL</a> or <a href="en/XTF">XTF</a>), consult the <a class="external" href="mailto:[email protected]">accessibility module owner</a>.
</li></ul>
<p>To learn more about accessibility in Mozilla, see the MDC <a href="en/Accessibility">Accessibility</a> page.
</p>
Revert to this revision