Accessibility Hub
Research participation portal for Stichting Accessibility
A portal connecting people with disabilities to accessibility research. I built the database structure, research pages, API endpoints and authentication integration.
Goal
Build a web app for Stichting Accessibility to coordinate research participation between people with disabilities and organizations doing accessibility research.
The system combined participant registration and profiles, finding and applying to research, admin approval steps, and an API for organizations. The foundation kept control over approvals and over what participant information was shared.
Constraints
The brief required a Python backend, a SQL database, an HTML/CSS frontend, JavaScript and AJAX, and a REST API. The team had to design the database and supply demo data and an ERD.
Accessibility and protecting sensitive participant information were central. The assignment specified WCAG 2.2 AA conformance, restricted access to personal data and administrator approval at key stages of the research process.
The administrator dashboard also had to update dynamically when new requests arrived.
Process
The team changed after WP-2: one teammate returned and two were new. Before dividing the work I asked about everyone's programming experience instead of assuming. I took an informal coordinating role, but let teammates work independently.
Everyone had to contribute across database, backend, API and frontend. I built my own work through those layers in order, database and models first, then API endpoints and participant pages, so teammates could use it as an example once it existed, instead of me preparing examples for everything upfront.
I made the database generator and ERD, the research models and reusable database operations, the research API endpoints, and the research listing and application pages with AJAX. I also integrated authentication and registration, reworked shared templates and organized routes into blueprints.
Working this way gave me time to weigh structural decisions and improve on earlier implementations. But participation in the team stayed inconsistent, extra work piled up on me, and I missed deadlines.
Result
A team prototype with participant registration and profiles, research listing and application pages, authentication, some moderator pages and API endpoints.
My part connected the database design and backend to the participant-facing pages. The README lists what was left, including organization API documentation and a standup report. Not every required workflow was finished, and accessibility conformance wasn't verified.
What I learned
I learned to find out what teammates can do by talking to them instead of assuming. A changed team meant understanding not just what people knew, but how independently they worked and what support they needed.
I also tried a more sustainable way to provide technical foundations. Instead of rushing to prepare the whole project for everyone, I prioritized my own end-to-end contribution and made it available as an example as it developed. That left room to think through design decisions and keep challenging myself.
The harder lesson was about accountability. I believed that focusing on my own contribution would protect my assessment even if someone else's participation was inconsistent. In practice, leaving the problem alone let more work fall to me and hurt my deadlines.
Looking back, I would raise participation problems earlier, make ownership and delivery expectations explicit, and escalate unresolved issues instead of quietly absorbing the work. Changing the team wouldn't necessarily have reduced the workload, but ignoring the problem didn't contain it.