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.

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.

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

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

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.

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? :)

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.

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?

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.

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

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

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.

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.

Accessibility helps everyone, not just disabled people.