4 ms·

I agree with the author that custom components don’t capture all the interaction details. Many times they are not accessible or cannot implement cross-platform

I agree with the author that custom components don’t capture all the interaction details. Many times they are not accessible or cannot implement cross-platform input well. However, I disagree with: > The browser’s built-in controls are quite sufficient. The problem is that browser components are good for simple forms but insufficient for other types of interaction. A good example is select. Using the select tag is the best way to have a dropdown list that’s accessible and supports mobile. But, select doesn’t cover most of the cases that you need for a complex app. Many of the WAI ARIA authoring examples (including the combobox patterns) are not covered by built in components. Interaction patterns like pop ups, dialogs, or lookup lists are quite common for an app… but hard to do in an accessible/cross-platform way. Web browsers need to do something different to support accessible/usable apps. The idea of leaving all those things to WebComponents makes sense, but the result is reinventing the broken wheel on each app.

nedt 5y ago
Oh the combobox element in the WAI ARIA is interesting. On mobile the dropdown can‘t be scrolled without scrolling the page (and the user losing where they were in the form). Also the tap targets are smaller. And there even is a combobox in HTML5. It‘s an input with a list attribute.
- extra88 5y ago
  Do you mean <datalist>? It doesn't meet all use cases (especially if what needs to be listed requires dynamic updating) but browser support slowly has gotten better. Unfortunately, I recently heard that all the major browsers fail to resize the datalist text on zoom (my guess is it's rendered outside the DOM, like the browser's UI). Bug report for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1756203 https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
  - bob1029 5y ago
    Datalist has some unfortunate UX quirks in my experience. Trying to view the list of available items after you have already selected one is not possible on the browsers I used this week. A select will allow you to view the list regardless of the current value.
mattlondon 5y ago
Yep I totally agree with this. There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/ https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly). I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?
- extra88 5y ago
  The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're best thought of as patterns designed to "exercise" a browser's support for ARIA attributes, browser developers can use them to test whether their implementation of ARIA support matches expectations. Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point. I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did. I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax). [0] https://open-ui.org/ https://open-ui.org/

nedt 5y ago

Oh the combobox element in the WAI ARIA is interesting. On mobile the dropdown can‘t be scrolled without scrolling the page (and the user losing where they were in the form). Also the tap targets are smaller. And there even is a combobox in HTML5. It‘s an input with a list attribute.

extra88 5y ago
Do you mean <datalist>? It doesn't meet all use cases (especially if what needs to be listed requires dynamic updating) but browser support slowly has gotten better. Unfortunately, I recently heard that all the major browsers fail to resize the datalist text on zoom (my guess is it's rendered outside the DOM, like the browser's UI). Bug report for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1756203 https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
- bob1029 5y ago
  Datalist has some unfortunate UX quirks in my experience. Trying to view the list of available items after you have already selected one is not possible on the browsers I used this week. A select will allow you to view the list regardless of the current value.

mattlondon 5y ago

Yep I totally agree with this. There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/ https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly). I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?

extra88 5y ago
The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're best thought of as patterns designed to "exercise" a browser's support for ARIA attributes, browser developers can use them to test whether their implementation of ARIA support matches expectations. Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point. I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did. I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax). [0] https://open-ui.org/ https://open-ui.org/