Hacker News Reader

Comment by simlevesque | Hacker News Reader

ctrl+f "accessibility" in part 2: zero results

ctrl+f "accessibility" in part 1: zero results

Does anyone care about digital access to content for disabled people ? Or about the ADA ?

Svg to canvas without any answer for accessibility is backwardness, plain and simple.

You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary or not and the older folks. Also screen translaters will not work on canvas.

Please follow the WCAG guidelines.

View on HN

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

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.

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

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.

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.

Reply on news.ycombinator.com