Living document Reviewed 10 Jul 2026
Browse documentation

Accessibility Principles

This page collects the accessibility principles guiding ViaSign and related Viathorne Labs work.

The goal is not only to build technology that works.

The goal is to build technology that supports access, dignity, language, community, and human communication.

Accessibility Is a Foundation, Not a Patch

Accessibility is often treated like something to add later.

Build the product first.

Add captions later.

Add support later.

Add accessibility settings later.

Design for disabled users later.

But “later” is often where accessibility becomes weaker.

When accessibility is added only at the end, it usually has to fit into a system that was not designed for it.

The result may technically exist, but it may not feel natural. It may help a little, but still leave people working around the system.

Accessibility should not be decoration, a compliance checkbox, or a feature hidden at the bottom of a roadmap.

It should be part of how the product is understood from the beginning.

Captions Are Important, But Not the Whole Picture

Captions are important.

They help many people access spoken information. They make videos, meetings, classrooms, announcements, and online content more reachable.

But Deaf accessibility cannot be reduced to captions alone.

For many Deaf people, written text is useful, but it is not always the same as having access in a natural language.

Signed languages are not visual versions of spoken languages. They have their own structure, rhythm, grammar, expression, and cultural meaning.

Singapore Sign Language is not simply English shown through the hands.

It is a language with its own way of carrying meaning.

This matters because many accessibility tools still assume that converting speech into text is enough.

Someone speaks.

The system generates captions.

The Deaf person reads the words.

Problem solved.

But real communication is not always that simple.

Access is not just about receiving information. It is also about comfort, speed, context, identity, and participation.

A more complete approach to accessibility can include captions, signed language support, visual learning tools, better communication bridges, feedback led by Deaf community members, and technologies designed with Deaf users in mind from the start.

Signed Languages Should Be Respected as Languages

Signed languages are living languages.

They are shaped by communities, culture, history, expression, and everyday use.

They are not simplified versions of spoken languages.

They are not just gestures attached to English.

They carry grammar, movement, space, timing, facial expression, body posture, context, and identity.

This means accessibility systems should not force signed languages to fit into spoken-language assumptions.

A system designed only around speech and text may still exclude people who communicate visually.

A system designed only for impressive output may look good, but still miss the deeper purpose.

For signed language accessibility, the foundation matters.

The language layer matters.

The motion layer matters.

The review layer matters.

The people involved matter.

AI Should Support, Not Replace

AI should not be built with the mindset of replacing Deaf people, Deaf teachers, interpreters, educators, or community knowledge.

That is not the goal.

The goal should be support.

Technology should make communication easier, not erase the people who already carry the language, culture, and lived experience.

An AI tool might help explain a sentence.

It might help prepare learning material.

It might help show possible sign structure.

It might help support communication in certain contexts.

It might help hearing people become more aware that signed languages are real languages with their own grammar.

But it should not pretend to be the final authority.

It should not pretend that human review is unnecessary.

It should not make people believe that generated output is automatically correct just because it looks polished.

A fluent signer, a Deaf teacher, an interpreter, or a community reviewer brings something AI does not have: lived experience, cultural understanding, judgement, context, and human responsibility.

That matters.

Deaf Community Feedback Should Shape the Work

Accessibility technology should not be built only in isolation.

It should be built with the people it is meant to support.

This matters especially when building tools for Deaf communities and signed languages.

Sign language accessibility is not just a technical problem.

It is also a language problem, a culture problem, a trust problem, a design problem, and a human problem.

A system can look impressive in a demo and still be wrong.

It can generate movement that looks like signing, but does not carry the right meaning.

It can follow a technical rule, but miss the natural way people actually communicate.

It can produce something that seems accessible to hearing developers, but feels awkward, incomplete, or inaccurate to Deaf users.

That is why Deaf community feedback matters.

Not as a final checkbox.

Not as something added at the end.

Not as a small validation step after the main decisions have already been made.

It has to be part of the process.

Good feedback makes the work stronger.

Community review makes the work safer.

Guidance from Deaf reviewers keeps the work grounded.

Systems Should Be Honest About Limits

AI can be powerful.

But power without care can create harm.

For AI accessibility, responsibility has to come before reach.

Before asking:

How many people can use this?

We should also ask:

  • Who reviewed this?
  • Who shaped this?
  • Who might be affected if this is wrong?
  • Does this respect the people it is meant to support?
  • Are Deaf people part of the process, or only the audience?

A system should show uncertainty when something needs review.

It should respect that some things cannot be solved by automation alone.

It should avoid pretending that generated output is automatically correct.

It should make limitations visible instead of hiding them behind polished output.

Build Carefully, Layer by Layer

For ViaSign, accessibility means building carefully.

Not rushing toward automation.

Not treating signed language as a visual trick.

Not using AI only because it is possible.

The goal is to build in layers, test carefully, stay honest about limitations, and invite feedback where it matters.

The goal is not just to generate.

The goal is to support.

The goal is not just to automate.

The goal is to include.

The goal is not just to make technology more advanced.

The goal is to make communication more reachable, respectful, and human.

Accessibility should not be something remembered after the product is already built.

It should be one of the reasons we build differently in the first place.

Because the future should not only be innovative.

It should be accessible from the start.