Accessibility is created in everyday work: in components, editorial templates, documents and test routines. This category collects articles from implementation — accessible navigation, dialogs and carousels, alternative texts and image descriptions, captions and transcripts, tables and data visualisations, PDF documents and native apps. Added to this are topics such as screen reader testing, assistive technologies, plain language and involving people with disabilities in evaluation. We also cover the organisational side: training for editors and developers, acceptance criteria in tenders, documenting test results and dealing with legacy content that cannot be reworked all at once. It is equally about recording test results so they remain traceable at the next change instead of getting lost when the project ends.
On this page you will find all posts on the topic “Practice & implementation”. The newest posts are at the top.
Below each title there is a short text about it. Click on a post. Then you can read the whole text.
Above the list you also see the other topics. At the bottom, a link takes you back to all posts.
How to commission Easy Language: choosing texts, the briefing, review by at least 2 people with learning difficulties and publishing under DIN SPEC 33429.
Countdown bar, basket timer and voucher pop-up: which element falls under WCAG 2.2.1 or 2.2.2, and what shops should test before the holiday campaign starts.
Three in four people over 65 are online, and 76 per cent of them shop there. Which WCAG criteria slow this clientele down and in which order to fix them.
A flaw in the product template appears on every item page. How to make variant choice, gallery, price line and add-to-cart feedback accessible.
Since 19 June 2026, § 356a BGB requires a withdrawal function. How it and the cancellation button work with keyboard, screen reader and zoom.
How a test round with blind, low-vision and motor-impaired participants is organised: recruitment, consent, task script, logging and the route into the remediation plan.
Section 4 BITV 2.0 requires sign language on the home pages of public bodies. What Annex 2 prescribes, how the player must behave and how to audit the result.
A WCAG audit report lists findings, but not an order. How to turn it into a remediation plan with waves, clear owners and a documented retest.
Map widgets bring barriers of their own. How a location search still works without a mouse, without colour perception and with a screen reader: list.
Speech input fails when the accessible name omits the visible text. How success criterion 2.5.3 works and how to test this way of operating your site.
Automated scans stop at the sign-in form. How a WCAG audit covers the protected area: scope, test accounts, session timeouts and screen reader testing.
Auto-rotating carousels without a pause violate WCAG 2.2.2 and lock out keyboard and screen reader users. How pause, keyboard and ARIA make sliders accessible.
96% of automatically detected WCAG errors come from six patterns - all in building blocks. Solve focus, keyboard and ARIA once in the component instead of on every page.
Plain language vs. easy language: lower comprehension barriers without extra budget and reach more people - a building block of your BFSG conformance.
Self-built date pickers fail on keyboard, focus and target size. How to make appointment booking operable under WCAG 2.2 for screen reader and keyboard users.
Parallax, auto-sliders and fast transitions can trigger dizziness. How prefers-reduced-motion and a pause mechanism make animations WCAG 2.2 compliant.
Alt text, descriptive link labels, semantic structure and contrast meet WCAG and support discoverability at the same time - accessibility and SEO as one lever.
The BFSG now covers native apps too. What iOS and Android apps must meet for WCAG 2.1 AA and EN 301 549: labels, tap targets, contrast and focus order.
Accessibility is an ongoing editorial process: train alt text, link text, headings and accessible PDFs in the team to prevent the gradual re-barriering.
Accessible navigation per WCAG 2.2: skip links, accessible menus with ARIA, aria-current, landmarks and visible focus management in practice.
The German Accessibility Strengthening Act has been in effect since June 2025. Who is affected, which deadlines apply, and what first steps are needed.
WCAG 2.2 introduces nine new success criteria. Focus Not Obscured, Dragging Movements and Redundant Entry explained with practical guidance.
Accessible checkout: usable payment forms, understandable error messages, address fields and progress indicators for online shops built to WCAG 2.2 AA level.
Screen reader optimisation for websites: ARIA landmarks, roles, live regions, semantic HTML and screen reader testing on Windows, macOS and mobile devices.
Understanding and implementing WCAG contrast requirements: tools, dark mode, focus indicators and non-text contrast for accessible websites.
Build accessibility in early instead of retrofitting it: the cost advantage of shift-left, clear roles, design tokens and a Definition of Done for the BFSG.
Keyboard navigation for accessible websites: tab order, focus management, skip links, keyboard traps and making custom widgets operable without a mouse at all.
Creating accessible PDFs: tagged PDFs, reading order, alt text, tables and forms tested and implemented per the PDF/UA standard and kept that way day to day.
Website accessibility testing: automated and manual testing methods, keyboard and screen reader testing and the professional WCAG audit at a glance.