5 ms·

It's such a blanket statement to say "you can't". Those controls themselves are coded up mostly using JavaScript so it is defiantly possible. It just requires a

by msoad 5y ago

It's such a blanket statement to say "you can't". Those controls themselves are coded up mostly using JavaScript so it is defiantly possible. It just requires a lot of work. The most accessible component library that I've seen is Adobe Spectrum React[1] which supports all of those nuances mentioned here for all of their controls and allow for styling and customization. [1] https://react-spectrum.adobe.com/react-spectrum/index.html https://react-spectrum.adobe.com/react-spectrum/index.html

lkxijlewlf 5y ago
> ... defiantly possible In a lot of cases, yes.
lol768 5y ago
> supports all of those nuances mentioned here for all of their controls and allow for styling and customization I don't believe it. Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour. The invisible input field behaviour Drew mentions in the article doesn't work. If I hit backspace, my browser doesn't know I'm in an input field and (correctly) navigates me to the previous page. In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing. I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether. > It's such a blanket statement to say "you can't". It's a blanket statement, sure, but in my experience it's absolutely true and I don't know why it's always frontend JS developers who are arrogant enough to think they can reinvent decades of work on e.g. Gtk in their crappy UI controls library but it's quite tiresome. Spoiler alert: you can't and won't, stop trying.
- mattwad 5y ago
  Nor should we want to! I have spent a week trying just to make my forms screen-reader-friendly and it is very hard, especially if you're using a library already to build the components. But the reason I know it won't work is that all my changes look like weird hacks and are bound to be immediately broken by the next person to work on them that's not using a screenreader.
- jakelazaroff 5y ago
  > In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing. I just tried the link (in Firefox) and all of these work correctly. > I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether. What do you mean, "click in the empty space before a form control"?
- stereocodes 5y ago
  in both examples where you claim this doesn't work it worked for me. clicking on an empty space next to the form element and hitting tab focused correctly for me. Also tabbing then starting to type worked as well. I tested in FF and Chrome. Are you sure the options exist in the select box when you type? That would make it seem like type completion doesn't work. I Tried the checkbox and radio buttons example in FF and Chrome both auto select the field and using arrow keys to make options selected worked just like native. I think the error is somewhere between keyboard and chair.
- phh 5y ago
  > Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour. Took me exactly three key presses. I navigate using vimium. I just don't know how to pick anything on vimium without my mouse on this, while standard select work just fine.
badsectoracula 5y ago
I think the real issue here isn't if JS control can or cannot (they certainly can) but that even if they can, they still wont behave like the native controls because the native controls depend on the native platform. E.g. imagine if someone is using a modified Gtk library that uses vi-like shortcuts/modes for multiline text areas. This wont work on custom JS controls. Or something more likely, someone using macOS which, AFAIK, has text edit controls that understand some Emacs-like shortcuts. Even if you sniff their OS from the user-agent or whatever and use macOS-like keys, the user still wont get the text functionality exposes via, e.g. the Services menu. Of course at the end of the day you may not care about such details - or care but you consider other things more important or have other concerns/limitations for the entire underlying system.
Vinnl 5y ago
This is such a fantastic library. Gave me a far better shot at making my work accessible than I'd otherwise have.

by msoad 5y ago

lkxijlewlf 5y ago

> ... defiantly possible In a lot of cases, yes.

lol768 5y ago

> supports all of those nuances mentioned here for all of their controls and allow for styling and customization I don't believe it. Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour. The invisible input field behaviour Drew mentions in the article doesn't work. If I hit backspace, my browser doesn't know I'm in an input field and (correctly) navigates me to the previous page. In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing. I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether. > It's such a blanket statement to say "you can't". It's a blanket statement, sure, but in my experience it's absolutely true and I don't know why it's always frontend JS developers who are arrogant enough to think they can reinvent decades of work on e.g. Gtk in their crappy UI controls library but it's quite tiresome. Spoiler alert: you can't and won't, stop trying.

mattwad 5y ago
Nor should we want to! I have spent a week trying just to make my forms screen-reader-friendly and it is very hard, especially if you're using a library already to build the components. But the reason I know it won't work is that all my changes look like weird hacks and are bound to be immediately broken by the next person to work on them that's not using a screenreader.
jakelazaroff 5y ago
> In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing. I just tried the link (in Firefox) and all of these work correctly. > I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether. What do you mean, "click in the empty space before a form control"?
stereocodes 5y ago
in both examples where you claim this doesn't work it worked for me. clicking on an empty space next to the form element and hitting tab focused correctly for me. Also tabbing then starting to type worked as well. I tested in FF and Chrome. Are you sure the options exist in the select box when you type? That would make it seem like type completion doesn't work. I Tried the checkbox and radio buttons example in FF and Chrome both auto select the field and using arrow keys to make options selected worked just like native. I think the error is somewhere between keyboard and chair.
phh 5y ago
> Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour. Took me exactly three key presses. I navigate using vimium. I just don't know how to pick anything on vimium without my mouse on this, while standard select work just fine.

badsectoracula 5y ago

I think the real issue here isn't if JS control can or cannot (they certainly can) but that even if they can, they still wont behave like the native controls because the native controls depend on the native platform. E.g. imagine if someone is using a modified Gtk library that uses vi-like shortcuts/modes for multiline text areas. This wont work on custom JS controls. Or something more likely, someone using macOS which, AFAIK, has text edit controls that understand some Emacs-like shortcuts. Even if you sniff their OS from the user-agent or whatever and use macOS-like keys, the user still wont get the text functionality exposes via, e.g. the Services menu. Of course at the end of the day you may not care about such details - or care but you consider other things more important or have other concerns/limitations for the entire underlying system.

Vinnl 5y ago

This is such a fantastic library. Gave me a far better shot at making my work accessible than I'd otherwise have.