Accessible Content: Training for Your Editorial Team
Accessibility is an ongoing editorial process: train alt text, link text, headings and accessible PDFs in the team to prevent the gradual re-barriering.
This is page 6 of the posts from our blog. The newer posts are on the pages before.
Each post explains one topic. Below the title there is a short text about it. Click on a post. Then you can read the whole text.
The posts are on more than one page. Below the list you can choose another page.
Accessibility is an ongoing editorial process: train alt text, link text, headings and accessible PDFs in the team to prevent the gradual re-barriering.
When AI chatbots and voice assistants fall under the BFSG and how conversational UI becomes WCAG-compliant with ARIA live regions and focus management.
What a WCAG 2.2 audit costs in 2026: prices by scope, sampling versus full audit, monitoring, the BFSG fine ceiling, conversion ROI and funding at a glance.
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 navigation per WCAG 2.2: skip links, accessible menus with ARIA, aria-current, landmarks and visible focus management in practice.
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.