DEV Community: Khushboo Parmar

I built an accessible gaming platform that profiles players through observation instead of settings menus

Khushboo Parmar — Mon, 30 Mar 2026 02:55:06 +0000

Every accessible game asks players to configure their own needs. But players who are newly disabled, new to gaming, or unfamiliar with accessibility terminology can't configure what they don't know they need.

I call this the configuration barrier — and I built ObservePlay to eliminate it.

The Solution

ObservePlay watches how you play during a 5-stage onboarding session and infers your accessibility profile automatically:

Stage 1: Welcome (no questionnaire)
Stage 2: Input Detection (9 input methods detected)
Stage 3: Visual Assessment (text size + contrast thresholds)
Stage 4: Audio Assessment (3-tone hearing classification)
Stage 5: Profile Review (accept or override)

The inferred profile drives automatic adaptation of game feedback, timing, sizes, contrast, and more.

Tech Stack

Framework: Next.js 16 (App Router) + React 19
Language: TypeScript (~25,000 lines)
Audio: Web Audio API (real-time synthesis, no audio files)
ML: TensorFlow.js (client-side emotion detection via WASM)
Database: PostgreSQL + pgvector
Real-time: WebSocket
Offline: Service Worker + IndexedDB (PWA)
Testing: Vitest + fast-check (property-based testing)

Architecture

11 service modules connected through a typed event bus:

Profile Learner ──┐
Accessibility Copilot ──┤
Emotion Engine ──┤
NL Controller ──┤
Audio Narrator ──┼──> Event Bus ──> WebSocket Hub ──> Client
AI Companion ──┤
Game Generator ──┤
Research Analyzer ──┤
Consent Manager ──┤
Copilot Adaptation Learner ──┤
Companion Learning ──┘

Key Design Decisions

Web Audio API for sound synthesis — all game sounds are synthesized in real time. No audio files to load, no network dependency. Four distinct tones (flip: 600Hz, match: C5-E5, mismatch: 200Hz, win: C5-E5-G5-C6).

Deterministic profile inference — same observation data always produces the same profile. Validated by property-based tests across 10,000 generated inputs.

Client-side emotion processing — TensorFlow.js runs facial expression analysis in the browser via WASM. No raw video ever leaves the device. This was a non-negotiable privacy decision.

Progressive Web App — service worker caches game assets and profiles for offline play. Cache-first for assets, network-first for API calls, IndexedDB for structured data.

Adaptation Rules

// Hearing-based feedback selection
if (profile.hearingCapability === 'none') {
  // Disable audio, enable screen flash + text indicators + card labels
} else if (profile.hearingCapability === 'partial') {
  // Enable audio AND enhanced visual feedback
} else {
  // Standard audio feedback
}

// Card size computation
const cardSize = Math.max(
  80,
  profile.minReadableTextSize * 4,
  profile.clickPrecision * 8
);

Testing Results

Metric	Value
Test files	27
Test cases	638
Pass rate	100%
Execution time	2.60s
Lighthouse accessibility	96/100
GAG compliance	86% (79/92)
Simulated profiles tested	100,000
Adaptation conflicts found	0

Try It + Give Feedback

I'm writing a research paper on this for ACM TACCESS and need community feedback.

Try the app: https://observeplay-jf9e.vercel.app/

Share feedback (anonymous, 5 min): https://forms.gle/GEt36zsUcUhnGBULA

Especially interested in hearing from:

Gamers with disabilities — did it correctly detect your needs?
Accessibility professionals — what's missing?
Developers — what would you architect differently?

The project is open-source. Contributions welcome.

What do you think about observation-based profiling as an alternative to manual accessibility configuration? Would love to hear your thoughts in the comments.

Catch issues before users notice 🚀 #Accessibilty

Khushboo Parmar — Mon, 23 Mar 2026 02:22:27 +0000

Khushboo Parmar

Mar 23

AI-Powered Accessibility: From Hype to Real-World Wins

#webaccessibility #inclusivedesign #cicd #devto

Comments

2 min read

AI-Powered Accessibility: From Hype to Real-World Wins

Khushboo Parmar — Mon, 23 Mar 2026 02:19:15 +0000

Accessibility isn’t just a checkbox—it’s a commitment to making the web usable for everyone. But with AI tools flooding the market, how do we separate hype from reality?

Here’s a practical approach:
1. Start with audits: Use tools like axe and Lighthouse to identify accessibility issues early. Automated tests catch ~30–50% of problems before they reach production.
2. Leverage AI smartly: AI plugins can suggest fixes for color contrast, missing alt texts, and semantic errors. But they aren’t perfect—human review is still critical.
3. Integrate in CI/CD: Don’t wait until launch. Run accessibility tests automatically on every pull request. Catch issues when they’re easiest to fix.
4. Real examples:
•AI identified missing ARIA labels in a React component.
•Lighthouse audit revealed skipped heading hierarchy issues on multiple pages.

✅ Outcome: Reduced accessibility debt, faster development cycles, and improved inclusivity.

💡 Tip: Accessibility isn’t a one-time fix. Treat it as a continuous improvement process, powered by AI but guided by humans.

AI-Powered Accessibility: Fix Issues Before Users Notice
Accessibility is no longer optional. AI tools can help catch issues automatically—but knowing how to integrate them makes all the difference.

💡 How it works:
1. Visits your page automatically
2. Runs accessibility checks (axe-core)
3. Reports violations before they reach production

Combine with AI suggestions for color contrast, alt texts, and semantic fixes. The result? Less accessibility debt and more inclusive apps


`javascript
// Example: Automated axe check in CI/CD pipeline
import { configureAxe } from 'axe-core';
import { runAxe } from 'axe-puppeteer';
import puppeteer from 'puppeteer';

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  const results = await new runAxe(page).analyze();
  console.log('Accessibility Violations:', results.violations);

  await browser.close();
})();
`

Minor issues—missing labels, poor contrast, or bad keyboard navigation—compound over time. Left unchecked, they make your app unusable for people with disabilities and expensive to fix later. The solution? Build accessibility into your workflow

Khushboo Parmar — Tue, 17 Mar 2026 03:02:37 +0000

Accessibility Debt: The Hidden Technical Debt in Modern Web Applications

Khushboo Parmar ・ Mar 17

#ai #a11y #programming #opensource

Accessibility Debt: The Hidden Technical Debt in Modern Web Applications

Khushboo Parmar — Tue, 17 Mar 2026 02:45:27 +0000

Accessibility debt accumulates silently in most web applications. Teams focus on shipping features, but minor accessibility issues—missing labels, poor contrast, bad keyboard navigation—compound over time.

When left unchecked:
• Applications fail WCAG compliance
• Users with disabilities are excluded
• The cost to fix issues later skyrockets

Best Practices:
1. Include accessibility in code reviews
2. Build accessible components from the start
3. Automate testing using CI/CD tools
4. Educate teams about accessibility best practices

Key takeaway: Accessibility is not a one-time fix—it’s a continuous responsibility. Tackling it early reduces technical debt and builds inclusive applications at scale.

Automating ADA Compliance in Modern Web Apps 🚀

Khushboo Parmar — Sat, 07 Mar 2026 03:12:21 +0000

Accessibility isn’t optional anymore. Automating ADA compliance in modern web apps saves time and keeps your app inclusive. Here’s how to do it smartly.

1️⃣ Automated Testing

Use tools like axe-core, Lighthouse, Pa11y to catch issues like missing labels, poor contrast, and ARIA misuse. Integrate them into CI/CD pipelines or unit tests.

Example with jest-axe in React:

import { render } from '@testing-library/react';
import { axe } from 'jest-axe';
import MyComponent from './MyComponent';

test('no accessibility violations', async () => {
  const { container } = render(<MyComponent />);
  expect(await axe(container)).toHaveNoViolations();
});

2️⃣ Semantic HTML & ARIA

Automation helps, but proper markup matters:
• over for actions
• or aria-label for inputs
• aria-live for dynamic updates

3️⃣ Continuous Monitoring

Web apps change fast. Run Lighthouse CI, add regression tests, and alert teams when issues appear.

4️⃣ Accessible Components

Reusable components must be accessible by default:
• Keyboard-friendly navigation
• Focus management for modals
• Support for high contrast themes

5️⃣ Manual Testing Matters

Automation catches most issues, but humans are irreplaceable:
• Test with screen readers
• Navigate keyboard-only
• Include real users with disabilities

Bottom line: Automation + best practices + continuous monitoring = a web everyone can use. Start small, iterate, and make accessibility part of your dev DNA. 💻✨

webdev #accessibility #reactjs #frontend