Accessibility

Web accessibility is about making websites usable by as many people as possible, regardless of their abilities or disabilities. This includes people with visual, auditory, motor, or cognitive impairments.

• All content and functionality must be perceivable, operable, understandable, and robust.
• Elements hidden visually using CSS must not be accessible to screen readers or keyboard navigation.
• Use semantic HTML whenever possible before relying on ARIA attributes.

Semantic HTML

• Semantic structure is not only about heading hierarchy.
• Pages must use the appropriate structural elements whenever possible, such as <header>, <main>, <nav>, <section>, <article>, and <footer>.
• Text content must be placed inside proper text elements such as <p>, <ul>, <ol>, <li>, or headings, instead of generic <div> or <span> elements.
• Use links when the element navigates to another page or resource.
• Use buttons when the element performs an action on the current page, such as opening a modal, toggling content, or submitting a form.

Page Structure & Titles

• Every page must contain one single H1 that represents the main topic of the page.
• Headings must follow a logical hierarchy (H2 → H3 → H4, never skipping levels).
• Headings should never be empty.

Caution

If a title is visually represented by an image or icon, include accessible text for screen readers.

Readability & Text

• Font sizes must be at least 16px.
• Ensure sufficient color contrast between text and background.
• Avoid long blocks of dense text; prefer clear paragraphs and lists.
• The interface must allow browser zoom without breaking content or functionality.

Keyboard Navigation

• All interactive elements must be accessible using the keyboard.
• Keyboard focus must always be visible.
• Keyboard navigation must follow a logical order that matches the visual and semantic structure of the page.
• Users should never get “lost” when navigating with the keyboard.
• Include skip links to allow users to bypass repetitive or blocking content. Skip links are especially useful for skipping elements such as:
  • the main header
  • the main navigation
  • repeated banners
  • embedded content that may interrupt navigation, such as social media iframes

Focus Management

When content changes dynamically, focus must move to the appropriate element.

Examples include:

• opening modals
• displaying error messages
• navigating between interface views

Focus should never remain on an element that is no longer visible or relevant.

Avoid removing focused elements from the DOM without moving focus to a valid destination.

Clickable & Interactive Elements

• Links or buttons without visible text must include a descriptive aria-label.
• Links that open in a new window or tab must clearly announce this to screen readers. If an element already has an aria-label, append “opens a new window” instead of replacing it.
• Links that open in a new tab must use rel="noopener noreferrer".
• Avoid using non-semantic elements such as <div> or <span> as clickable controls.

<a
  href="https://external-site.com"
  target="_blank"
  rel="noopener noreferrer"
  aria-label="Terra Blog, opens a new window"
>
  Terra Blog
</a>

Touch Targets

Clickable elements must be large enough to interact with comfortably.

Recommended minimum target size:

• 44 x 44 px for buttons, links, and interactive elements

Navigation & Menus

• Use the semantic <nav> element for navigation.
• If semantic elements are not possible, use appropriate ARIA roles such as role="navigation".
• For dropdown menus:
  • use aria-haspopup="true"
  • toggle aria-expanded="true" / aria-expanded="false" based on state

<button
  aria-haspopup="true"
  aria-expanded="false"
>
  Menu
</button>

Media & Visual Content

• All meaningful images must include descriptive alt text.

  <img src="chart.png" alt="Sales growth chart for Q1 2024" />

• Decorative images or icons should be hidden from assistive technologies.

  <img src="divider.png" role="presentation" alt="" />

• Figure elements must either:
  • contain accessible text, or
  • be excluded using role="none"

Forms & Inputs

• Every form field must have:
  • a <label> element, or
  • an aria-label
• Required fields must include aria-required="true".
• Validation errors must be communicated using aria-invalid.

  <label for="email">Email</label>
  <input
    id="email"
    type="email"
    aria-required="true"
    aria-invalid="false"
  />

• Search inputs must include role="search" for semantic clarity.

Placeholder Usage

Placeholders must not replace labels.

Placeholders disappear when users start typing and may not be announced consistently by assistive technologies.

Always include a visible <label> for form fields whenever possible.

Dynamic Content & Announcements

When content updates dynamically without a page reload, the change must be announced to assistive technologies.

Use aria-live regions to notify screen readers of important updates such as:

• loading states
• form validation errors
• search results
• status messages

Example:

<p aria-live="polite">Loading results...</p>
<p aria-live="assertive">There was an error submitting the form.</p>

• aria-live="polite" should be used for non-critical updates.
• aria-live="assertive" should be used for urgent messages that must be announced immediately.

Sliders & Carousels

• Sliders and carousels must be clearly identified as landmarks.
• Use aria-label to describe their purpose (e.g. carousel, featured articles).
• Carousels are often problematic for accessibility. Avoid them when possible.
• Navigation controls (next / previous) must be accessible and labeled.
• Pagination items must indicate:
  • their function
  • the current slide

<button aria-label="Next slide"></button>

Iframes & Embedded Content

• Iframes must include a descriptive title or aria-label.
• If iframe content is irrelevant to screen-reader users, it should be hidden.

<iframe
  src="video.html"
  title="Product introduction video"
></iframe>