By Tanvi, Ranadeep, Nachiketh, Jeathraditya

Developed under the guidance of Professor Chanda Raj Kumar,
and we are thankful for his valuable support throughout this project.

Online exams aren't built for everyone.

Most digital examination platforms assume every student sees the screen clearly, types comfortably, and processes text without difficulty. The reality for students with visual impairments, dyslexia, or motor disabilities is entirely different, they are left to patch together other methods like browser plugins, screen readers bolted on , or human invigilators typing on their behalf.
The gap isn't just inconvenient. It's a systemic barrier to fair assessment.
AceExam is our attempt to close it. We aim to implement accessibility at the architecture level, training custom AI models for exam interaction, and using MongoDB as the data backbone for a platform that serves genuinely different kinds of users from a single codebase.

"Accessibility is not a feature. It is a starting point. AceExam treats accommodation types as first-class citizens, not optional add-ons."

How AceExam Is Structured

AceExam follows a clean three-tier hierarchy with clear permissions at each level:

Organisation (super admin) → Teacher / Admin → Student

The system has three roles Organisation, Teacher, and Student each with their own dashboard. A teacher creates an exam, adds questions with difficulty ratings, and assigns it to students. When adding a student, they specify the student's disability type. That single field disability_type is the key that unlocks everything.

When a student logs in and starts their exam, the system reads their disability_type from MongoDB, activates the right accessibility feature profile automatically, extends the exam timer, and transforms the UI — before the first question even loads. No manual setup. No settings menus.

The Tech Stack

Backend
Python (Flask) with MongoDB — scoped queries and mutations per role, with MongoDB as the primary data store for flexible document structures across exam types.

Frontend
HTML, CSS, Vanilla JavaScript (Server-side rendering via Jinja2 templates) with a consistent light theme and a compact five-button accessibility toolbar that persists across all exam pages.

AI / ML
Custom PyTorch models for speech-to-text and eye tracking, plus Python NLP libraries for text simplification and TTS via the Web Speech API.

Deployment
Built as a web-based platform — no installation required for students. Accessibility features run client-side using browser APIs where possible.

Why MongoDB?

Exam data is not flat. A single student attempt bundles together their profile, accommodation type, question set, per-question response, timestamps, and accessibility state and these fields vary significantly between accommodation types. A blind student's record carries voice command logs; a dyslexic student carries font and overlay settings.

Forcing that into a rigid relational schema means either sparse columns everywhere or a patchwork of JOIN tables that make every query more complex than it needs to be.
MongoDB's document model handles this naturally. Each student attempt is one document. Loading an attempt for grading or review is one read — no assembling rows from multiple tables, no N+1 queries. The flexible schema also means adding a new accommodation type or a new accessibility field doesn't require a migration that touches every existing record.
We use MongoDB as the primary data store across three collections:
users — organisation, teacher, and student accounts with roles and accommodation types
exams — question banks, assignment metadata, and per-exam settings created by teachers
attempts — one document per student attempt, with responses, scores, and accessibility state embedded
The once-only constraint on attempts is enforced at the data layer. Once a student submits, the attempt document is locked — subsequent submission calls check the document status before writing anything.

Accessibility by Accommodation Type

When a student logs in, AceExam reads their registered accommodation type and automatically enables the relevant feature set. No manual configuration. No settings menu to navigate.
🔵 Blind
Text-to-speech reads every question aloud. Voice commands handle navigation and answer selection.
🟣 Dyslexic
Dyslexia-friendly font, increased letter spacing, and pastel background overlays to reduce visual stress.
🟢 Motor Impairment
Full keyboard navigation with single-key shortcuts. Eye tracking allows gaze-based option selection without any physical input device.
⚪ Standard
The default interface, with the five-button accessibility toolbar available if needed.

The AI We Built: Custom Speech-to-Text

Rather than dropping in a general-purpose speech API, we trained a custom keyword classification model — exam_listener_v1.pt — specifically for exam interaction using PyTorch.
The model classifies audio input into exactly 11 command categories:
cancel · confirm · next · option_a · option_b · option_c · option_d · previous · read · silence · submit

Why a narrow vocabulary?

A general ASR model that understands free-form speech introduces significant surface area for misclassification during an exam. If a student says "I think it's option B" while thinking aloud, a general model might select option B unintentionally. Our model knows only the valid exam commands — and classifies only those.

Accuracy Comparison

Our model trades raw accuracy for domain specificity. The accuracy gap reflects limited training data and noise sensitivity — known drawbacks we're addressing through data augmentation and noise-robust training in the next iteration.

Eye Tracking for Motor Accessibility

For students with motor impairments, AceExam includes a webcam-based eye tracking module built in Python using OpenCV. It maps pupil position to on-screen MCQ options — sustained gaze on an option triggers selection with no mouse or keyboard required.

Accuracy Comparison

The current implementation is computationally intensive and struggles under variable lighting — an acknowledged limitation. It demonstrates the feasibility of gaze-based exam interaction; production-grade accuracy would require a calibrated backbone like MediaPipe. That replacement is already on the roadmap.

The Exam Attempt Flow

Every student attempt follows the same path:

Login
  → Accommodation type read from MongoDB
    → Accessibility features auto-enabled
      → Exam loads
        → Attempt (once only)
          → Submit confirmation dialog
            → Score written to MongoDB (attempt locked)

During the attempt, three accessibility channels run in parallel: the five-button toolbar, single-key keyboard shortcuts, and voice commands. Students can use whichever channel suits them without any mode-switching.

What MongoDB Enables in Practice

Flexible document structure across accommodation types. A blind student's attempt document carries different fields from a motor-impaired student's — MongoDB handles both without schema pressure.
Single-read exam loading. The full context needed to render an exam attempt — questions, student profile, accessibility settings, prior responses — lives in one document. One read to load the exam. No assembly required.
Atomic attempt locking. Once a student submits, a single $set on the attempt document marks it as locked. No race conditions, no partial writes, no separate status table to consult.
Scalable across teacher and student volumes. MongoDB's horizontal scaling means adding new schools, new exam sets, and new student cohorts doesn't require redesigning the data layer.

What's Next

AceExam is a research prototype — a proof of concept that accessible digital examination is achievable with a focused stack and well-scoped AI models. The next directions:
Automated question generation via NLP
Semantic answer grading (not just keyword match)
Text simplification for dyslexic users using transformer-based models
MediaPipe-backed eye tracking to replace the current custom implementation
Noise-robust STT training with data augmentation to close the accuracy gap

Key Takeaways

The decision to train domain-specific AI models rather than use off-the-shelf APIs was deliberate. A narrow vocabulary STT model makes fewer exam-context errors even at lower raw accuracy. A gaze-based selection system, even at 40% accuracy in prototype form, proves the interaction paradigm is viable and gives us a concrete upgrade path.
MongoDB's document model was the right call for a platform where user data shapes vary significantly by role and accommodation type. Flexible schema meant faster iteration, and the single-document-per-attempt design kept the data access patterns clean.
The goal was never to build a finished product. It was to demonstrate that the gap between standard exam platforms and genuinely accessible ones can be closed — and to show exactly where the hard problems still live.