Theme

Website Accessibility Compliance (WCAG 2.1 AA)

Written by

in

User Story

As a user with visual, motor, auditory, or cognitive impairments,
I want the website to meet WCAG 2.1 AA accessibility standards (https://www.w3.org/TR/WCAG21/),
So that I can navigate, understand, and interact with all content and features without barriers.

1

Scenario: Semantic HTML structure supports screen readers

Given a user navigates the website using a screen reader
Then each page must contain semantic landmarks (e.g. header, nav, main, footer)
And headings must follow a logical hierarchical order (h1, h2, h3, …)
And all ARIA roles and attributes must be used appropriately where native HTML is insufficient (only use ARIA when absolutely needed)

2

Scenario: Images include meaningful alternative text

Given a user encounters an image on any page
Then every image (including background image) must include a descriptive alt attribute

3

Scenario: All interactive elements are keyboard accessible

Given a user navigates the website using only a keyboard
Then all buttons, links, form elements, and controls must be reachable using Tab
And focus order must follow the visual layout and user expectations
And the focused element must have a clear visual indicator (e.g. outline or border)

4

Scenario: Provide high contrast mode toggle in the website footer

Given the user scrolls to the footer of any page
Then the footer must include a clearly labeled button or link called "High Contrast Mode"

DEsk: https://www.figma.com/design/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?node-id=11897-3602&m=dev

Mobile: https://www.figma.com/design/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?node-id=11897-3607&m=dev
And the toggle must be accessible via keyboard and screen readers
And activating the toggle must apply or remove the high contrast mode as defined
And the toggle state must visually indicate whether high contrast is active
And the user’s preference must persist across pages and sessions

4.1

Scenario: Optional high contrast mode toggle for improved readability

Given a user requires enhanced visual contrast
When the user clicks the "High Contrast Mode" toggle
Then the website must apply a high-contrast stylesheet or class
And all text must meet a minimum contrast ratio of 4.5:1 against the background
And interactive elements (buttons, links) must remain clearly distinguishable
And the user’s preference should persist across sessions
And the toggle must be accessible via keyboard and screen readers

Toggle button in footer:

Desk: https://www.figma.com/design/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?node-id=11940-2255&m=dev

Mobile: https://www.figma.com/design/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?node-id=11897-3607&m=dev

Toogle button: https://www.figma.com/design/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?node-id=11940-2531&m=dev

5

Scenario: Text can be resized up to 200% without loss of content or functionality

Given a user zooms the browser up to 200%
Then all text must remain legible
And content must not overflow, be cut off, or require horizontal scrolling

6

Scenario: Forms are accessible and assistive-technology friendly

Given a user interacts with a form
Then each form field must have a visible label
And each input must be programmatically labeled (using label for=, aria-label, or aria-labelledby)
And error messages must be associated with the relevant inputs via ARIA or HTML
And required fields must be explicitly indicated

7

Scenario: Avoid flashing and motion that causes seizures or disorientation

Given the site includes animations or effects
Then no element may flash more than 3 times per second
And users with prefers-reduced-motion must see reduced or no animation

8

Scenario: Language is correctly defined

Given a user visits a page
Then the <html> element must include the correct lang attribute (e.g. lang="en", lang="fr")
And any language change within the content must be marked using lang attributes

9

Scenario: Accessible name and role for custom components

Given a user interacts with a custom component (e.g. modal, dropdown, slider)
Then it must expose a name, role, and state to assistive technologies using ARIA roles and properties
And the component must be operable via keyboard and screen reader

Comments

Leave a Reply

More posts