Making Accessibility Accessible by Despecializing It
What is AriaML?
Aria Markup Language is a language derived from HTML, designed to bridge the structural gaps of the modern web by restoring the document's autonomy over JavaScript. It specifically addresses the following issues:
- Hyper-dependency on JavaScript: Interactivity and rendering optimizations now rely almost exclusively on third-party scripts.
- Incomplete coverage of ARIA patterns: There should be, as much as possible, a native HTML component for every Aria APG pattern. see Aria APG Patterns
- Tight coupling between CSS and the DOM: Style sheets are too closely bound to the structure, preventing CSS from being truly interchangeable across different websites.
- Massive data redundancy: Duplication of information across Meta tags, JSON-LD, and the DOM, without any native link between these three layers.
- Costly URI context switches: Complete and abrupt page reloads in the absence of complex Single Page Application (SPA) software optimizations written in JavaScript.
- Lack of semantic adaptability: Inability for a component to fluidly change its role based on the display context without script intervention (e.g., a heading morphing into a dropdown button to optimize space on a smartphone).
The DOM, Enslaved by JavaScript
By nature, HTML sits on the boundary between a document and an application. Initially, it is fully accessible and natively interactive (often referred to as Plain Old Semantic HTML).
However, while the HTML/JavaScript duo offers undeniable power, the intrinsic enrichment of the HTML language itself has been sidelined in favor of developing new JavaScript APIs. The DOM has ultimately become a puppet for scripts. Lacking native alternatives, developers frequently alter the behavior of strict semantic elements (for instance, hijacking an <h1> heading into a button), unintentionally breaking both the user experience and accessibility.
The ARIA (Accessible Rich Internet Applications) specification theoretically allows DOM elements altered by JavaScript to be properly exposed to assistive technologies. AriaML proposes a paradigm shift: moving the description of behaviors and accessibility directly to the language level.
About Accessibility
Why is web accessibility still an "obscure skill" in 2026? Industry efforts have focused on the evolution of JavaScript for several decades now. Yet, in 2026, the full set of W3C design patterns (the ARIA Authoring Practices Guide or APG) is still not natively covered by HTML.
Today, there are a million JS component libraries that all do exactly the same thing: reinvent the wheel to patch major semantic and interactive gaps. As long as a simple interaction requires dozens of lines of code, accessibility will remain the privilege of a minority of experts and will be ignored by the majority of projects. To solve this problem, we must understand how the history of the web has fractured the way we design interfaces.
Part 1: The Layout Trap and the Semantic Paradox of the Modern Web
The illusion of the dynamic document
CSS allows for this extraordinary thing of separating appearance from document structure. Let's look at how this induces formidable side effects.
In the early days of the web, the question of a divergence between the Accessibility Object Model (AOM) and the structural tree (DOM) did not arise. Both worlds were strictly merged. HTML was a linear document format: buttons were used to submit forms, checkboxes for binary choices, and links to change pages. There were no Single Page Applications (SPAs), no hamburger menus, no custom modal windows. Everything appeared in the actual order of the data stream, offering native robustness where each element possessed a precise location, a standardized appearance, a clear, predictable, and immutable role.
However, the evolution of CSS and JavaScript has split the user experience into two parallel worlds. On one side, modern CSS (Flexbox, Grid) allows for completely decoupling the visual order from the structure of the code. Visually, an element can be moved anywhere on the screen, but without corrections via tabindex, keyboard navigation and screen readers will still follow the initial and linear order of the DOM.
This is the classic layout trap: what is seen and what is traversed do not necessarily share the same order. To correct this, developers must inject heavy scripts to dynamically manipulate the tabindex attribute or manually move DOM nodes based on the screen size. The web is thus attempting to adapt a historically static document architecture to the graphic and dynamic requirements imposed by modern (visual) design.
The heresy of exclusive visual design
The dominant technical culture suffers from a major bias: designing "screen-first" (and often with a mouse). This paradigm drives the abusive and sterile use of neutral tags like <div> or <span> to build complex components (such as buttons or switches).
Yet, healthy software engineering practice consists of choosing the native tag with the most robust fallback solution. For example, if one wants to create a "Switch" component, the starting point based on semantic common sense is to use an <input type="checkbox">. Even if stylesheets or scripts fail to load, the box remains functional (checked/unchecked). The basic user experience is preserved: in the absence of JavaScript, the field's value will simply be updated via form submission instead of being sent via Ajax.
However, if we choose an element (fallback) whose role is distant from the destination component (example: moving from a span to a button), the gap widens. A button, a link, or a checkbox do not react the same way to keyboard keys (the Space bar, Enter, or arrow keys). Lacking declarative alternatives, the developer must manually code every missing event to close the gap between the semantics of the base element (fallback) and the behavior expected from its new role (e.g., behavior when pressing the space bar, type of action during a click, not to mention that the appearance and style must be consistent with the role).
The burden of the ARIA promise
To correct these gaps, the ARIA (Accessible Rich Internet Applications) specification was introduced as a semantic band-aid. But ARIA suffers from an inherent paradox: it forces the developer to manually maintain a "semantic promise" via JavaScript. ARIA essentially tells the developer: “You are allowed to change the behavior of a native element, but you must use my attributes to re-expose its semantics to assistive technologies, and you must code all the associated interaction logic yourself.”
This is where the model collapses under the weight of complexity. Due to a lack of time or specialization, code ends up littered with "bad ARIA" (attributes injected naively, without any underlying event logic).
Let us take a use case that has become universal: a responsive site displays a large block of information with a heading. On a desktop screen, the heading is static. On a smartphone screen, to save space, this heading (or its container) must, in certain designs, change its nature and become an accordion button (a dropdown trigger) capable of hiding or showing the underlying block. With the current state of technology, achieving this contextual mutation requires writing JavaScript to listen to screen dimensions, intercept clicks, toggle the aria-expanded state, dynamically alter the role, and manage focus.
We cannot, and must not, settle for a simple CSS hack. For instance, putting the heading inside a checkbox and using a sibling selector like input[checked].title ~ div {display: block;}. This is a solution that seems highly elegant when starting out because you believe you are breaking free from JavaScript: a theoretically legitimate intention, but one that ignores the principles and constraints of accessibility.
The conclusion is undeniable: the markup language has become dependent on a programmatic software overlay to ensure its own semantics.
Part 2: The AriaML Architecture or Responsive Declarative Semantics
Faced with this reality, we have two choices:
- Either we freeze the web in a static paradigm and abandon CSS and JavaScript (a return to the prehistory of the web),
- Or we finally give semantic and dynamic capabilities to the markup language itself. This is the goal of AriaML (Aria Markup Language), a fork of HTML designed to restore the document's autonomy and despecialize accessibility by making it purely declarative.
AriaML introduces an architecture that resolves the highlighted issues by eliminating the need for third-party scripts for basic structure and interactivity.
1. Behavior Sheets (.bhv)
To solve the problem of components that must change their nature based on screen size (like our heading becoming an accordion button on mobile), AriaML separates responsibilities. Just as CSS handles appearance via Media Queries, the Behavior Sheet handles semantics and interaction responsively.
These sheets use a syntax close to CSS but act exclusively on the dynamics of the DOM and the AOM. They allow linking elements together (natively defining that one element controls the expanded / collapsed state of another) and modifying the actual order of the DOM based on screen constraints. The discrepancy between the visual order and the keyboard navigation order disappears, maintaining perfect and automatic coherence without any focus manipulation scripts.
"Behavior sheets" are non-normative. By using selectors, you can create whatever interactive components you want. This is very practical if you need to inject these behaviors into a site from which JS scripts have been removed, without having to modify the templates.
2. Lifecycle and Navigation Integration
Common navigation patterns (Single Page Application, form transitions) and their associated accessibility criteria are integrated into the document's native lifecycle.
Removable zones are defined using the nav-slot attribute. Thus, when a user clicks a link or submits a form, AriaML handles the targeted and surgical mutation of the affected areas in a purely declarative way. During this URI transition phase, the document automatically toggles to the aria-busy="true" state, handles the inertia of unmodified areas, and intelligently repositions focus on the new content. Request payloads are reduced, CPU resources are preserved (no full page recalculation at every context switch), and screen reader accessibility is guaranteed by the rendering engine, eliminating the sometimes faulty behaviors of JS routers.
3. Unifying the Data Model and Semantics via XPath
AriaML eliminates the historical redundancies of HTML by removing obsolete concepts like the doctype, <head>, <body>, or duplicated <meta> tags. The entirety of the metadata and the state model of the document is centralized in a standardized data block in JSON-LD format (Schema.org).
To bind this data to display elements without relying on a JavaScript framework, AriaML resurrects and integrates the declarative concepts of XHTML's XForms module via the ref attribute. This attribute uses the power of XPath (a native technology available in all browsers since the 2000s) to bind and synchronize in real time the content of an element (or its value if it is a form field) with the underlying data model.
Here is an example of a valid, complete, and dynamically synchronized AriaML document:
<aria-ml>
<script type="application/ld+json">{
"@context": "[https://schema.org](https://schema.org)",
"@type": "WebPage",
"name": "Making accessibility accessible",
"description": "A manifesto for a declarative and resilient web."
}</script>
<h1 ref="name"></h1>
<p ref="description"></p>
</aria-ml>
The state model could serve as the basis for future reactive synchronization with the server (without JavaScript). This is under study (and you can contribute!).
Backward Compatibility, Security, and Resilience
Although AriaML behaves as a standalone language, it is designed to be perfectly backward-compatible and seamlessly integrate into the existing ecosystem:
-
Content Negotiation: On the server side (via a PHP SSR implementation), the server analyzes the
Acceptheader. If the browser natively supports thetext/aria-mltype, the raw document is sent to it. Otherwise, the server delivers the AriaML document encapsulated in a standard HTML container accompanied by an interpretation polyfill (in JavaScript - SIC). This same polyfill is available as a web extension. It allows the browser to receive thetext/aria-mlversion and process it even when JavaScript is disabled by the user. - Enhanced Security: By moving interaction logic and data synchronization into a declarative layer, AriaML makes JavaScript optional once again in most cases. This drastically reduces the browser's attack surface by limiting the execution of complex scripts, thereby eliminating the inevitable and common zero-day vulnerabilities tied to the complexity of JS engines, and restricting fingerprinting capabilities.
By taking accessibility out of the hands of scripts alone to write it directly at the declarative language level, AriaML despecializes it. It becomes once again a native and automatic characteristic of any web document, accessible to any integrator, designer, or junior developer. JavaScript can then finally find its original function: a non-intrusive progressive enhancement layer.
Top comments (1)
Pensez-vous que le HTML moderne a pris du retard en déléguant toute sa dynamique à JavaScript ? Comment gérez-vous les demande du design avec les exigences de l'accessibilité?