- Have you followed the contributing guidelines?
- Have you explained what your changes do, and why they add value to the project?
Accessibility is a priority for Accessibility Toolkit — please review our Accessibility Statement and confirm the items below that apply to your change. Check N/A for any item that doesn't apply (for example, content-only edits with no UI changes).
- Headings follow a logical hierarchy and don't skip levels (
#,##,###, …). - Link text is unique and descriptive (no "click here" / "read more").
- Images have meaningful alternative text or are marked decorative when appropriate (alt Decision Tree).
- Complex images and diagrams have a nearby text alternative.
- Semantic lists are used instead of manually typed numbering.
- Plain language is used; abbreviations are expanded on first use.
- Meaning isn't conveyed by color, position, or styling alone.
- Any embedded video has captions and a transcript.
- Keyboard navigation works end-to-end (everything interactive is reachable and operable without a mouse).
- Focus states are visible and follow reading order.
- Forms have associated labels.
- Error messages are programmatically associated with their fields.
- Color isn't the only indicator of state, error, or meaning.
- Reduced motion is respected if animations were added (
prefers-reduced-motion). - Screen reader behavior was checked at least once (VoiceOver, NVDA, JAWS, or TalkBack).
- Native HTML elements are preferred over custom controls where possible; ARIA is used only when needed.
- Touch targets are at least 24×24 CSS pixels with adequate spacing.
- Tested with an automated tool (e.g. Axe DevTools or the GitHub Accessibility Scanner) and any new violations are resolved or explained below.
Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.