DDEHTML

Rethinking the Interactive Web

Presentation of the DDEHTML working group

Introduction

Modern web development is caught in a time loop. For a decade, we've seen countless JS libraries rise and fall, each promising to provide the "definitive" components implementing the ARIA Authoring Practices Guide (APG) patterns. Recently, this layer of complexity has simply shifted to the Shadow DOM via Web Components. The same problems are perpetually "solved" by new, supposedly modern techniques.

However, the basic observation is bitter: as long as we need JS for things as common and basic as a navigation menu, an accordion or a "slider", the structural dependency between HTML and JS will remain a chain that is far too heavy for the Web. If you do it with pure hacky CSS, it is declarative, but you loose accessibility. If you do it with JS you reinvent the wheel. "Recently", HTML give us new tags (details/summary + dialog). But the entire list of ARIA APG is not covered

It's time to break this cycle. The first idea that comes to mind is to invent new HTML tags. However, in many situations this is impossible without imposing something too prescriptive. This is probably why the HTML tag "carousel" doesn't exist. Therefore, we propose an intermediate approach. Like stylesheets, behavior sheets can describe the relationships, semantics, and behavior of HTML elements using rules and selectors. This is what the DARIA (Declarative Accessible Rich Internet Applications) extension offers.

The problem: The omission of "non-intrusive JavaScript"

We have collectively forgotten a fundamental web recommendation: "non-intrusive JS". Today, JS has become a default requirement, transforming even the simplest document into a potential application. Now, two paradigms are in opposition without a clear boundary: the Document (the domain of HTML) and the Application (the domain of JS).

Switching between the two should be a conscious action. In an ideal web, browsers should have a "Trust this site" dialog box to enable JS, explicitly signaling to the user that they are leaving secure document mode and entering application mode. Sites that absolutely require JS should announce this via a meta tag, justifying the need. This dialog box will be provided by the "Secured Mode" extension.

It is the prior enrichment of HTML by DARIA behavior sheets that makes possible this vision in which we can do without JS without penalizing the user experience for the most classic interactions.

This is not about replacing JS

There will always be use cases where JS (or other languages ​​like Java, Rust, WASM, etc.) is essential. For example, I won't be able to launch a game console emulator in my browser using purely declarative technology. That's why, in these situations, it's important for websites to be able to announce when and why they need JS.

For all other more classic situations, the goal of the DDEHTML group is to finally relegate JS to its rightful place: to be, as much as possible, optional.

The Roadmap

The working group's mission is structured around three key stages:

  1. Creating the DARIA declarative language for behavior sheets: The first step is to cover the majority of cases where JS is currently unnecessarily required. We need to design a language that allows us to resolve ARIA patterns (tabs, carousels, tree view, treegrid, window spiltter, tri state buttons...) in a non-normative way, as simply as editing a CSS stylesheet today (probably more simple).
  2. WebExtension and Native Implementation: Develop a WebExtension compatible with the most widely used browsers, packaging all DDEHTML extensions. Recommend that browser developers implement these extensions natively. The goal is for this behavior to work everywhere, from the latest popular browsers to text-based browsers like Lynx (for which we will also suggest implementation).
  3. Continuous standardization: Finally, the group's mission will be to regularly transform innovations commonly made in JS (or other languages) into a purely declarative layer, if they improve the user experience and can be carried into the "document" paradigm.

Conclusion

HTML should not remain a static description language dependent on a scripting language for even the slightest interactivity. By adopting Dynamic Declarative Extensions, we can build a more robust, more accessible by default, and more user-friendly web.

We invite all web stakeholders, developers, accessibility experts and browser vendors, to join this crucial discussion for the future of web standards.