Disability Services and Accommodations Software: What Happens When 300 Exams Need Extended Time in the Same Week?

Why accommodations break in the week they matter most

It is the Monday of finals week at a public university. The testing centre has 22 seats, four of them in reduced distraction rooms, and three proctors on shift. The queue holds 61 exams for that day. Nineteen students have double time, which means a three hour exam occupies a seat for six. Four need a reader or a scribe, which consumes a proctor entirely. Two exams start at 8am in a course whose instructor has still not uploaded the paper. A student with a 1pm booking arrives to find her seat given away because someone rescheduled her without telling her, and she is now going to miss the exam that decides whether she graduates.

Nobody in that room is careless. They are running a capacity constrained scheduling problem in a spreadsheet, and the spreadsheet does not know that a double time student occupies twice the seat hours, or that a reader assignment removes a proctor from the floor, or that the reduced distraction rooms are the actual bottleneck rather than total seats.

The stack is typically Symplicity Accommodate, Accessible Information Management or ClockWork for the case record, the SIS for enrolment, email for faculty notification letters, a shared calendar for the testing centre, a separate spreadsheet for interpreter assignments, and a folder of documentation PDFs. Those products are real and they do the case management part. Where institutions with high volume testing centres and multi campus interpreting pools consistently run out of road is scheduling, and scheduling is the part that produces the complaints.

The stakes are not administrative. A failure here is an ADA or Section 504 matter that can reach the Office for Civil Rights, and the institution's defence is its documentation. In the disability services projects we have delivered, the recurring theme is that the office is doing careful, thoughtful work and cannot prove it, because the record of what was requested, what was decided, why, and what actually happened is spread across email, a case file and a whiteboard.

Problem 1: the testing centre is a resource problem, not a calendar

Booking software treats a room as a slot. A testing centre is a set of typed resources consumed for durations that depend on the student's accommodation. A standard seat, a reduced distraction room, a private room, a computer with screen reading software installed and licensed, a proctor, a reader, a scribe. Extended time multiplies duration. Some students cannot be scheduled adjacent to others. Instructors set windows that do not match the centre's opening hours.

Accommodate and ClockWork both handle exam booking, and they do it adequately at moderate volume. What they do not do is optimise against a genuinely constrained finals week, where the honest question is not can this student book a slot but what is the feasible arrangement of 300 exams across 22 seats and three proctors given every student's entitlements.

What a custom build does: model resources and consumption explicitly, then solve. A constraint model over seats, rooms, proctors and time windows, with student entitlements as hard constraints and preferences as soft ones, will schedule a finals week in seconds and tell you precisely which day is infeasible and by how much. That last output is what your dean needs, because the answer to an over subscribed finals week is either more seats, longer hours or an earlier instructor deadline, and you cannot argue for any of them without a number. When a booking cannot be honoured, the system says so at booking time rather than on the morning, which is the difference between an inconvenience and a complaint.

Problem 2: faculty notification has to follow live enrolment, every term, without fail

Every term, every instructor of every section a student with accommodations is enrolled in needs the notification letter. Students add and drop for three weeks. Sections change instructors. A student may not want a specific accommodation applied in a specific course, which is their right. Cross listed sections have two instructors and one of them is not in the obvious field in the SIS.

The common failure is not a system failure, it is that the notification went out in week one and the student added a course in week three, so one instructor never received it. When that student is then denied extended time on a quiz, the institution has a real problem and no defence, because the record shows a letter that was sent to the wrong list.

What a custom build does: run notification continuously against live enrolment rather than as a start of term batch. Any new enrolment for a student with active accommodations generates a notification to the instructor of record within a day, with per course elections respected. The instructor acknowledges, and the acknowledgement is recorded, so the question of whether an instructor knew has an answer with a timestamp. Instructors get one consolidated view of their sections rather than eight separate letters, which is a small courtesy that materially improves compliance because a wall of email is how notifications get missed.

Problem 3: alternate format production has lead times nobody is tracking

A student needs an accessible version of a textbook. Your office requests the publisher file, converts it, remediates it, and delivers it. That process takes real time and depends on the publisher responding. Braille and tactile graphics take longer still and require an outside vendor for anything complex. If the request arrives two weeks before term, the student starts the course without materials, which is the failure that ends up in a complaint.

The commercial tools track a request. What they do not do is manage a production queue with capacity, lead times, dependencies and escalation, which is what the operation actually is.

What a custom build does: model each conversion as a job with stages, a due date derived from the course start rather than from the request date, and an owner per stage. Publisher file requests are tracked with their own follow up clock, because the most common delay is waiting on a file. The queue shows which jobs will miss the course start given current capacity, in time to outsource or reprioritise. Where AI does one specific and honest job in this domain: automating the first pass of PDF remediation, meaning reading order, heading structure and image detection, produces a draft a specialist then corrects. It does not produce a compliant document on its own, and any vendor claiming otherwise is describing something you should test with your own worst scanned chapter before believing.

Problem 4: interpreters and captioners are a scheduling market with real money in it

American Sign Language interpreting for a full course load means multiple interpreters, team assignments for long classes, skill matching for technical content, travel time between campuses, and a cancellation policy where a late cancellation still costs you the booking. CART captioning has its own providers and its own lead times. This is one of the largest line items in a disability services budget and it is frequently managed in a spreadsheet by one coordinator.

What a custom build does: treat interpreters as a resource pool with qualifications, availability, cost rate and travel constraints, then assign against class schedules pulled from the SIS. Team requirements for long sessions are a rule, not a memory. Cancellations follow the policy automatically and the cost consequence is visible, which changes behaviour. Agency bookings are requested through the system with the same record, so your annual spend is a report rather than an accounts payable archaeology exercise. In our experience this module frequently reveals that a meaningful share of interpreting cost is late cancellations that were never charged back or never avoided, and that finding funds the project.

Problem 5: the interactive process is your defence and it lives in email

The Americans with Disabilities Act Amendments Act shifted the emphasis away from proving a disability and toward providing reasonable accommodation, which means your documentation review is less about gatekeeping and more about a documented, individualised interactive process. Every request, every determination, every denial with reasons, every alternative offered, and every appeal is part of the record you will rely on if a complaint reaches the Office for Civil Rights.

What a custom build does: make the interactive process a structured record. A request, the documentation considered, the conversation with the student, the determination with a written rationale, the alternatives discussed where a request was not granted, and the appeal path with its outcome. Denials in particular need a reason from a defined set plus a narrative, because a denial with no recorded rationale is the single worst artefact to bring to an investigation. Faculty pushback belongs in the record too: when an instructor objects that an accommodation fundamentally alters the course, that objection, the review, and the outcome should be documented as a case, since it is exactly the sequence an investigator asks about.

One more requirement that belongs in the build and not in an afterthought. The system itself has to be accessible, at WCAG 2.1 level AA, on every screen a student or faculty member touches. The Department of Justice rule on web and mobile accessibility for state and local government entities makes this explicit for public institutions, with compliance dates keyed to entity size. It is also simply indefensible to run a disability services office on a tool your own students cannot use. Budget accessibility testing with actual assistive technology users into the project, not as a final audit.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release, meaning intake and determination records with a structured interactive process, continuous per term faculty notification against live enrolment with acknowledgement, and capacity aware exam scheduling with a constraint solver, runs $55,000 to $120,000 and ships in 12 to 16 weeks. Accessibility conformance work is inside that number, not on top of it. A full platform adding alternate format production queues with publisher request tracking, interpreter and captioning assignment with cost tracking, note taker management, assistive technology loans, multi campus operations and reporting for your Office for Civil Rights obligations runs $140,000 to $320,000 phased over 6 to 12 months.

What drives price up specifically in this category: testing centre complexity, since multiple centres with different room types and shared proctor pools is a materially harder scheduling problem. The size of your interpreting operation. Multi campus travel constraints. Integration depth with the SIS, because live enrolment is the requirement and a nightly feed is the minimum acceptable cadence. And accessibility conformance itself, which is real engineering time on every screen and should be priced honestly rather than promised cheaply.

What keeps price down: starting with the testing centre and faculty notification only. Those two produce most of the complaint risk and most of the daily pain, and they teach the scheduling model that everything else reuses.

Build versus buy, and when buying is the right call

Buy if you are under roughly 2,500 students with a testing room rather than a testing centre, a modest interpreting need, and a caseload one coordinator can hold. ClockWork is well established in this space, Accessible Information Management is used widely and seriously, and Symplicity Accommodate integrates with a broader student services suite that many institutions already own. Building at that scale is not a good use of money.

Build when two or more of these are true. Your testing centre exceeds roughly 3,000 proctored exams a year and finals week is scheduled by hand. You run multiple campuses with a shared interpreting or proctor pool. Your alternate format production regularly misses course start dates. You have received an Office for Civil Rights complaint or entered a resolution agreement and your evidence was assembled by hand. Or your current tool is not itself accessible to the students using it, which is a position no institution should be comfortable defending.

Our position: the case management half of this category is well served by products and you should not rebuild it lightly. The scheduling half is where institutions with real volume are being failed, and scheduling is a solvable problem that nobody in this market has solved properly for the constraints a large testing centre actually has.

How to choose a developer for disability services software

Ask them how they would schedule a finals week with 300 exams, 22 seats, four reduced distraction rooms and three proctors. If they describe a booking calendar, they will build you a prettier version of your current problem. The answer you want involves modelling typed resources, entitlement driven durations, and an optimiser that reports infeasibility rather than silently overbooking.

Ask what accessibility conformance level they will commit to and how they will test it. A developer who has not planned for screen reader testing with real assistive technology users, and who cannot name the standard, should not be building software for this office.

Ask how faculty notification stays correct when a student adds a course in week three. If the answer is a start of term batch, they have designed the exact failure that produces complaints.

Ask who owns the code and the case records, in writing, before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. These records are disability related and sensitive, and they are also your legal defence, so they should never live somewhere your institution cannot reach or control.