20
edits
Accessibility/Triage: Difference between revisions
→Triaging Firefox and Gecko feature defects: adding clarification cases for HCM
(→Triaging incoming accessibility review requests: boldened the encouragement statement) |
(→Triaging Firefox and Gecko feature defects: adding clarification cases for HCM) |
||
| Line 13: | Line 13: | ||
* <code>s1</code>: '''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. | * <code>s1</code>: '''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. | ||
* <code>s2</code>: '''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. | * <code>s2</code>: '''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, touch targets below WCAG recommendations, etc. These bugs should absolutely block a feature from shipping to our stable release audience. | ||
* <code>s3</code>: '''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. | * <code>s3</code>: '''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, 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, 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. | ||
* <code>s4</code>: '''Feature available with minor defects.''' Examples include minor overlapping of the control borders while on HCM, 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. | * <code>s4</code>: '''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, 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 <code>access-s1</code>, <code>access-s2</code>, <code>access-s3</code> and <code>access-s4</code> labels are used in the same way as the Accessibility Severity values described above. | 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 <code>access-s1</code>, <code>access-s2</code>, <code>access-s3</code> and <code>access-s4</code> labels are used in the same way as the Accessibility Severity values described above. | ||