Accessibility statement
Last reviewed:
TaxKiln targets WCAG 2.1 Level AA. We treat accessibility as part of the editorial baseline, not a retrofit. This page sets out what we commit to, the known gaps, and how to flag anything we've missed.
Standard we target
TaxKiln targets the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. That is the standard the UK public sector is required to meet under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, and the standard we hold the editorial site to even though we are not a public-sector body.
What this means in practice
• Semantic HTML throughout: real headings, lists, landmarks, and one <main> element per page. • Keyboard navigation works without a mouse: every interactive control is reachable and operable from the keyboard. • Skip-to-content link at the top of every page for screen-reader and keyboard users. • Visible focus rings on links, buttons, and form controls so keyboard users can see where they are. • Colour contrast meets WCAG AA against both the light and dark themes; semantic design tokens drive every surface so contrast is consistent. • Text resizes cleanly up to 200% without loss of content or function. • Images carry meaningful alt text; decorative images use empty alt. • Forms have associated labels; calculator inputs announce their purpose to assistive technology.
Known limitations
We test against axe-core and manual keyboard / screen-reader passes, but TaxKiln is a large editorial site and individual pages can drift. If you find a heading-level skip, a missing label on a calculator, an unlabelled icon button, or a contrast regression on a sponsor placement, tell us — those are bugs, not by design.
Report an accessibility problem
Email hello@kilnguides.co.uk with the page URL and a short description of what didn't work for you, including the browser and assistive technology if relevant. We aim to acknowledge within five working days and to fix accessibility regressions ahead of routine editorial work.
What we will not do
We will not deploy an 'accessibility overlay' or a third-party widget that claims to make the site compliant by overriding its markup. Those tools degrade the experience for the assistive-technology users they purport to help and add a third-party tracker we have explicitly committed not to load. Accessibility lives in the underlying HTML, CSS, and editorial discipline.
Accessibility sits alongside privacy and statute-citation as a structural commitment: if the site stops being usable with a keyboard or a screen reader, that is a regression we treat as a bug, not a stylistic choice.
Related editorial pages
Last reviewed: