One in five students has a disability, and many more use assistive technology some of the time: captions in a noisy library, zoom on a phone, a keyboard because their trackpad broke. Accessible software isn’t a favour to a few students. It’s better software for all of them.
Why WCAG 2.2 matters
The Web Content Accessibility Guidelines (WCAG) are the standard most accessibility rules point to. Version 2.2 adds requirements that matter a lot in education, such as larger touch targets, not hiding help between pages, and logins that don’t rely on memory puzzles.
Five places to start
- Keyboard access. Every link, button and form field must work without a mouse, with a visible focus outline.
- Forms and errors. Each field needs a real label, and errors should say what went wrong and how to fix it.
- Colour contrast. Text should have a contrast ratio of at least 4.5 to 1 against its background.
- Headings and structure. One main heading per page and a logical order, so screen reader users can jump around.
- Documents. Timetables and handbooks as accessible web pages or tagged PDFs, not scanned images.
Test with real people. An automated checker finds about a third of the problems; students find the rest.
Make it part of how you build
Accessibility is cheapest when it’s built in. Add it to your design reviews, include it in your definition of done, and test each release with a keyboard and a screen reader. Publish an accessibility statement that’s honest about what still needs work and how students can get help.
Where we can help
We audit portals and forms against WCAG 2.2 and fix what we find. If you’d like a review of your student-facing services, get in touch.
Was this article helpful?
Be the first to let us know.
Comments0
No comments yet. Be the first to share your thoughts.