Accessibility is still (mis)conceived as something a ‘designer’ is solely responsible for ‘designing’

Onscreen, it’s things like contrast, keyboard access, captions and labels and in the physical world it’s ramps or lifts.

Nobody’s going to claim that getting those kinds of things right isn’t crucial, but evidence is beginning to accumulate that’s showing that even getting all of them 100% right turns out to not deliver accessibility in many significant cases. [1][2]

Human functioning, condition, and situation is in a constant state of flux and contingency across people, places, devices and moments.

Therefore, any system designed to satisfy specific ‘disability accommodation requirement’s can still prevent a particular person from understanding, navigating or completing today’s task, simply because the factors affecting their condition produce a ‘combinatorial explosion’ of requirements that no simply defined ‘service adjustments and accommodations’ could ever guarantee to render a service genuinely accessible to all. [2][3]

This article calls the prevailing standards-and-adjustments model Accessibility 1.0 and proposes a completely new model referred to as Accessibility 2.0

Accessibility 2.0 is the proposed next layer:

Accessible foundations supplemented by and integrated with a missing, hitherto unspecified dimension:

User-directed and user-condition-and-behavior-responsive, contextual, reversible adaptation backed up by promptly provided human support when adaptation fails [3][4]

The argument is not that standards should be abandoned. It is that conformance supplies a necessary floor, while experienced accessibility, successful task completion and personal agency determine whether access actually exists. [1][5]

The newest evidence: automated adaptation can also cause harm

In July 2026, Wanscher, Lorensen, Shafiq, Moghaddam and Alipour tested user-side language-model repairs across twenty live websites. Their unverified changes produced 24 improvements and 20 regressions in 100 usable trials. [6]

Their central warning was unusually direct: “Conformance is not experience.” On already accessible control sites, fourteen trials improved measured outcomes while fourteen regressed them, demonstrating why adaptation needs a do-no-harm control. [6]

The same study’s verified loop detected all 57 seeded violations, returned no false positives, and rejected all 126 deliberately harmful candidates. Verification, reversibility and perceptual grounding therefore belong inside adaptive accessibility. [6]

Because this was a small, structured pilot using CSS-addressable measures and one evaluator, it cannot establish universal effectiveness. It does, however, empirically expose the danger of allowing unverified automation to rewrite interfaces. [6]

A standards-compliant phrase can still be meaningless

In June 2026, Rakesh and Wei reported that names such as “Read more” may satisfy accessible-name rules yet become unintelligible when screen-reader users encounter them outside the surrounding visual context. [7]

Their five-site pilot found substantial variation between learned and heuristic approaches, while their registered full study remained unfinished. The responsible conclusion is therefore a research question, not proof of a deployable solution. [7]

The example exposes Accessibility 1.0’s conceptual weakness: a component can pass its isolated rule while the relationship that supplies meaning remains invisible to the person navigating non-visually. [7][8]

Accessibility 2.0 would test comprehension in the interaction sequence, connect controls to relevant context, and let the user request clarification without abandoning the transaction or discovering specialist terminology. [3][7]

The web’s measurable baseline worsened in 2026

WebAIM’s February 2026 automated analysis of one million prominent home pages detected WCAG failures on 95.9 percent, averaging 56.1 detectable errors per page, 10.1 percent above 2025. [1]

Low contrast appeared on 83.9 percent of pages; missing alternative text on 53.1 percent; and missing form labels on 51 percent. Six recurring categories represented 96 percent of detected errors. [1]

WebAIM expressly cautioned that “absence of detected errors does not indicate that a page is accessible or conformant.” Automation can establish evidence of failure, but cannot establish complete accessibility. [1]

This evidence blocks two shortcuts. Organisations cannot skip standards because adaptation is coming, and they cannot declare success because a scanner reports zero errors. Both foundations and lived task testing remain necessary. [1][5]

Cognitive access makes static categories particularly fragile

On 5 February 2026, W3C’s draft Cognitive Accessibility Research Modules described needs involving cognition, learning, communication, neurodivergence, brain injury, ageing, mental health and temporary effects from illness, medication or anxiety. [2]

W3C also identified evidence gaps: inaccessible paywalled research, wide variation among impairments, reluctance to disclose disability, and usability samples over-reliant on university students. These limitations constrain confident universal prescriptions. [2]

The draft’s breadth matters because cognition is not a single setting. Memory, attention, language, emotional regulation and processing difficulty can intersect, fluctuate and intensify under pressure during consequential online tasks. [2][9]

A menu labelled “cognitive mode” would merely create another crude category. Accessibility 2.0 should instead offer task-specific choices: explain, shorten, pause, preserve progress, confirm meaning, or connect a person. [2][9]

The law already anticipates more than identical treatment

The Equality and Human Rights Commission’s statutory Code, updated 5 August 2026, says equal service “does not necessarily mean that service providers should treat everybody in the same way.” [10]

The Code explains three reasonable-adjustment duties for services: change a provision, criterion or practice; provide auxiliary aids or services; and alter physical features where the statutory conditions require it. [10]

Its treatment of anticipatory adjustment means providers should consider disabled people generally before a particular person encounters disadvantage. Accessibility 2.0 strengthens that anticipation, but cannot redefine the law or guarantee compliance. [10]

Legal duties remain jurisdiction-specific and reasonableness remains contextual. The proposed framework should therefore be treated as an evidence-led design model, independently reviewed against applicable equality, data-protection, safety and sectoral rules. [10][11]

WCAG itself is moving beyond a binary finish line

W3C’s 4 September 2025 WCAG 3 working draft described a user-needs-led structure covering foundational requirements, supplemental requirements and assertions, while warning that its developing material was not yet a standard. [5]

W3C’s accompanying 2025 briefing asked how guidance could cover more cognitive and low-vision needs, remain future-ready and avoid an “all or nothing, 100% pass/fail conformance model.” [5]

WCAG 2.2, published 5 October 2023, remains the current Recommendation and adds criteria addressing focus visibility, dragging alternatives, target size, consistent help, redundant entry and accessible authentication. [8]

Accessibility 2.0 should therefore extend, never displace, semantic structure, keyboard operation, alternatives, reflow and predictable interaction. Personalisation layered onto defective foundations simply moves defects into a more complicated system. [5][8]

Disability technology succeeds when disabled people shape it

The Royal Society’s June 2025 report combined literature reviews, international case analysis, workshops, focus groups, more than 800 disabled UK respondents and a representative survey of roughly 2,000 British adults. [3]

More than half of surveyed digital-assistive-technology users said they could not live as they do without it. The report nevertheless documented affordability, training, infrastructure, sustainability, obsolescence and data barriers. [3]

Its design conclusion was categorical: “Inclusive design (or ‘co-design’) practices are essential.” Disabled people should participate throughout development, receive accessibility information before launch, and see their post-launch feedback acted upon. [3]

That requirement changes Accessibility 2.0 from technology delivered to disabled people into infrastructure governed with them. Paid participation, accessible research materials and documented decisions should be programme requirements, not gestures. [3]

Personalisation is promising, but evidence remains early

Wickramathilaka, Grundy, Madampe and Haggag’s AdaptForge paper, revised 28 July 2025, reported developer and older-user evaluations of rule-based interface adaptations derived from explicit context-of-use models. [4]

The study supports feasibility and practical utility, not universal superiority. Its adaptations were created at design time for Flutter applications, so it does not validate continuous, autonomous changes across unrestricted live services. [4]

In February 2025, Chundury and colleagues proposed “softerware”: separating an interactive representation’s content from presentation so disabled users can personalise views without requiring authors to predict every configuration. [12]

Together these projects justify further testing of adaptable systems. They do not justify inferring impairment from behaviour, silently rearranging consequential interfaces, or claiming that generated alternatives preserve the author’s meaning. [4][6][12]

What Accessibility 2.0 actually proposes

First, build and maintain the standards-based foundation: valid semantics, robust keyboard access, labelled controls, alternatives, sufficient contrast, reflow, captions, error identification and compatibility with assistive technologies. [1][8]

Second, expose a plain-language request channel on every consequential journey. A person should describe the immediate barrier without naming a diagnosis: “keep my place,” “explain this question,” or “use fewer choices.” [2][3]

Third, respond through bounded adaptations chosen from tested components. Changes may simplify language, reduce distraction, enlarge targets, change modality, preserve progress or reveal context, while leaving purpose and legal meaning intact. [3][4][9]

Fourth, provide rapid human escalation when the system cannot adapt safely. Equality duties include auxiliary services, and W3C research identifies conversational, decision-support and wayfinding needs that cannot always be solved automatically. [2][10]

Adaptation must remain under the user’s control

Every adaptation should be offered, explained, reversible and easy to stop. The July 2026 browser-agent study made reversibility a design goal because generated changes sometimes worsened already accessible pages. [6]

Users should be able to save preferences locally, apply them once, or refuse memory entirely. A service should not require disability disclosure merely to enlarge text, reduce motion or receive clarification. [3][13]

The interface should distinguish user-requested adaptation from inferred assistance. Repeated errors may justify offering help, but not diagnosing cognition, emotion or impairment from cursor movement, typing speed or hesitation. [3][13]

For high-stakes tasks, the original content, adapted content and submitted answer should remain recoverable. That audit trail supports correction without forcing users to understand the underlying adaptation machinery. [6][11]

Privacy is not a secondary accessibility issue

The Royal Society identified privacy, bias, data minimisation, informed consent and equitable access as cross-cutting ethical concerns determining whether disabled people will adopt digital assistive technologies. [3]

Its report also warned that large datasets may under-represent minority groups, reinforcing patterns favouring non-disabled people. Context-specific small-data approaches offer promise, but the Society called them emerging. [3]

NIST’s July 2024 Generative AI Profile treats privacy, confabulation, harmful bias and human over-reliance as risks requiring governance, measurement and management across the system lifecycle. [13]

Accessibility 2.0 should therefore minimise collection, prefer on-device processing where practical, prohibit advertising uses, separate preferences from identity, publish retention periods and permit deletion without withdrawing ordinary service access. [3][13]

Physical and digital access form one journey

W3C’s October 2024 WCAG2ICT guidance explains how WCAG principles can apply beyond web pages to documents and software, including closed products whose functionality prevents users attaching assistive technologies. [14]

The Royal Society likewise recommended recognising smartphones as assistive technology, noting their roles in magnification, navigation, captioning, colour correction, speech-to-text and text-to-speech, while also documenting unequal ownership and connectivity. [3]

A theoretically accessible station application cannot compensate for absent mobile coverage, an unusable ticket machine or an obstructed route. Nor can a ramp repair inaccessible booking, payment or disruption information. [3][14]

Accessibility 2.0 therefore evaluates end-to-end journeys: discovery, booking, arrival, navigation, service, payment and recovery. Each stage requires an accessible default, adaptable information and a reachable human contingency. [3][10][14]

A proposed operating architecture

The first layer is invariant: standards-conformant content, stable semantics and tested assistive-technology compatibility. These features should survive personalisation because screen readers and other tools depend upon predictable programmatic relationships. [1][8]

The second layer is preference: explicit controls for modality, density, timing, language complexity, target size, distraction and help. W3C personalisation work supports machine-readable purposes and familiar symbols for such adaptation. [9]

The third layer is contextual assistance: the system notices friction and offers a bounded option, never an undisclosed diagnosis. Acceptance, rejection and undo must be equally accessible and must not obstruct completion. [3][6][13]

The fourth layer is service recovery: a trained person can view the user-approved context, preserve progress and complete an equivalent route. The user should not restart or repeatedly disclose the barrier. [3][10]

How the proposal should be tested

Conformance testing should combine automated checks, expert review and assistive-technology testing. WebAIM’s methodology confirms that machines detect only a subset, while Wanscher and colleagues show measured improvement can coexist with regression. [1][6]

Task studies should measure completion, errors, time, abandonment, comprehension, recovery and perceived control. Results must be disaggregated by functional needs and intersections, without treating one participant as representative of a diagnosis. [2][3]

Every trial needs a do-no-harm condition using already accessible journeys. Testing only broken pages can conceal unnecessary changes, while aggregate improvement can hide serious regressions affecting smaller groups. [6]

Research reports should publish dates, participant characteristics, recruitment methods, tasks, devices, assistive technologies, adverse outcomes and limitations. Disabled researchers and participants should help define success before data collection begins. [2][3]

Governance must be as adaptive as the interface

Organisations should assign accountable owners for foundations, adaptations, data and human escalation. Versioned change logs should connect each intervention to evidence, testing, approvals, complaints, reversals and unresolved risks. [3][6][13]

Procurement should require interoperability, exportable preferences, security updates, repairability and an exit route. The Royal Society warned that obsolescence and vendor discontinuation can remove essential functions from users’ lives. [3]

Complaint data should trigger investigation, not merely become another personalisation signal. Users need an accessible route to challenge an adaptation, correct stored assumptions and reach someone empowered to resolve the underlying barrier. [3][10][13]

Independent evaluation should examine distributional harm, not only average benefit. A system that accelerates most journeys while blocking a small group cannot call that group’s exclusion a statistically acceptable trade. [3][6]

What Accessibility 2.0 must never become

It must not become another overlay promising legal immunity. WebAIM’s 2026 results and the July 2026 agent study both show that automated intervention can miss barriers or create new ones. [1][6]

It must not force disabled people to surrender sensitive data, accept surveillance or train systems before receiving ordinary service. Such conditions would exchange one access barrier for another. [3][13]

It must not make important content endlessly mutable. Predictability is itself an accessibility need; adaptations should preserve meaning, transaction terms, navigation landmarks and the user’s ability to return to a known state. [2][6][8]

It must not remove human responsibility. When technology fails, an accountable organisation still owes an accessible service, a reasonable response and an effective route through the task. [3][10]

A more defensible definition of inclusion

Accessibility 1.0 asks whether prescribed features exist. Accessibility 2.0 additionally asks whether this person can complete this task, in this context, with control, dignity, comparable meaning and effective recovery. [2][3][5]

The evidence supports the direction, not the finished system. Personalisation can help; unverified adaptation can harm; disability data can illuminate needs; and the same data can reproduce exclusion or violate privacy. [3][4][6]

Accordingly, Accessibility 2.0 should be developed as a falsifiable research programme: publish hypotheses, compare outcomes, report adverse effects, retain accessible controls and abandon adaptations that do not improve lived access. [2][3][6]

The radical proposition is therefore disciplined rather than magical: standards as the floor, disabled people as co-designers, personal agency as the control, evidence as the judge and humans as the backstop. [1][3][6]

Sources and relevant reading for: Accessibility 2.0 Because Today’s Accessibility 1.0 Just Isn’t Accessible Enough

[1] WebAIM. The WebAIM Million: 2026 report on the accessibility of the top 1,000,000 home pages. Analysis conducted February 2026; updated 30 March 2026. https://webaim.org/projects/million/ In the Accessibility 2.0 document, this source is raised regarding the web’s measurable baseline worsening in 2026, the percentage of home pages containing WCAG failures and recurring error categories, automation’s limitations in establishing complete accessibility, the baseline requirements of the standards-based foundation, and how automated interventions can miss barriers or create new ones. These details are found in the main summary metrics and the recurring error categories sections of the WebAIM report, which outline the overall percentage of home pages containing detected WCAG failures and break down the specific frequency of low contrast, missing alternative text, and missing form labels.

[2] W3C Accessible Platform Architectures Working Group. Cognitive Accessibility Research Modules. Group Note Draft, 5 February 2026. https://www.w3.org/TR/coga-research-modules/ In the Accessibility 2.0 document, this source is raised regarding cognitive access needs and diverse user demographics, evidence gaps and limitations in university student samples, intersections of memory, attention, and language under pressure, task-specific choices instead of crude “cognitive modes”, plain-language request channels, conversational and decision-support needs requiring automated solutions, disaggregation of research results, and preserving navigation landmarks and user control. These details are found in the introduction and individual sub-modules (such as voice systems and online safety) detailing cognitive disabilities, diverse user demographics, research challenges, and user needs under pressure.

[3] The Royal Society. Disability technology: How data and digital assistive technologies can support independent, fulfilled lives. June 2025. https://royalsociety.org/-/media/policy/projects/disability-technology/disability-technology-report.pdf In the Accessibility 2.0 document, this source is raised concerning the integration of inclusive co-design and governance with disabled people, barriers like affordability and obsolescence, plain-language request channels, bounded adaptations and human escalation, privacy, data minimization, and informed consent, smartphone roles as assistive technology alongside connectivity barriers, end-to-end journey evaluations, service recovery and complaint handling, and ensuring technology does not remove human responsibility. These details are found across the report’s main findings, case studies, and policy sections covering co-design practices, digital assistive technology user surveys, affordability and obsolescence barriers, privacy, and end-to-end journey evaluations.

[4] Wickramathilaka, S., Grundy, J., Madampe, K. and Haggag, O. Adaptive and Accessible User Interfaces for Seniors Through Model-Driven Engineering. Submitted 26 February 2025; revised 28 July 2025. https://arxiv.org/abs/2502.18828v2 In the Accessibility 2.0 document, this source is raised for exploring rule-based interface adaptations derived from explicit context-of-use models, supporting feasibility and practical utility for seniors, and utilizing tested components for bounded adaptations while leaving legal meaning intact. These details are found in the introduction and evaluation sections of the paper, detailing model-driven engineering approaches, context-of-use parameters, rule-based Flutter application adaptations, and user evaluations with seniors.

[5] W3C Accessibility Guidelines Working Group. W3C Accessibility Guidelines (WCAG) 3.0. Working Draft, 4 September 2025. https://www.w3.org/TR/wcag-3.0/ In the Accessibility 2.0 document, this source is raised regarding the user-needs-led structure and avoiding an all-or-nothing pass/fail conformance model, extending semantic structures without displacing foundations, and defining inclusion by task completion and personal agency. These details are found in the draft’s structural overview and explanatory notes covering the user-needs-led framework, supplemental requirements, and the shift away from a binary pass/fail conformance model[cite: 1, 2].

[6] Wanscher, L.B., Lorensen, M.H., Shafiq, M.A., Moghaddam, M.T. and Alipour, M. From Blind Edits to Verified Repair. arXiv preprint, 26 July 2026; ICMI Companion 2026. https://arxiv.org/html/2608.24913v1 In the Accessibility 2.0 document, this source is raised regarding language-model repairs producing improvements and regressions on live websites, the danger of unverified automation and the necessity of do-no-harm controls, verified loops detecting violations, audit trails for high-stakes tasks, and demonstrating that automated intervention can create new barriers. These details are found in the pilot study evaluation and methodology sections, detailing language-model repairs on live websites, measured improvements and regressions, and the verified loop mechanism[cite: 1, 2].

[7] Rakesh, K. and Wei, S. Contextual Associations Between Webpage Elements for Web Accessibility: An Empirical Study. Registered report submitted 25 June 2026. https://arxiv.org/abs/2606.27506v1 In the Accessibility 2.0 document, this source is raised for insights into how isolated names like “Read more” can become unintelligible outside visual context, pilot findings on learned versus heuristic approaches, and Accessibility 2.0’s approach to testing comprehension within interaction sequences. These details are found in the pilot study and methodology sections analyzing contextual names like “Read more” and comparing learned versus heuristic approaches for non-visual navigation[cite: 1, 2].

[8] W3C. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, 5 October 2023. https://www.w3.org/TR/WCAG22/ In the Accessibility 2.0 document, this source is raised regarding current criteria for focus visibility, target size, and accessible authentication, maintaining backward compatibility and semantic structure, and preserving navigation landmarks. These details are found in the specification’s success criteria sections covering focus visibility, dragging alternatives, target size, consistent help, and accessible authentication[cite: 1, 2].

[9] W3C. Making Content Usable for People with Cognitive and Learning Disabilities. W3C Working Group Note, 29 April 2021. https://www.w3.org/TR/coga-usable/ In the Accessibility 2.0 document, this source is raised regarding intersecting cognitive needs, task-specific choices for cognitive access, and machine-readable purposes and familiar symbols for adaptation layers. These details are found in the guidelines and design patterns sections providing design recommendations for plain language, consistency, error prevention, and reducing cognitive load[cite: 1, 2].

[10] Equality and Human Rights Commission. Equality Act 2010: Code of Practice for services, public functions and associations, 2026. Updated 5 August 2026. https://www.gov.uk/government/publications/equality-act-2010-code-of-practice-for-services-public-functions-and-associations-2026/ In the Accessibility 2.0 document, this source is raised regarding statutory reasonable-adjustment duties, anticipatory adjustments for disabled people, legal boundaries and contextual reasonableness, and providing auxiliary services and human contingencies. These details are found in the statutory code chapters detailing reasonable adjustment duties, auxiliary services, and the legal obligations of service providers[cite: 1, 2].

[11] European Parliament and Council. Directive (EU) 2019/882 on the accessibility requirements for products and services. Adopted 17 April 2019; applicable from 28 June 2025. https://eur-lex.europa.eu/eli/dir/2019/882/oj In the Accessibility 2.0 document, this source is raised as a legal framework requiring independent review alongside equality and safety rules, and supporting audit trails for high-stakes tasks. These details are found in the directive’s main articles and annexes outlining mandatory accessibility requirements for digital products, services, and commercial operations[cite: 1, 2].

[12] Chundury, P. and colleagues. Towards softerware: Enabling personalization of interactive data representations for users with disabilities. Submitted 25 February 2025. https://arxiv.org/abs/2502.18348v2 In the Accessibility 2.0 document, this source is raised regarding separating interactive representation content from presentation to allow user-driven views, and supporting further testing while avoiding implicit impairment inferences. These details are found in the system design and evaluation sections detailing the separation of content from presentation to allow user-driven view personalization[cite: 1, 2].

[13] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. 26 July 2024. https://doi.org/10.6028/NIST.AI.600-1 In the Accessibility 2.0 document, this source is raised concerning managing privacy, confabulation, and human over-reliance risks across the AI lifecycle, prohibiting advertising uses of personal preferences, and governing contextual assistance without diagnosing emotion or impairment. These details are found in the profile’s risk management tables and lifecycle guidance addressing privacy, data minimization, confabulation, and human over-reliance[cite: 1, 2].

[14] W3C. Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT). Group Note, 8 October 2024. https://www.w3.org/TR/wcag2ict-22/ In the Accessibility 2.0 document, this source is raised regarding applying WCAG principles beyond web pages to closed products, documents, and software, and evaluating end-to-end service journeys. These details are found in the guidance notes explaining how WCAG principles map onto non-web software, documents, and closed hardware functionality[cite: 1, 2].

Footnote Zone for Accessibility 2.0: Today’s Accessibility 1.0 Isn’t Accessible Enough

Disclosure: The diagnostic tools referenced below were developed by NokNok, a specialist in online responsiveness tool design.

This Footnote Zone uses NokNok’s diagnostic toolkit to examine how the static compliance failures, overlay barriers, and rigid accommodation gaps described in this article can be identified, measured, and addressed.

Email Finder: Pair this tool with the trend of organizations hiding contact options, abandoning mailboxes, obscuring email access, or creating web-form friction when users try to report digital accessibility failures. Scans an organization’s website and related public-facing materials for published email addresses, then reports on structural deficiencies, discrepancies, missing contact routes, or other contactability gaps.

• Reply Radar: Pair this tool with the trend of plummeting response times, ignored messages regarding barrier removal, delayed replies, understaffed human accessibility queues, or unreliable customer-response operations. Deploys targeted test emails and quantitatively measures reply rates, latency, response consistency, and related responsiveness benchmarks.
• Compliance Sniffer: Pair this tool with the issue of automated “hallucination loops” in surface-level overlay widgets, empty compliance platitudes, degraded message quality, evasive responses from platforms claiming EAA compliance, or failure to meet basic communication and accessibility expectations. Analyzes incoming responses for objective quality, clarity, relevance, escalation, and compliance benchmarks.
• Mystery Shopper: Pair this tool with systemic user-experience breakdowns in static environments, aggressive gateway filters, obstructive forms, defensive user journeys, broken escalation paths, or end-to-end contact failures experienced by assistive technology users. Executes a comprehensive end-to-end responsiveness UX audit, testing how a real user experiences the organization’s contact, response, and escalation pathways.

Disclosure: The diagnostic tools referenced in this Footnote Zone were developed by NokNok, a specialist in online responsiveness tool design. ReplyResearch may use NokNok tools, resources, or analysis when preparing coverage, while retaining responsibility for its editorial decisions, including what topics to cover, what sources to cite, and how stories are presented. Read the full ReplyResearch Collaborative Disclosure Policy.