Comment by mattlondon | Hacker News Reader

Comment by mattlondon | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com