> For the complete documentation index, see [llms.txt](https://docs.devlaunchers.org/dl-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devlaunchers.org/dl-docs/universal-design-system/universal-design-system/getting-started/copy-of-accessibility-commitment.md). # Copy of Accessibility Commitment ### β™Ώ Accessibility Best Practices Inclusive design is not just a legal or ethical requirement β€” it’s essential for ensuring digital experiences are usable by everyone. Our system incorporates accessibility best practices from the ground up. Below are key areas to prioritize across all components and layouts. *** #### πŸ”  Text Size & Legibility * Use minimum text sizes of **16px** for body content and **12–14px** for labels. * Maintain a **clear hierarchy** using appropriate font weights and spacing. * Avoid using long blocks of all caps or excessive italics, which can hinder readability. #### πŸŒ— Color Contrast * All text, icons, and interactive elements must meet **WCAG AA minimum contrast ratios** (4.5:1 for normal text, 3:1 for large text). * Use the **Contrast Figma plugin** to test your color pairings before handoff. * Our appearance layer system is designed to support high-contrast themes across modes β€” but mix-and-match options still require contrast testing. #### 🧭 Keyboard Navigation & Focus * All interactive elements must be accessible via **keyboard (tab) navigation**. * Use consistent **focus indicators** (e.g., outlines, shadows) to show active state. * Avoid removing default focus styles unless replacing them with a custom alternative. #### 🎯 Touch Targets & Hit Areas * Ensure interactive elements have a **minimum 44x44px target area**. * Avoid placing elements too close together to prevent mis-taps. #### 🚫 Avoid Sole Reliance on Color * Never use color alone to convey information (e.g., error states). * Always pair visual cues with **text labels, icons, or status indicators**. #### πŸ§ͺ Component-Level Accessibility * **Use semantic tags** in components to identify their role in the content structure (e.g., headings, labels). * Toggle **is-descriptive** in image components to add alt text. * Apply **boolean props** like `is-required`, `is-expanded`, and `is-selected` to inform interaction states and ensure proper feedback. *** #### 🧰 Recommended Tools * **Contrast Plugin (Figma)**: For checking color contrast * **Axe DevTools** or **Wave**: For browser-based audits during implementation * **Screen readers (VoiceOver, NVDA)**: Test with actual assistive tech during QA *** #### βœ… Make Accessibility the Default Don’t treat accessibility as an afterthought β€” bake it into your workflow from the beginning. When in doubt, **default to accessible** choices and verify with tools and real users. This not only improves usability for people with disabilities but strengthens your design for everyone. For more guidance, consult the [Dev Launchers Accessibility Guide](https://docs.google.com/document/d/1R0fVc4o32o1r-bh60OLKc-v9BLOa7J2HvYZPTGBLAcc/edit). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devlaunchers.org/dl-docs/universal-design-system/universal-design-system/getting-started/copy-of-accessibility-commitment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.