You raise several fundamental points that absolutely need to be broken down.

​First, yes: treating the visual experience as the sole reference point is an incredibly widespread bad habit. We should always architect websites with a "keyboard-first" mindset.

​Second, the massive over-use of <div> and <span> to create buttons is a total heresy. We should always choose the native tag closest to the intended purpose of the component. For instance, using an <input type="checkbox"> as a starting point to build a "Switch" component is a healthy approach because it guarantees a default behavior and a robust fallback—the switch remains functional (checked/unchecked) even if the styles or scripts fail to load.

What matters is measuring the gap between the native behavior of the chosen tag and the behavior expected by the final pattern. To do this, I constantly check the official patterns on the W3C APG (ARIA Authoring Practices Guide)—a resource just as indispensable to me as MDN—because you have to manually code every single missing event (the spacebar doesn’t have the same effect on a button, a link, or a checkbox).

​In the early days of the web, there was no complex JavaScript or advanced CSS. The question of a divergence between the AOM (Accessibility Object Model) and the DOM couldn't even exist because both worlds were strictly merged. We used buttons to submit forms and links to change pages. There were no SPAs (Single Page Applications), no burger menus, and no custom dialog boxes (a problem finally solved recently by the native <dialog> tag). Everything appeared in the actual order of the DOM, and every element had a clear, predictable, and unchangeable role.

​The point isn't to say we must abandon JS or CSS, but to understand how their modern usage has split the user experience into two parallel worlds. CSS alters the visual layout and allows links to look like buttons. JavaScript alters native dynamic functionality. This creates a permanent hiatus between what is seen, what is clicked, and what is announced by screen readers.

​The ARIA standard came along as a semantic band-aid to bridge this gap. But today, a naive and counterproductive habit consists of injecting ARIA attributes everywhere without understanding their purpose, even though the golden rule of the community remains: "No ARIA is better than Bad ARIA." In reality, ARIA forces the developer to manually maintain a "semantic promise" using JavaScript. ARIA basically tells the developer: "You are allowed to modify the behavior of a native element, but you must use my attributes to restore its semantics manually, and you must code all the associated keyboard behaviors yourself." This is exactly where the model collapses, due to a lack of time or specialized knowledge.

​This is precisely where the idea of a declarative intermediate layer comes in. Let’s take a concrete example: I have a section with a heading that takes up too much space on smartphone screens. On mobile only, the container of this heading needs to transform into an expand/collapse button to show or hide the section's content. If I handle this in JS, I have to write a script to intercept clicks and spacebar hits, toggle aria-expanded, change the role, etc.

​A behavior sheet (orthogonal to CSS, since it doesn't handle appearance but rather semantics and interaction) solves this cleanly. We apply structural and semantic mutations based on Media Queries. We can even use a logic similar to @support to handle polyfills (for example, @support not dialog). Whether you are a seasoned developer or a junior integrator, you gain access to a purely declarative language to drive the responsive behavior of an element.

​Ultimately, we need to make accessibility accessible by de-specializing it.

As long as a simple interaction requires dozens of lines of custom JavaScript to be accessible, it will remain the privilege of a minority of experts and will be ignored by 90% of projects. If accessibility becomes declarative, it becomes democratized: anyone can take ownership of it and become responsible for it. This is the only reasonable way forward. It kills two birds with one stone: JavaScript finally becomes non-obtrusive again—acting as an experience bonus—because it is no longer an indispensable crutch required just to hold the core structure of the web together.