ReadEasy

Inspiration

Government pages are the pages people need most — benefits, health coverage, school deadlines — and the hardest to read: dense paragraphs, bureaucratic wording, deadlines buried three screens down. Browser reader modes strip ads but keep the same wording and structure. Readers with dyslexia, ADHD, or low vision pay the highest price for that wall of text. ReadEasy started there: the web fails readers, so reshape the page itself.

What it does

ReadEasy is a web app: paste any URL — or raw text when a site blocks fetching — hit Transform, and get a split-screen result. The cleaned original sits on the left; an accessible, plain-language version sits on the right. Modes adapt the page to how you read: Focus cards, Dyslexia/Bionic view, an Action checklist extracting deadlines and steps, Listen with karaoke word-highlighting, and ADHD micro-cards with one idea per screen. Ask this page answers questions grounded only in that page's text; a Reading level toggle switches Standard and Simpler variants. Cosmetic controls, history, and print-friendly export round it out. Bureaucratic pages become checklists: what must I do, and by when.

How I built it

One pipeline: Fetch → Clean → Restructure → Render. POST /api/transform fetches the URL server-side, Mozilla Readability plus jsdom strips ads, nav, and scripts with no AI, then OpenRouter restructures cleaned text into strict JSON (title, summary, reading time, action items, sections) with one automatic retry. Every Mode is a client-side renderer of that JSON through a mode registry — one registry line plus one file per Mode. Stack: Next.js 15, React 19, TypeScript on Vercel — stateless, no database, no auth. Without an API key a canned stub keeps the UI fully usable.

Challenges I ran into

First, hostile inputs: some government sites refuse server fetching — ssa.gov returns 403 — so a raw-text paste path runs the same pipeline with no fetch. Second, no hallucination: the AI only reshapes on-page text, enforced by the strict schema plus the side-by-side view where any reader verifies nothing was dropped or added. Third, demo reliability: cached fixtures for the demo trio (IRS EITC, UT Dallas Apply, USCIS Students) remove network dependence from the core path.

What I learned

Accessibility is a restructuring problem, not a styling problem — wording and structure are the barrier reader mode never touches. I learned to treat the LLM as unreliable: strict schemas, one retry, structured errors, fallback models, never a crash. And verifiability is a feature: the visible original turned skeptical testers into trusting users.

What's next

Next: a browser extension adding one-button Transform to any page, plus history and sharing with caregivers and teachers. New Modes stay cheap via the registry; reader requests decide what comes first.

Try it: Live demo · Source: GitHub — hackathon/ai-builders

Built With: Next.js 15, React 19, TypeScript, Mozilla Readability + jsdom, OpenRouter, Vercel, browser speechSynthesis

Provenance

Built on the ReadEasy base developed for Buildverse Sep 1–6, 2026; extended in this hackathon with health-literacy reframing, UX polish, the 10-slide deck, demo video, and disclosure doc.

Built With

• ai
• llm
• mozilla-readability-+-jsdom
• next.js-15
• openrouter
• react-19
• typescript
• vercel
• voice