Page 13 - Barrierefreiheit

text-wrap balance and text-wrap pretty solve two different line break problems: balance evens out short headings across all lines, pretty prevents single words from being left alone at the end of body text paragraphs. Using both values deliberately instead of interchangeably yields noticeably cleaner typography without any extra JavaScript.

axe-core checks a rendered page against a fixed catalog of automatable accessibility rules, such as color contrast, missing form labels, or incorrectly nested headings, and integrates through @axe-core/playwright in end-to-end tests as well as through vitest-axe in component tests. It's important to know the limits of automated checking, though, since tab order logic and content clarity fall outside what it can cover.

A breadcrumb bar built from nested div and span elements with separators looks correct to sighted users, but delivers no information whatsoever to a screen reader that it's a navigation aid with a clear position in the page hierarchy. This article covers how nav with aria-label, aria-current, a semantically correct list structure, and accessible pagination controls create real, usable navigation for screen reader users, with complete practical examples from Hyva.

EN 301 549 is the invisible foundation underneath most accessibility discussions in Europe: the BFSG, the European Accessibility Act, and public procurement rules all point back to this standard, yet few project teams have ever opened the actual document. Anyone who only knows WCAG only knows part of it.

An accessibility audit or an automated scan routinely produces several hundred individual findings at once, ranging from a completely unusable checkout form to a slightly weak contrast in a footer, and without clear prioritization, all of these findings land undifferentiated in the same backlog, where the most urgent problems get buried under the sheer mass of less relevant ones. This article covers severity categories aligned with WCAG conformance levels, an impact assessment by affected user group, and clean integration into Jira or Linear that makes sure findings actually get worked through instead of vanishing into a backlog graveyard.

Accordions and tabs are among the most frequently misimplemented interface patterns on the web, because they look visually simple while requiring, underneath, a precisely defined keyboard interaction and their own ARIA role structure. An accordion that only reacts to a click on a div, or tabs that know no arrow key navigation, appear to work perfectly for mouse users while remaining unusable or at least confusing for keyboard and screen reader users.

Animations and transitions improve the user experience, for most users. For people with vestibular disorders, migraines, or epilepsy, those same animations can trigger serious health problems. The Tailwind CSS motion-reduce variant makes it easier than ever to build accessible animations and meet WCAG 2.2.

Navigation is the backbone of every website, and at the same time the component that reveals whether Tailwind CSS is being used for simple styling tasks or as a complete UI system. This guide shows how to correctly implement the most important Tailwind CSS navigation patterns: with ARIA attributes, keyboard navigation and Alpine.js.

A modal without a focus trap lets keyboard users disappear into the background while the dialog sits visually in front. This guide shows how to implement a custom focus trap in React, set ARIA attributes correctly, and reliably restore focus after closing, all without a ready made library.

A modal that visually covers everything but leaves keyboard focus free to wander through the page behind it is not really an overlay for keyboard and screen reader users. They tab through navigation, header, and footer of the background page while the dialog visually floats in front, invisible to their own focus cursor. A correctly implemented focus trap makes sure keyboard focus stays exactly where it visually appears: inside the dialog, until it is deliberately closed.