ReadWave

ReadWave is a Chrome extension that generates a short, on-device summary for any page with Chrome’s built-in AI, inserts it at the top (ARIA live region), helping screen-reader users decide faster.

Comment

About ReadWave

Inspiration

Finding out whether a page is relevant is exhausting with a screen reader—you plow through navigation, ads, and pop-ups before hitting the first paragraph. I wanted a privacy-preserving way to surface a short, trustworthy summary immediately so blind and low-vision readers can triage pages quickly and move on if the article isn’t relevant.

What it does

ReadWave scans the current page for the dominant article text, generates a 2–4 sentence on-device summary using Chrome’s built-in AI, and injects it at the very top of the document inside an accessible region. Audio cues, an ARIA live region, and a keyboard shortcut make the experience fast and screen-reader friendly.

How I built it

  • Architecture: Manifest V3 extension (service worker + content script + options page).
  • Content extraction: Heuristics favor <article> / <main> and long visible paragraphs, skipping aria-hidden, off-screen, and boilerplate sections.
  • AI pipeline: Prefer the Summarizer API when available; fall back to the Prompt API or language model surface—normalizing outputs so the UI stays consistent.
  • Accessible injection: A summary card is inserted before <main> (or top of <body> as a fallback) within
  <section id="readwave-summary" role="region" aria-label="Page summary" aria-live="polite"></section>

It preserves focus, avoids layout shifts, and uses a shadow root to prevent CSS collisions.

  • UX: Toolbar button, context-menu item, and Ctrl+Shift+S / ⌘⇧S shortcut. Per-site settings are stored in chrome.storage.local. A small cache avoids re-summarizing unchanged pages.
  • Resilience: MutationObserver re-validates the insertion on SPAs that reflow content.

Challenges I ran into

  • Capability variance: API availability differs by Chrome version/flags, so I implemented capability detection and graceful degradation across Summarizer / Prompt / language model surfaces.
  • Reliable extraction: Complex news layouts buried articles; I iterated on landmarks + visibility checks to avoid nav bars, comments, and paywall stubs.
  • Accessible presentation: Injecting a summary without hijacking focus or clashing with site styles required careful ARIA, contrast, and theming decisions.

Accomplishments I'm proud of

  • A working prototype that screen-reader users can trigger with a single shortcut and get immediate audio/voice feedback.
  • A fully on-device pipeline—no page content leaves the browser.
  • A summary card that feels native on modern sites while remaining robust and compliant with accessibility semantics.

What I learned

  • How Chrome’s built-in AI surfaces differ and why capability detection is essential.
  • Practical techniques to extract readable text without heavy libraries while respecting ARIA landmarks and reading order.
  • The power of small affordances (tones, polite live regions, scroll margins) to make assistive experiences delightful, not just functional.

What’s next for ReadWave

  • Image-aware summaries: incorporate captions/alt text and, when permitted, image context.
  • Smarter caching: revalidate with ETag/last-modified and SPA-aware diff detection.
  • Customization: per-site auto-summarize rules, TL;DR length presets, and optional translate-then-summarize flow using Chrome’s Translator API.
  • Shareability: copy/share summary and minimal provenance (“sections used”) for trust.

Built With

  • chrome-built-in-ai-(summarizer-api
  • chrome-extensions-(manifest-v3)
  • css
  • eslint
  • html
  • javascript
  • prompt-api)
  • typescript
  • vite
  • web-accessibility-(wai-aria)
Share this project:

Updates