Deaf-led · open source · live on GitHub

Build digital experiences that do not depend on sound.

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

A public home for code, decisions and community.

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.

Official repository github.com/UpliftiQ/
accessibility-toolkit

Teams keep rebuilding the same accessibility foundations.

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.

01

Accessibility is rebuilt

Every team spends time solving caption controls, transcripts, focus states and visual feedback again.

02

Patterns stay fragmented

Useful solutions remain inside private products instead of becoming documented, reusable infrastructure.

03

Testing lacks lived experience

Automated conformance checks cannot replace structured review by Deaf and hard-of-hearing people.

One open toolkit. Many kinds of accessible products.

The components support education, work, public information and community services—not only the UpliftiQ learning platform.

Developers

Public React and TypeScript source, typed APIs, examples, test foundations and practical accessibility documentation.

NGOs and community organisations

Reusable patterns for training, awareness content, public programmes and sign-language-supported resources.

Businesses and product teams

Accessible onboarding, product education, internal learning and customer-support media without starting from zero.

Schools and universities

Caption-first lectures, accessible course players, visual learning states and better transcript navigation.

Government and public services

Clearer digital information, staff training and service explainers that do not depend only on spoken audio.

Online coursesEmployee trainingPublic-service videosEventsHelp centresCommunity programmes

One lesson. Multiple visual arrangements.

Try the controls to see how a learner could choose the layout and caption size that works for them.

Video layout
Caption size
Lesson 04Photosynthesis
Teaching visual
ISL educatorDeaf-led explanation
Plants use sunlight, water and carbon dioxide to create energy.

This lightweight preview explains the interaction pattern. Open the live project documentation for running component examples and API guidance.

Three focused packages, one accessible foundation.

The public monorepo contains three focused pre-release packages, documentation and automated tests. Package APIs may still change before the first npm release.

02

@upliftiq/deaf-ui

Visual-first interface primitives

Accessible components for visual alerts, progress, turn-taking, feedback and learning states—designed with Deaf users.

  • Visual alerts
  • Focus states
  • Progress
  • Preferences
03

@upliftiq/isl-tools

Indian Sign Language utilities

Helpers and data contracts for ISL media references, glossary linking, sign-language metadata and bilingual learning flows.

  • Media metadata
  • Glossary links
  • ISL labels
  • Content models

Explore working source and accessible media patterns.

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.

LessonVideo.tsx

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."
        }
      ]}
    />
  );
}

Small layers. Clear responsibilities.

Applications compose the toolkit. The toolkit uses native web primitives. Quality gates protect every public component.

01Your productLMS · website · app · portal
02UpliftiQ packagesPlayer · UI · ISL utilities
03Web standardsHTML · WebVTT · ARIA · CSS
04Quality gatesTests · audits · Deaf review

Project rules stay close to the code.

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

Open primitives. Private learning platform.

The toolkit publishes reusable accessibility infrastructure. The UpliftiQ learning platform, learner data, course content and internal operations remain separate.

Open source

  • Reusable React packages
  • Documentation and examples
  • Accessibility test suite
  • Public roadmap and governance

UpliftiQ platform

  • Private learner data
  • Proprietary course content
  • Commercial operations
  • Internal AI services

Quality is measured with people and tests.

WCAG conformance is a baseline—not the finish line. Lived-experience review and public test evidence guide release decisions.

Deaf-led review

Major experience changes should include review by people with relevant lived experience.

Keyboard complete

Every interactive component works without a pointer and has a clear focus state.

Readable media

Captions, transcripts, speaker cues and visual context remain easy to find and control.

Public evidence

Automated checks, manual findings and known limitations are documented openly.

Modern, maintainable and friendly to contributors.

The stack favours web standards, small dependencies and tools familiar to the React open-source community.

Core principleUse native HTML and browser accessibility first; add JavaScript only where it improves the learner’s control.
Current technology choices and purposes
AreaChoicePurpose
LanguageTypeScriptStrict, predictable public APIs
ComponentsReact + native HTMLReusable UI on semantic foundations
MediaHTML media + WebVTTCaptions and timed text without lock-in
Workspacepnpm workspacesFast multi-package repository
DocsVite + StorybookExamples, API guidance and visual review
TestsVitest + Playwright + axeUnit, interaction and accessibility checks
ReleaseChangesets + GitHub ActionsReviewed, traceable npm releases

A component is not complete until people can use it.

These project rules apply to maintainers and contributors. Automated checks support the work, but never replace human review.

01

Start with semantic HTML

Use real buttons, links, headings, labels, lists and media elements before adding ARIA.

button—not a clickable div
02

Never depend on sound alone

Alerts, completion states, errors and turn-taking need visible equivalents.

sound + text + visual state
03

Keyboard is a release requirement

Focus order must follow meaning. Every action needs a visible focus style and predictable key behaviour.

Tab · Enter · Space · Escape
04

Captions are content

Include accurate timing, speaker identity and useful audio cues. Never burn essential controls into video.

[door closes] · Speaker: text
05

Give users control

Let people change caption size, contrast, transcript view, sign-video position and motion preferences.

preferences belong to the user
06

Test beyond automation

Run unit, browser and axe checks, then complete manual keyboard and Deaf-user review.

automated + manual + lived experience
07

Protect sign-language media

Document consent, usage rights, attribution and retention. Never treat signed video as free training data.

consent must be specific
08

Write plain documentation

Use short steps, visual examples and expected results. Caption every tutorial video.

show what success looks like

Before a change can merge

  • TypeScript and unit tests pass
  • Keyboard path documented
  • Focus and contrast checked
  • axe scan has no serious violations
  • Public behaviour is documented
  • Deaf review completed for major UX changes

Live source today. A careful path to stable packages.

The repository is public and testable now. The next milestones focus on evidence, API stability and a responsible first package release.

1

Live today

Public foundation

MIT licence, governance, contribution guides, three packages, documentation and automated checks.

Available: source + live docs
2

Current focus

Validate the core

Strengthen caption-player behaviour, examples, manual checks and community feedback.

Goal: release-ready APIs
3

Next release

Publish packages

Complete package metadata, release notes, npm publishing and installation guidance.

Goal: first npm release
4

Toward v1

Learn and stabilise

Respond to real adoption, document limitations, refine APIs and publish migration guidance.

Goal: evidence-backed v1
3Pre-release packages in the monorepo
8Unit and component tests passing
2Playwright browser tests passing
MITOpen-source licence

Repository snapshot verified before publication. Check GitHub Actions for the latest status; future milestones are direction, not promises.

There is a useful first contribution for every skill.

Code is only one part of the project. Research, documentation, caption review, ISL knowledge and accessible design are equally important.

Build

Implement a component, repair a keyboard interaction, improve performance or add a test.

Good for engineers

Document

Write a plain-language guide, improve examples or caption a technical walkthrough.

Good for writers

Test

Report a barrier with clear steps, expected behaviour, device and browser information.

Good for users and QA

Guide

Review Deaf experience, ISL usage, visual communication and cultural assumptions.

Good for community experts
1Choose an issueLook for “good first issue” or propose a user need.
2Discuss the approachAgree on behaviour before writing a large change.
3Build and testFollow coding, accessibility and documentation rules.
4Open a pull requestExplain the user benefit and show test evidence.
5Review togetherMaintainer and community feedback becomes part of the work.

Ask early. Accessibility questions are welcome.

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.