Compatibility for supported assistive technologies such as screen readers, braille devices, and screen magnification features, will not be impacted by the canvas-based rendering change. We will continue to ensure assistive technology is supported, and work on additional accessibility improvements enabled by canvas-based rendering
Flutter is (somewhat) accessible with the help of an alternate, hidden DOM, only provided if an "enable accessibility" button is pressed, for performance reasons. Unfortunately, some privacy zealots prevented web browsers from communicating that a screen reader was detected, so we need to press an extra button anytime we visit a Flutter app.
Google Docs has had two relatively good accessibility implementations for a long time, none of which relied on the original DOM, which was hidden from screen readers. The default one relies on pushing raw strings for the screen reader to speak, while the other one (called Braille mode, as the first method couldn't provide braille display compatibility), uses more modern APIs to provide the required information in the DOM, relying on special announcements only where necessary.
Have you tried using a screen reader with Flutter apps or the canvas-based Docs?
From the very first result on “Flutter accessibility”:
>> We strongly encourage you to include an accessibility checklist as a key criteria before shipping your app. Flutter is committed to supporting developers in making their apps more accessible, and includes first-class framework support for accessibility in addition to that provided by the underlying operating system
Enforced accessibility would be horrible. What if I want to make an application just for me? Or a game or something else where the basic concept isn't fundamentally accessible for blind people?
A lot of the open source software I release is for one reason and one reason only: it's useful for me. I generally try to make it a bit useful for others as well, but that's mostly just a nice bonus. I do care about accessibility in general (actually, I've been meaning to ask Matt about accessibility on CLI programs) but it's not really something I think about on these kind of programs, just like I usually don't consider most use cases outside of my own. If someone were to bring it up then I'd see if something could be done (like any other issue people bring up), but this depends on my available time and "if I feel like it" as well.
The alternative would be to never release it at all and keep it in my ~/code directory. I think that would be a loss.
> (actually, I've been meaning to ask Matt about accessibility on CLI programs
Assuming you meant me and not some other Matt, go ahead. In general, I'd say it's pretty hard to make line-oriented CLI programs inaccessible. Screen-oriented (e.g. ncurses-based) programs are, in my experience, harder to use with a screen reader, but still generally not terrible. Anyway, happy to answer any specific questions you have.
Some time ago I was drafting an article on CLI UX principles, and I wondered if there are specific a18y issues or annoyances that could be included. I couldn't find a lot of resources on this.
I do remember this old bsdtalk interview from years ago[1] about a Braille user, and what she said pretty much mirrors your comment: "CLI apps are usually really good, curses can be tricky". My feeling was that there wasn't much written about it because there's not much to write about: "it just works".
Still, there might be (small) things that might make a difference; as you pointed out in your other reply, it's hard for me to truly "experience" this. I thought it might be a good idea to check in with some people.
Your statement contains a misguided assumption that adoption of Flutter on the web explicitly breaks accessibility; it's no wonder that you didn't receive a response.
Under 15 employees, Title I does not apply to an organization's website.
Above that number, and, provided that it's part of the design phase, ADA Title I and/or Title III compliance can be achieved by ensuring that each element, attribute and operation is sufficiently tagged; this validation can be built into widget testing in the same manner as one might do for React components.
flutter and the canvas-based google docs are completely inaccessible