Accessibility checklist for school management, ERP, and SIS

Define who must be able to complete the work

Accessibility starts with tasks and people, not a generic compliance statement. List the staff, families, students, administrators, finance users, and support teams who need to view information, complete actions, correct records, approve, publish, or request help.

For each role, describe the device, connection, language, assistive technology, time pressure, and fallback that may affect the workflow. Ask what a person must accomplish, not only which page they open.

Check content and interaction

Review headings, labels, instructions, focus order, keyboard operation, error messages, contrast, status changes, document formats, notifications, and time limits. Test forms with missing or invalid values and make the correction understandable.

Check that family-facing status, fees, attendance, assessments, documents, and messages are available in the required formats and languages. Do not promise universal accessibility or localization without testing the actual product and content.

• Can users identify the current record and task?
• Can they complete it without a mouse or visual cue?
• Are errors explained and recoverable?
• Can assistive technology perceive status and structure?
• Is support available in the user’s channel and language?

Test with representative users

Automated checks can find some issues, but people using the real workflow reveal problems in language, timing, cognitive load, device behavior, and recovery. Use controlled data and invite representative users to complete a normal case and an exception.

Record the task, barrier, impact, workaround, owner, evidence, and correction date. A workaround may help one user while excluding another; treat it as a temporary risk, not proof of accessibility.

Include suppliers and school responsibilities

Ask which accessibility behavior is native, configured, integrated, content-dependent, manual, roadmap, or unknown. GOV.UK procurement guidance recommends clear responsibilities, minimum necessary data, access control, security, subprocessors, incident handling, and data return or deletion.

The school owns content, workflow definitions, permissions, training, communication, and support even when a supplier owns the platform. Put those responsibilities in the implementation plan.

Review accessibility continuously

Review support questions, task completion, errors, device patterns, language requests, and user feedback at 30, 60, and 90 days. Re-test after a product update, form change, document change, or new family workflow.

Keep an accessibility issue register with owner, priority, evidence, temporary support, and review date. Accessibility is part of the quality of the workflow, not an optional final inspection.

Apply the guidance to one school decision

Before approving this guidance for accessibility checklist for school management software, translate it into one school-specific decision record. State the workflow, roles, data fields, permissions, evidence, support route, academic-calendar constraint, and condition that would hold the next phase.

Run the decision with controlled data and the people who will operate the workflow. Record what was observed, what remains unknown, who owns the unresolved item, and when it will be reviewed. Revisit the record after launch at 30, 60, and 90 days. Keep the record beside the acceptance tests, support guidance, and change log so later reviewers can see why the school proceeded, narrowed scope, or held the next phase.

If the evidence is incomplete, narrow the claim and the release. Explain what the school can verify today, what needs supplier or legal review, and what a reviewer should not infer from a demonstration or policy statement. This keeps the article useful without turning an unresolved question into a product promise.

Ask the accountable owner to confirm the next action in plain language and to identify the people who must be informed. A quality gate is complete only when the operators can perform the approved workflow, understand the exception route, and know how to report a problem without creating an uncontrolled copy of the record.

Keep the review proportionate to the risk. A small workflow may need a clear role test and data sample; a sensitive or cross-campus workflow may also need supplier documentation, incident handling, recovery, retention, and local legal review. Record the distinction so future readers understand why the gate is sufficient or still open.