DEV Community: Naima Kader

How I Built Phantom: A Chrome Extension That Fixes Accessibility So Developers Don't Have To

Naima Kader — Sat, 08 Aug 2026 13:32:39 +0000

1.3 billion people worldwide live with some form of disability. When they visit a website, there is a 97% chance it will fail basic accessibility standards — broken form labels, missing image descriptions, unreadable color contrast, keyboard traps that make navigation impossible.

Every tool that exists to help — Lighthouse, axe DevTools, WAVE — does the same thing. It generates a report. It tells you what is broken. Then it leaves you alone.

A developer reads the report, tries to find the broken element somewhere in thousands of lines of HTML, researches what the WCAG rule actually means, attempts a fix, and re-runs the audit. This process takes hours. Most companies never get around to it.

I wanted to build something different. Not a report — a workspace.

That became Phantom.

What I Built

Phantom is a Chrome Extension that transforms how developers interact with accessibility issues. It finds every broken element. It draws a border around it on the real page. It shows you the broken HTML. It generates the corrected HTML. It exports a professional PDF report in one click.

GitHub: github.com/naimakader/phantom
Stack: React 18, TypeScript, Chrome Extension Manifest V3, axe-core, jsPDF, Vite

The Hardest Technical Problem: Scanning a Live Page From Inside a Popup

A Chrome Extension popup is an isolated HTML page. It cannot directly read or modify the tab the user is browsing. The only bridge is Chrome's scripting API.

The naive approach — injecting axe-core as a script tag — fails in Manifest V3 because of the new Content Security Policy restrictions. I discovered the solution after reading Chrome Extension source code and Manifest V3 migration guides: a two-step injection pattern.

Step 1: chrome.scripting.executeScript({ files: ['axe.min.js'] })
This injects axe-core as a web-accessible resource into the live page.

Step 2: chrome.scripting.executeScript({ func: runAxeScan })
Now that axe exists on the page, this runs axe.run() and returns the results.

This two-call pattern is not documented anywhere. It is the only reliable way to run a WebAssembly-powered accessibility engine inside a foreign page from an extension popup.

The Live Element Highlighter

This was the hardest feature to build. After scanning, every broken element on the page should glow red — without breaking the page, without affecting the site's own CSS, and without persisting after the user clears highlights.

Three problems had to be solved.

Z-index conflicts. Many sites use z-index: 9999 on overlays and modals. A naive outline injection would be hidden behind them. The solution was to use outline with outline-offset rather than border or box-shadow — outlines render outside the element's box model and are not affected by the stacking context of child elements.

Cleaning up. Every injected style was scoped to a unique id (phantom-styles) so a single element.remove() call cleans everything up. No leftover CSS, no data attributes.

Hover tooltips without a React tree. The tooltip had to work inside the live page, not inside the popup. This meant pure DOM manipulation — a CSS ::after pseudo-element reading from a data-phantom-label attribute set per element. No React, no event listeners, no memory leaks.

Extracting Live HTML for the Fix Engine

The fix engine needed the actual broken HTML from the page — not a generic example. axe-core returns a CSS selector for each violation. Using that selector to extract the outerHTML required another chrome.scripting.executeScript call with the selector passed as an argument.

The key constraint: chrome.scripting functions run in a completely isolated context. They cannot close over variables from the popup. Everything must be passed explicitly as args. This forced a clean separation between popup state and page-side execution that made the code more reliable overall.

Client-Side PDF Generation Without a Backend

The PDF report needed to look professional — dark cover page, score ring, severity badges, paginated violation list, page numbers. jsPDF provides a low-level drawing API similar to Canvas — every element is positioned with explicit coordinates.

The score ring required manual arc math:

circumference = 2π × radius
arc_length = circumference × (score / 100)
strokeDashoffset = circumference - arc_length

Page breaks required tracking the current Y position and triggering a new page when remaining space was insufficient for the next violation card.

Zero backend infrastructure. Zero user data leaving the machine. Instant downloads.

Why These Architecture Decisions

axe-core over Lighthouse: Lighthouse requires a full page reload and runs in a separate DevTools process. It cannot scan a page being actively browsed. axe-core runs as a JavaScript library directly inside the page's DOM — it sees exactly what the user sees, including dynamically rendered content and SPA state.

Manifest V3 over V2: Google deprecated Manifest V2 in 2024. V3's service worker model forced a cleaner architecture — instead of a persistent background page with direct DOM access, all page interaction is explicit and auditable through chrome.scripting.

chrome.storage over localStorage: chrome.storage.local is shared across all extension contexts — popup, background worker, content scripts. It persists across extension updates and browser restarts. localStorage is scoped to a single page origin and is destroyed when the popup closes.

What I Learned

The browser is a platform, not just a runtime. Building Phantom required understanding how Chrome manages isolated execution contexts, how the scripting API bridges them, and how CSS rendering works at the level of stacking contexts and box models. This is a different category of knowledge from building React applications.

Constraints produce better architecture. The Manifest V3 restriction on background page access forced every page interaction through a single, explicit API. The resulting code is easier to reason about than the V2 equivalent would have been.

The demo is the product. The most important engineering decision I made was choosing the live element highlighter as a feature. A popup showing a list of issues is forgettable. A tool that draws red borders on a real website while you watch — that is memorable. When I demo Phantom, people understand the problem and the solution in under 10 seconds.

Results

57 WCAG 2.2 rules checked per scan
Scans BBC.com in under 3 seconds
PDF report generates and downloads in under 1 second
13 unit tests — 100% passing
7 features shipped
Zero backend infrastructure

What's Next

Multi-page site audit — crawl an entire domain and aggregate scores across pages.
Score trend chart — visualize accessibility improvement over time using D3.
Real AI integration — replace smart mock fixes with actual AI-generated fixes using the Anthropic API.

Final Thought

Building Phantom taught me that the browser is one of the most underestimated platforms in software development. Most developers use it as a display layer. It is actually a full operating system with security boundaries, execution contexts, storage APIs, and scripting capabilities that most people never touch.

I touched all of it. And the result is a tool that makes the web slightly more accessible for 1.3 billion people.

That felt worth building.

Built by Naima Kader
Portfolio: https://portfolio-seven-beryl-29.vercel.app/
GitHub: github.com/naimakader/phantom

How I Built NeuroSpace: An AI Productivity Platform That Actually Thinks With You

Naima Kader — Sat, 08 Aug 2026 04:32:22 +0000

Most productivity apps are passive. They hold your tasks and wait. You still have to decide what to work on, estimate how long things take, and figure out why you keep missing deadlines. The cognitive overhead of managing a productivity system often exceeds the benefit.

I wanted to answer one question: what would a productivity tool look like if it actually thought alongside you?

That question became NeuroSpace.

What I Built

NeuroSpace is a full-stack AI productivity platform. The core loop is simple: plan your work with AI, execute it with a focus timer, review your patterns with data analysis, and get warned before you fall behind.

Live: neurospace-zr2n.vercel.app
Code: github.com/naimakader/Neurospace

The Stack and Why

I chose Next.js 15 App Router because server components reduce the client bundle and API routes keep server logic close to the UI that uses it.

TypeScript gave me shared types between API responses and UI state — the source of truth lives in one place instead of being duplicated.

For auth I used Clerk. Production-grade authentication without building session management from scratch. JWT templates let Clerk tokens authenticate Supabase requests directly.

For the database I chose Supabase with PostgreSQL. Row-level security scopes every query to the authenticated user automatically. A JSONB column stores session snapshots efficiently — more on why that matters below.

For AI I used OpenAI GPT-4o-mini. Best price-to-quality ratio for structured JSON generation and conversational responses.

The Hardest Engineering Decision: Session Snapshots

The naive approach to loading state: on every page load, fetch all tasks and reconstruct the board. The problem is that undo/redo history is lost, column order is lost, and archived tasks disappear.

My approach: after every mutation, save the complete state as { tasks, archived } to a task_history table using an upsert on user_id. One row per user, always current.

On load, I try the snapshot first. It is the complete, ordered, correct state. I fall back to the tasks table only if no snapshot exists.

This also makes undo/redo persistent across page refreshes. After undo, the restored state saves immediately as the new snapshot and re-inserts into the tasks table so the database matches memory.

Why useRef for Undo/Redo

Undo/redo stacks do not cause re-renders — they only matter at the moment of undo. Using useState would trigger unnecessary renders on every single mutation registration.

I used useRef for both the past and future stacks, and structuredClone to create deep copies that handle Date objects correctly — safer than JSON.parse/stringify.

Why Midnight Archiving Instead of 24 Hours

A task completed at 11pm would still appear in the Done column the next morning under a 24-hour rule. The correct boundary is midnight in local time — not UTC, which would shift by the user's timezone offset.

This is a small detail that completely changes the user experience. Getting it wrong makes the app feel broken even when the code is technically correct.

The Bugs That Taught Me the Most

Silent persistence failure. Tasks were saving locally and appearing on the board but disappearing on refresh. No errors in the console. Every POST request returned 400 silently. The API was validating the wrong data shape — the snapshot structure had changed when I added archive support but the API never got updated. Lesson: when two systems share a data contract, define the type once and import it in both places.

Undo across refresh. Undo worked perfectly in the same session. After refresh the undone delete came back. The task had been physically deleted from Supabase — the snapshot saved the restored state but the tasks table did not have the row. Fix: after every undo/redo, sync the actual database state to match restored state.

Hydration mismatch. Math.random() was called at module level to generate a tab identifier. Server rendered one value, client hydrated with a different value. React threw a hydration error. Fix: move random generation inside a useRef that only initializes on the client.

Case sensitivity on Linux. The app worked perfectly on Windows locally. Vercel build failed with Module not found. The file was saved as focusMode.tsx — Windows is case-insensitive, Linux is not. Fix: git mv to rename the file. Lesson: always match import casing to file casing exactly.

AI Integration: Graceful Degradation

Every AI endpoint has a local fallback. The app works without OpenAI credits. It gets smarter when you have them.

The planner also adapts to the user's energy level before calling GPT. A mood multiplier adjusts session lengths — low energy gets 60% of normal session length, high energy gets 130%. GPT's time allocations match actual capacity instead of assuming everyone works the same way.

Results

Clerk JWT to Supabase auth: under 100ms per request
Full state restoration: single JSONB query
AI plan generation: 1-3 seconds, instant with local fallback
Undo/redo: O(1) push/pop with ref stacks, persistent across refresh
First load JS: 287kb

What I Would Do Differently

Define API contracts first. I built the provider and API routes in parallel and they drifted. In a real team you write the OpenAPI spec first and generate types from it.

Test the error paths, not just the happy path. The silent persistence failure would have been caught immediately by a test asserting the snapshot shape.

Use a type-safe API client. Raw fetch with manual JSON parsing requires manual type assertions everywhere. tRPC would have made the shape mismatch impossible.

Never assume case-insensitivity. Build and test on Linux from day one.

Final Thought

The hardest part of building something complex is not any single technical problem. It is keeping the whole system coherent while solving them one by one.

NeuroSpace taught me that more than any tutorial ever could.

Built by Naima Kader
Portfolio: https://portfolio-seven-beryl-29.vercel.app/
GitHub: github.com/naimakader/Neurospace
Live: neurospace-zr2n.vercel.app

I Built an AI Courtroom Simulator with Next.js and OpenAI — Here's the Full Technical Breakdown

Naima Kader — Tue, 04 Aug 2026 05:13:56 +0000

I Built an AI Courtroom Simulator That Lets Law Students Practice Against a Judge, Prosecutor, and Witness — Here's How

When I started building LexAI I had one question: what would happen if you put three AI personas in a courtroom and let a law student argue against all of them simultaneously?

Six weeks later I had my answer — and a production app that law students are actually using.

This is the full technical breakdown of how I built it.

The Problem

Moot court is how law students learn to argue. The problem is brutal:

A professional coach costs $500 per hour
Most law schools offer fewer than 12 practice sessions per year
Students who cannot afford coaching lose more cases
There was no free, intelligent alternative

I am a self-taught developer based in Jijiga, Ethiopia. I have never been to law school. But I recognized a product problem with a clear technical solution — and I built it.

What I Built

LexAI is a full-stack AI courtroom simulator with:

3 AI personas — a strict federal judge, an aggressive prosecutor, and a defensive witness
Real-time argument scoring — every argument rated 0 to 100 on logic, precedent, and persuasiveness
Witness cross-examination with contradiction detection
Session replay timeline showing score progression across every turn
Real-time multiplayer battle mode — two students argue opposite sides simultaneously
Professor dashboard with class management and student analytics
Shareable session cards with dynamic OG image generation on the edge
10 landmark cases including Miranda, Brown v. Board, Roe v. Wade, Apple v. Samsung

Live: lexai-fd92.vercel.app
GitHub: github.com/naimakader/Lexai

The Stack

Next.js 15 App Router
TypeScript
Tailwind CSS
Supabase (PostgreSQL + Realtime)
Clerk Authentication
OpenAI GPT-4o-mini
Vercel OG (Edge Runtime)
Framer Motion

The Hardest Technical Problem — Multi-Persona AI State

The core challenge was keeping three AI personas consistent across a long conversation.

Each persona needed to:

Respond in character without breaking tone
Remember what was said earlier in the session
React to the user's specific argument — not a generic response

My solution was to send the full conversation history to OpenAI on every request with a role-locked system prompt. Each API call includes the complete transcript so the AI has full context.

const prompt = `
You are running a courtroom simulation.

Case facts: ${caseData.facts}

Conversation so far:
${conversation}

Respond with a JSON object with exactly these 5 fields:
- judgeResponse: The judge's response (1-2 sentences, formal)
- prosecutionResponse: The prosecution's counter-argument (aggressive)
- score: 0 to 100 rating the defense's last argument
- scoreDelta: How much the score changed from previous turn
- feedback: One short coaching sentence for the defense

Return only valid JSON. No extra text.
`

Using response_format: { type: "json_object" } on GPT-4o-mini guarantees structured output every time. No parsing failures, no broken JSON.

The Witness Contradiction Detection System

This was the feature that surprised me most technically.

The witness has a prepared testimony. When the user asks questions, the AI tries to stay consistent. But if the user asks a clever question that exposes an inconsistency — the witness stumbles.

The key insight was in the system prompt:

const prompt = `
You are playing the role of a witness in a courtroom cross-examination.

Your original testimony: ${caseData.witness.testimony}

IMPORTANT RULES:
- Stay consistent with your original testimony unless the attorney 
  asks a very clever question that exposes a contradiction
- If caught in a contradiction admit it reluctantly but try to explain it away
- Be evasive and defensive when pressed on weak points
- Never volunteer information the attorney did not ask for

Return a JSON object including:
- witnessResponse: Your answer (1-3 sentences)
- contradiction: true if the attorney caught a contradiction
- score: 0 to 100 rating the question's effectiveness
`

When contradiction: true comes back, a red banner flashes on screen and the score jumps. Users genuinely feel the moment they catch the witness.

Real-Time Multiplayer with Supabase Realtime

The battle mode was the most technically interesting feature to build.

Two players join the same room — one as defense, one as prosecution. Every argument one player makes triggers an AI judge response that both players see simultaneously.

The architecture:

Player 1 creates a room — gets a 6-letter code
Player 2 enters the code — joins as prosecution
When either player submits an argument, the API route calls OpenAI, saves the updated messages to Supabase, and returns the response
Supabase Realtime fires a postgres_changes event to both clients
Both UIs update simultaneously

useEffect(() => {
  const channel = supabase
    .channel(`battle_room_${room.id}`)
    .on(
      "postgres_changes",
      {
        event: "UPDATE",
        schema: "public",
        table: "battle_rooms",
        filter: `id=eq.${room.id}`,
      },
      (payload) => {
        setRoom(payload.new)
      }
    )
    .subscribe()

  return () => {
    supabase.removeChannel(channel)
  }
}, [room.id])

The beauty of this approach is simplicity. I do not need WebSocket servers or complex state synchronization. Supabase handles everything. One database update triggers real-time UI updates across every connected client.

Dynamic OG Images on the Edge

After finishing a session users can share their results on LinkedIn and Twitter. When they paste the link, a dynamic preview image appears showing their score, grade, case name, and best argument.

This uses Vercel's @vercel/og library running on the Edge Runtime:

export const runtime = "edge"

export async function GET(req: NextRequest) {
  const { searchParams } = new URL(req.url)
  const caseTitle = searchParams.get("case") || "State v. Miranda"
  const score = searchParams.get("score") || "0"
  const bestArgument = searchParams.get("best") || ""

  return new ImageResponse(
    <div style={{ background: "#03030A", width: "100%", height: "100%" }}>
      // JSX rendered to a 1200x630 PNG on the edge
    </div>,
    { width: 1200, height: 630 }
  )
}

Every share generates a unique image in milliseconds. No pre-rendering, no storage costs.

The Clerk + Supabase Auth Problem

This was the bug that cost me the most time.

Clerk handles authentication. Supabase handles the database. But Supabase's Row Level Security uses auth.uid() which expects Supabase Auth — not Clerk. So RLS policies blocked all reads and writes even for authenticated users.

The fix was to use the Supabase service role key in all server-side API routes:

// lib/supabase-admin.ts
import { createClient } from "@supabase/supabase-js"

export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

The service role client bypasses RLS. I use it in all API routes where I verify the user via Clerk first, then query Supabase with elevated permissions.

The regular anon client is used only for Supabase Realtime subscriptions on the client side — where I do not need to read or write protected data.

The Session Replay Timeline

After each session, users can replay their entire argument history. Every turn is saved with:

The argument text
The score for that turn
The score delta — how much it went up or down
Whether it was a defense turn or witness turn

This data drives a visual bar chart and a turn-by-turn timeline showing exactly where the user won or lost the case.

const newEntry = {
  turn: (scoreHistory?.length || 0) + 1,
  score: result.score,
  argument: currentInput,
  delta: result.scoreDelta || 0,
  mode: "defense",
}

const updatedHistory = [...(scoreHistory || []), newEntry]

The best argument is calculated on every save:

const bestArgument = updatedHistory.reduce(
  (best, entry) => entry.score > (best?.score ?? 0) ? entry : best,
  updatedHistory[0]
)

Security

Three things I implemented before deploying:

1. Row Level Security on all tables

Even though I use the admin client in API routes, RLS is enabled on all tables as a defense-in-depth measure.

2. Rate limiting

Each user is limited to 50 API calls per hour. This prevents prompt injection attacks and runaway API costs.

3. Input sanitization

All user inputs are limited to 1000 characters before hitting the AI. This prevents prompt injection and keeps costs predictable.

What I Learned

Structured JSON outputs are underrated. Using response_format: { type: "json_object" } eliminated an entire category of bugs. No more regex parsing, no more broken responses, no more try-catch around JSON.parse for normal flow.

Supabase Realtime is genuinely magical. Building multiplayer with WebSockets from scratch would have taken weeks. With Supabase Realtime it took two hours. The postgres_changes subscription is one of the most elegant APIs I have used.

The hardest part of AI products is not the AI. It is the state management around the AI. Keeping conversation history consistent, handling loading states, recovering from errors gracefully — that is where the real engineering work is.

Ship with security from day one. I added RLS and rate limiting before the first deployment. Going back to add security to a running production app is much harder than building it in from the start.

What Is Next

Voice arguments — speak your legal argument instead of typing
AI feedback report — a full written analysis of your performance after each session
More landmark cases — currently at 10, targeting 50 by end of year
Mobile app — React Native version for studying on the go

Try It

Live: lexai-fd92.vercel.app
GitHub: github.com/naimakader/Lexai

If you are a law student, try arguing State v. Miranda. If you are a developer, look at the battle mode and the OG image generation — those are the two parts I am most proud of technically.

Questions welcome in the comments.

Built by Naima — frontend developer who ships full-stack products from Jijiga, Ethiopia.