Inspiration

UNFAIR MODE is a game you are supposed to lose—not because you lack ability, but because the interface is unfair.

I arrived in the United States from Korea only one week before this hackathon. While navigating unfamiliar systems, I noticed how many interfaces silently assume that everyone can read low-contrast text, accurately click tiny controls, understand complex instructions, and process information quickly under pressure.

But this is much bigger than being new to a country. Disabled people, older adults, people using an unfamiliar language, and people experiencing temporary impairments encounter these barriers every day. Hospital check-in kiosks are an especially important example: an inaccessible interface can become the front door blocking someone from healthcare.

Accessibility problems are often discussed through guidelines and audit reports. We wanted to make them immediately understandable through play.

What it does

UNFAIR MODE is a playable accessibility challenge built around a hospital check-in kiosk.

The player must complete a check-in flow while the interface applies three barriers:

  • Low contrast makes important information difficult to perceive.
  • Small targets make controls difficult to operate accurately.
  • Cognitive load turns simple instructions into unnecessarily complex language.

The game measures the player's completion time and errors. DigitalOcean AI then analyzes structured information about the interface, identifies accessibility barriers, and recommends prioritized repairs.

The player applies the repairs and starts a second round with:

  • Stronger contrast
  • Larger interaction targets
  • Plain-language instructions
  • Clearer progress and feedback
  • Visible keyboard focus

The final screen compares both attempts.

If fixing the interface changes the score, the user was never the problem.

UNFAIR MODE does not claim to simulate disability or reproduce anyone's lived experience. It demonstrates specific failures in interface design and shows how changing the system—not blaming the user—can improve access.

How we built it

We built UNFAIR MODE as a lightweight web application using:

  • Semantic HTML
  • Responsive CSS
  • Vanilla JavaScript
  • A Python standard-library server
  • DigitalOcean AI integration through a server-side API adapter

The application contains four main systems:

  1. Barrier engine
    Applies controlled interface failures to a realistic hospital check-in flow.

  2. Game instrumentation
    Measures completion time and validation errors across the unfair and repaired rounds.

  3. DigitalOcean AI analysis
    Sends a structured description of the current screen and active barriers to a server-side endpoint. The AI returns constrained JSON containing issue severity, explanations, and recommended repairs.

  4. Controlled repair engine
    Maps approved recommendations to predefined accessible components. We intentionally do not execute arbitrary AI-generated code.

Keeping the DigitalOcean AI request behind the Python server protects credentials and separates the model integration from the browser. If the AI endpoint is unavailable, the prototype uses a saved analysis that is explicitly labeled Demo fallback rather than pretending it is a live response.

Challenges we ran into

Framing the experience responsibly

Our biggest challenge was ethical, not technical. An early concept risked sounding like a “disability simulator.” A short visual effect cannot reproduce another person's lived experience, and presenting it that way would trivialize the people the project is intended to support.

We changed the concept so that the player is not pretending to have a disability. Instead, the player confronts concrete interface barriers. The unfair design is the opponent.

Making AI essential instead of decorative

We did not want to add a chatbot merely to qualify as an AI project. DigitalOcean AI needed a clear responsibility in the product.

We connected it directly to the repair loop: it analyzes structured interface context, prioritizes barriers, and produces actionable recommendations that the application can validate and apply.

Balancing AI flexibility with demo reliability

Allowing a model to generate and execute arbitrary interface code would be unpredictable and unsafe. We instead constrained the model output to a JSON schema and mapped its recommendations to tested repairs.

This preserves the useful reasoning role of AI while keeping the live experience stable and inspectable.

Building under hackathon constraints

We needed the project to run with minimal setup and remain demonstrable even if connectivity or credentials failed. We used browser-native technologies and Python's standard library, avoiding a large dependency chain. We also created an honestly labeled fallback path for the analysis stage.

Accomplishments that we're proud of

  • Created a complete game loop: unfair round, AI diagnosis, repair, and rematch
  • Made the accessibility problem understandable through direct interaction
  • Connected DigitalOcean AI to a meaningful product decision
  • Built measurable before-and-after results using time and error counts
  • Avoided executing arbitrary model-generated code
  • Added a transparent fallback instead of misrepresenting cached output as live AI
  • Kept the project lightweight and easy to run
  • Reframed accessibility around fixing systems rather than blaming users

What we learned

We learned that accessibility is not a collection of isolated styling rules. Contrast, target size, language, focus, sequencing, and feedback interact as a system. Several seemingly small design decisions can combine into a serious barrier, especially in high-pressure environments such as healthcare.

We also learned that responsible AI requires boundaries. AI is useful for accelerating an initial accessibility analysis, but its recommendations should be structured, inspectable, and validated. It should support—not replace—disabled users, accessibility professionals, and real usability testing.

Most importantly, we learned that social-impact technology can still be engaging. A serious issue does not need to become a dry compliance dashboard. Play can make an invisible design problem visible, memorable, and discussable.

What's next for UNFAIR MODE

Next, we want to expand UNFAIR MODE beyond the hospital kiosk demo.

Teams could submit a screenshot or DOM snapshot from a real public-service interface. DigitalOcean AI could analyze the interface, produce a developer-ready issue report, and map recommendations to a controlled accessible design system.

Future versions could include:

  • More public-service scenarios, such as voting, transit, benefits, and emergency information
  • Additional measurable barriers involving keyboard navigation, screen-reader structure, timing, and error recovery
  • Developer exports for GitHub Issues and project-management tools
  • Expert-labeled evaluations of AI recommendations
  • Testing and co-design with disabled users
  • Long-term measurement of whether recommended repairs improve real task outcomes

The goal is not to create another automatic compliance score or claim that AI can certify accessibility.

The goal is to help teams experience the consequences of unfair design early enough to fix it.

Built With

Share this project:

Updates

Submission history