Accessibility and Inclusive Product Standard

Draft 0.1 — 2 August 2026
This standard is a product baseline, not a jurisdiction-specific accessibility opinion. Legal obligations may be broader, narrower, or differently framed depending on product, market, customer, and user.

Objective

ANUKA products should be usable by people with disabilities as a normal product requirement, not as a late-stage exception handled through support.

The governing rule is:

Critical participation, consent, identity, payment, support, governance, and exit flows must not depend on one sensory, motor, cognitive, or interaction mode.

Baseline target

For public web interfaces, the default target is:

WCAG 2.2 Level AA for complete supported user journeys.

Products must record:

exact WCAG version;
target conformance level;
pages, components, and journeys assessed;
technologies and assistive technologies tested;
known exceptions;
remediation owner and date;
date and reviewer of any conformance claim.

A partial component pass is not a full-page or full-product conformance claim.

Accessibility principles

ANUKA adopts the WCAG foundations:

perceivable;
operable;
understandable;
robust.

Products should additionally emphasize:

dignity;
equivalent access;
low cognitive burden;
user control;
compatibility;
recoverability;
plain language;
accessible support;
continuous improvement.

Scope

This standard applies to:

product web applications;
public Backstage interfaces;
browser extensions;
documentation;
consent and verification screens;
Passport presentations;
payment and sponsorship flows;
contributor tools;
governance interfaces;
AI-agent approval interfaces;
emails and critical notifications;
support portals;
mobile and desktop applications where used.

Critical journeys

At minimum, review:

discovering product purpose and status;
creating and recovering an account;
authenticating;
reviewing and partially approving a data request;
revoking access;
submitting feedback;
finding and accepting an opportunity;
submitting contribution evidence;
receiving a decision and appeal path;
making or refunding a payment;
viewing ledger or payout status;
approving an AI-agent action;
reporting an incident or barrier;
exporting data;
exiting or closing an account.

Accessibility ownership

Every product has:

accountable product owner;
accessibility lead or named responsible role;
engineering owner;
design owner;
content owner;
support escalation;
remediation owner for known barriers.

Accessibility cannot be assigned only to QA.

Design requirements

Structure and semantics

semantic headings and landmarks;
correct labels and relationships;
meaningful document language;
programmatic names, roles, and states;
lists and tables used appropriately;
status changes announced where necessary;
no visual-only structure.

Keyboard access

all interactive functions reachable by keyboard;
logical focus order;
visible focus;
no keyboard trap;
skip or bypass mechanisms;
dialogs manage focus correctly;
drag operations have alternatives;
shortcuts do not conflict without user control.

Visual presentation

sufficient contrast;
information not conveyed through color alone;
reflow and zoom without loss of function;
responsive behavior at supported sizes;
text spacing tolerance;
visible error and status states;
target sizes appropriate for touch and motor needs;
motion can be reduced or avoided.

Forms and errors

labels and instructions;
required state exposed programmatically;
error identification and suggestions;
preserved user input after recoverable failure;
confirmation for consequential actions;
no unnecessary repeated entry;
accessible timeout warnings and extensions;
predictable validation.

Content

plain language appropriate to the audience;
jargon explained;
link purpose understandable;
consistent navigation and help;
text alternatives for meaningful images;
captions, transcripts, or media alternatives;
no inaccessible image-only documents for critical information.

Accessible authentication

WCAG 2.2 adds accessible-authentication criteria addressing cognitive-function tests.

ANUKA products should:

support password managers and paste;
avoid blocking assistive tools;
provide an alternative to memory or puzzle tests where required;
support passkeys or other accessible options where practical;
avoid inaccessible CAPTCHAs as the only route;
make recovery accessible;
preserve security without imposing unnecessary cognitive tests.

Security and accessibility must be designed together.

Consent and data-request screens must:

identify the requester;
state purpose and duration;
expose each requested item;
permit individual selection;
show required versus optional items;
provide keyboard and screen-reader operation;
avoid preselected nonessential access;
communicate denial consequences accurately;
allow review before final approval;
support revocation without inaccessible navigation.

Data visualization

Charts and live activity views require:

text summary;
data table or equivalent detail where appropriate;
non-color differentiation;
readable labels;
keyboard access to interactive elements;
accessible update behavior;
alternatives for maps or animation;
no requirement to interpret motion alone.

AI interfaces

AI-generated interfaces and content must be reviewed for:

semantic correctness;
reading order;
label quality;
hallucinated instructions;
inaccessible dynamic updates;
voice-only assumptions;
complexity and ambiguity;
approval clarity;
alternative human route.

An agent must not autonomously declare accessibility conformance.

Browser extension requirements

The extension should support:

keyboard activation;
accessible popup and side panel;
screen-reader labels;
focus restoration;
sufficient contrast;
browser zoom;
reduced motion;
no interference with host-page accessibility;
clear permission explanations;
non-pointer route to all actions.

Injected UI must avoid breaking host-page semantics or focus behavior.

Documentation accessibility

Documentation should include:

logical headings;
descriptive links;
language metadata;
alt text;
accessible tables;
keyboard-operable navigation;
code examples with explanatory text;
no meaning encoded only through emoji or color;
downloadable formats only when accessible or paired with accessible HTML.

Testing model

Accessibility verification combines:

Automated testing

Useful for issues such as:

missing accessible names;
contrast candidates;
invalid ARIA;
structural errors;
form labeling;
some keyboard and focus issues.

Automation detects only a subset and cannot establish full conformance.

Manual keyboard testing

Test all critical journeys without a pointer.

Use supported combinations and record:

screen reader;
browser;
operating system;
version;
journey;
result.

Zoom, reflow, and responsive testing

Test large text, narrow viewport, orientation, and content scaling.

Cognitive and plain-language review

Review instructions, consent, errors, financial terms, and high-impact decisions for comprehension.

Testing with disabled users

Include compensated participants with relevant access needs where practical, especially for critical or novel interactions.

User testing supplements but does not replace standards testing.

Component library

Shared UI components should publish:

semantics;
keyboard behavior;
focus behavior;
ARIA use;
states and errors;
contrast tokens;
supported use cases;
prohibited compositions;
automated and manual tests;
known limitations.

Product teams should reuse verified components but still test complete journeys.

Accessibility conformance report

A report contains:

product and version;
WCAG baseline;
scope;
test environment;
methods;
criteria results;
known barriers;
severity;
workarounds;
remediation plan;
reviewer;
date;
next review.

Public summaries must avoid overstating scope.

Barrier severity

A0 — Cosmetic or minor friction

Does not prevent completion but should be corrected.

A1 — Meaningful difficulty

Creates extra burden or confusion for a group of users.

A2 — Critical-journey impairment

A critical task is difficult or unreliable without assistance.

A3 — Blocker

A user group cannot complete a critical task or obtain an equivalent route.

A4 — Harmful or high-impact exclusion

Can deny money, identity, consent, opportunity, legal rights, or safety-related access.

A3 and A4 barriers normally block general launch unless an effective equivalent alternative and approved remediation plan exist.

Equivalent alternatives

An alternative must be:

available without disproportionate delay;
accessible itself;
free of extra charge;
privacy-preserving;
capable of the same meaningful outcome;
clearly discoverable;
supported during relevant hours;
not dependent on disclosing disability unnecessarily.

A phone number that is rarely answered is not an equivalent alternative.

Accessibility exceptions

An exception record includes:

exact barrier;
affected journey and users;
severity;
reason;
current alternative;
evidence;
owner;
remediation plan;
expiry;
launch consequence;
communication.

Exceptions cannot erase the barrier from public reporting where disclosure is appropriate.

Feedback and support

Products provide an accessible way to report barriers.

The intake should capture:

affected page or feature;
task attempted;
assistive technology if the user chooses;
browser/device;
description;
desired contact method;
consent for diagnostic follow-up.

Do not require the user to prove disability.

Procurement and providers

Third-party services should be assessed for:

accessibility documentation;
conformance reports;
keyboard and screen-reader behavior;
issue response;
roadmap;
contractual commitments where material;
fallback or replacement options.

A third-party barrier remains a product barrier from the user’s perspective.

Releases and regression

Accessibility tests should run in:

component CI;
integration tests;
critical-journey test suites;
launch reviews;
periodic manual audits;
incident and user-report follow-up.

A release may be stopped for a material accessibility regression even when business metrics improve.

Metrics

Useful metrics include:

critical journeys with current manual test;
open A3/A4 barriers;
remediation age;
accessibility regression rate;
support response time;
percentage of shared components with documented accessibility contract;
test coverage by assistive-technology combination;
user-reported barrier recurrence.

Do not turn disability or accessibility needs into a user reputation score.

Public claims

Allowed examples:

“Critical web journeys were evaluated against WCAG 2.2 Level AA on 15 July 2026 using the documented test environment. Known exceptions are listed.”

Avoid:

“100% accessible”;
“ADA certified” without an actual recognized program and legal basis;
“WCAG compliant” without version, level, scope, method, and date;
implying automated tooling is independent certification.

Governance

Material accessibility decisions require:

accountable product owner;
accessibility expertise;
affected-user input where practical;
visible exception and remediation;
appeal or escalation for unresolved critical barriers.

Protected principles and user rights cannot depend on inaccessible interfaces.

Anti-patterns

accessibility at the end of development;
automated scan equals conformance;
overlay widgets as a replacement for fixing product code;
keyboard access without visible focus;
inaccessible authentication for security theater;
publishing inaccessible PDFs as the only policy source;
excluding disabled users from experiments;
requiring users to call support for every critical task;
hiding barriers from launch reports;
measuring accessibility only by issue count.

MVP acceptance criteria

WCAG 2.2 Level AA is the default public-web target;
critical journeys are listed;
ownership is assigned;
automation, keyboard, screen-reader, zoom, and cognitive review are included;
consent, payment, identity, support, and exit flows are tested;
A3/A4 barriers block launch unless a valid exception exists;
alternatives are equivalent and accessible;
public claims state scope, method, and date;
feedback intake is accessible;
regressions are part of release gates;
AI cannot self-certify conformance.

Sources

Verification record

Sources opened and checked: 2 August 2026
WCAG version: 2.2 Recommendation dated 12 December 2024
Default target: Level AA
Automated-only conformance claim: Prohibited
Disabled-user testing: Required where risk and novelty justify it