Inspiration
Public-service pages — tax credits, admissions, immigration — are dense, jargon-heavy walls of text that exclude readers with dyslexia, ADHD, low vision, or limited literacy. Reader modes only strip styling; they never simplify language, extract deadlines, or adapt to how a person reads. The gap between what accessibility checkers flag and what a struggling reader experiences — fatigue, missed benefits, dependence on others — inspired this invention: semantic restructuring instead of cosmetic stripping, with the source always visible for verification.
What it does
Paste any URL — or raw text for blocked sites — and ReadEasy returns a split-screen result: the cleaned original left, an accessible rewrite right. Modes render one structured result for different readers: Focus cards, Dyslexia/Bionic view, an Action checklist with tasks, urgency, and deadlines, Listen with karaoke highlighting, and ADHD micro-cards with one idea per screen. Ask this page answers questions grounded strictly in that page's text; the Reading level toggle switches Standard and Simpler. Cosmetic controls, local history, and print-friendly export complete the prototype — every output verifiable against its source.
How I built it
One server route owns the methodology: POST /api/transform takes a URL or raw text and returns the cleaned original plus the restructured result. Fetch pulls HTML server-side with no AI; Clean applies Mozilla Readability plus jsdom; Restructure calls OpenRouter to reshape text into strict JSON (title, summary, reading time, action items, sections) with one retry and fallback models; Render maps that JSON through a client-side mode registry — one registry line plus one file per Mode. POST /api/ask answers grounded questions, pre-cached for the demo trio. Stack: Next.js 15, React 19, TypeScript, stateless on Vercel, no database, no auth; Node.js 22.x replicates it.
Challenges I ran into
Reproducibility first: the README documents setup, env vars, and a stub fallback so every Mode works without an API key. Hostile inputs second — ssa.gov returns 403 to server fetching — solved with a raw-text path through the same pipeline. Third, no hallucination: schema, single retry, structured errors, and the permanent side-by-side source view guarantee the AI reshapes only on-page text.
What I learned
End-to-end flow beats model cleverness: deterministic cleaning before the LLM call made outputs stable and cheap. Designing for verification rather than trust changed how testers reacted to AI text. And one JSON contract with many renderers turns personalization from a rewrite into a one-file addition.
What's next
Roadmap: a browser extension for one-button Transform on any open page, more Modes driven by reader feedback, and benchmarked readability gains across public-service pages to quantify impact.
Try it: Live demo · Source: GitHub — hackathon/gibc-open
Built With
- mozilla-readability-+-jsdom
- next.js-15
- openrouter
- react-19
- typescript
Log in or sign up for Devpost to join the conversation.