4 ms·

It's unfortunate that the web mode uses a canvas and won't work with native browser accessibility stuff. That was the show stopper for me last time I've tried i

by haolez 6y ago

It's unfortunate that the web mode uses a canvas and won't work with native browser accessibility stuff. That was the show stopper for me last time I've tried it.

yjbanov 6y ago
(disclaimer: I work on Flutter Web) We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.
- novok 6y ago
  How about stuff like being able to select text in the UI? I tried a couple apps in https://gallery.flutter.dev/#/ https://gallery.flutter.dev/#/ and none of the text was selectable like in web and desktop interfaces
  - leppr 6y ago
    Proper links and mapping of navigation to browser history are also important for any content-focused webapp. Keyboard navigation is incomplete too (some elements like dropdowns).
    - yjbanov 6y ago
      I hear you. There's a link widget coming, multiple browser history models (we've only supported URL fragments, but are adding pushState, and custom URL strategies, as well as navigation API improvements). Keyboard navigation is being actively improved. Bug reports are always welcome: https://github.com/flutter/flutter/issues/new/choose https://github.com/flutter/flutter/issues/new/choose
  - redbrogdon 6y ago
    Flutter's Text widget (which is generally the default for most devs when displaying text) doesn't allow for text selection. There's a SelectableText widget that does, though: https://api.flutter.dev/flutter/material/SelectableText-class.html https://api.flutter.dev/flutter/material/SelectableText-clas...
    - yjbanov 6y ago
      While Flutter makes text selection an explicit choice for developers, Text vs SelectableText, for some reason Text ended up being most used. This is likely because SelectableText came after Text and because of Flutter's mobile background. Most mobile apps use non-selectable text, and so this ended up on Flutter developers' default path. I personally expect this trend to continue, as in most desktop native apps text is not selectable either. In fact, in many web apps (those that are really _apps_, not just static web-sites) there's lots on non-selectable text. Case in point, I just checked Gmail's landing screen, and I failed to find a single piece of selectable text.
      - novok 6y ago
        Huh I never noticed that with gmail. I'm guessing it's because if I wanted to copy some sort of text, you could do it with the email detail page. And most text is selectable there, from the email name, actual emails, document content, etc. In mobile devices, text selection is such a pain so the desire to do it is less. Does selectable text have a performance penalty? In iOS UILabel is far faster to render than UITextView, but only UITextView is selectable. I wouldn't mind if many of my UILabels were selectable, but I'm forced by performance constraints to not let it happen. Maybe put forward making SelectableText the default and renamed to Text and Text is renamed to UnselectableText and becomes the non default if there isn't a perf penalty? It would need an automatic migrator for that to happen although.
realusername 6y ago
That has been worked on, they do use proper tags instead of a canvas so accessibility now works fine. The next issue is performance / scroll jank though and that will be tough to solve since the rendering model is very different from the web.
- K0nserv 6y ago
  I tried it briefly and no they don't? For example, pressing "f" with Vimium should enumerate things that can be clicked(think anchor elements and button elements) but it enumerates nothing on https://gallery.flutter.dev/#/ https://gallery.flutter.dev/#/. This is a pretty good proxy for accessibility too i.e. things that can be clicked look like they can be to the machine. A quick document.querySelectorAll('a') and document.querySelectorAll('button') in the console verifies that there are no such elements. Another one, basic browser features like backswipe on the trackpad to go back just doens't work. Custom user agent stylesheets is another accessibility/power user feature that will not work You cannot select any text as far as I can tell Reader mode doesn’t work, not even on the news demo which is a prime example of where it should work You cannot copy or preview link URLs You cannot copy image URLs Navigating by landmarks(such as headings) probably also doesn’t work(I haven’t tried this yet)
  - yjbanov 6y ago
    (disclaimer: I work on Flutter Web) Vimium is an interesting use-case. I've never heard of this extension. We have in the past enabled accessibility DOM all the time, but due to performance concerns changed it to be opt-in. If you use the standard screen reader (e.g. VoiceOver on iOS/macOS, TalkBack on Android, etc) you will get a way to enable accessibility DOM with ARIA tags, etc. Perhaps we should reconsider it (may need to optimize it a little though). I'd be curious whether Vimium works when accessibility is enabled. Some features you list we either should support or already do: backswipe (good feature request), text selection (use the SelectableText widget), links (in the works), image URLs (good feature request). Not sure what navigating by landmarks is, but perhaps something we could support too. Stylesheets are a non-goal. We do allow embedding plain HTML/CSS (called "platform view"), where you can use CSS, but Flutter's own widget system uses its own styling/theming. Reader mode makes sense for "documents" (think news sites, wiki, documentation, etc), but it's unlikely to work out of the box in dynamic apps (think email, calendar, maps, graphics editor, etc) which is the kind of apps Flutter is going for. There's a similar issue with Ctrl + F (Cmd + F) to find text on page, which is not helpful in dynamic apps. Dynamic apps are better off implementing their own app-specific "reader mode" and "search bar", one that takes the nuances of the app into account. But never say never, maybe that's doable too, perhaps using our accessibility tree, at least for static document use-cases.

by haolez 6y ago

It's unfortunate that the web mode uses a canvas and won't work with native browser accessibility stuff. That was the show stopper for me last time I've tried it.

yjbanov 6y ago

(disclaimer: I work on Flutter Web) We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.

novok 6y ago
How about stuff like being able to select text in the UI? I tried a couple apps in https://gallery.flutter.dev/#/ https://gallery.flutter.dev/#/ and none of the text was selectable like in web and desktop interfaces
- leppr 6y ago
  Proper links and mapping of navigation to browser history are also important for any content-focused webapp. Keyboard navigation is incomplete too (some elements like dropdowns).
  - yjbanov 6y ago
    I hear you. There's a link widget coming, multiple browser history models (we've only supported URL fragments, but are adding pushState, and custom URL strategies, as well as navigation API improvements). Keyboard navigation is being actively improved. Bug reports are always welcome: https://github.com/flutter/flutter/issues/new/choose https://github.com/flutter/flutter/issues/new/choose
- redbrogdon 6y ago
  Flutter's Text widget (which is generally the default for most devs when displaying text) doesn't allow for text selection. There's a SelectableText widget that does, though: https://api.flutter.dev/flutter/material/SelectableText-class.html https://api.flutter.dev/flutter/material/SelectableText-clas...
  - yjbanov 6y ago
    While Flutter makes text selection an explicit choice for developers, Text vs SelectableText, for some reason Text ended up being most used. This is likely because SelectableText came after Text and because of Flutter's mobile background. Most mobile apps use non-selectable text, and so this ended up on Flutter developers' default path. I personally expect this trend to continue, as in most desktop native apps text is not selectable either. In fact, in many web apps (those that are really _apps_, not just static web-sites) there's lots on non-selectable text. Case in point, I just checked Gmail's landing screen, and I failed to find a single piece of selectable text.
    - novok 6y ago
      Huh I never noticed that with gmail. I'm guessing it's because if I wanted to copy some sort of text, you could do it with the email detail page. And most text is selectable there, from the email name, actual emails, document content, etc. In mobile devices, text selection is such a pain so the desire to do it is less. Does selectable text have a performance penalty? In iOS UILabel is far faster to render than UITextView, but only UITextView is selectable. I wouldn't mind if many of my UILabels were selectable, but I'm forced by performance constraints to not let it happen. Maybe put forward making SelectableText the default and renamed to Text and Text is renamed to UnselectableText and becomes the non default if there isn't a perf penalty? It would need an automatic migrator for that to happen although.

realusername 6y ago

That has been worked on, they do use proper tags instead of a canvas so accessibility now works fine. The next issue is performance / scroll jank though and that will be tough to solve since the rendering model is very different from the web.

K0nserv 6y ago
I tried it briefly and no they don't? For example, pressing "f" with Vimium should enumerate things that can be clicked(think anchor elements and button elements) but it enumerates nothing on https://gallery.flutter.dev/#/ https://gallery.flutter.dev/#/. This is a pretty good proxy for accessibility too i.e. things that can be clicked look like they can be to the machine. A quick document.querySelectorAll('a') and document.querySelectorAll('button') in the console verifies that there are no such elements. Another one, basic browser features like backswipe on the trackpad to go back just doens't work. Custom user agent stylesheets is another accessibility/power user feature that will not work You cannot select any text as far as I can tell Reader mode doesn’t work, not even on the news demo which is a prime example of where it should work You cannot copy or preview link URLs You cannot copy image URLs Navigating by landmarks(such as headings) probably also doesn’t work(I haven’t tried this yet)
- yjbanov 6y ago
  (disclaimer: I work on Flutter Web) Vimium is an interesting use-case. I've never heard of this extension. We have in the past enabled accessibility DOM all the time, but due to performance concerns changed it to be opt-in. If you use the standard screen reader (e.g. VoiceOver on iOS/macOS, TalkBack on Android, etc) you will get a way to enable accessibility DOM with ARIA tags, etc. Perhaps we should reconsider it (may need to optimize it a little though). I'd be curious whether Vimium works when accessibility is enabled. Some features you list we either should support or already do: backswipe (good feature request), text selection (use the SelectableText widget), links (in the works), image URLs (good feature request). Not sure what navigating by landmarks is, but perhaps something we could support too. Stylesheets are a non-goal. We do allow embedding plain HTML/CSS (called "platform view"), where you can use CSS, but Flutter's own widget system uses its own styling/theming. Reader mode makes sense for "documents" (think news sites, wiki, documentation, etc), but it's unlikely to work out of the box in dynamic apps (think email, calendar, maps, graphics editor, etc) which is the kind of apps Flutter is going for. There's a similar issue with Ctrl + F (Cmd + F) to find text on page, which is not helpful in dynamic apps. Dynamic apps are better off implementing their own app-specific "reader mode" and "search bar", one that takes the nuances of the app into account. But never say never, maybe that's doable too, perhaps using our accessibility tree, at least for static document use-cases.