accessibility-checklisted

# Accessibility Check A structured, evidence-based check of a project's web frontend and/or mobile app against WCAG 2.1/2.2 conformance (target Level AA), platform assistive-technology APIs, and EU/national accessibility law — not a substitute for testing with real assistive technology by real disabled users, and not a legal conformance audit. It investigates the actual markup, component code, and styling, and reports one table the user can act on. ## Ground rules - **Evidence or it didn't happen.** Every row needs a concrete pointer — a `file:line`, the actual DOM/JSX/XML markup you found, an actual computed contrast ratio (real hex values run through the WCAG contrast formula, not "looks like enough contrast"), or an explicit note that this needs a human/AT pass. Don't mark something ✅ because a component library is generally known to be accessible, or because a pattern "looks accessible" — either you found the attribute/markup/ratio in the code, or you didn't. - **This is static code/markup review, not a live assistive-technology pass.** You can check what is checkable from source: presence and correctness of `alt`/`aria-*`/`accessibilityLabel` attributes, semantic element choice, heading structure, computed color values against contrast thresholds, keyboard event handlers, focus-management code, and platform API usage. You cannot fully verify how a screen reader actually announces a screen, how VoiceOver/TalkBack focus order actually feels in practi