The Web Content Accessibility Guidelines are the technical yardstick for digital accessibility — in Europe via the harmonised standard EN 301 549. This category explains the success criteria so they become usable day to day: contrast values and text sizes, keyboard operability and visible focus, target sizes for controls, motion and autoplay, form errors and status messages, semantic structure and accessible names. We look at the differences between conformance levels, at what WCAG 2.2 added, and at which checks can be automated and which necessarily remain manual. Every article names concrete testing steps rather than general appeals. We also classify the tools: what automated checks reliably find, where they produce false positives and why an assessment without manual testing stays incomplete.
On this page you will find all posts on the topic “WCAG & standards”. 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.
Empty links and buttons are among the most common WCAG findings. Fix patterns for icon buttons, image links and “more” links, checked via the links list.
Success Criterion 1.4.13 asks for three things at once: dismissible, hoverable, persistent. This article takes the wording apart and shows the BITV test path.
What forced colors mode does to your design, which properties fall away in the process and how to set up forced-colors, system colours and focus styles cleanly.
ATAG 2.0 audits the tool, not just the website: Part A covers the editing interface, Part B the guardrails that make accessible content the likely outcome.
On 10 September 2026 the W3C published a new WCAG 3 Working Draft. What has changed, why WCAG 2.2 AA remains the relevant benchmark and what teams should do today.
Accessible sign-in under WCAG 2.2 SC 3.3.8: password managers, magic links, passkeys and low-barrier CAPTCHA alternatives using object recognition and audio.
When AI chatbots and voice assistants fall under the BFSG and how conversational UI becomes WCAG-compliant with ARIA live regions and focus management.
Accessible route changes in SPAs: move focus to the new heading, keep the page title in sync and announce view changes via a live region per WCAG 2.4.3.
Design charts accessibly: patterns instead of colour alone, sufficient contrast, text alternatives per WCAG 1.1.1 and a table fallback for charts.
Accessible error and status messages per WCAG 4.1.3 using ARIA live regions, role=alert, role=status and aria-describedby for forms and dynamic content.
Build modal dialogs accessibly: role=dialog, aria-modal, focus trap, ESC, return focus and an inert background following WCAG 2.4.3 and the ARIA Dialog Pattern.
Build data tables accessibly: th with scope, caption, headers and id for complex tables, layout vs. data tables and responsive tables following WCAG 1.3.1.
Captions, transcripts and audio description under WCAG guideline 1.2 and the BFSG: what makes video and audio accessible in 2026 - explained in practice.
How to write alt text under WCAG 1.1.1 correctly: describe informative, decorative and complex images, charts and infographics with long descriptions clearly.
WAI-ARIA in practice: roles vs. native HTML, states like aria-expanded and aria-selected, live regions with polite and assertive plus common mistakes.
Accessible forms per WCAG 2.2: programmatic labels, required field marking, error messages with aria-describedby and role=alert, plus focus management.