Design System Accessibility Tickets

Component-level accessibility findings need different tickets than one-off page bugs. The ticket should name the reusable pattern, affected instances, owner, rollout path, and retest evidence.

Use this guide when the same accessibility defect appears in buttons, dialogs, form fields, accordions, tabs, cards, filters, toasts, table components, or CMS blocks that are shipped through a design system or shared frontend library.

Open this design system finding in the generator

When a finding belongs in the design system

Repeated component defect: the same button, input, dialog, tab, toast, card, or menu pattern fails in several places.
Shared styling or token defect: contrast, focus indicator, spacing, target size, or disabled-state treatment comes from shared CSS or design tokens.
Reusable behavior defect: focus trapping, focus return, live-region announcements, disclosure state, validation association, or keyboard operation is owned by the component.
Documentation gap: the component supports an accessible pattern, but examples or usage guidance lead teams to implement it incorrectly.
Rollout dependency: fixing the component requires package release, CMS block update, frontend template change, or migration notes for product teams.

Ticket structure

Title:
[Severity] Design system component: accessibility behavior fails across affected instances

User impact:
Explain the user task that breaks or becomes unreliable when teams use this shared pattern.

Evidence:
- Component or token:
- Affected instances:
- Owner:
- Source finding:
- Assistive technology or keyboard path:
- Actual behavior:
- Expected behavior:

Rollout notes:
- Component/package version or template path:
- Product areas that need retesting:
- Documentation or example updates:

Likely WCAG references to verify:
- Add only the criteria supported by the evidence.

Acceptance criteria:
- The shared component or token is fixed at the source.
- Known affected instances are retested after rollout.
- Component examples and usage notes prevent the same mistake in new implementations.

Example conversion: modal focus return

Raw note:
The shared modal component does not return focus to the trigger after close. Reproduced in checkout address editing, account settings, and newsletter signup.

Developer ticket:
[High] Design system modal: focus is lost after closing shared dialogs

User impact:
Keyboard and screen reader users can lose their place after closing a dialog, especially in checkout and account flows where the next action depends on returning to the triggering control.

Evidence:
- Component: Modal
- Affected instances: checkout address edit, account settings, newsletter signup
- Actual result: focus lands near the top of the page or disappears from the active workflow
- Expected result: focus returns to the trigger or next logical control

Likely WCAG references to verify:
- 2.4.3 Focus Order
- 2.1.2 No Keyboard Trap

Acceptance criteria:
- The shared modal records the trigger before opening and restores focus after close.
- Escape, close button, and completion paths use the same focus-return rule.
- At least three affected instances are retested after the component rollout.
- Component documentation names the expected focus behavior.

Example conversion: focus ring token

Raw note:
Focus outline is clipped on card buttons and filter chips because the shared component wrapper uses overflow hidden. The issue appears in product listing, article cards, and saved-items cards.

Developer ticket:
[High] Design token/card components: focus indicator is clipped on reusable card actions

User impact:
Keyboard users cannot reliably see which card action or filter chip has focus, which makes product browsing and saved-item management error-prone.

Evidence:
- Components: product card, article card, saved-items card, filter chip
- Shared source: card wrapper and focus-ring token
- Actual result: focus indicator is partially hidden by the component boundary
- Expected result: the focused control and indicator remain visible in every card state

Likely WCAG references to verify:
- 2.4.7 Focus Visible
- 2.4.11 Focus Not Obscured (Minimum)
- 1.4.11 Non-text Contrast

Acceptance criteria:
- Shared wrappers no longer clip visible focus indicators.
- Focus ring color and offset meet design-token requirements in default, hover, selected, and error states.
- Product listing, article cards, saved-items cards, and filter chips are retested at desktop and mobile widths.

Common split decisions

One shared component ticket: use this when one component fix resolves the repeated defect and product teams only need retesting.
Component plus migration tickets: use this when teams must update markup, pass new props, or replace older component versions.
Design token ticket: use this for contrast, focus indicator, spacing, target size, and visual-state defects shared across many components.
Documentation ticket: use this when the component can be accessible, but published examples, Storybook stories, or CMS guidance encourage the wrong pattern.
Separate product ticket: keep one-off page content, page-specific copy, and broken CMS entries outside the design system backlog unless they prove a reusable pattern problem.

Paste-ready input for the generator

Design system accessibility finding:
Component, token, or template:
Affected instances:
Owner:
Source finding:
Assistive technology or keyboard path:
Actual behavior:
Expected behavior:
Rollout dependency:
Documentation update needed:
Acceptance criteria:

Open the accessibility ticket generator and paste this structure with the component evidence.