An accessible product is one that people can perceive, understand, navigate and interact with regardless of ability, device or context. Our system is built to make that the default, not an afterthought.

That default is shaped by lived experience on our team, not just standards on paper. This documentation and the A11Y checklist reflect what actually works in practice, both for us and for the people using our products.

Principles for product teams #

These principles guide design and engineering decisions in any product built on Kesko Design System. They build on WCAG 2.2 and what our team has learned from shipping accessible products.

Keep it consistent #

Consistency enhances clarity and makes your product more predictable and easy to use. When the same control means the same thing on every page and feature, people don’t have to relearn it.

  • Use familiar conventions and apply them consistently.
  • Use the design system’s styles and components as the base. They have built-in accessibility features and create consistency across products.
  • Use the same styles, components, and interaction patterns for the same experiences across pages to lessen cognitive load.

Keep it simple #

Respect people’s time by creating products that are uncomplicated and easy to use.

  • Use consistent and clear language, avoid jargon.
  • Ensures content is understandable for everyone.
  • Avoid complex interaction flows and experiences.
  • Aim for content to be written at a reading level of ages 12 to 14.

Make it inclusive #

Making our products inclusive is about putting people first. Regardless of their age, gender, mobility, ethnicity, sexual orientation, or circumstances.

  • Use inclusive language.
  • Don’t make assumptions about people’s abilities.
  • Avoid figures of speech, idioms, and complicated metaphors.

Give control #

Ensure people are in control. People should be able to access and interact with content in their preferred way.

  • Allow people to zoom, adjust text scale, contrast, and colors.
  • Don’t override them with e.g. user-scalable=no or fixed font sizes.
  • Honour prefers-reduced-motion setting.
  • Enable reflow across all viewport sizes.

Use semantic HTML #

Semantic HTML carries meaning to assistive technology and helps people interpret the elements on a page.

  • Use <button> for actions, <a href> for navigation, and the appropriate form elements (<input>, <select>, <textarea>) for data entry.
  • Use landmark elements (<nav>, <main>) and a single <h1> per page, with <h2>-<h6> reflecting the actual content hierarchy.
  • Reserve <div> and <span> for purely visual grouping.

Offer text alternatives #

Text is the most flexible representation of content. It can be magnified, narrated, or rendered on a braille display.

  • Always use visible and accessible text labels.
  • Give every meaningful image an alt attribute. Decorative images use alt="".
  • Caption and transcribe video and audio content, or link to a transcript.
  • Pair every form control with a visible <label>. If a label must be hidden visually, use the Visually Hidden component or the utility class.

Don’t rely on color alone #

Having some form of color vision deficiency is common, and many more view your products in bright sunlight, on cheap displays, or in dark mode.

  • Never rely on color alone to convey meaning.
  • Instead, pair color with text, an icon, or a shape whenever it conveys status.
  • Verify text contrast meets WCAG requirements. 4.5:1 for body text, 3:1 for large text and non-text elements such as icons and form borders.

Test broadly #

Automated checkers catch around a third of accessibility issues. The rest need a human and a real assistive technology.

  • Include people with disabilities in usability testing. Synthetic tests cannot replace lived experience.
  • Tab through every flow with the keyboard alone.
  • Use different types of assistive technology to test your product.

Design for all users #

Disability is the mismatch between a person and their environment, not a property of the person. Most of us experience that mismatch at some point. Temporarily, situationally, or permanently. Design for the full range, not for a single profile.

Vision #

  • Provide alt text and semantic structure so screen readers and magnifiers have something to work with.
  • Verify color contrast against the background you’re actually using.
  • Don’t rely on color alone to convey meaning.
  • Don’t hide focus indicators.
  • Real world examples:
    • Low vision (permanent)
    • Eye strain (temporary)
    • Bright sunlight (situational)

Hearing #

  • Caption all video content. For audio-only content, provide a transcript.
  • Don’t rely on sound alone for alerts or feedback. Pair audio with a visual change.
  • Real world examples:
    • Hard of hearing (permanent)
    • Blocked ears from a cold (temporary)
    • Public transit (situational)

Motor #

  • Make selectable targets at least 24×24 size.
  • Support keyboard navigation, including a visible focus ring and a logical tab order.
  • Don’t require precise gestures, drag operations, or quick double-actions without an alternative.
  • Real world examples:
    • Arthritis (permanent)
    • Broken wrist (temporary)
    • Carrying shopping (situational)

Cognitive #

  • Use consistent and clear language.
  • Ensures content is understandable for everyone.
  • Avoid complex interaction flows and experiences.
  • Don’t impose tight time limits without an option to extend or remove them.
  • Real world examples:
    • Dyslexia (permanent)
    • Sleep deprivation (temporary)
    • Time pressure (situational)

Accessibility checklist #

For a release-readiness check, use the Kesko accessibility checklist. It is an interactive, browser-based accessibility checklist used by the design system team that allows you to sign off things section by section.

Open A11Y checklist

Resources #