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