Skip to content
Optimal Systems Styleguide

Accessibility

##Why Accessibility Matters

Accessibility is part of good UX and a quality indicator of our products. It ensures:

  • Inclusion and the best possible UX for everyone
  • An advantage in tenders, where accessibility is often a key criterion
  • Compliance with legal standards (BITV / WCAG)
  • Fewer support cases and greater trust

Core Principles

Section titled “Core Principles”
  • Perceivable: All content can be perceived visually and audibly.
  • Operable: Everything can be controlled using the keyboard.
  • Understandable: Language and structure are clear.
  • Robust: Works with assistive technologies.

Roles & Responsibilities

Section titled “Roles & Responsibilities”
  • Dev: ARIA, focus management, keyboard control, screen reader output
  • Designer: Contrast, states, visual readability
  • PO / QA: Definition and testing of accessibility criteria

Developer Checklist

Section titled “Developer Checklist”

Semantic HTML5 is used:

Section titled “Semantic HTML5 is used:”
  • Headings (h1–h6) in a logical order
  • Buttons, links, inputs, lists instead of div / span (HTML5 standard elements)
  • Meaningful landmarks (
    ,
  • RIA attributes used as supplements (aria-expanded, aria-pressed, aria-label, aria-describedby)

Labels:

Section titled “Labels:”
  • Every input field is connected to a
  • Placeholders do not replace labels

Icons:

Section titled “Icons:”
  • Have either accompanying text or a title
  • If purely decorative → aria-hidden=“true”

All functions are fully operable via keyboard:

Section titled “All functions are fully operable via keyboard:”
  • No “focus trap” (focus must not get stuck or lost anywhere)
  • Logical and predictable focus navigation order
  • Tab + Shift+Tab work consistently
  • No hidden interactive elements in the focus flow

Dialogs, Pop-ups, Menus:

Section titled “Dialogs, Pop-ups, Menus:”
  • Focus moves to the first element when opened
  • Focus returns to the triggering element when closed
  • Can be closed using ESC
  • “Focus loop” implemented (Tab stays within the dialog and cannot jump behind it)

Contrast Ratios:

Section titled “Contrast Ratios:”
  • Text to background at least 4.5:1
  • Large text (≥ 18 px or bold ≥ 14 px): 3:1
  • Focus outline at least 2 px wide (or a 2 px visual difference from the unfocused state if an outline already exists)
  • Focus outlines always meet contrast requirements
  • No information is conveyed by color alone

Zoom & Responsiveness:

Section titled “Zoom & Responsiveness:”
  • Pages and components remain readable and operable at 400% zoom
  • Responsive layouts (no horizontal scrolling at standard viewport sizes)

Screen Reader Output:

Section titled “Screen Reader Output:”
  • Name and role of every interactive element
  • Status and state changes of elements announced in real time (e.g. expanded/collapsed, active/inactive, checked/unchecked)
  • The system status must always be perceivable, especially for screen reader users - User notifications - For automated processes, aria-live and aria-busy are used so the screen reader can detect and appropriately announce them (progress bars, blocking loading processes)
  • Action labels (“Add button”, not just “Button”)

##Important Resources (please make sure to use):

-[NVDA screen reader download] (https://www.nvaccess.org/download/) -[Contrast checker] (https://accessibilityinsights.io/) (Use the desktop version!!!)