The accessibility problem with traditional proctoring
Traditional proctoring tools create two distinct accessibility failures:
1. They impose sensory requirements that many disabled students cannot meet
Screen recording, webcam monitoring, and audio analysis require students to be in a controlled physical environment — a requirement that disadvantages students with visual impairments, motor disabilities, chronic health conditions, and students in non-standard living situations (caregivers, small children, noisy environments).
2. They collect sensitive disability data to compensate
When students request accommodations, traditional tools often require disclosure of their disability to the proctoring vendor — creating a data collection obligation that is both privacy-invasive and, in many jurisdictions, legally precarious.
ProctorSafe's architecture sidesteps the first problem entirely. This article explains how, and maps out what your institution still needs to do to be fully WCAG 2.1 AA compliant.
What ProctorSafe doesn't require — and why that matters for accessibility
No mandatory webcam stream
Traditional proctoring tools require a live webcam feed throughout the exam. ProctorSafe's on-device model doesn't transmit video — it processes presence and face signals locally. For students who cannot meet the physical requirements of a stable webcam setup (motor disability, fatigue conditions, visual impairment), this removes a structural barrier that no accommodation request can fully mitigate.
No audio recording
ProctorSafe's optional audio monitoring measures ambient level only — not content. Students who use text-to-speech tools, screen readers, or who vocalise while thinking (common in neurodivergent learners) are not penalised by false audio anomalies.
No room scan
Room scans are legally vulnerable for all students (see: Room Scans: Legally Vulnerable and Institutionally Dangerous) — but they're particularly burdensome for students with mobility impairments, students in temporary housing, and students whose religious practices affect their environment. ProctorSafe does not require a room scan.
No browser lockdown (in standard mode)
Traditional lockdown browsers create compatibility problems with assistive technology. ProctorSafe's standard mode does not require a lockdown browser — it monitors the exam environment through the SDK, which is compatible with most screen readers and magnification tools.
WCAG 2.1 AA: what's relevant to proctoring
WCAG 2.1 (W3C recommendation, now incorporated into EN 301 549 under the EU Accessibility Act) has specific success criteria relevant to online assessment platforms.
| WCAG criterion | Relevance to proctoring | ProctorSafe status |
|---|---|---|
| 1.1.1 Non-text content — text alternatives for images | Proctoring tools often use visual prompts | ProctorSafe SDK has no visual prompts in the student flow |
| 1.3.1 Info and relationships — structure is programmatically determinable | Exam content must be readable by AT | This is your LMS and exam tool's responsibility |
| 1.4.3 Contrast (minimum) — 4.5:1 for normal text | Proctoring UI elements | ProctorSafe's student and instructor UIs meet 4.5:1 |
| 2.1.1 Keyboard — all functionality via keyboard | Proctoring consent flows, dashboard | ProctorSafe UIs are fully keyboard navigable |
| 2.4.3 Focus order — logical focus sequence | Dashboard and review tools | ProctorSafe meets this criterion |
| 2.4.7 Focus visible — clear focus indicator | Dashboard and review tools | ProctorSafe meets this criterion |
| 3.1.1 Language of page — correct lang attribute | Proctoring UI | ProctorSafe sets correct lang attributes |
| 4.1.2 Name, role, value — ARIA used correctly | Proctoring UI elements | ProctorSafe uses ARIA correctly |
What your institution still needs to address
ProctorSafe removes significant accessibility friction, but full WCAG compliance requires coordination across your entire assessment stack:
1. Exam content accessibility
The accessibility of your exam questions — screen reader compatibility, alt text for diagrams, captioning for video-based questions — is your responsibility. ProctorSafe does not touch the exam content itself.
Action: Run your exam content through a WCAG audit before it enters the LMS. Use tools like axe DevTools or engage an accessibility specialist.
2. Accommodations workflow
When a student has an approved accommodation (extra time, alternative format, breaks), this must be configured in your LMS before the ProctorSafe session launches. ProctorSafe reads the accommodation settings from the LMS via LTI launch parameters.
Action: Verify that your LMS's accommodation settings are correctly passed to ProctorSafe. Test this in your staging environment with a dummy student who has a documented accommodation.
3. Assistive technology compatibility testing
ProctorSafe's SDK is compatible with most screen readers and magnification tools, but your exam content may not be. Before deploying, test with:
- JAWS + Chrome
- NVDA + Firefox
- VoiceOver + Safari
- ZoomText
If your exam content fails AT compatibility, ProctorSafe cannot compensate for that — the issue is in the content delivery layer.
4. Students with temporary injuries or situational limitations
Students with temporary injuries (broken arm, post-surgery fatigue), students in noisy shared housing, or students with young children in the home are not covered by disability law but face genuine barriers in traditional proctoring environments.
Action: ProctorSafe's configurable thresholds allow you to apply a more flexible monitoring policy for students who request a temporary accommodation — without requiring disclosure of a disability or medical condition.
5. The EU Accessibility Act (EAA) — applies from June 2025
If your institution is in the EU or serves EU students, the European Accessibility Act (Directive 2019/882) came into force in June 2025. It requires that products and services used in educational assessment are accessible.
ProctorSafe's declaration of conformance is available on request. It covers:
- EN 301 549 conformance (web accessibility)
- WCAG 2.1 AA compliance for all user-facing interfaces
- SDK compatibility with AT in standard mode
A privacy-first approach to accommodation disclosure
One of the most sensitive issues in proctoring accessibility is disability disclosure. Traditional proctoring vendors often require students to disclose their disability to the vendor platform — a requirement that:
- May deter students from requesting accommodations
- Creates unnecessary sensitive data collection
- Is inconsistent with GDPR's data minimisation principle
ProctorSafe's recommended model is different:
- The student discloses their accommodation need to their institution — not to ProctorSafe
- The institution configures the accommodation in the LMS — ProctorSafe reads it from LTI launch
- ProctorSafe never learns the student's disability or condition — it only receives the accommodation parameters (extra time, breaks allowed, etc.)
This model keeps sensitive health data within the institution's existing GDPR-compliant systems and prevents unnecessary disclosure to a third-party vendor.
Checklist: accessibility readiness for your next exam cycle
- ProctorSafe UIs tested for WCAG 2.1 AA compliance (using axe or equivalent)
- Exam content audited for AT compatibility
- Accommodation settings tested in staging — confirmed passed correctly via LTI
- Students notified of the ProctorSafe privacy model and given the student guide
- Instructor dashboard reviewed for accessibility (especially for staff with disabilities)
- EU Accessibility Act EAA compliance reviewed for EU-serving institutions
- Accommodations workflow documented and communicated to faculty
Accessibility coordinators and assessment leads: for a full WCAG conformance report, accessibility testing documentation, or EAA compliance guidance specific to your institution, contact the ProctorSafe team at proctorsafe.eu.