Accessibility/Triage: Difference between revisions
DavidBolter (talk | contribs) (l) |
mNo edit summary |
||
| Line 1: | Line 1: | ||
== | == Triaging Firefox and Gecko feature defects == | ||
([https://bugzilla.mozilla.org/buglist.cgi? | |||
The Firefox Accessibility Team helps to prioritize accessibility issues across most Firefox and Gecko components. We do this by setting a Whiteboard flag in those components, leaving the Priority flag to the component or bug owner. Below find the Whiteboard flags, their descriptions, and some examples of the types of bugs that warrant those flags. | |||
'''[access-p1]''' | |||
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-p2]''' | |||
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-p3]''' | |||
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 == | |||
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 priorities on these bugs directly using the Priority field. | |||
([https://bugzilla.mozilla.org/buglist.cgi?f17=OP&v10=Core&f10=product&f15=component&f5=CP&o11=equals&v15=Accessibility%20Tools&o2=casesubstring&query_format=advanced&f14=product&f18=product&f9=OP&v14=DevTools&f16=CP&v18=Firefox&chfieldfrom=-60d&f20=CP&o7=equals&f6=OP&o19=equals&resolution=---&o4=anyexact&o3=notsubstring&o18=equals&o14=equals&chfield=%5BBug%20creation%5D&j_top=OR&f2=keywords&f11=component&v2=access&f12=CP&o15=equals&v11=Disability%20Access%20APIs&f8=OP&o10=equals&j8=OR&f3=status_whiteboard&v3=%5Baccess-p&f1=OP&f4=product&f21=CP&v19=Disability%20Access&f22=CP&f13=OP&v4=Core%2CFirefox%2CDevTools%2CToolkit&f19=component&f7=priority&v7=--&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&list_id=15212885 bug query link]) | |||
== | |||
Revision as of 03:51, 23 April 2020
Triaging Firefox and Gecko feature defects
The Firefox Accessibility Team helps to prioritize accessibility issues across most Firefox and Gecko components. We do this by setting a Whiteboard flag in those components, leaving the Priority flag to the component or bug owner. Below find the Whiteboard flags, their descriptions, and some examples of the types of bugs that warrant those flags.
[access-p1] 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-p2] 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-p3] 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
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 priorities on these bugs directly using the Priority field.