Accessibility Guidelines

These guidelines help ensure that all Cynosure components are usable by everyone, including people with disabilities. They are based on WCAG 2.2 AA standards. Follow these principles and best practices when designing or developing new components.

---

1. Semantic HTML First

• Use native HTML elements whenever possible (<button>, <a>, <form>, etc).
• Avoid using generic containers (<div>, <span>) for interactive controls.
• Proper semantic tags improve screen reader and assistive technology support.

1<!-- Good -->
2<button type="submit">Send</button>
3
4<!-- Bad -->
5<div onclick="sendForm()">Send</div>
6

---

2. Keyboard Navigability

• All interactive elements must be accessible and usable by keyboard alone.
• Use the correct tabindex (tabindex="0" for custom elements, avoid positive values).
• Never trap the keyboard; ensure focusable elements are in logical order.

1element.addEventListener('keydown', (event) => {
2  if (event.key === 'Enter' || event.key === ' ') {
3    // Trigger button action
4  }
5});
6

Test: Tab through your component. Can you reach & operate all controls without a mouse?

---

3. Visible Focus Styles

• All interactive elements must have a visible focus indicator.
• Do not remove or hide focus outlines unless you provide a suitable custom alternative.

1.button:focus {
2  outline: 2px solid #1473e6;
3  outline-offset: 2px;
4}
5

---

4. Color & Contrast

• Text and UI components must meet minimum contrast ratios:
  • Text: 4.5:1 (normal), 3:1 (large, 18pt/24px or bold 14pt/18.5px)
  • UI Elements/Graphics: 3:1
• Do not convey information by color alone.
• Use accessible color palettes and check with tools like WebAIM Contrast Checker.

---

5. ARIA Labels & Roles

• Use ARIA attributes only if semantic HTML does not communicate the necessary meaning.
• Apply roles such as role="dialog", role="alert", aria-label, aria-labelledby, aria-describedby as needed.
• Avoid “div/aria soup”: only use ARIA to supplement, not replace, HTML semantics.

1<input aria-label="Search this site" type="search" />
2

---

6. Alternative Text

• All meaningful images and media must have descriptive alt attributes or ARIA labels.
• Decorative images should use alt="" (empty alt).

1<img src="profile.jpg" alt="User: Jane Doe" />
2<img src="decoration.svg" alt="" />
3

---

7. Headings & Landmarks

• Use headings (<h1>–<h6>) to structure content hierarchically.
• Define landmarks for regions using header, nav, main, aside, footer, or ARIA roles.

1<main>
2  <h1>Accessibility Guidelines</h1>
3  ...
4</main>
5

---

8. Dynamic Content & Updates

• Announce important dynamic UI changes with ARIA live regions (aria-live="polite" or aria-live="assertive").
• For JavaScript-rendered updates, ensure screen readers are informed.

1<div aria-live="polite" id="status-message"></div>
2<script>
3  function showMessage(msg) {
4    document.getElementById('status-message').textContent = msg;
5  }
6</script>
7

---

9. Error Messages & Validation

• Always provide clear, specific error messages for invalid fields.
• Link errors to fields using aria-describedby or by placing messages adjacent to controls.
• Do not rely solely on color to indicate errors.

1<label for="email">Email</label>
2<input id="email" aria-describedby="email-error" type="email" />
3<span id="email-error" role="alert">Please enter a valid email address.</span>
4

---

10. Motion, Animation & Timing

• Avoid auto-updating, moving, blinking, or scrolling content that can’t be paused.
• Respect user’s prefers-reduced-motion settings in CSS and JS.

1@media (prefers-reduced-motion: reduce) {
2  * {
3    animation-duration: 0.01ms !important;
4    animation-iteration-count: 1 !important;
5    transition-duration: 0.01ms !important;
6    scroll-behavior: auto !important;
7  }
8}
9

---

11. Accessible Component Patterns

• Follow accessible patterns for interactive components (accordions, modals, tabs, menus, etc.).
• Use guidance from WAI-ARIA Authoring Practices.
• Test custom widgets with both keyboard and screen readers.

---

12. Test Early & Often

• Use automated tools like axe-core, Lighthouse, or WAVE to check accessibility.
• Test with keyboard, color contrast analyzers, and major screen readers.
• Fix violations before launch.

---

References

• WCAG 2.2 Quick Reference
• WAI-ARIA Authoring Practices
• Accessibility Insights

---

By following these guidelines, Cynosure components can achieve AA-level accessibility and provide equal access for all users.