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 requirements which should be checked before a Mozilla product or feature is considered release-ready.

All markup languages (HTML, XUL)

• Is the markup semantic, wherever possible? Are buttons, checkboxes, links, list boxes, etc. used from the native host language?
• If custom widgets had to be implemented (including containers like toolbars, dialogs, labelled groups, etc.), are they augmented with the proper WAI-ARIA roles, states and properties?
• Are custom widgets also operable with the keyboard?
• Is the focus visible even when a mouse is not used?
• For content: Are proper headings, lists, tables, etc. used semantically where appropriate?
• Are images either given meaningful alternative text or marked as decorative with alt=””?
• Are form controls properly associated with a label for screen reader accessibility and bigger click targets for people who cannot accurately move the mouse or finger?
• If controls or content are effectively hidden visually, are they also hidden semantically using the hidden attribute, CSS display: none, CSS visibility: hidden or aria-hidden?
• Is focus set appropriately when a new screen or a pop-up appears or is dismissed? 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?

All of the above can be checked with either the accessibility inspector in the developer tools, or by operating the UI with a keyboard.

Text

Applies to both markup languages and native UI.

• Does text 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. (This can be checked in the developer tools.)
• Is text zoomable?
• For iOS: Does text adhere to the Dynamic Type Accessibility setting?
• Does it respect Bold text or Large Text, and other text-related accessibility settings?
• Android: Is zoom working properly with the UI?
• Do errors or other information indicators get communicated via more than color alone? For example, instead of saying “Correct all fields marked in red”, provide real contextual error messages everybody can clearly relate to, including color-blind people (roughly 8% of the population).

Mobile native UI

• 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?

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.