Accessibility/Triage: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Make display of triage links more friendly (link text instead of URL).)
(→‎Search Queries: Updated the Android query to exclude bugs from Disability Access APIs that already have Severity set (it was filtering "--" string))
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Search Queries ==
== Search Queries ==


* [https://mzl.la/3pjFR8R New Untriaged Bugs in Bugzilla]
* [https://bugzilla.mozilla.org/buglist.cgi?f8=OP&o14=equals&f22=CP&v15=Accessibility%20Tools&f12=CP&bug_type=defect&v3=---&chfield=%5BBug%20creation%5D&f4=product&f1=OP&f19=component&f2=keywords&f18=product&f17=OP&o7=equals&query_format=advanced&f11=component&f21=CP&j8=OR&o3=equals&o15=equals&v14=DevTools&resolution=---&f5=CP&columnlist=bug_type%2Cshort_desc%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate%2Cstatus_whiteboard%2Ckeywords%2Cpriority%2Cbug_severity&v7=--&f10=product&f20=CP&v18=Firefox&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&o10=equals&f13=OP&v4=Core%2CFirefox%2CDevTools%2CToolkit&j_top=OR&chfieldfrom=-60d&v19=Disability%20Access&v2=access&o11=equals&f3=cf_accessibility_severity&f15=component&list_id=16594388&o18=equals&v10=Core&f16=CP&f9=OP&f7=bug_severity&f6=OP&f14=product&v11=Disability%20Access%20APIs&o2=casesubstring&o19=equals&o4=anyexact New untriaged Bugs in Gecko and Firefox Desktop]
* [https://mzl.la/35kLz2h Older Untriaged Bugs in Bugzilla]
* [https://bugzilla.mozilla.org/buglist.cgi?o14=equals&f14=product&o7=equals&f7=bug_severity&j8=OR&v3=---&f6=OP&f12=CP&f20=CP&f11=component&o11=equals&f1=OP&v4=Core%2CFirefox%2CDevTools%2CToolkit&v2=access&chfieldfrom=-3000d&chfield=%5BBug%20creation%5D&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&o18=equals&f18=product&v15=Accessibility%20Tools&query_format=advanced&f8=OP&o19=equals&v10=Core&f19=component&bug_type=defect&o3=equals&f3=cf_accessibility_severity&list_id=16594594&f16=CP&v14=DevTools&j_top=OR&v7=--&f13=OP&v11=Disability%20Access%20APIs&f17=OP&v18=Firefox&resolution=---&o4=anyexact&o2=casesubstring&f4=product&f2=keywords&f9=OP&f21=CP&v19=Disability%20Access&f5=CP&f22=CP&f10=product&o10=equals&columnlist=bug_type%2Cshort_desc%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate%2Cstatus_whiteboard%2Ckeywords%2Cpriority%2Cbug_severity&o15=equals&f15=component Older untriaged Bugs in Gecko and Firefox Desktop]
* [https://github.com/mozilla-mobile/fenix/issues?q=is%3Aopen+is%3Aissue+label%3Aneeds%3Atriage+label%3Ab%3Aa11y+created%3A%3E2020-07-28 Untriaged Fenix Bugs]
* [https://bugzilla.mozilla.org/buglist.cgi?j10=OR&o6=equals&o17=equals&f14=cf_accessibility_severity&f16=OP&f12=short_desc&f10=OP&f2=OP&v4=iOS&f5=CP&f17=component&f6=op_sys&query_format=advanced&v3=Fenix%2CFocus%2CGeckoView&o14=isempty&j1=OR&v11=access&o12=anywords&f15=CP&f20=CP&f1=OP&f7=CP&f3=product&j8=OR&v17=Disability%20Access%20APIs&v6=Android&f8=OP&o4=nowords&f18=bug_severity&f11=keywords&o3=anyexact&f13=CP&f19=CP&list_id=16773164&o18=isempty&f4=component&v12=%5Ba11y%5D%2CTalkback&o11=anywords&f9=OP&resolution=--- Untriaged bugs in Firefox for Android]
* [https://docs.google.com/spreadsheets/d/1VApqSeSg4DEpsszfrhb0wvZLxjLj_kHWcdDVgfAi15c/edit#gid=0 A11y Reviews Tracker] (Internal Mozilla-only Google Sheet)
* [https://github.com/mozilla-mobile/firefox-ios/issues?q=is%3Aopen+is%3Aissue+label%3Aaccess+-label%3Aaccess-s1+-label%3Aaccess-s2+-label%3Aaccess-s3+-label%3Aaccess-s4 Untriaged bugs in Firefox for iOS]


== Triaging Firefox and Gecko feature defects ==
== Triaging Firefox and Gecko feature defects ==


The Firefox Accessibility Team helps to assess accessibility issues across most Firefox and Gecko components. For accessibility issues reported in components not owned by the Firefox Accessibility Team (bugs with the access Keyword) we set a Whiteboard severity flag which communicates the team's assessment of the user impact of the issue. Below find the Whiteboard flags, their descriptions, and some examples of the types of bugs that warrant those flags.
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:


'''[access-s1]'''
* 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.
Accessibility of the entire product is broken. Examples include the accessibility engine failing or 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.


'''[access-s2]'''
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.
Feature completely unavailable/inaccessible. Examples include lack of keyboard support for screen reader users, insufficient contrast or missing focus indicators, or 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, etc. These bugs should absolutely block a feature from shipping to our stable release audience.  


'''[access-s3]'''
== Triaging for components owned by the accessibility team ==
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, 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.


'''[access-s4]'''
The Firefox Accessibility Engineering Team owns the following Bugzilla components:
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.


== Triaging for Disability Access and Disability Access APIs ==
* Core: Disability Access APIs
* Firefox: Disability Access
* Dev Tools: Accessibility Tools


The Firefox Accessibility Team is also responsible for triaging bugs in the Disability Access and the Disability Access APIs components. As these components are owned by the Firefox Accessibility Engineering Team, we set severity and priority on these bugs directly using the Severity and Priority fields.
We set severity and priority on these bugs directly using the Severity and Priority fields as described in [https://firefox-source-docs.mozilla.org/bug-mgmt/policies/triage-bugzilla.html 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.


== Triaging Fenix (Firefox for Android) GitHub Issues ==
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.
 
The Firefox Accessibility Team is responsible for triaging all Fenix bugs with the b:a11y label. We use P1 to describe completely broken features, P2 to describe difficult to use features, and P3 for general backlog bugs.
 
== Triaging and Reviewing Accessibility Reviews ==
 
* Add items that come in
* Check for "due" items that need follow up
* Assign Owners

Latest revision as of 19:22, 27 October 2023

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.allizom.org/index.php?title=Accessibility/Triage&oldid=1248755"