Comment by diegof79 | Hacker News Reader

Comment by diegof79 | Hacker News Reader

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.

Yep I totally agree with this.

There are however a bunch of ARIA tags & best practices etc (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?

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/

> 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).

Opera 12 does that. It predates ARIA, so it navigates based on the elements available at that time. Default keys (Tools → Preferences → Advanced → Shortcuts → Keyboard setup → Edit… → Input context and shortcuts → Document Window):

• a : Highlight next URL

• q : Highlight previous URL

• s : Highlight next heading

• w : Highlight previous heading

• d : Highlight next element

• e : Highlight previous element

I can mash the keys like crazy to get where I want. The browser is super responsive, keyboard navigation is a joy to use.

The browser also offers spatial navigation (Shift + arrow keys), this navigates interactables not by their functionality, but by their apparent position to each other.

The open-ui is only potentially good when you need something that resembles the standard controls and interactions. At the moment it only has a few controls specified and if you need anything not covered by those you are going to end up creating your own UI -- e.g. using a treeview dropdown instead of a listbox, or if you have a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user.

When you have custom UI, then you need to mark that up in a way that is accessible and implement things like keyboard navigation properly. No matter how many standardized UI elements you create there will always be cases where you need to use ARIA markup and not just for styling/theming, but for accessibility as well like in my form error example above.

The ARIA authoring practices is the best thing I know of that does that, along with other resources like www.a11ymatters.com for patterns like pagination.

If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns (disclosure, dialog, select, etc.) that works on all screen reader/browser combinations and documents all current features (ARIA, keyboard, dark mode, reduced motion, styling/theming, etc.). It should also include notes on what issues and resolutions to look out for, and details on what users of assistive technologies are looking for (e.g. when and what content should be read out).

You can (and should) have a set of common components that implement these patterns in a way that can easily be styled to handle 80% of the use cases. But there should also be a way to support the other 20% of use cases -- which is what ARIA was designed for.

>a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user.

ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, <fieldset>, and error messages should go where they make sense; the fieldset's <legend> is the name of the group but since it is repeated like a description after the name of each child input, it could be useful to add an error message to it.

> If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns

I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for. For example, their disclosure widget examples look okay (though in real life at least some of them should be just <details> <summary> elements) but their modal dialog example won't reliably keep screen readers from navigating to other parts of the page while it's open.

No one with the resources is willing to create and maintain a library of components, in part because it seems like there's not an 80/20 divide, that it's much more common that people need some variation from whatever is standard (or think they do).

There's https://a11ysupport.io for sharing user-submitted tests but that's simply a record of what individual ARIA attributes and HTML elements work with various assistive technology and browser combinations (without specifying their version numbers).

[0] https://www.w3.org/TR/wai-aria-1.2/#select

> ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, <fieldset>, and error messages should go where they make sense; the fieldset's <legend> is the name of the group but since it is repeated like a description after the name of each child input, it could be useful to add an error message to it.

Thanks for the fieldset tip.

> > If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns

> I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for.

Oh right. That makes sense. I use those as a reference point, not as something to use as-is. I mainly refer to the keyboard, role, and attribute specification in the main document, as they are clearly specified.

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.

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

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.

Reply on news.ycombinator.com