4 ms·

Disclaimer: I work at Google but not on docs. I thought docs was working? At least in Mac's voice over on a laptop. There's also a menu setting to turn on mo

by Tyr42 4y ago

Disclaimer: I work at Google but not on docs. I thought docs was working? At least in Mac's voice over on a laptop. There's also a menu setting to turn on more accessibility things. Not sure what that actually does though. But as of December VO could read the body text.

rektide 4y ago
There are ways to have some accessibility support, but still break absolutely every extension an accessibility user might want to use (already know/enjoy), by not having HTML/DOM. These efforts will, in some cases, have hacks & workarounds. The ARIA group is active building alternative imperative accessibility options for graphical systems. Every one of the folks involved ripping out the actual html web for their own developer-defined Canvas-powered stack realizes accessibility is a minimum legal requiremement. But it can still violate every norm & break every tool an accessobility user wants to use/has ever used, and tick this legal box. It can still be a nightmare hellscape for them. (It probably will be.) And we get much accessibility by default from having DOM/HTML. It's quite possible that these "Modern" un-web apps have accessibility options in the framework, but that many developers botch up or dont spend the time to use these accessibility options, or they use them poorly. There's plenty of A11Y/ARIA concerns sites should consider on the current web, and fail to do great. But the baseline can be ok, & the user can refine the site/experience (since it's html/dom)!!!! Whether the baseline did-nothing experience stays the same/gets better/gets worse for users (assuming they happen to have compatible a11y tools, per above paragraphs) on these "Modern" un-web apps is very TBD, and I tend strongly towards believing it'll be worse. And it wont be as malleable.

4 ms·

Disclaimer: I work at Google but not on docs. I thought docs was working? At least in Mac's voice over on a laptop. There's also a menu setting to turn on mo

by Tyr42 4y ago

rektide 4y ago
There are ways to have some accessibility support, but still break absolutely every extension an accessibility user might want to use (already know/enjoy), by not having HTML/DOM. These efforts will, in some cases, have hacks & workarounds. The ARIA group is active building alternative imperative accessibility options for graphical systems. Every one of the folks involved ripping out the actual html web for their own developer-defined Canvas-powered stack realizes accessibility is a minimum legal requiremement. But it can still violate every norm & break every tool an accessobility user wants to use/has ever used, and tick this legal box. It can still be a nightmare hellscape for them. (It probably will be.) And we get much accessibility by default from having DOM/HTML. It's quite possible that these "Modern" un-web apps have accessibility options in the framework, but that many developers botch up or dont spend the time to use these accessibility options, or they use them poorly. There's plenty of A11Y/ARIA concerns sites should consider on the current web, and fail to do great. But the baseline can be ok, & the user can refine the site/experience (since it's html/dom)!!!! Whether the baseline did-nothing experience stays the same/gets better/gets worse for users (assuming they happen to have compatible a11y tools, per above paragraphs) on these "Modern" un-web apps is very TBD, and I tend strongly towards believing it'll be worse. And it wont be as malleable.