Around 16% of pupils in England have identified Special Educational Needs or Disabilities. In a class of 28 students, that's roughly four or five children who may struggle with a digital learning platform that hasn't been designed with their needs in mind.
WCAG 2.1 AA is the legal accessibility standard that most UK public sector digital services must meet under the Public Sector Bodies Accessibility Regulations 2018. WCAG compliance is also the standard that most ed-tech platforms cite when asked about accessibility. The problem is that WCAG 2.1 AA was designed for general web content — not specifically for young children with learning difficulties doing maths practice. Meeting the standard is necessary but not sufficient.
Here's what we built beyond WCAG compliance, and why it matters for the specific population of SEND students in UK primaries.
Dyslexia: Font, Spacing, and Text Reduction
Around 10% of the UK population has dyslexia, with about 80% of those having a mild-to-moderate presentation. In primary schools, many students with dyslexia are not yet identified — the average age of dyslexia diagnosis in the UK is 11, meaning many KS1 and KS2 students with dyslexia are in classrooms without formal support in place.
The primary issues for dyslexic students using digital tools are: character confusion (b/d, p/q, 6/9, 3/8 are the most commonly transposed in primary-age students), visual crowding (text or numbers too close together creating tracking difficulty), and cognitive load from reading instructions alongside solving problems.
WCAG 2.1 AA requires a minimum text size and colour contrast ratio, which helps — but it doesn't specify anything about character spacing, line height, or the specific font choices that reduce confusion. We made three changes beyond WCAG minimum requirements:
We use a custom digit variant that distinguishes 1, 7, and 4 more clearly than standard sans-serif fonts (which render these as ambiguous in some typefaces). We increased letter-spacing to 0.12em and line-height to 1.8em throughout the student interface — above WCAG guidance, which requires only that these are not overridden by user stylesheets. We reduced on-screen text to the minimum necessary: question text uses the simplest phrasing that accurately represents the mathematical concept, and instructions are presented in single sentences rather than paragraphs.
The third change has benefits beyond dyslexia: shorter, simpler instructions reduce cognitive load for all learners, particularly those with English as an Additional Language. In our pilot schools, where 30–40% of students had EAL status, simplified question phrasing measurably reduced the rate of "comprehension errors" (where a student answered incorrectly not because they didn't know the maths but because they didn't understand the question).
Visual Impairment: Contrast, Size, and Screen Reader Support
Visual impairment in primary-age children includes a range of conditions: refractive errors (the most common, typically corrected by glasses), amblyopia ("lazy eye"), colour vision deficiency, and less common but more significant conditions including nystagmus and low vision. Schools using the platform will have students across this range.
Our base interface meets WCAG 2.1 AA contrast requirements (4.5:1 for normal text, 3:1 for large text). We added a high-contrast mode activated by a single button in the student interface — this switches to a 7:1 contrast ratio throughout, with black text on a cream background (which reduces the halation effect that pure white backgrounds produce for some students with visual stress) and increases all text sizes by 30%.
For screen reader support: all question elements use ARIA labels, and mathematical notation is rendered as both visual symbols and as accessible text alternatives. The question "7 × 8 = ?" is marked up as "seven multiplied by eight equals what?" for screen readers — which is what a screen reader user actually needs, not "7 times 8 equals question mark" (which is what an unmodified rendering would produce).
Keyboard navigation is fully supported throughout the student interface. Tab order follows the logical sequence of a question, and all interactive elements — including the numeric answer grid — are reachable and activatable by keyboard. This benefits both screen reader users and students who find touchscreen or mouse interaction difficult.
ADHD and Attention: Visual Noise and Distraction
ADHD affects approximately 5% of school-age children. For students with ADHD, digital interfaces with animations, non-relevant visual elements, and notification-style feedback can significantly disrupt sustained attention on the task at hand.
Our standard interface uses subtle animations for correct/incorrect feedback — a brief colour change and icon. We added a Reduced Motion setting (accessible from the student profile, or toggled by a teacher for a class) that eliminates all animations and transitions. The Reduced Motion setting is distinct from the OS-level "prefers-reduced-motion" media query: we respond to the media query automatically, but the explicit toggle is available for cases where a student uses a shared device or a device where the OS setting hasn't been configured.
We also reduced the quantity of decorative elements in the interface on the advice of an occupational therapist we consulted during the design process. The student interface has no background patterns, no decorative icons adjacent to question text, and no moving elements in the question viewport. The interface is intentionally sparse. Several teachers commented that this "looks boring" during initial demos. We consider that a feature: a maths practice interface that visually competes with the question is an accessibility failure even for students without ADHD.
SEMH: Separating Self-Worth From Performance Signals
Social, Emotional, and Mental Health needs cover a broad range of presentations. One specific concern for digital learning tools is the use of performance feedback in ways that activate shame or anxiety — which is directly counterproductive to learning.
The most common implementation failure is the use of negative feedback (cross marks, red indicators, "wrong!" messages) that presents incorrect answers as failures rather than as information. For students with SEMH needs — and for many students without formal SEMH diagnoses who nonetheless have maths anxiety — this kind of feedback increases avoidance behaviour and reduces willingness to attempt difficult questions.
Our feedback system treats incorrect answers as data, not failure. An incorrect answer shows a neutral indicator (a small flag icon) and immediately presents the correct answer with a brief visual cue linking back to the relevant number fact. There is no "X" mark, no red colour, no "wrong" text. The question loops back later in the session — but the second presentation is after several other questions, not immediately (which would feel punitive).
We also removed the concept of a "score" from the student view entirely. Students see their progress through a session (question 8 of 15) and a simple visual representation of which topics they're working on — but they don't see a percentage score or a ranking. Score visibility is reserved for the teacher dashboard, where it provides useful data without the social comparison dynamic it creates when students can see each other's results.
Testing With Actual SEND Students
The features described above were not developed by a design team hypothesising about SEND students. During the pilot, we worked with three specialist SEND support teams in the pilot schools to run structured user-testing sessions with students who have identified needs — including a student with Level 2 visual impairment, three students with confirmed dyslexia diagnoses, and four students with ADHD diagnoses.
The most significant insight from these sessions: SEND students are not a homogeneous group. What helps a student with dyslexia (increased spacing, simplified text) is different from what helps a student with ADHD (reduced animation, visual simplicity) which is different from what helps a student with visual impairment (high contrast, keyboard navigation). Designing for accessibility requires understanding specific populations, not applying a single set of adaptations and claiming inclusivity.
We didn't solve every accessibility challenge in the first release. There are students whose needs we haven't designed for adequately, and we know this because the SEND support teachers told us directly. The goal is continued iteration, not a claim that the current product serves all needs perfectly.
The Argument for Inclusive Design Beyond Compliance
Every accessibility feature described in this article benefits students beyond the population it was originally designed for. Simplified text helps EAL students. High contrast helps students using poor-quality displays or working in bright sunlight. Reduced animation helps students with slow hardware. Keyboard navigation helps students with physical motor difficulties that don't rise to a formal SEND diagnosis.
This is the practical case for inclusive design as a core design principle rather than a compliance exercise: the features that make a platform accessible to students with significant needs also make it better for students with minor differences that never appear on any SEND register. Given that UK primary schools now report that over 40% of students have at least one identifiable learning need (including those below the formal SEND threshold), the overlap between "accessibility features" and "good product design" is very large.
WCAG compliance is the floor. Designing for the actual range of learners who'll use your platform is the job.