Accessible learner support software: designed for everyone

Learner support software for inclusion that is not accessible would be a contradiction. Many of the people using Inclusion Studio will be disabled staff and learners, or people with temporary needs. This page explains how accessibility is built in, what the prototype offers and what has not yet been tested.

How accessible is this learner support software, and what is the target?

The target is WCAG 2.2 at level AA, the current W3C recommendation, published in October 2023. WCAG sets testable criteria for contrast, keyboard use, focus, target size, error handling and more. Meeting it also needs good content: plain language, clear instructions and sensible structure. Our guide to WCAG 2.2 for education software explains what it means for providers.

Public sector bodies, including many colleges, have their own duties under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. Buyers will want evidence. We do not claim conformance yet.

What accessibility features are planned, step by step?

1. Design and build to the criteria. Colour contrast, text size, focus states and target sizes are set as design tokens and checked.
2. Keyboard first. Every action works without a mouse. Dialogs trap and return focus correctly. Skip links jump to the main content.
3. Status is never colour alone. Statuses such as “Review ready” or “Awaiting tutor” are shown in words as well as colour.
4. User settings. Larger text and reduced motion are available to each user.
5. Plain language. Labels, instructions and errors use short, clear words.
6. Automated checks. Run in the build to catch common failures.
7. Manual testing. Keyboard, screen reader, zoom and voice-control checks for critical journeys.
8. Independent review. An external accessibility audit before real learner data is used.

Automated checks alone are not sufficient. They find some problems and miss many.

What do we mean by accessible content?

Software can be technically accessible and still hard to use if the words are unclear. The plan and review screens use short labels, plain sentences and a consistent layout, so that a learner can read their own plan without help. Where a provider sends learners a document from the product, the export should itself be accessible, with real headings and readable tables. Our accessible materials checklist is a free way to check your own documents.

Who benefits?

• Learners who use screen readers, magnification, voice control, switch access or dyslexia-friendly settings.
• Staff with disabilities, who should not meet barriers using the tool.
• Everyone on a phone, in a bright workshop, or tired at the end of the day.

What is in the prototype today?

In the prototype:

• Larger text: a setting that increases workspace text size.
• Reduce motion: keeps transitions still and immediate.
• A “Skip to workspace” link.
• Keyboard shortcut Command or Control and K to focus search, and Escape to close menus.
• Dialogs for plan, review and settings that can be closed from the keyboard.
• Status wording alongside colour.
• Body text at 16 pixels and above for priority content.
• A phone layout with a collapsible menu. The closed menu is removed from keyboard focus.
• Form errors shown as alerts that clear once resolved.

What has been checked: the main interactions were exercised in a browser at desktop and phone sizes, and the browser console showed no application errors. See the accessibility statement.

What has not been done: full assistive-technology testing with screen readers, voice control and switch access; real device testing; an independent audit. No conformance level is claimed.

What is being built for the pilot?

• Accessibility checks in the build process.
• Manual keyboard and screen reader testing of the critical journeys: request, plan, delivery, review and export.
• Learner-facing views designed with accessibility from the start.
• A published accessibility statement listing known issues.
• A route to report an accessibility problem and get a response.

Who sees what?

Accessibility settings belong to each user. They are personal preferences and do not change what a user is permitted to see. See permissions and roles.

Who is this for?

Learners and staff who need the tool to work for them. IT and systems staff and quality leads who need to evidence accessibility when buying. See learners and IT and systems.

What does this look like in practice? (fictional example)

A fictional tutor who uses a screen magnifier opens the settings dialog and turns on larger text. The workspace text increases, and the layout reflows without hiding controls. A learner who is sensitive to movement turns on reduced motion, and transitions become immediate. A staff member who relies on the keyboard uses the skip link to reach the main content, opens a review with the keyboard and closes it with Escape. In every case the status of a learner is readable as words, not only as a colour. These are the behaviours checked in the prototype, and they are the starting point for the manual testing still to come.

Related guides and next steps

• WCAG 2.2 for education software
• Accessible teaching materials
• Accessibility statement and the pilot.