Accessibility is rebuilt
Every team spends time solving caption controls, transcripts, focus states and visual feedback again.
UpliftiQ Accessibility Toolkit is a public React and TypeScript project for caption-first media, sign-language-ready layouts and visual-first interfaces—so accessibility starts in the architecture, not at the end.
Repository live · docs, CI, browser tests and CodeQL passing
Now live
Source code, documentation, tests, governance and contribution history now live under the official UpliftiQ GitHub organisation. The toolkit is MIT-licensed and open for review and contribution.
The open-source gap
Captions are often added late, sign-language video is placed in a tiny fixed box, transcripts are separated from the content and keyboard access breaks when custom controls are introduced.
The toolkit turns repeated accessibility work into shared, tested building blocks that developers, nonprofits, schools, businesses and public teams can reuse and improve.
Every team spends time solving caption controls, transcripts, focus states and visual feedback again.
Useful solutions remain inside private products instead of becoming documented, reusable infrastructure.
Automated conformance checks cannot replace structured review by Deaf and hard-of-hearing people.
Who this helps
The components support education, work, public information and community services—not only the UpliftiQ learning platform.
More control over captions, transcripts, sign-language video, layout, reading comfort and visual alerts.
Public React and TypeScript source, typed APIs, examples, test foundations and practical accessibility documentation.
Reusable patterns for training, awareness content, public programmes and sign-language-supported resources.
Accessible onboarding, product education, internal learning and customer-support media without starting from zero.
Caption-first lectures, accessible course players, visual learning states and better transcript navigation.
Clearer digital information, staff training and service explainers that do not depend only on spoken audio.
Interactive accessibility pattern
Try the controls to see how a learner could choose the layout and caption size that works for them.
01:18 Plants use sunlight, water and carbon dioxide to create energy.
01:26 This process is called photosynthesis. Oxygen is released into the air.
This lightweight preview explains the interaction pattern. Open the live project documentation for running component examples and API guidance.
Toolkit architecture
The public monorepo contains three focused pre-release packages, documentation and automated tests. Package APIs may still change before the first npm release.
@upliftiq/caption-player
Composable React components for teaching video, sign-language video, WebVTT captions, searchable transcripts and user-controlled layouts.
@upliftiq/deaf-ui
Accessible components for visual alerts, progress, turn-taking, feedback and learning states—designed with Deaf users.
@upliftiq/isl-tools
Helpers and data contracts for ISL media references, glossary linking, sign-language metadata and bilingual learning flows.
Developer hub
The public API below matches the current pre-release source. Clone the monorepo to run it today; package names and APIs may still change before the first npm release.
import { CaptionPlayer } from "@upliftiq/caption-player";
import "@upliftiq/caption-player/styles.css";
export function LessonVideo() {
return (
<CaptionPlayer
title="Introduction to photosynthesis"
videoSrc="/lesson.mp4"
captionTracks={[
{
src: "/lesson-en.vtt",
label: "English",
srcLang: "en",
default: true
}
]}
signLanguage={{
src: "/lesson-isl.mp4",
label: "Indian Sign Language"
}}
transcript={[
{
id: "cue-1", start: 0, end: 5.2,
speaker: "Educator",
text: "Plants use sunlight to create energy."
}
]}
/>
);
}
Technical architecture
Applications compose the toolkit. The toolkit uses native web primitives. Quality gates protect every public component.
Current monorepo
Packages, documentation, Storybook examples and tests share one reviewable workspace.
accessibility-toolkit/
├── packages/
│ ├── caption-player/
│ ├── deaf-ui/
│ └── isl-tools/
├── apps/
│ └── docs/
├── stories/
├── tests/
│ └── e2e/
├── docs/
│ ├── GETTING_STARTED.md
│ └── API_REFERENCE.md
├── CONTRIBUTING.md
├── GOVERNANCE.md
├── SECURITY.md
└── LICENSE
Clear project boundary
The toolkit publishes reusable accessibility infrastructure. The UpliftiQ learning platform, learner data, course content and internal operations remain separate.
Accessibility commitment
WCAG conformance is a baseline—not the finish line. Lived-experience review and public test evidence guide release decisions.
Major experience changes should include review by people with relevant lived experience.
Every interactive component works without a pointer and has a clear focus state.
Captions, transcripts, speaker cues and visual context remain easy to find and control.
Automated checks, manual findings and known limitations are documented openly.
Current tech stack
The stack favours web standards, small dependencies and tools familiar to the React open-source community.
| Area | Choice | Purpose |
|---|---|---|
| Language | TypeScript | Strict, predictable public APIs |
| Components | React + native HTML | Reusable UI on semantic foundations |
| Media | HTML media + WebVTT | Captions and timed text without lock-in |
| Workspace | pnpm workspaces | Fast multi-package repository |
| Docs | Vite + Storybook | Examples, API guidance and visual review |
| Tests | Vitest + Playwright + axe | Unit, interaction and accessibility checks |
| Release | Changesets + GitHub Actions | Reviewed, traceable npm releases |
Coding and accessibility rules
These project rules apply to maintainers and contributors. Automated checks support the work, but never replace human review.
Use real buttons, links, headings, labels, lists and media elements before adding ARIA.
button—not a clickable divAlerts, completion states, errors and turn-taking need visible equivalents.
sound + text + visual stateFocus order must follow meaning. Every action needs a visible focus style and predictable key behaviour.
Tab · Enter · Space · EscapeInclude accurate timing, speaker identity and useful audio cues. Never burn essential controls into video.
[door closes] · Speaker: textLet people change caption size, contrast, transcript view, sign-video position and motion preferences.
preferences belong to the userRun unit, browser and axe checks, then complete manual keyboard and Deaf-user review.
automated + manual + lived experienceDocument consent, usage rights, attribution and retention. Never treat signed video as free training data.
consent must be specificUse short steps, visual examples and expected results. Caption every tutorial video.
show what success looks likePull-request gate
Public project status
The repository is public and testable now. The next milestones focus on evidence, API stability and a responsible first package release.
Live today
MIT licence, governance, contribution guides, three packages, documentation and automated checks.
Available: source + live docsCurrent focus
Strengthen caption-player behaviour, examples, manual checks and community feedback.
Goal: release-ready APIsNext release
Complete package metadata, release notes, npm publishing and installation guidance.
Goal: first npm releaseToward v1
Respond to real adoption, document limitations, refine APIs and publish migration guidance.
Goal: evidence-backed v1Repository snapshot verified before publication. Check GitHub Actions for the latest status; future milestones are direction, not promises.
Open contribution
Code is only one part of the project. Research, documentation, caption review, ISL knowledge and accessible design are equally important.
Implement a component, repair a keyboard interaction, improve performance or add a test.
Good for engineersWrite a plain-language guide, improve examples or caption a technical walkthrough.
Good for writersReport a barrier with clear steps, expected behaviour, device and browser information.
Good for users and QAReview Deaf experience, ISL usage, visual communication and cultural assumptions.
Good for community expertsNeed help?
Read the contribution guide before a large change. Use GitHub Issues for bugs and defined feature work, or contact the maintainers when you are unsure where to begin.