Our commitment
PointCPD is built to WCAG 2.1 AA as a genuine engineering target, not a compliance afterthought bolted on at the end. That standard covers the practical things that actually matter to a real user with a disability or access need: sufficient colour contrast, keyboard navigability throughout the site and the module player, captions on video content, and interface elements sized and spaced for real-world use — including with a work glove on, on a phone, on-site.
Why this matters specifically for a CPD platform
CPD content that isn’t genuinely accessible isn’t just a general fairness problem — for a builder who needs it to renew a real licence, an inaccessible module is a direct barrier to a legal and financial obligation, not just an inconvenience. That’s a higher bar than most consumer websites need to clear, and we take it as a hard requirement rather than a nice-to-have, consistent with how we treat every other non-negotiable in this build (server-side point verification, immutable audit records) as genuinely non-negotiable rather than aspirational.
What we’ve actually built for this
Our brand colour palette was chosen with contrast in mind from the start — our signal yellow accent is used deliberately sparingly against dark ink text and light surfaces specifically because yellow-on-white and yellow-on-light backgrounds are a common contrast failure point, and we designed around that constraint rather than discovering it after launch. The module player is built with keyboard navigation as a first-class path through every block type, not a fallback. Where video content exists, captions are a requirement before publishing, not an optional extra. Progressive enhancement is a deliberate architectural choice across the site — animated and interactive elements (like our scroll-reveal animations) never hide content if JavaScript fails to load or a user has reduced-motion preferences set; the underlying content is always fully visible and usable regardless.
Where we know we have more work to do
We’d rather be honest here than claim perfection: accessibility is an ongoing practice, not a box you tick once and close. As we add new interactive block types (branching scenarios, hotspot images, drag-and-drop exercises), each one needs its own genuine accessibility review — a drag-and-drop interaction in particular needs a real keyboard-operable alternative path, and we treat that as a launch-blocking requirement for any new block type, not a follow-up task.
If something isn’t accessible
If you hit a genuine accessibility barrier anywhere on PointCPD — a module block you can’t complete with a keyboard, insufficient contrast somewhere, missing captions, or anything else that gets in the way of you actually completing CPD you need for your licence — tell us directly via our contact page. We read every message personally, and an accessibility barrier on a platform builders rely on for a real licence requirement gets treated as a genuine priority, not routine feedback.
Assistive technology and browser support
The platform is built on standard, semantic HTML and standard web accessibility patterns rather than a custom framework that fights against screen readers or other assistive technology — that’s a deliberate choice to maximise compatibility with whatever tools you already use, rather than requiring you to adopt something specific to us.
Specific block types and how we’ve approached them
Knowledge-check and assessment blocks (multiple choice, multi-select, true/false) are built on standard, fully keyboard-navigable form controls — there’s no custom widget here that a keyboard or screen reader user would struggle with. Scenario and branching blocks present a decision and a consequence in plain, readable text alongside any imagery, so the interaction never depends on visually parsing an image alone. Hotspot image blocks (tap parts of a photo to identify something) are the block type that needs the most deliberate accessibility work, since “tap a point on an image” is inherently visual — we build a text-equivalent list of the identifiable points as a keyboard-operable alternative alongside the visual hotspot interaction, so the same content and assessment is reachable either way.
Reduced motion
Every animated element on the site and in the module player — scroll-reveal animations, progress-ring fills, step-tracker animations — respects the prefers-reduced-motion setting in your operating system or browser. If you have that preference set, animations are disabled outright rather than just slowed down, and no content is ever hidden or gated behind an animation completing.
Testing approach
We test new interactive block types with keyboard-only navigation as a standard part of building them, and check colour contrast against WCAG 2.1 AA thresholds for any new UI element before it ships, not as a retrospective audit. This isn’t a substitute for testing with real assistive technology and real users with access needs, which is exactly why the feedback channel below matters as much as our own internal testing.
Why this is a genuine hiring criterion for future roles
When we do formalise roles, comfort working within the accessibility, security, and audit-trail constraints this platform requires will be a real, stated part of what we’re hiring for — not a footnote. A talented engineer who’s used to moving fast and loose with data integrity, or a content writer who treats accuracy as optional, isn’t a good fit here regardless of raw skill, because the entire premise of this platform is that a builder’s real licence renewal depends on us getting these things right consistently.
Feedback shapes this page
This page will be updated as our accessibility practice matures and as specific issues are raised and fixed — it’s meant to reflect our actual current state honestly, not a static aspirational statement that never changes.