Page 4 - Barrierefreiheit

SVG icons are increasingly replacing icon fonts, but without deliberate labeling they carry no text for screen readers at all. Anyone who fails to give a meaningful icon like a wishlist heart button a clear name, and fails to hide decorative icons with aria-hidden, ends up with invisible or confusing controls. This article shows the correct technique for both cases, with a complete practical example.

Automated scanners like axe-core catch only a fraction of the real barriers in an application. This guide shows how a structured manual audit with keyboard pass, screen reader pass, zoom and contrast pass, and reduced motion pass runs systematically, how findings are prioritized by real user impact instead of raw violation count, and how automated and manual results can be combined into one report that developers can actually act on.

ARIA applied incorrectly often makes web pages less accessible rather than more. This article walks through the most common ARIA mistakes in real frontends, from redundant roles to misused aria-hidden and missing required states, and delivers a practical before-and-after audit for Magento and Hyvä projects.

The wishlist button is one of the most unassuming yet most frequently mismarked interaction elements in an online store: a heart icon flips its state on click without any visible change to the surrounding markup, and that silent status change is invisible to screen reader users without extra ARIA work. Applying the toggle button pattern with aria-pressed consistently, and actively announcing status changes, turns a purely visual switch into a traceable action, including while managing the wishlist itself.

A cookie banner that swallows focus, only allows rejection through a hidden link, and stays invisible to screen readers is not just a dark pattern, it is several concrete accessibility violations at once.

Accessibility in React components often fails on one detail: IDs for aria-labelledby and htmlFor must be unique and must match between server and client. useId solves both at once, without boilerplate and without hydration errors.

With the light-dark() function, a light and a dark mode color value can be specified in a single declaration, instead of maintaining two separate prefers-color-scheme blocks. The browser automatically picks whichever of the two values applies based on the currently active color-scheme, both for system preference and for a manual toggle that overrides it.

Flatpickr brings along kilobytes of jQuery heritage and an external dependency. A custom Alpine.js datepicker fits into fewer than 80 lines of reactive JavaScript, complete with month navigation, keyboard support, min/max limits, and full ARIA semantics, without a single external dependency.

The HTML element together with and displays small annotation text, so-called ruby annotations, directly above or beside individual characters. In Japanese and Chinese content, these annotations explain the pronunciation and meaning of whole character blocks, and for international shops with an East Asian audience they are not a niche feature but a standard requirement.

The WCAG splits its success criteria into three conformance levels: A, AA and AAA. Understanding what each level technically requires lets you set realistic goals instead of vaguely hoping for full completeness. This article explains the differences between the levels, why AA is the right legal and practical target for most commercial websites, and which individual AAA criteria are still worth adopting selectively.