Update: add mapping tables for customizable select #2369
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
jnurthen
requested review from
rahimabdi,
aleventhal,
giacomo-petri and
jcsteh
closes #2382 and is related to #2344 / #2369 This PR adds aria-valuetext as a supported property for the combobox role. the `aria-valuetext` definition is slightly updated to indicate that the attribute can be used on other supported roles. I'm not sure if we want to do any further updates to that section in this PR - or if that really should be handled in a larger PR to resolve #711
| it does not serve as a submit, reset, or generic 'button' type. Rather, | ||
| its purpose is directly tied to the rendering of a customized select | ||
| serving as the visible indicator/styleable node to serve as the | ||
| invoking element for the select's listbox popup. |
There was a problem hiding this comment.
Do you want to mention that the UA stylesheet applies interactivity: inert to this button, to ensure that this comment is true (modulo developer shenanigans)?
closes #2382 and is related to #2344 / #2369 This PR adds aria-valuetext as a supported property for the combobox role. the `aria-valuetext` definition is slightly updated to indicate that the attribute can be used on other supported roles. I'm not sure if we want to do any further updates to that section in this PR - or if that really should be handled in a larger PR to resolve #711
html-aam/index.html
Outdated
| <p> | ||
| The calculated role of the customizable `select` element's popup picker is a `listbox`, by default.</p> | ||
| <p> | ||
| If authors include invalid elements (according to the the `select` element's content model) as descendants of the `select` element, and those invalid elements result in accessible objects being present as siblings in the accessibility tree to the valid descendent elements of the select, then user agents SHOULD expose the popup picker with the role dialog in the modeless state.</p> |
There was a problem hiding this comment.
provide direct link to the select element in HTML, here
There was a problem hiding this comment.
For the "generic" button element (which is out of scope for this PR), should we label it as "button (with no parent select element)" or something similar? This would keep it consistent with similar scenarios and help ensure readers don't mistakenly stop here if they have a button within a select.
|
|
||
| <p class=note>Treating the picker as a `dialog` can help inform users that content beyond the expected elements of a `listbox` popup are present, as they can then inspect the content of the dialog with their assistive technology to discover such content.</p> | ||
|
|
||
| <p>See also <a href="#el-button-select-child">`button` element as a child of a `select` element.</p> |
There was a problem hiding this comment.
For better readability, should we move (or duplicate) the link to the 'button as a child of a select element' section closer to the second bullet point in the accessible name computation? It might help readers understand, for example, why an aria-label set on the button doesn’t contribute to the accessible name computation.
| <p> | ||
| The calculated role of the customizable `select` element's popup picker is a `listbox`, by default.</p> | ||
| <p> | ||
| If authors include invalid elements (according to the the `select` element's content model) as descendants of the `select` element, and those invalid elements result in accessible objects being present as siblings in the accessibility tree to the valid descendent elements of the select, then user agents SHOULD expose the popup picker with the role of `dialog` in the modeless state.</p> |
There was a problem hiding this comment.
Implementation requirements that depend on content model are unusual. Browsers typically don't include conformance checkers, so can't easily tell if the content model is being violated or not. What is the purpose here?
There was a problem hiding this comment.
thanks for pointing this out @zcorpan
the rational here was talked about a lot in open ui, but the high level gist is that since the parsing for select was changed to allow for anything, the role of the popup needs to let users know whether they're interacting with a version that follows the content model (and thus can be exposed as a listbox) or has elements in it which are important to make AT users aware of / doesn't follow the content model, and thus was decided to be exposed as a dialog to help surface this to users.
with that said though, i talked with @mfreed7 about this and we were thinking that to mitigate this explicit reference to the content model, we this can be updated to more overtly call out what HTML elements / allowed implicit roles will allow for the default role=listbox, and how the inclusion of others would result in the popup needing to be role=dialog.
Initial draft of select / button as child of a select mappings.
daniel-montalvo
force-pushed
the
select-select-button
branch
from
0208cd4 to
df2b946
Compare
Initial draft of select / button as child of a select mappings.
Test, Documentation and Implementation tracking
Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.