Accessibility Review

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. Accessibility Review is a service provided by the Mozilla Accessibility team to review features and changes to ensure they are accessible to and inclusive of people with disabilities.

Do I Need Accessibility Review?

You should consider requesting accessibility review if you aren’t certain whether your change is accessible to people with disabilities. Accessibility review is optional, but it is strongly encouraged if you are introducing new user interface or are significantly redesigning existing user interface.

When Should I Request Accessibility Review?

Generally, it’s best to request accessibility review as early as possible, even during the product requirements or UI design stage. Particularly for more complex user interfaces, accessibility is much easier when incorporated into the design, rather than attempting to retro-fit accessibility after the implementation is well underway.

The accessibility team has developed the Mozilla Accessibility Release Guidelines which outline what is needed to make user interfaces accessible. To make accessibility review faster, you may wish to try to verify and implement these guidelines prior to requesting accessibility review.

Attention

For design reviews, please allow at least a week between review request and expected-engineering-handoff.

The deadline for engineering review requests is the Friday before the first week of nightly builds for the release in which the feature/change is expected to ship. This is the same date as the Manual QA Request deadline.

Requesting Design Review

Review Request Policy

The accessibility team is committed to reviewing projects in the following categories. Not sure if your project qualifies? Submit a review with the workflow below and an accessibility team member will reach out after triaging.

High-Severity Surface Projects

Certain Firefox surfaces, like the URL bar and the tab strip, must remain free of accessibility bugs to ensure the rest of the browser is usable. Here are some examples of projects that fall into this category:

  • Address Bar

  • Container Tabs

  • Tab Groups, Notes

  • Tab Strip (Vertical and Horizontal Tabs)

Revenue-Generating/For-Pay Projects

Projects that generate revenue, and those that are offered to users at a cost, have additional risks and requirements when it comes to accessibility. Here are some examples of projects that fall into this category:

  • Firefox Enterprise

  • VPN

  • Homepage New Tab

  • Anything in the Subscription Platforms ecosystem

Other Projects

Teams with projects outside of the above categories should reach out to the accessibility team on slack (#accessibility) for ad-hoc assistance on specific questions. These teams should also request engineering review after the project has been implemented.

Note

Unlike design reviews, there are no categorical restrictions on engineering reviews. Every project is eligible.

How to Request Design Review

Design review should be requested using the Accessibility Review Request workflow in the #accessibility slack channel. To access this workflow, click on the workflow link in the #accessibility slack channel header or in the links sidebar. You can also type /accessibility design review request from any channel or DM. Then, fill in the information requested.

Self-Review Tasks

Please complete all following self-review tasks before requesting a design review. Note: Some of the following links require SSO authentication.

  • Perform a contrast audit: Using either a Figma Contrast Checker tool or a third-party Figma plugin that audits contrast, check your designs for color contrast sufficiency. Your designs should be at least “AA” rated in order to pass accessibility review. “AAA” is even better! If there are particular components that are difficult to adjust to meet “AA” standards, make a note in the figma file and the a11y team will provide specific guidance during review.

  • Add focus order and role annotations: Focus order annotations describe the behaviour a keyboard user should expect when navigating your design. Generally this follows the reading order. Note that we only care about focusable elements here (ie. links, buttons, inputs, etc.). Role annotations help screen readers and other assistive technologies identify the “kind” of component they’re navigating through. These mappings expose semantic information to the user. You can find a list of common roles here. You do not need to annotate every view in your design, pick those with the largest amount of new content. We recommend using a set of Acorn’s A11y Annotation Components for Figma to annotate focus and roles for this process. The Acorn Design System team created an expansive guide for creating annotations and built these components in both the File Presentation Library and in the UX Project Template in Figma.

  • Create Windows High-Contrast Mode (HCM) mockups: Our designs should be accessible to users running HCM. You can read more about how HCM affects color selection, and how to design for HCM. Using the “Night Sky” HCM palette, translate your designs into High Contrast. Remember, it’s important we use these colors semantically, not based on a desire for a particular aesthetic. Colors are labelled according to their uses – Background for page background, Button Text for button or control text, Selected Item Background for backgrounds of selected or active items, etc.. You do not need to mock up every view in your design, pick those with the largest amount of new content. You can find examples of previous HCM mock ups here. Where possible, we should rely on SVG’s and PNG’s for image content to increase adaptability.

Requesting Engineering Review

For an engineering-focused review, you submit a review request by setting the a11y-review flag to “requested” on a bug in Bugzilla and filling in the template that appears in the comment field. For features spanning several bugs, you may wish to file a new, dedicated bug for the accessibility review. Otherwise, particularly for smaller changes, you may do this on an existing bug. Note that if you file a new bug, you will need to submit the bug and then edit it to set the flag.

Unlike design reviews, there are no categorical restrictions on engineering reviews. Every project is eligible.

During the review process, the accessibility team will modify the a11y-review flag:

  • assigned: The review has been triaged by the team and an engineer has been assigned to the review. If the flag has been set on a bug filed specifically for the purposes of review (i.e., the bug does not have additional engineering work attached, and the bug is not a meta bug) the review assignee will assign the bug to themselves. Otherwise, they’ll comment on the bug so you know who they are :)

  • passed: Either no changes are required, or some changes are required but the accessibility team does not believe it is necessary to review or verify those changes prior to shipping. Generally, a review will not be passed if there are outstanding s2 or certain high impact s3 accessibility defects which should block the feature or change from shipping. However, despite their high severity, some s2 defects are trivial to fix (e.g. missing accessibility labels), so the accessibility team may elect to pass the review on the condition that these are fixed promptly.

  • changes required: Changes are required and the accessibility team will need to review or verify those changes before determining whether the accessibility of the feature or change is acceptable for shipping. It is the responsibility of the requesting engineering team to re-request accessibility review once changes are made to address the accessibility team’s initial round of feedback.

Phabricator Review Group

There is also an accessibility-frontend-reviewers group on Phabricator. We recommend using the automated review tool described below before submitting to the review group. This group should only be used if:

  1. The patch addresses a complex change requested by an accessibility team member as part of an engineering review and you aren’t confident that the patch correctly addresses the change; or

  2. There is a very specific aspect of accessibility implemented in the patch and you would like the accessibility team to confirm whether it has been implemented correctly. You should first discuss your approach with the team in the #accessibility channel on slack.

After tagging the accessibility-frontend-reviewers group, review-bot will prompt you for some additional information about your patch. Your patch will be removed from our queue until you post a comment with the requested information, and re-add the group.

Here’s what you’ll see:

You've tagged the accessibility team for review. If you've already spoken
to a team member about your request, please request review from the
specific team member you spoke to.

Otherwise, please do ALL of the following:

    1. Post a comment describing the specific accessibility behaviour
       you're looking for feedback about
    2. Attach screenshots showing behaviour before and after your
       patch (if this is a visual change)
    3. Post a description of screen reader output/behaviour before
       and after your patch (if this change affects assistive
       technology users)

Once you have posted all of the above, please re-add the group.
The group will not be removed again after you re-add it if the
above conditions are met.

If you would like the accessibility team to assess whether a feature or change is sufficiently accessible, this is not the right pathway.

Please request an accessibility engineering review as described above. Without this, the accessibility team will not have sufficient context or understanding of the change or how to test it. This is necessary to thoroughly assess its accessibility.

Automated Accessibility Review Skill

The accessibility team maintains a frontend accessibility review skill for Claude Code and other LLM agents, available in the Firefox repository. You can invoke it via /accessibility-frontend-review in your LLM environment.

This skill accepts either a Phabricator patch reference (URL or D####) or a local changeset, and performs static analysis to catch common issues before review. Specifically, it checks for:

  • Inappropriate ARIA roles

  • Missing required ARIA states or properties

  • Missing labels that screen reader users depend on

  • High Contrast Mode (HCM) coverage and design token usage, with recommendations for improvements

This skill does not perform live, automated testing with assistive technologies (ATs). It is a supplement to, not a replacement for, a full accessibility review. You should continue to test your patches with ATs on your own machine, and to request accessibility engineering review for features or changes involving UI or UX work.

Questions?

If you have any questions, please don’t hesitate to contact the Accessibility team:

  • #accessibility on Matrix or Slack

  • Email: accessibility@mozilla.com

  • Please avoid reaching out to individual team members directly – containing review requests and questions in these channels helps us balance our workload. Thank you!