What an Accessible AI Transparency Report Should Look Like
A transparency report can fail before a reader reaches its conclusions. The chart exists only as an image. The benchmark table loses its row and column relationships when read by assistive technology. The evaluation conditions are buried in a footnote. The model version appears in a filename. A keyboard user can open the page but cannot operate the interactive filters.
Every disclosure may be present. The evidence is still inaccessible.
An accessible AI transparency report should be a versioned, HTML-first evidence record that enables readers to find, perceive, understand, question, and reuse the basis for its claims. It should identify the system evaluated, the conditions of evaluation, the methods used, the results observed, the uncertainty surrounding those results, the limitations of the evidence, and the decisions the evidence cannot support. Charts, tables, downloadable files, and interactive elements need accessible equivalents. A technically conforming page is the baseline. The real test is whether a reader can independently determine what the report proves and where that proof ends.
Public disclosure is not the same as accessible disclosure
The need for better reporting is not hypothetical. The 2025 Foundation Model Transparency Index found that the average transparency score of evaluated foundation-model developers fell from 58 out of 100 in 2024 to 40 in 2025. The largest information gaps concerned training data, training compute, and models’ post-deployment use and impact.
That finding measures disclosure, not accessibility. A developer can publish more information while still making it difficult to locate, interpret, compare, or verify. A 90-page PDF may disclose more than a short web page and remain less useful to a screen-reader user, a policy analyst seeking one controlling fact, or a researcher trying to reproduce a result.
The distinction matters because AI transparency reports serve readers with different tasks. A model developer may need implementation details. A public administrator may need to know whether an evaluation resembles the proposed use. An accessibility specialist may need evidence about interface testing. A journalist may need to trace a claim to its source. A person affected by an AI system may need to understand its limitations and locate a route for correction or redress.
NIST’s AI Risk Management Framework describes meaningful transparency as access to information at an appropriate level for the role and knowledge of the person receiving it. NIST also cautions that transparency does not establish that a system is accurate, secure, private, or fair.
An accessible report must therefore do two things at once: preserve technical evidence and present that evidence in forms different readers can use.
Begin with the decision the evidence can support
Most weak transparency reports begin with a score. An accessible report should begin with scope.
The first screen should identify the system, model, or service being evaluated; the organization responsible for it; the evaluated version; the evaluation period; the report owner; the publication date; and the most recent revision. It should state the intended use being examined, the users and environments included in the evaluation, and the uses that remain outside scope.
The report should then give a bounded conclusion. That conclusion should explain what the evidence supports, under which conditions, and for which decision. It should also identify material unknowns.
“Model X achieved 87 percent” is not a decision-ready conclusion. The reader still needs to know what the denominator was, how examples were selected, whether repeated trials were performed, which model settings were used, what counted as success, how uncertain the estimate is, and whether the test resembles the intended use.
The original model-card proposal by Mitchell and colleagues called for documentation of intended uses, evaluation procedures, relevant conditions, performance characteristics, and contexts in which a model may be unsuitable. Its proposed structure includes model details, intended and out-of-scope uses, evaluation factors, metrics, data, quantitative analyses, ethical considerations, and caveats.
Those elements remain useful, but accessibility requires an additional question: can each reader find the element needed for the decision they are facing?
Build the report in layers without hiding the evidence
Plain language and technical precision are sometimes treated as competing goals. They are not. The conflict usually comes from forcing every reader through the same presentation layer.
The opening layer should provide an accurate summary of the evaluation question, the principal finding, the strongest limitation, and the decision boundary. Technical terms should be defined where they first appear. The summary should say “not evaluated” or “unknown” where evidence is absent rather than allowing silence to imply success.
A methods layer should expose the experimental conditions. For a language-model evaluation, this may include the model and system versions, access date, prompt or instruction format, sampling settings, evaluation dataset and version, inclusion and exclusion rules, scorer, number of trials, human-review process, runtime environment, statistical method, and known sources of measurement error. The level of detail will differ by evaluation, but the report should contain enough information for an informed reader to understand what produced the result.
An evidence layer should connect each important conclusion to its supporting results. Aggregate scores should be accompanied by condition-specific findings, variation across runs where relevant, unsuccessful cases, and uncertainty estimates appropriate to the method. The report should distinguish observed results from interpretations and recommendations.
A final artifact layer should provide the underlying material that can responsibly be released: machine-readable results, evaluation prompts, code or harness versions, data documentation, analysis scripts, and change records. These artifacts supplement the human-readable report. A CSV file is not an accessible explanation, and an accessible narrative cannot substitute for reproducibility evidence.
Stanford’s HELM Capabilities project illustrates the value of artifact-level transparency by exposing evaluation prompts and making results reproducible through the HELM framework. That depth is useful, although prompt-level transparency alone does not establish that the surrounding interface or documentation is accessible.
Make the evidence survive different ways of reading
For public-facing reporting, semantic HTML should be the default publication format. This is a design recommendation rather than a universal legal rule, but it has a strong practical basis: HTML can support headings, landmarks, reflow, browser magnification, adaptable presentation, links, and structured data without requiring a reader to download specialized software. UK government publishing guidance treats new PDFs as a last resort and directs publishers to provide an HTML version, while warning that PDFs cannot be made fully accessible to every assistive-technology user.
A PDF may still be useful for archiving, printing, formal submission, or offline access. It should be treated as a separate publication artifact requiring its own reading-order, tagging, language, title, table, link, alternative-text, and assistive-technology review. Exporting an accessible web page to PDF does not automatically preserve accessibility.
Within the HTML report, headings should describe the actual questions answered by each section. W3C guidance explains that semantic headings communicate page organization and allow browsers and assistive technologies to provide in-page navigation. Visual size alone does not create that structure.
Tables require the same discipline. Their row and column headers must be programmatically associated with the corresponding data cells. W3C notes that screen readers depend on these relationships to preserve context as a user moves between cells. A screenshot of a table has no such structure.
Charts should never carry the only copy of a result. Each chart needs a concise statement of its purpose, a text explanation of the material pattern, accessible labels, and access to the underlying values. Color should not be the sole means of distinguishing categories. When a visual shows a complex relationship, its alternative should explain that relationship rather than merely naming the chart type.
Interactive filters, expandable methods, tooltips, and result explorers must work by keyboard, expose meaningful names and states to assistive technology, preserve visible focus, and remain understandable when magnified or reflowed. A static alternative should be available when an interaction cannot be made reliably accessible.
The report should also withstand cognitive and linguistic barriers. Definitions should be concrete. Sentences should separate conditions from conclusions. Abbreviations should be expanded. Metric descriptions should explain what a higher or lower value means, what the metric omits, and why it was selected.
WCAG 2.2 provides the current W3C technical standard under the principles of perceivable, operable, understandable, and robust content. W3C also acknowledges that WCAG does not address every user need. Its cognitive-accessibility guidance is supplemental rather than a conformance requirement, and it recommends measures such as clearer language, predictable organization, personalization, and participation by people with cognitive and learning disabilities.
Accessibility therefore cannot be reduced to shortening the report. The better approach is layered precision: a clear path into the evidence, with deeper material available without changing the meaning of the conclusion.
The headline metric is a proxy
This is where the design problem changes.
At first, accessibility appears to concern format: headings, contrast, keyboard behavior, alternative text, and document structure. Those requirements are essential. Yet the deeper barrier in many AI transparency reports is epistemic. The reader cannot determine what the measurement means.
A score is accessible only when its construct is accessible.
Suppose a report labels a result “factual accuracy.” The reader needs to know whether the test measured atomic claims, entire responses, agreement with a reference answer, citation support, human judgments, or an automated scorer’s output. These methods can answer different questions. Presenting them under one familiar label can create clarity at the interface while preserving ambiguity in the evidence.
The same problem appears in subgroup reporting. A disaggregated result may seem transparent while omitting sample sizes, uncertainty, category definitions, missing groups, or the consequences of multiple comparisons. A latency figure may omit geography, provider load, response length, streaming behavior, or failure retries. An environmental estimate may omit hardware, grid assumptions, utilization, and whether it covers training, inference, or both.
The central requirement is therefore traceability. A reader should be able to move from a conclusion to the metric, from the metric to the evaluated examples, from the examples to the selection method, and from the method to its limitations.
Transparency is not the volume of disclosure. It is the reduction of avoidable uncertainty for a real reader making a real decision.
A template cannot guarantee a meaningful report
Standardized sections help authors remember what to disclose and help readers compare reports. They do not guarantee substance.
A 2024 analysis of 32,111 model-documentation records on Hugging Face found uneven informativeness. Sections addressing evaluation, limitations, and environmental impact had some of the lowest completion rates, despite the presence of model-card conventions.
This is a warning against equating a completed form with transparency. A report can contain a “Limitations” heading followed by a generic disclaimer. It can contain an “Evaluation” section without enough information to reproduce the test. It can name an intended use without identifying affected users or foreseeable misuse.
The original model-card authors identified a related limitation: the usefulness and accuracy of a card depend on the integrity of its creators. They argued that model cards should operate alongside other mechanisms, including independent audits, adversarial testing, and broader user feedback, because no document format can prevent misleading representation by itself.
An accessible report should therefore disclose authorship, organizational responsibility, reviewer roles, conflicts of interest, source ownership, and whether the evaluation was performed by the model developer, a customer, an independent evaluator, or a mixed team. These facts do not determine whether the findings are correct. They help the reader judge the conditions under which the evidence was produced.
Accessibility testing must include tasks, not only automated checks
Automated tools can identify missing labels, structural errors, contrast problems, and some invalid markup. They cannot determine whether the report’s central claim is understandable, whether a chart’s alternative conveys the right relationship, whether a technical definition introduces a new ambiguity, or whether a screen-reader user can efficiently locate the evidence behind a conclusion.
The appropriate test is task-based. Can a keyboard-only reader locate the report version and open the methodology? Can a screen-reader user identify the worst-performing condition without traversing an incoherent table? Can a magnification user follow a chart without losing its legend? Can a reader with cognitive or learning disabilities distinguish an observed result from a recommendation? Can a non-specialist determine which decision the evidence should not support?
Research on Interactive Model Cards reinforces the need for human-centered evaluation. Crisan and colleagues conducted a design inquiry involving 30 participants across expert and non-expert groups and examined how interactive documentation could help users explore model information. The study offers design evidence, not proof that one interface will work for every user or disability context.
Affected-user participation should be planned, compensated, accommodated, and documented. A report should state who participated, which tasks were tested, which assistive technologies and configurations were used, what barriers remained, and what the study cannot generalize. An organization should not infer disability status from behavior or substitute proxy reviewers for affected users while claiming inclusive validation.
State the exact standard, scope, and date
A statement such as “the report is WCAG compliant” is incomplete.
WCAG exists in several stable versions. W3C presents WCAG 2.2 as its current standard, while legal and procurement regimes may incorporate earlier versions. The revised U.S. Section 508 standards require federal electronic content to conform to WCAG 2.0 Level A and AA, and the federal document-testing baseline applies those requirements to non-web electronic documents.
For state and local government web content and mobile applications, the U.S. Department of Justice’s Title II rule uses WCAG 2.1 Level AA. An April 2026 interim final rule extended the principal compliance dates to April 26, 2027, for public entities with populations of at least 50,000 and April 26, 2028, for smaller entities and special district governments.
Those examples do not establish the obligations of every publisher. Applicable requirements depend on the organization, content, jurisdiction, contracts, funding, and use. They show why a transparency report must name the exact standard or policy version, conformance target, tested pages and artifacts, evaluation method, test date, evaluator, known failures, and exceptions. Legal review remains separate from technical accessibility evaluation.
Versioning matters outside accessibility as well. NIST currently states that AI RMF 1.0 is being revised. A report that says it “follows the NIST AI RMF” without identifying the version, selected outcomes, and implementation evidence leaves the reader unable to determine what was actually applied.
Accessibility does not require unlimited disclosure
There are legitimate limits to transparency. Publishing personal data, restricted datasets, security-sensitive implementation details, confidential contractual material, or instructions that create a credible misuse risk may cause harm.
NIST recognizes that transparency practices must account for resources and the protection of proprietary information. The responsible response is not to present withheld information as if it never existed. The report should identify the category of information withheld, explain the reason at a level that does not recreate the risk, describe how the material was reviewed, and state how the omission limits independent verification.
A public report may also be unable to expose full evaluation data because of licensing or privacy constraints. It can still disclose provenance, selection rules, dataset version, sample characteristics, exclusions, review procedures, and the consequences of restricted access.
Accessibility concerns the usability of evidence that can responsibly be disclosed. It does not create a duty to publish every internal record.
An accessible report is not a safety certificate
A well-designed report can clarify evidence. It cannot establish universal safety, fairness, reliability, legality, or fitness for every deployment.
That distinction should appear in the conclusion, not be hidden in boilerplate. The report should state which claims were tested, which were inferred, which remain disputed, and which require evidence from a real deployment context. It should identify adverse results and unresolved questions with the same visual prominence given to favorable scores.
It should also provide a correction path. Readers need a way to report inaccessible content, factual errors, broken artifacts, and disputed interpretations. Material revisions should receive visible version notes describing what changed and why. Older versions should remain identifiable where preservation is lawful and safe.
TAIRC’s Open LLM Transparency & Evaluation Frameworks program is explicitly scoped to evaluation, documentation, reproducibility, and public accountability. It does not train proprietary large-scale models, fine-tune commercial systems, deploy production models, certify safety, endorse vendors, or issue regulatory approval. TAIRC’s broader research portfolio likewise places evaluation before deployment and treats governance and open, non-exclusive dissemination as institutional commitments rather than claims of completed research.
Accordingly, the standard described here is a source-backed editorial and methodological recommendation. It is not a claim that TAIRC has completed an accessibility certification, released a transparency-reporting benchmark, or validated a universal reporting format.
The publication test
Before an AI transparency report is released, its publisher should attempt one final task:
Can a reader, using their own tools and without privileged access, determine what system was evaluated, under what conditions, which evidence supports each material claim, what failed, what remains unknown, and which decision the report cannot support?
The answer must come from the report itself—not from a private briefing, a developer’s reputation, or an unexplained score.
When that task cannot be completed, the report may be public. It is not yet accessible.
Sources and verification
World Wide Web Consortium, Web Content Accessibility Guidelines resources. Used to verify the status and scope of WCAG 2.2, the four accessibility principles, semantic heading navigation, structured table requirements, and the distinction between normative WCAG requirements and supplemental cognitive-accessibility guidance.
U.S. Access Board, Revised Section 508 Standards and ICT Testing Baseline for Electronic Documents. Used to verify the federal scope of Section 508, its treatment of electronic documents, the incorporation of WCAG 2.0 Level A and AA, and the September 2024 document-testing baseline.
U.S. Department of Justice, ADA Title II web and mobile accessibility materials. Used to verify the WCAG 2.1 Level AA requirement and the compliance dates extended by the April 2026 interim final rule.
UK Government Digital Service, “Publishing accessible documents.” Used to verify the official HTML-first guidance, the treatment of new PDFs as a last resort, and the limitations of PDF accessibility.
National Institute of Standards and Technology, AI Risk Management Framework and AI Resource Center. Used to verify NIST’s definitions of meaningful transparency, the limits of transparency as evidence of trustworthiness, the voluntary nature of the framework, and the current revision status of AI RMF 1.0.
Mitchell et al., “Model Cards for Model Reporting,” 2019. Used to verify the original model-card purpose, proposed reporting elements, intended-use and evaluation disclosures, and the authors’ warning that model cards depend on creator integrity and should complement other transparency mechanisms.
Crisan et al., “Interactive Model Cards: A Human-Centered Approach to Model Documentation,” 2022. Used to verify the 30-participant design inquiry and its investigation of interactive documentation for expert and non-expert users.
Liang et al., “What’s Documented in AI? Systematic Analysis of 32K AI Model Cards,” 2024. Used to verify the analysis of 32,111 Hugging Face model-documentation records and the reported gaps in evaluation, limitations, and environmental-impact sections.
Stanford Center for Research on Foundation Models, HELM Capabilities. Used as a named example of prompt-level evaluation transparency and reproducibility through a published evaluation framework.
Wan et al., “The 2025 Foundation Model Transparency Index.” Used to verify the decline in average developer transparency scores from 58 in 2024 to 40 in 2025 and the identified disclosure gaps.
TAIRC Research Categories and Research Portfolio. Used solely to verify TAIRC’s mission, program scope, organizational boundaries, and the distinction between planned research outputs and completed work.