Page 7 - Barrierefreiheit

Building interactive controls out of a generic div or span throws away keyboard support, focus order, and screen reader announcements, forcing you to rebuild all of it laboriously with ARIA. Native HTML elements like button, a, ul, and h2 deliver these properties for free. This article shows how to spot semantic mistakes in Magento and Hyvä templates and replace them with the right elements.

Dark mode is often treated as a pure taste question, but it is an accessibility topic with real tension built in: it relieves light-sensitive users while potentially worsening readability for users with astigmatism through the halation effect. Teams that recalculate contrast ratios correctly, respect prefers-color-scheme, and avoid pure black build a color scheme that genuinely works for both groups.

Drag and drop feels intuitive for sighted mouse users: grab an element, move it, release it. For keyboard users and screen reader users, this interaction usually does not exist at all, because it is built exclusively on mouse and touch events, without a single one of the involved elements being reachable via Tab or activatable via Enter. Offering product sorting in the admin or a wishlist order exclusively through drag and drop effectively locks an entire user group out of the feature.

Accessibility knowledge that lives in a single team member is a quiet risk: vacation, illness or a job change can open a gap overnight. This article shows practical, low-cost ways that pairing sessions, screen reader demos and a shared checklist embed knowledge across the whole team, bringing new developers and designers along from day one.

Data visualizations in Vue 3 are often wired in as a black box: the chart library takes over the canvas DOM and Vue loses track of what's happening. With the right composable pattern, charts stay reactive, get destroyed correctly, support screen readers through ARIA text alternatives, and load via defineAsyncComponent only once they are actually visible.

For people with vestibular disorders, migraines, or epilepsy, excessive animation on websites can trigger real physical discomfort. The CSS media query prefers-reduced-motion gives developers a way to respect that system-wide preference, and WCAG 2.2 makes it a requirement. This article explains the background, the correct implementation strategies, and the most common mistakes.

Alpine.js components often look interactive and modern, yet remain unusable for screen reader and keyboard users whenever ARIA attributes are not reactively wired to component state. This article shows, hands on, how to correctly use x-bind:aria-expanded, x-on:keydown and clean focus management, then builds a fully accessible accordion and a dropdown menu from scratch, including keyboard navigation and screen reader support.

ARIA never overrides appearance or behavior, it only overlays the accessibility tree with roles, states, and properties that screen readers and other assistive technologies read out. Developers who use ARIA without knowing the five ground rules often build interfaces that are less accessible, not more. This article uses a real tab component to show when ARIA is actually necessary and when a native HTML element remains the better choice.

Updating dynamic content with JavaScript without informing screen reader users creates invisible errors and silent success messages. ARIA live regions with aria-live, aria-atomic and aria-relevant announce changes reliably without shifting focus, making cart updates, form validation and search results understandable for every user.

Choosing the right Vue 3 component library decides accessibility, bundle size and how much design control the team keeps. Headless UI, Radix Vue, shadcn/vue, PrimeVue and Naive UI follow fundamentally different philosophies, and this article shows which one is right for which context.