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