Page 14 - Barrierefreiheit
-
Maxim Mironjuk
-
February 23, 2025
A focus ring is to keyboard users what the mouse cursor is to everyone else: the only way to see where they currently are. With the ring-* utilities, focus-visible and ring-offset, Tailwind CSS builds focus indicators that stay visible instead of disappearing behind outline-none.
-
Maxim Mironjuk
-
February 22, 2025
The MutationObserver is the modern, efficient alternative to DOMSubtreeModified and polling-based approaches to watching the DOM. It reacts asynchronously to attribute, child-node and text changes in the DOM, without the rendering-thread blocking that the old mutation events caused.
-
Maxim Mironjuk
-
February 18, 2025
An accessible checkout in Magento and Hyva guides screen reader users, keyboard only users and voice control users safely through shipping, payment and order review. This article shows in practical terms how a central error summary, keyboard operable payment methods, clean focus management and announced status messages prevent lost sales, build trust and bring the entire checkout flow reliably up to WCAG 2.2 level.
-
Maxim Mironjuk
-
February 18, 2025
Deque Systems' axe-core has long stopped being a single tool. It is the shared testing engine behind axe DevTools, Lighthouse, jest-axe, cypress-axe and a long list of other testing tools, all running the same rules against the same DOM. Treating axe-core as a CI-only concern throws away its biggest advantage: catching barriers in seconds, right at a developer's own desk, long before a commit even exists. This article covers using axe-core in Storybook, in local development and through the browser extension every day, and where automated detection genuinely stops.
-
Maxim Mironjuk
-
February 15, 2025
A single prefers-reduced-motion rule in a single component does not solve a team problem. Only a central motion token system with clear tiers, automated testing and documented patterns ensures that every new animation in the project automatically takes proper account of motion sensitivity.
-
Maxim Mironjuk
-
February 11, 2025
Screen reader users do not orient themselves by scrolling, but by jumping deliberately between landmarks like header, nav, main, aside and footer. Using these HTML5 elements correctly and sparingly gives blind and low vision visitors a fast overview of every page and direct access to content, while excessive or unlabeled landmarks do the opposite and make navigation noticeably harder.
-
Maxim Mironjuk
-
February 07, 2025
A tooltip that only appears on mouse movement stays invisible to keyboard users and screen readers. Accessible tooltips with Tailwind CSS connect supplementary information via aria-describedby, respond to hover and focus alike, and close reliably with Escape.
-
Maxim Mironjuk
-
February 07, 2025
A dropdown that only works with a mouse is useless to keyboard users and screen reader users. The WAI-ARIA listbox pattern defines precisely how arrow keys, Home, End, Escape, and type-ahead must behave in a dropdown, and Alpine.js makes the implementation surprisingly elegant.
-
Maxim Mironjuk
-
February 03, 2025
On a classic page load, the browser reliably resets focus to the top of the document. With client-side routing and dynamically toggled modals, that does not happen on its own. Fail to explicitly move focus after navigation and when opening or closing dialogs, and your single page application becomes effectively unusable for keyboard and screen reader users.
-
Maxim Mironjuk
-
February 01, 2025
A contrast error in a mockup can be fixed with a single click, the same error after launch costs person-days. This article shows how to check contrast, focus order, and touch target sizes during design, how accessibility acceptance criteria belong in the design handoff, and why designers share responsibility from the start.
-