Web Accessibility Guide

Avoid wrapping elements in <div>s without meaning. This makes it difficult for assistive technologies like screen readers and search engines to interpret content correctly. Instead, use meaningful HTML elements:

• Use <h1> to <h6> for headings
• Use <p> for paragraphs
• Use <button> for interactive buttons
• Use <input type="radio"> for single-choice selections
• Use <input type="checkbox"> for multiple-choice selections

If using <div>s for styling, make sure to include the correct ARIA roles.

SEO: Helps search engines index your content correctly.
Screen Readers: Clearly communicates structure to visually impaired users.
RSS Readers: Ensures proper parsing and styling.

• Use only one <h1> per page for better SEO and accessibility.
• Do not skip heading levels (h2 should not jump to h4).
• Use proper HTML elements instead of <div>s and <span>s where possible.

The Web Accessibility Initiative – Accessible Rich Internet Applications (ARIA) improves accessibility for complex UI elements when native HTML is not sufficient.

Not for everything – Use semantic HTML first whenever possible.
For complex UI components like modals, tooltips, and dynamic content.

• aria-expanded – Indicates if an element (e.g., accordion) is open (true) or closed (false).
• aria-controls – Links elements together (e.g., button controlling an expandable section).
• aria-labelledby – Associates an element with a visible label.
• aria-hidden – Hides decorative elements from screen readers.
• aria-live – Announces live content updates (e.g., errors, chat messages).

Problem: A button labeled "Read more" provides no context.
Solution: Use clear, descriptive text or add an aria-label.

Problem: A departure time ("15:44") doesn’t explain its meaning.
Solution: Use aria-label: "Departure at 15:44. Arrival at 22:27. Travel time is 6 hours and 43 minutes."

Problem: Images/icons without alt text are meaningless for screen readers.
Solution: Use aria-hidden="true" for decorative elements.

Tab: Move forward through interactive elements.
Shift + Tab: Move backward.
Enter: Activate links.
Spacebar: Activate buttons and checkboxes.
Arrow keys: Navigate dropdowns and radio buttons.

• Ensure logical tab order – Follow the natural reading order.
• Avoid unnecessary tab stops – Don’t make users tab through unimportant elements.
• Avoid tabindex values greater than 0 – It disrupts the natural flow.
• Avoid keyboard traps – Ensure users can always navigate forward and backward.

• All interactive components should be accessible (accessible={true}).
• Use accessibilityLabel for meaningful descriptions.
• Use accessibilityRole to define component purpose (button, link, header).
• Use accessibilityState to describe component states (e.g., selected, disabled).
• Use accessibilityLiveRegion to notify users of dynamic changes.

Enable VoiceOver:

• Mac: System Preferences → Accessibility → VoiceOver → Enable.
• iPhone: Settings → Accessibility → VoiceOver → Enable.

Navigation:

• Ctrl + Option + Arrow keys: Move through content.
• Ctrl + Option + Space: Activate elements.
• Ctrl + Option + Cmd + H: Jump between headings.

Enable NVDA: Ctrl + Alt + N Navigation:

• H / Shift + H: Move through headings.
• Up/Down arrows: Move line by line.
• Caps Lock + Space: Enter/exit forms mode.

Enable TalkBack: Settings → Accessibility → TalkBack → Enable.
Navigation:

• Swipe left/right: Move through elements.
• Double-tap: Activate elements.
• Drag with two fingers: Scroll.

• Test your site at 125%, 150%, and 200% zoom to ensure layouts remain usable.
• Avoid fixed pixel (px) units for spacing and font sizes; prefer relative units (rem, em).
• Borders (e.g., 1px solid) are fine but should be tested under high contrast settings.

• Mac: System Preferences → Accessibility → Display → Text Size.
• Windows: Settings → Ease of Access → Display → Make text bigger.
• Android: Settings → Accessibility → Visibility Enhancements → Font Size and Style.
• iPhone: Settings → Accessibility → Display & Text Size → Larger Text.

We recommend reading the Guidelines section of the component documentation when importing a component. This section may contain important guidance on how to ensure the component is implemented in an accessible way and supports good web accessibility.

Additional reading:

• W3C Web Accessibility Guidelines⁠Ekstern lenke
• ARIA Patterns & Best Practices⁠Ekstern lenke