Accessibility/Guidelines

Introduction

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?

Text

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

Mobile

• 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

• Accessibility inspector in the Developer Tools toolbox

High Contrast Mode

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

Screen Readers

• Orca for Ubuntu: https://help.ubuntu.com/stable/ubuntu-help/a11y-screen-reader.html.en
• NVDA for Windows: https://www.nvaccess.org/download/
• VoiceOver for macOS: https://support.apple.com/guide/voiceover/welcome/mac

Resources

Here are some resources that you might find useful when working towards meeting the above requirements.

• For markup languages such as HTML
  • The front page of learning accessibility on MDN. Use this to jump to the topic you need more information on.
  • Introduction to the auditing features of the accessibility inspector, also available as a video series:
    • Understanding website accessibility
    • Test keyboard accessibility
    • Testing color contrast and simulating color blindness
    • Test for text label issues
• For Android
  • Make apps more accessible on Android Developers.
  • Prinicples for improving app accessibility on Android Developers.
  • Test your app's accessibility on Android Developers.
• For iOS
  • Introduction to accessibility on iOS on Apple Developer.
  • WWDC session videos.
  • UIKit accessibility reference.
  • Introduction to Accessibility Inspector for iOS in Xcode on the Deque blog.