A somewhat common approach is to maintain a parallel DOM structure for accessibility and keep it in sync with the data structures driving the canvas view.

Genuinely asking, how do you make something like their map view accessible with so many objects and layers? I'd imagine you end up with a solution that exposes various content rectangles and ignores everything else, kind of how Google Maps does it.

This is a problem that turns up in Flutter when they compile for the web.

The long term answer is the Accessibility Object Model spec currently under development.

The current answer is to build a replica DOM structure for accessibility purposes.

Not all of accessibility is for those who cannot see (well). WCAG also has a bunch of guidelines for loss of dexterity and other ailments:

• keyboard support (being able to navigate to all controls as needed, not being stuck in a navigation island from which there is no escape with the keyboard, etc.)

• pointing device considerations (not requiring drag unless absolutely essential, no action on mouse-down, etc.)

• not requiring the simultaneous use of mouse and keyboard (e.g. via modifier keys)

• sufficient size for buttons and other pointer targets

• the ability to suppress animations, flashing images, etc.

• the ability to control colors and contrast of things on the screen

...

Of course, something like Photoshop, Illustrator, or the visual part of Google Maps is hard to use when you cannot see, but there are so many different disabilities that some or even most accessibility guidelines can apply to pretty much any software.

No action on mouse down? So we need to develop applications that you can't click? Is that really part of accessibility requirements these days?

There's a difference between mouse down and mouse up. A click needs both.

Oh is that why modern American software is almost unusable? Give me back my modifier keys and compact UIs

They are also letting down anyone who doesn't speak English, anyone who doesn't have a recent computer and decent internet, anyone who doesn't want to execute JavaScript in their browser… and even anyone who has no interest in making maps.

Not everything is for everyone, get over it.

Unless they have a legal requirement to provide product for disabled people, why would they care? It's a huge investment for very little output, unless this product is specifically targeted.

Accessibility helps everyone, not just disabled people.

This attitude is why sooner or later everyone ends up with legal requirements for disabled people.

Products are targetted toward people. Are the disabled not people? If you need an honest answer to "why would they care?", you need more help than can be provided here.

Tangential question: how does accessibility work in Google Docs after they've switched to canvas?

Or in Google Maps, which would be a much closer parallel?

While not directly related to your question, Google docs' switch to canvas broke my custom dark theme which I'd been maintaining for years, and several others were also using. This had been the main draw for me switching to Google docs in the first place and they took it away. I'd argue this is much less accessible as I can't use the product at night. Ironically, I feel like I've experienced more bugs after the switch than before

> Ironically, I feel like I've experienced more bugs after the switch than before

Not ironic, expected. When you do a refactor like this any good PM knows you’re creating a bunch of new bugs, and the ROI of the rewrite should consider this.

Unfortunately the way it goes most of the time is “ok, what if we’re really careful not to write any bugs? Then it’s all upside!”

…and now your dark theme is broken

There's an accessibility mode you can enable which provides keyboard and menu navigation, as well as audio cues. It's basically an alternative interface for interacting with the data layer.

I actually think this is a better approach to accessibility in web applications than trying to hang all of HTML+CSS+ARIA on the DOM. Check out Accessibility Object Model (AOM) for one spec proposal around this idea.

I've never used the product, but I did see this snippet in the article, which gives me a flicker of hope that the product does address some accessibility concerns:

> One particularly nice aspect of this system is that key presses follow the same flow as pointer events, which is not how things work in the DOM. In the DOM, you usually bind key handlers globally, and pointer events per element. But here, we get all the benefits of stopping propagation centrally, which is a real help for adding keyboard shortcuts and modifier keys.

The quote doesn’t seem particularly related to accessibility. Having keyboard shortcuts doesn’t by itself imply accessibility.

It's Flash Player all over again! Remember when SEO became important and everyone who had a Flash website had to make "low bandwidth HTML" sites for indexing? :)