Fair and accessible for whom?

An AI tool may be technically enabled for everyone and still fail to give everyone the same real opportunity to use it. Anyone who assesses a procurement decision only by a feature list, a demo, and an average score may see neither the barrier at the start of a work path nor the additional work that ultimately falls to learners or employees. The question “Is this product accessible?” is therefore too broad. What matters is: for which task, under which conditions, through which communication routes, and with which possibility of objection does it work?

This article develops a practical testing route for a small continuing education company considering an AI-supported learning portal. It connects a philosophical question about real freedom and institutional power with research on language and disability, the in-house F v5 and K models, and a procurement-oriented test plan. The case example is entirely constructed and does not depict a real person, organisation, or event.

1. The purchase helps determine who has to adapt

Most decisions about accessibility are made before a system reaches everyday use. A specification identifies which tasks count as important. A demo directs attention towards particular ways of using it. A contract determines what support, correction, and response time the supplier owes. If a team asks only after purchase whether a product works for a particular group, fundamental changes are often more expensive or organisationally harder.

This makes procurement an ethical practice. It distributes more than money: it also distributes time, risk, freedom to act, and correction work. If an automatic summary appears quick but course leaders must regularly rebuild it into a screen-reader-friendly structure, part of the work has not disappeared. It has been shifted. If a chatbot permits only one input method, “voluntary use” may be a formal choice while the practical alternative is absent. If only average completion time is measured, it remains invisible who takes additional detours or drops out altogether.

A small organisation does not have to solve every possible product problem in advance. It does, however, need to describe the intended use precisely enough for relevant risks to be testable. That includes taking the non-AI option seriously. A well-structured static course page, an editable document, or a human contact person may be better suited to a purpose than a conversational model. “We use AI” is not an independent quality goal.

2. The same function does not mean the same opportunity

A useful philosophical distinction begins with the question of what equality concerns. Amartya Sen asks whether justice should focus on equal resources, equal welfare, or real capabilities and opportunities to act [4]. For product testing, this means that it is not enough for everyone to be shown the same button. It is necessary to test whether people can actually carry out, understand, control, and, where needed, stop a task that matters to them by using it.

Iris Marion Young extends the question beyond the distribution of goods. Her political theory directs attention to power relations, institutional rules, cultural standards, and groups’ participation in decisions [5]. Applied to AI procurement, this means asking not only who receives an outcome, but also who defines the test criteria, whose language counts as “normal,” and who bears the cost of an error. These philosophical texts are not AI fairness metrics. They help frame the testing question more comprehensively.

In its preamble, the UN Convention on the Rights of Persons with Disabilities describes disability in connection with the interaction between impairments and barriers in the environment. It treats accessibility, communication, universal design, and participation as connected normative issues [1]. For SME procurement, the Convention is neither a technical product specification nor a completed legal assessment. It does, however, offer a clear ethical correction: a difficulty should not be hastily recorded as a property of a person when the process, presentation, language, or organisational rule itself can be changed.

Universal Design aims to make products and environments usable by as many people as possible. A good baseline, such as clear structure, several input methods, and understandable guidance, prevents access from arising only after an individual request. It does not eliminate every specific need, however. People use different assistive technologies, languages, forms of communication, and working strategies. A universally designed product can reduce the number of avoidable obstacles; it does not make specific adaptations, choices, and a human way out unnecessary.

This results in a two-part test of justice:

Distribution: Who receives the benefit, and who bears error costs, waiting times, corrections, or data risks? Which groups can more easily stop or bypass the process?

Procedure and recognition: Who determines what counts as success? Can affected people influence the decision, retain their preferred way of expressing themselves, and reject an unsuitable function without penalty?

One number cannot answer these questions fully. A high overall compliance score can conceal a critical access failure; conversely, a low average can conceal specific supports that genuinely help particular people. Measurement is necessary, but it requires a justified selection of tasks and must not suggest false completeness.

3. What standards test, and what they leave open

For digital content, the Web Content Accessibility Guidelines (WCAG) 2.2 are an important technical reference. The W3C Recommendation describes testable, technology-independent success criteria. At the same time, W3C points out that WCAG does not cover all individual needs of people with disabilities [2]. WCAG testing can structure important questions of perceivability, operability, understandability, and robustness. It does not decide, however, whether generated learning answers are substantively appropriate, whether a translation retains meaning in a particular course context, or whether a user can put forward their concern in their preferred form of expression.

Nor is a product declaration automatically a use test. A supplier statement can be the starting point for follow-up questions: Which version does it cover? Which functions and views were tested? With which assistive technologies, devices, languages, and tasks? Which problems remain open? Was only an automated scan conducted, or was there also manual testing with keyboard, screen reader, captions, and users? If the answer remains unclear, that is a procurement finding, not merely missing documentation.

Legal standards must likewise be read closely against the particular use. Directive (EU) 2019/882, known as the European Accessibility Act, has applied since 28 June 2025 to the product and service categories named in the Directive [3]. This does not mean that every internal AI application or every SME website automatically falls within its scope. The product type, service offered, user group, role in distribution, national implementation, and possible exceptions can be decisive. Anyone with a specific applicability or contractual question should refer the case, with product, purpose, role, jurisdiction, and date, to qualified specialists. A checklist or this article does not replace that assessment.

For small teams, the practical consequence is to describe requirements early, trace supplier statements back to specific evidence, and test real use. A standard is a shared starting point for verifiable minimum conditions. It is neither evidence of fair outcomes nor a substitute for feedback from people whose access route depends on the function.

4. Research provides specific warning signals, not universal judgments

Research on disability and AI brings two opposing risks into view: systems can make access easier, and those same systems can distort expression, evaluation, or control. Anyone who considers only one side builds a poor procurement question.

A study of automated and assisted communication had twelve people who use augmentative and alternative communication (AAC) try live suggestions from a language model in three scenarios: expanding short responses, answering biographical questions, and asking for support. Participants saw potential to save time as well as physical and cognitive effort; at the same time, it mattered to them that suggestions reflected their own way of expressing themselves and their preferences [7]. This is not evidence that today’s language models are generally beneficial or harmful for AAC. The sample and tasks were limited. The finding is still an important design signal: less input must not automatically mean that the system speaks in place of a person.

Language itself is not a neutral surface either. A survey of 519 disabled people from 23 countries examined preferences for person-first and identity-first language. In this sample, 49 percent preferred identity-first language, 33 percent person-first language, and 18 percent had no preference [8]. This does not yield a universal rule for German, Turkish, or other languages; instead, it shows why suppliers and organisations should not assume that one respectful form always fits. Where possible and relevant, self-description, choices, and a clear correction route help. In translations, it must also be tested whether meaning and tone are retained and whether a model draws false conclusions about ability or intent from a short formulation.

A study using pretrained word vectors and Transformer models examined implicit bias in language about people with disabilities. Using a perturbation analysis, it found significant negative biases in the models examined [6]. This is a controlled finding about particular model families and testing methods, not a statement about every current AI product and not evidence that a particular organisational decision is discriminatory. It does, however, justify asking whether procurement tests only superficial keywords or also tests the effect of wording and changes in context.

In a participatory study of dialogue models, 56 disabled participants in 19 focus groups described a range of problematic representations that could not be reduced to narrow toxicity or slur testing [9]. Because this is a qualitative study, no frequencies for the overall population can be derived from it. It shows that harms can lie in interpretation, assumptions, and relationship, even when an answer sounds polite.

Taken together, these sources do not yield a blanket diagnosis that “AI is fair” or “AI is ableist.” They show which testing paths belong in procurement: Can a person control an outcome? Does their own voice remain recognisable? What assumptions are made about ability, assistance, or independence? For which specific tasks can the system reduce barriers, and where does it create new ones?

5. A fictional case makes the open question testable

A small continuing education company is considering buying an AI-supported learning portal. The system is intended to summarise course materials and answer questions about modules. Management expects shorter preparation times; instructors expect less routine work. The supplier shows a fluent text demo. Before purchase, however, there are no jointly agreed tasks, languages, assistive technologies, or success criteria.

The team does not begin by deciding whether the product is “inclusive.” It takes four learning tasks into the test: finding a summary, asking a subject question, comparing an answer with the course source, and reaching a human contact person when something is unclear. For every task, it tests several possible routes: keyboard rather than mouse, screen reader rather than visual orientation, captions or a written alternative to audio, clear rather than unnecessarily complex language, and, where the actual course provides for it, a tested language version alongside the main language.

An initial internal run finds that the answer field is easy to reach only with a mouse, that a heading in a generated summary is not marked up as a heading, and that the link to the source in the answer text is not easy to find. These are fictional test findings in the case example, not claims about a particular real product. The team now changes its procurement question: it does not merely request “accessible AI.” It requires a verifiable keyboard and screen-reader test for these specific functions, an accessible fallback option, the version of the software tested, and a process through which reported problems are fixed before a purchasing decision or documented as an open limitation.

The team also invites people who are familiar with the relevant learning tasks and access routes. Participation is voluntary, arranged accessibly, and paid. No one should have to disclose their disability in order to report a barrier. No one stands in for an entire group. The claim remains open for tasks not covered; the small group provides learning indications, not a claim of representativeness.

6. The in-house F v5 turns “is it fair?” into a better question

The F v5 Question Expansion model works in the fixed order A→B→D→C. In the article, it changes the procurement decision instead of appearing as a mere list of stages.

A – Context: clarify input and terms. The starting question is: “Is this AI learning portal fair and accessible?” A examines what “fair” and “accessible” mean in the concrete learning process. Which course task is the portal intended to support? Where will it be used? Which languages, input routes, and output routes are actually planned? Who needs an alternative when a function fails? What benefit does the team expect, and what assumption is already embedded in the word “automation”?

A also marks which perspectives are missing. This is not an attempt to sort people by identity characteristics. It is the recognition that product teams cannot infer from their own use whether an access route works everywhere. When there is uncertainty, the team must identify tasks and access conditions, not add another adjective to the supplier questionnaire.

B – Alternatives: keep multiple explanations and options open. A good summary can make learning material more accessible. At the same time, missing structure can make navigation harder. A multilingual answer can make entry easier, yet distort technical terms. A short prompt can be efficient; it must not be read as evidence of low competence. A supplier statement can summarise genuine tests; it can equally omit a function the course needs. B keeps these hypotheses alongside one another rather than confirming the first one that fits.

For procurement, B produces a real alternative to a quick decision: not only “buy the product or do without it,” but, for example, limited test access, a different configuration, a non-AI alternative, or postponement until there is a verifiable fix. The hypotheses are test assignments, not assumptions about individual learners.

D – Feedback / Revision: organise follow-up questions and fallback. D determines which feedback is obtained, how it feeds back into requirements, and how missing experience of use is documented. The team provides easily reachable routes for feedback, enables use without disclosure of unnecessary personal information, and specifies who handles a problem. If a test shows that the design of a task prevents access, the specification is amended and tested again. If the accessible alternative is not yet ready, the manual course version is the fallback; it must not be treated as a personal failure of the affected person.

D also requires the limits of the test to remain visible. Was only one language tested? Was a mobile device omitted? Was there no test for a particular assistive technology? These gaps are recorded visibly. An absent finding is not a pass.

C – Test brief: record the tested final question, work assignment, and process trace. After A, B, and D, the procurement question in the case is: “Does Version X of the learning portal meet our predefined criteria for the four most important course tasks via keyboard, screen reader, the appropriate media alternatives in each case, and the planned language versions? Which problems, additional work steps, and open test gaps remain, and which conditions or alternatives are required before we buy?”

A specific F-C work assignment can read as follows:

Test Version X for the tasks [tasks] under the agreed conditions [devices, languages, and access routes] against the criteria [criteria]. Separate observed results, supplier statements, interpretations, and open questions. For each route, mark what has been tested, not tested, or remains open, and assign evidence with a date. Do not invent experience of use and do not infer ability or intent from brief input, disability, or assistive technology. Record barriers, additional work, feedback, and missing perspectives separately. For the subsequent K decision, prepare the options of purchase under conditions, limited pilot, postponement, or no purchase with the evidence needed in each case, a human fallback, a stop criterion, the responsible role, and a review date; do not make the procurement recommendation yourself. Do not claim general fairness, accessibility, or legal compliance on the basis of this test.

The process trace briefly documents how A narrowed the intended use and terms, B kept competing explanations and alternatives open, and D organised follow-up questions, participation, fallback, and revision. It separates evidence and interpretation, notes unresolved risks, and explains why the final question is narrower or different from the starting question. It also includes the responsible role, a stop criterion, and a date for re-testing.

F v5 connects its conclusion with a concise GROW plan: Goal – a traceable decision brief for the stated tasks; Reality – available evidence, current barriers, and untested use paths; Options – a supplier fix, limited pilot, different product, manual solution, or postponement; Will – who will initiate which test or change by when and return with what evidence. The plan makes the final question workable for the subsequent K decision step without anticipating a procurement recommendation.

The value of F is not that a better prompt guarantees truth. A removes ambiguity, B keeps possible explanations competing, D makes revision and fallback mandatory, and C translates the result into a testable procurement question. The answer may still be “do not buy yet.”

7. The K consultation model addresses the value conflict

F improves the question. The K consultation and governance model addresses how a team reaches an accountable, reviewable decision and makes the procurement recommendation in a value conflict. Its four-stage core cycle is Exploration, Reflection / Analysis, Decision / Recommendation, and Feedback / Evaluation. In the fictional case, these stages perform different roles.

In Exploration, the team describes the task, the people, the access paths, and the data. It records what the supplier has already evidenced and what has only been promised. It also looks at the existing non-AI solution: How is a question answered today, and which obstacle is actually removed by the new software?

In Reflection and Analysis, benefits, dignity, self-determination, linguistic and cognitive requirements, distribution of error costs, and opportunities for influence are weighed against one another. There is no neutral one-number solution here. A very short answer can help some people and deprive others of context. Automatic simplification can lower a barrier and at the same time erase a technical distinction. The guiding question is therefore not which group “wins,” but whether the proposal respects different routes, removes avoidable barriers, and discloses remaining conflicts.