Look at almost any major AI announcement and notice what’s being measured: a benchmark score, a larger context window, a difficult exam passed, or a new demonstration of what the latest model can accomplish.
The AI industry is exceptionally good at raising the ceiling, but there’s another measure of progress that deserves just as much attention.
The floor.
The floor is what someone with limited resources, different accessibility needs, or little technical support can actually accomplish with the technology available to them.
A more powerful model doesn’t automatically make AI more accessible. If that capability requires expensive hardware, a larger subscription, or an interface someone cannot use, the benefits may remain out of reach.
We started Fair Play to tell stories about people and organizations working to raise that floor, and we believe that means being willing to measure ourselves against the same standard.
Accessibility Is a Requirement, Not an Upgrade
In barbershop singing, four voices can align so precisely that listeners hear what sounds like a fifth voice. It’s often called the expanded sound, but the effect depends on the voices working together. When the necessary conditions aren’t present, the effect disappears.
Accessibility can work the same way.
Imagine an online application that works beautifully for most users but has one required field a screen reader cannot identify. For someone who depends on that screen reader, the problem may prevent the entire application from being completed.
Nine accessible steps don’t compensate for the tenth step that blocks someone from finishing.
That’s why accessibility belongs in the design process from the beginning. It should influence how we build interfaces, present information, structure workflows, and evaluate whether a system works for the people expected to use it.
Our Standard: POURS
The World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) organize accessibility around four principles, commonly called POUR:
- Perceivable: People can access information through forms they can perceive.
- Operable: People can navigate and interact with the system.
- Understandable: Information and interactions are clear enough to use.
- Robust: Content works reliably across compatible technologies, including assistive tools.
We’ve adopted an internal extension we call POURS, adding a fifth consideration:
Safe and Secure.
For us, accessibility also means examining whether people can use a system without compromising the security or privacy of their information. We apply these principles beyond visible interfaces.
Consider an automated process that runs overnight.
Did it produce an understandable record of what happened? Can someone inspect the result? Can a person using assistive technology determine whether the task succeeded or failed?
Accessibility should be considered throughout the workflow, including the outputs people depend on.
POURS is our internal design framework, informed by WCAG. It is not a separate W3C standard or a substitute for formal accessibility testing.
Measuring Ourselves Against the Standard
It’s easy to say accessibility matters. It’s harder, and more useful, to document where the work stands.
In our internal accessibility review, we mapped our work against 55 criteria in our WCAG 2.2 Level A and AA assessment checklist.
The initial results were:
- 5 criteria: Aligned in our preliminary review
- 3 criteria: Known gaps
- 47 criteria: Not yet verified
We also evaluated our work supporting blind and Deaf users, using an internal five-point assessment.
Our overall score was 2.6 out of 5.
The lowest area, at 1.5 out of 5, was the consistency with which people with disabilities participate in evaluating what we build.
That’s an important finding, because it identifies a gap that better technical documentation alone cannot resolve. We need more direct participation from the people whose experiences should inform our design decisions.
Some capabilities are already part of our work. Our KeyCenter interface includes a nonvisual interaction path using sonification, along with configurations designed for eyes-free use, sound-free use, and people who are hard of hearing.
Our speech recognition workflow can operate on local hardware, allowing recordings to be processed without sending them to an external speech recognition service.
Braille output remains on our development roadmap.
These are steps forward, but they are not evidence that the entire system is accessible.
The 47 unverified criteria matter as much as the five we have preliminarily aligned with. Publishing that baseline gives us something concrete to improve.
Accessible Technology Is Better Technology
Accessibility is sometimes discussed as though it benefits a narrow group of users. Many technologies developed around accessibility needs have applications far beyond their original audience: noise-canceling headphones, voice interfaces, audio navigation, and cameras that describe what’s in front of them.
These capabilities can help people with disabilities, and they can also help someone working with their hands occupied, navigating a noisy environment, or struggling to read a screen late in the day.
Researcher and assistive technology developer Dr. Kyle Keane works at the intersection of human perception, artificial intelligence, and technology that makes information accessible through different senses.
His work reflects a principle worth carrying into AI development: people benefit when technology accommodates more ways of perceiving and interacting with information.
A particularly compelling example is OneCourt. The Seattle-based company developed a haptic device that translates live sports data into vibrations and audio information, helping blind and low-vision fans follow the action through touch and sound.
It creates a new way to experience a game, and it demonstrates what becomes possible when accessibility is treated as a design opportunity.
Affordability Is Part of Access
Accessibility also has an economic dimension. For the small businesses, nonprofits, and community organizations Fair Play focuses on, cost can determine whether a technology is useful or simply unavailable.
An AI workflow might be affordable during a pilot but become expensive when employees begin relying on it every day. Usage-based processing, subscription fees, infrastructure requirements, and ongoing support can all affect whether an organization can sustain the capability.
We believe that cost deserves attention during design.
One approach we’re pursuing is to identify repetitive AI-supported tasks that can eventually be handled through simpler, deterministic processes.
When a workflow becomes sufficiently well understood, some steps may no longer require a model call every time. That can reduce ongoing processing costs for suitable tasks, although the savings depend on the workflow, implementation, and maintenance requirements.
The broader principle is straightforward: a technology becomes more accessible when organizations can afford to keep using it.
For a small nonprofit, predictable operating costs may matter as much as an impressive demonstration.
The People Who Know Need to Be in the Room
Our accessibility assessment exposed an important weakness in our process. We haven’t yet made participation by people with disabilities a sufficiently consistent part of evaluation. That’s something we intend to change.
Our conversations with the National Federation of the Blind are part of that effort.
We want to bring our assumptions, unverified criteria, and unfinished work into conversations with people who can identify problems we may have missed.
The purpose is to learn, test, and improve.
Accessibility cannot be established solely by the people building a product. It requires meaningful evaluation with people who use different technologies, have different needs, and encounter barriers developers may never experience themselves.
That participation should become a routine part of the work.
Raising the Floor Is the Work
The AI industry will continue raising the ceiling. Models will become more capable, hardware will improve, and new applications will accomplish things that seemed impossible only a few years ago.
Those advances matter, but we also need to ask who can actually use them.
Can someone navigate the interface without sight? Can a small nonprofit afford the operating costs? Can a person understand what an automated system did? Can users protect their information while accessing the same capabilities as everyone else?
Those questions belong alongside performance benchmarks.
At Varium and Pensato, we’re working toward that standard, and our own assessment makes clear that we have more work to do.
Fair Play exists to recognize organizations raising the floor and to examine what meaningful access requires.
What does the floor look like in the technology you’re building, and who’s standing on it?
Comments are closed