Accessibility/Triage

From MozillaWiki
Jump to: navigation, search

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 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 that disappears or becomes otherwise inaccessible with large zoom factors, touch targets below WCAG recommendations, 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 focus indicators, touch targets under mobile platform recommendations, 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 … 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.

Retrieved from "https://wiki.mozilla.org/index.php?title=Accessibility/Triage&oldid=1248755"