Mozilla Accessibility Release Guidelines

From MozillaWiki
Jump to: navigation, search


At Mozilla, accessibility is a fundamental part of our mission to ensure the internet is "open and accessible to all," helping to empower people, regardless of their abilities, to contribute to the common good.

To that end, this document outlines accessibility guidelines and resources which should be referenced before a Mozilla product or feature is considered release-ready.

General Considerations

When working in the following areas, we've provided a general list of considerations when designing, implementing, and testing accessibility. This is not exhaustive and you will find more best practices and guidance in the detailed resources provided.

Markup languages (HTML, XUL)

All of the below can be checked with either the accessibility inspector in the Developer Tools toolbox and/or by navigating the user interface with a keyboard.

  • Is the markup semantic, wherever possible?
  • Are buttons, checkboxes, links, list boxes, etc. used from the native host language?
  • Are proper headings, lists, tables, etc. used semantically where appropriate?
  • If controls or content are visually hidden, are they also semantically hidden using the hidden attribute, CSS display: none, CSS visibility: hidden or aria-hidden?
  • Are custom widgets (containers like toolbars, dialogs, labelled groups, etc.), augmented with the proper WAI-ARIA roles, states and properties?
  • Are custom widgets operable with the keyboard?
  • Is the focus visible, even when a mouse is not used?
  • When a new screen, notification, or pop-up appears or is dismissed is the focus set appropriately? For example, when a pop-up appears, is focus moved to a control inside the pop-up? When a pop-up is dismissed, does focus return to the element which was focused before the pop-up appeared?
  • Is meaningful alternative text provided for images (or marked as decorative with an empty alt=””)?
  • Are form controls associated with a label for screen reader accessibility and bigger click targets for people who cannot accurately move the mouse or finger?


Applies to markup languages and native user interfaces.

  • Does the text (color) have enough contrast to the background so it conforms to WCAG 2.1 standards? For example, normal text must have a contrast ratio of 4.5:1 with its background to be valid.
  • Is the text zoomable and/or flow in the interface as expected?
  • Does text respect Bold text or Large Text, and other text-related accessibility settings?
  • Do errors or other information indicators get communicated with more than color? For example, instead of saying “Correct all fields marked in red”, provide contextual error messages everybody can relate to, including color-blind people (roughly 8% of the population).


  • Does text respect Bold text or Large Text, and other text-related accessibility settings?
  • Android: when you Zoom, does the text work as expected within the UI?
  • iOS: Does text adhere to the Dynamic Type Accessibility setting?
  • iOS and Android: Are controls properly labeled with accessibilityLabel or contentDescription?
  • Are controls actionable with VoiceOver or TalkBack gestures (tap to select, double-tap to activate)?
  • Do custom elements expose proper accessibility semantics on all platforms? For example, for a custom slider on iOS, does accessibilityTraits include the adjustable trait and are the accessibilityIncrement and accessibilityDecrement methods implemented?
  • If controls or content are effectively hidden visually, are they also hidden semantically; e.g. using the accessibilityElementsHidden property on iOS?
  • Do system settings such as Zoom, Reduce Animations/Motion and Dynamic Type affect the UI as appropriate?
  • Is the touch target size for controls sufficiently large, 48x48 device pixels for Android and 44x44 for iOS?

Testing and Tools

Web Content and Browser


Color Contrast and Color Blindness

Preliminary documentation available here

High Contrast Mode is a solution implemented in operating systems and applications like Firefox. To enable it when testing:

  • Windows: Settings > Ease of Access > High Contrast Mode
  • macOS: System Preferences > Accessibility > Display > Increase Contrast (Note: you may also need to adjust about:preferences in Language & Appearance > Colors > (menulist) Only with High Contrast Themes)
  • Linux: Accessibility menu > High contrast
  • Firefox: Language & Appearance > Colors > (menulist) Always (Note: for this configuration, you should not have any OS-level contrast preference enabled.)

Video guide to testing color contrast and simulating color blindness.

High contrast design guide for Firefox available here.

Screen Readers


Here are some resources that you might find useful when working towards meeting the above requirements. Some broad and general material is provided here with more specific categories below:

Mozilla Internal Only

Web and Markup languages