Page 10 - Barrierefreiheit

An accessibility statement is no longer optional under the BFSG, it is a legal requirement with clearly defined content. Companies that honestly document known limitations, provide a working feedback mechanism, and keep the statement regularly updated meet the requirements of BFSG and EAA and protect their business from cease-and-desist claims.

Screen reader users lose no information when a purely decorative image is missing, but they lose important context when an informative image has no alt text. This article shows a practical test for telling the two apart, correct techniques like empty alt, CSS background images and aria-hidden, and common mistakes when handling icons and decorative graphics in Magento and Hyvä stores.

A keyboard trap happens when keyboard focus enters a modal, dropdown, or third-party widget and can't find its way back out with Tab or Shift Tab. For keyboard users and screen reader users, that means a complete blocking point. This article covers common causes, a systematic test procedure, and a correct focus trap implementation that can always be exited reliably with the Escape key.

A mini-cart that updates only visually leaves screen reader users unsure whether a product was actually added. With a correct live region, full keyboard operability and clean focus management, the flyout becomes usable, testable and WCAG compliant for every visitor alike.

Star ratings look like a trivial component at first glance, but once half stars, an interactive input with a hover preview, and an accessible implementation are all required at the same time, there are more detail problems hiding inside than expected. This article shows how to cleanly implement both the read-only display of an average rating and the editable input variant with Tailwind CSS, including precise rendering of half stars and an accessibility approach that does not rely on visual stars alone.

Forms are the most critical touchpoint on any website for people using screen readers, because without correct label association, meaningful fieldset and legend grouping and clearly communicated required fields, a checkout simply becomes unusable. This article walks through a practical address form to show how Magento and Hyva developers build forms that are semantically correct, communicate errors accessibly and implement WCAG compliant input assistance.

The classic :valid and :invalid pseudo-classes fire as soon as a form field exists, often before the first keystroke. That leads to red borders around empty required fields right when the page loads. The newer :user-valid and :user-invalid pseudo-classes instead wait for real user interaction and solve this problem entirely without JavaScript.

The checkout is the most business-critical page in any online store, and it is exactly where accessible interfaces fail most often. Blocked progress indicators, invisible error messages and keyboard traps in the payment step cost paying customers and open legal exposure under accessibility law. This article shows how to systematically audit, test and implement every single step of the checkout process for Magento and Hyva.

An automatically generated invoice PDF from Magento looks correct to sighted customers, but to screen reader users it is often just an unstructured collection of text fragments, or even a plain image with no recognizable text at all. This article covers what the PDF/UA standard concretely demands, how tagged PDFs differ from scanned images, and how to rework Magento invoices, catalogs, and data sheets into accessible documents step by step with Adobe Acrobat and the PAC checker.

Automated accessibility tests with axe-core reliably catch roughly a third of all WCAG violations and integrate directly into an existing Playwright or Cypress suite. With a baseline strategy the build only fails on new violations, while known legacy issues stay visible instead of blocking the pipeline permanently. Manual review remains essential for keyboard operation and screen readers.