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.
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 violate WCAG 2.2.2 and lock out keyboard and screen reader users. How to make sliders accessible with pause, keyboard and ARIA.
96% of all 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 reading barriers without extra budget, reach more people and meet WCAG - 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 act as ranking signals 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.