User:Ayeddi
Hi there,
I am a Senior Software Engineer - Accessibility on the Firefox team working on front-end accessibility of the browser and beyond. If you're looking for someone to chat about or review:
- Assistive technologies:
- Desktop (Windows and macOS): Keyboard-only use, NVDA, VoiceOver, Voice Control, and magnification
- Mobile (Android and iOS): TalkBack, VoiceOver, Switch Control, Voice Control, magnification, and inverse colors
- Accessibility needs of users who experience any of the following:
- Cognitive disabilities
- Neurodivergency
- Limited mobility
- Color deficiency
- Low vision
- Accessibility Reviews:
- Design review and audits
- Accessibility engineering reviews (functional requested via Bugzilla and code ones requested via Phabricator)
- High contrast mode (HCM) mockups
... I might be able to help! You can find me on Slack and Matrix at @ayeddi, try me there first before reaching out over email. I'm also only a ni? away on Bugzilla.
DRAFT below
Triaging Firefox and Gecko feature defects
The Firefox Accessibility Team helps to assess accessibility issues across most Firefox and Gecko components on Bugzilla and GitHub. In components not owned by the Firefox Accessibility Team, reported issues that may have an accessibility impact should get the access keyword on the bug to indicate the need to the accessibility triage.
During triage, the Accessibility Team will set the value in the Accessibility Severity field on bugs in Bugzilla and the access-s1 through access-s4 labels on issues in GitHub/Jira, which communicates the team's assessment of the user impact of the issue.
Accessibility Severity values and some examples that warrant those values:
s1- Accessibility of the entire product is broken. These bugs represent catastrophic failures and should be rare.
Examples include: a critical piece of the browser's functionality like the URLbar not working Firefox crashes when assistive technology is used
s2:
- Feature completely unavailable/inaccessible.
- These bugs should absolutely block a feature from shipping to our stable release audience.
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 or inappropriate CSS system colors combinations) 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
s3: Feature available but difficult to use. 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.
| inconsiderate focus and/or reading order |
| missing alt text for non-text content |
| visually hidden but not accessibility hidden content |
| inconsistent heading levels |
| dialogs that not exposed to assistive technology and should have role="document" |
| difficult to see focus indicators |
| missing control borders or unexpected CSS system colors used for states on HCM |
| touch targets under mobile platform recommendations |
s4(Feature available with minor defects)- These bugs should be fixed but probably do not block a feature from shipping to our release audience. This is the backlog.
Examples include: minor overlapping of the control borders while on HCM UI patterns that are technically compliant with WCAG, but could be improved to be more delightful and efficient to use
Note: If you're looking for ways to request an evaluation of how accessible is a UI or a feature is, refer to the Accessibility Review - Firefox Source Docs to request a design or engineering a11y review.