Accessibility/Triage

Search Queries

Triaging Firefox and Gecko feature defects

The Firefox Accessibility Team helps to assess accessibility issues across most Firefox and Gecko components on Bugzilla. For accessibility issues reported in components not owned by the Firefox Accessibility Team, the access keyword should be set on the bug to indicate that the bug has accessibility impact.

During triage, the accessibility team will set the Accessibility Severity field on these bugs, which communicates the team's assessment of the user impact of the issue. Following are the possible Accessibility Severity values, their descriptions, and some examples of the types of bugs that warrant those values:

s1: Accessibility of the entire product is broken. Examples include a critical piece of the browser's functionality like the URLbar not working. These bugs represent catastrophic failures and should be rare.
s2: Feature completely unavailable/inaccessible. Examples include lack of keyboard support, missing labels for screen reader users on icon buttons/links, insufficient contrast, missing focus indicators, missing controls in HCM (due to no background images) that make a feature not discoverable/actionable by users with low vision, UI does not adapt to HCM at all, or adapts in a way that makes it unusable such as having a foreground and background color that are the same, UI that disappears or becomes otherwise inaccessible with large zoom factors (200% and 400%), touch targets below WCAG recommendations (interactive target areas are smaller than 24x24 CSS px on desktop or smaller than 35 dp on mobile), etc. These bugs should absolutely block a feature from shipping to our stable release audience.
s3: Feature available but difficult to use. Examples include inconsiderate tab order, missing alt text for non-text content, visually hidden but not accessibility hidden content, inconsistent heading levels, dialogs that should be role=document, difficult to see or partially covered focus indicators, UI adapts to HCM and is visible but may not use semantic colors correctly for some themes (i.e. it is using a `ButtonText` system color on `Canvas` background), which may result in low visibility, UI that is cut off, obscured, truncated, or causes two-dimensional scroll with large zoom factors, touch targets under mobile platform recommendations (interactive target areas are between 24x24 and 44x44 CSS px on desktop or between 35-41 dp on mobile), etc. These bugs should be fixed and may or may not block a feature from shipping to our stable release audience and will be evaluated for blocking status on a case by case basis.
s4: Feature available with minor defects. Examples include minor overlapping of the control borders while on HCM, UI that adapts to HCM and is visible but may have minor defects such as incorrect border sizing, or focus ring that slightly overlaps other controls but doesn't render them unusable, interactive target areas that are between 42-48 dp on mobile, technically compliant with WCAG patterns that could be improved to be more delightful and efficient to use, etc. These bugs should be fixed but probably do not block a feature from shipping to our release audience. This is the backlog.

Firefox for iOS uses GitHub instead of Bugzilla, but a similar triage process is used. The access label is used to indicate accessibility impact and the need for accessibility triage. During triage, the access-s1, access-s2, access-s3 and access-s4 labels are used in the same way as the Accessibility Severity values described above.

Triaging for components owned by the accessibility team

The Firefox Accessibility Engineering Team owns the following Bugzilla components:

Core: Disability Access APIs
Firefox: Disability Access
Dev Tools: Accessibility Tools

We set severity and priority on these bugs directly using the Severity and Priority fields as described in Firefox's bug handling guide. The access keyword should not be set on these bugs, since they already exist in a component specific to accessibility. During triage, the access keyword should be removed from these bugs if it has accidentally been set previously, as this causes problems for our triage queries.

Sometimes, accessibility bugs in other components are mistakenly placed in the Firefox: Disability Access component. Generally, most bugs here should be moved to the component where the bug resides. For example, an accessibility bug in the Firefox address bar should be moved to Firefox: Address Bar. When a bug is moved, its priority and severity should be cleared and it should then be triaged according to #Triaging Firefox and Gecko feature defects above. The Firefox: Disability Access component should only be used for accessibility bugs that absolutely do not fit into any other component.

Triaging incoming accessibility review requests

The Firefox Accessibility Engineering Team encourages all Mozilla teams to request accessibility reviews for designs, code, and features, following our Accessibility Review documentation.

To help manage volume and shifting priorities, we use an Accessibility Reviews Prioritization Rubric to triage requests based on factors like product impact, user risk, and project timelines. Reviews are prioritized based on their priority category and team availability, so turnaround times may vary. We encourage early outreach and collaboration to help ensure accessibility is considered from the start.

Slack and Matrix Questions

Bug triage rotates weekly among team members and is reflected in the 'Triage Owner' field on bugzilla for the a11y-owned components listed above. In addition to bug triage, the triage owner of the week is responsible for responding to general accessibility questions in the #accessibility slack channel. If your question has gone unanswered for a few days, please check the triage owner on bugzilla and @ them as a reminder. All team members monitor matrix