Meeting minutes
New Issue Triage
bryan: role=group missing.
jamesn: scott added a comment, can it be dealt it in GH or do we need agenda+
added... may resolve before then
core-aam grid mappings
spectranaut_: I will update the mapping to reflect current browser behavior
spectranaut_: i'll review the issue
pkra: needs a definition tweak re: hierarchy
pkra: this came out of the other hierarchy PR. assign to me
pkra: similar hierarchy issue. I'll take it...
jamesn: core-aam aria-haspopup=true
spectranaut_: I'll work with the new contributor on this one
jamesn: open question.. agenda+
WPT-raised spec issue. agenda+
jcraig: okay to close
New PR Triage
New Issue Triage
New PR Triage
Editorial: add `<menu>` to `list` role
jamesn: scott, mel, and rahim to review
Issue198 - examples missing content
pkra: editorial
PR is a respec workaround
StefanS: editorial. ready for review.
jamesn: scotto and matt to review
"Updated instances of contradiction regarding focus management"
scotto: might as well review this one.. too I guess
jamesn: jcraig to review this one too.
"Fix AX API aria-haspopup mappings"
What labels does the ARIA WG want to use for WPT search results?
jcraig: we have 586 tests now \o/
jcraig: we have some tags "accessibility", "a11y", directories have labels
jcraig: maybe we should have a live version of "can I use"
jcraig: if there was a problem with part of the accname algorithm, we could have a specific tag for that area
jcraig: for now, since we are limited to role and label, we might not have a lot to label
jcraig: but we have some proposals for additions to webdriver/future testability
jcraig: so what labels would you all like?
<melsumner> plus one to adding labels by spec
jamesn: I think this all go back to how we imagine having something linked from the spec
jamesn: for example, this is all related to ...
jcraig: we do have a separate generic roles file, if we want to have per role, we need to break up the tests into separate tests
jcraig: tests can have multiple label, but they can only be applied at the folder or file level
jcraig: not the subtest level
jamesn: the only place it really makes sense to link from aria is at the role level
jcraig: we add stuff to it all the time, we didn't have css pseudo element stuff in all the browsers when we added it to accname
jcraig: what if we start by link the accname name computation to the tests?
jamesn: you know what would be useful, would be a way for repec to generate these links?
jcraig: ok we can file a respec issue, but its not a per spec basis, its more about parts of the spec
jamesn to file an issue against respec
jamesn: we don't have to had to hard code the links ourselves
jamesn: I'm going to protoype how we want this to look, and we can put the code in our aria libraries
jamesn: and after we have something working I will file an issue
scotto: I was going to ask about as I understood, do we want to split out individual roles for testing... I initially thought that was a good idea, and automated checkers would be interested in, we could show that aria-expanded had rubbish support, and then we could show the support was never there
scotto: a particular attribute might be useful on one role, but it is not actually properly implemented on another
scotto: seems like we should split out by role and test features by role
jcraig: obviously I didn't anticipate having a per role label
jcraig: I'll take an issue to double check that I can't do a label per subtest...
jcraig: if it is then we wouldnt need to split up those files, otherwise, we can split them up
scotto: if that ends up being the case maybe I can help split up the tests.. since I suggested it....
jcraig: just do the html ones O:-)
jcraig: more complicated roles already have their own file
jcraig: it doesn't matter if the tabgroup role doesn't work if the tab doesn't work, so come grouping does make sense
Rahim: I wanted to ask about the invalid role tests
Rahim: there is a utility function called "assignandverfiyrolebyrolename"
(scribe stopped minuting because its sort of technical/specific)
(to test writing utilites)
Valid use cases and patterns for aria-roledescription beyond 1.3
jamesn: maybe we should take a look at the PR right now, with the group
jamesn: pr aria 2022
jamesn: this is adding a single line
jamesn: with in aria-roledescription properties
we need to agree on this path forward if we are to do this
StefanS: implementations can be misused to mask the base role.
author doesn't usually localize the base role string
second reason, as soon as one AT decides to speak the base role, there is redundancy
e.g "button button"
Matt_King: i think this is an author misunderstanding of role description
<scotto> +1
purpose is for the times when the base role is not an adequate description of the element... (e.g. "pie slice" in the EDU)
StefanS: users are confused when authors misuse role-description
Matt_King: why not just use the label
Matt_King: if AT announces the base role, it breaks the purpose of role description
jamesn: on the fence. would be okay if there was an option in AT settings to always announce the base role on widgets or interactives
no reason to say "slide, region"
<melsumner> roledescription is meant to provide improved information, I don't agree that users should have access to it, and I think it would make the UX more confusing
StefanS: calendar example based on grid... "calendar" is insufficient to convey the use of a grid.
Matt_King: these are great examples where the author should not use role desc
Matt_King: I need to re-prioritize the APG section on role desc
if this is the opinion of the group (that role desc should never be used on grid) it's unclear
matt: not "never"
scotto: strongly agree that these are all author errors
<spectranaut_> jcraig: this is another example of a powerful tool that is useful and necessary, but also some tools are dangerous, like power tools -- dangerous is misuse -- in this case, if the author misuses the tool, the the user gets hurt. but if we could strongly recommend that AT always uses the base role, it would break the good uses of aria-roledescription
<spectranaut_> jcraig: these are all great examples of author errors, I don't think there is a spec issue
<spectranaut_> jcraig: as far as recommending an option for AT.... maybe an "AT may..."? but I think we may have removed all those. can't remember
<spectranaut_> jcraig: we have had the ability for native apps to overwrite role description for voiceover
<spectranaut_> jcraig: if they do it wrong we reach out to them to correct it
Jaunita_George: need APG examples
Matt_King: have 3 uses, but I will comment in the PR
mario: loc is an issue... usability is the other... If you've overriden the functionality queue (e.g. button is clickable), the use is confused
pkra: should we add another warning?
<scotto> agree with adding a warning. maybe even specifically call out the localization effort that would fall on authors, too
the name is confusing to authors... warning may help
<scotto> aria-toxic=you
<melsumner> TBH if we are going to warn users that this aria- could go wrong we should start adding it to other things ;)
<BGaraventa> Example of aria-roledescription as requested: https://