Meeting minutes
<jamesn> * [Proposal: do not follow aria-labelledby/aria-describedby into content-visibility:hidden](https://
<jamesn> * [Updated spec text to reflect the processing of hidden elements when c…](https://
[New Issue Triage](https://bit.ly/3rsQwlq)
<Greta> +present
jnurthen: accname 147. sounds more like html-aam
… scott, can you ask if html-aam covers what they are after?
aaron: I think this might refer to my proposal from a while back.
jnurthen: ok, sounds like we have an issue for that. so let's ask if they're happy with that.
… next: aria 1654
… assign to pkra
… next core aam 102, assigned to valerie
… next: aria 1653. document in dialog.
scott: don't think this needs spec update
… it's due to outdated advice
jnurthen: let's close it?
… [no disagreement]
… next aria 1651, roleDescription
scott: thanks for the responses. came from research on generic / paragraph. saw that nvda did something. I wanted to clarify the spec's intent here.
… make sure authors know what will (not) do something
jnurthen: aria 1649
scott: PR is there and approved.
jnurthen: next core-aam 101
carolyn: noticed this while looking at nameless forms. all other roles have special AX subroles. Not sure if it exists for real.
jcraig: I'll look into it. A bit of an enigma why it shows up in WebKitGtk, but not other areas of WebKit. Will look into it..
jnurthen: core-aam 100.
carolyn: can assign to me but needs relevant people on board.
joanie: maybe pull in people who consume it (e.g., NVDA)
[New PR Triage](https://bit.ly/3okOoKB)
jnurthen: aria 1652 remove reference to range
… seems editorial.
scott: changed to input type range
carolyn: will review
pkra: me too
jnurthen: aria 1650. purely editorial.
… aria 1648 spec prod issue.
[Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates)
jnurthen: next week: deep dive on hit point.
… I suspect nothing for Dec 16, so no new ones until new year.
[Figure out what to do with the DPUB mappings overlap with the ARIA Core spec, in the context of newer implementation differences](https://github.com/w3c/aria/issues/1643)
jnurthen: marked for deep dive. lots of activity. Anything to do?
jcraig: I think we need DPUB stakeholders there.
jnurthen: can wait until 2022?
jcraig: yes.
jnurthen: so let's organize deep dive next year.
Accname and hidden stuff - next steps?
jnurthen: we first had innerText proposal. Is that done and not happening? If so, what else?
bryan: unclear to me.
aaron: we're working to implement accessible name on hidden object without innerText.
jnurthen: will that be compatible with other platforms?
… are you implementing the spec?
aaron: was there any vagueness?
<jcraig> what is the issue number?
jnurthen: if not directly hidden, it would not expose child node.
jcraig: IIRC bryan wrote the PR, I edited that, aaron didn't like innerText, make proposal
https://
aaron: IIRC "doubly hidden" was confusing.
<jamesn> https://
aaron: it's not just me having an issue with innerText, right?
… it was a good way to get around the problem.
… but didn't really do what we wantd.
<jamesn> <div hidden><!-- everything beneath this is unrendered b/c html@hidden is implemented as display: none; -- >
<jamesn> <i id="desc">
<jamesn> This is a label.
<jamesn> <b>This should stay hidden because it's unrendered.</b>
<jamesn> <b hidden>This should stay hidden too. Unrendered from ancestor node, despite parent node being included by IDREF.</b>
<jamesn> <b aria-hidden="true">This should stay hidden too. Still unrendered from ancestor, so aria-hidden is redundant here.</b>
<jamesn> </i>
<jamesn> </div>
<jamesn> <input title="Field Name" id="test" aria-labelledby="desc" />
jcraig: an update would be good, maybe as implementation nears completion.
aaron: hopefully done by January.
jnurthen: example from issue.
byran: innerText might create discrepancies between visual and non-visual
I had some audio failure, please correct me, bryan.
aaron: there were some interesting edge cases, e.g., tooltip. useful but not common.
<jcraig> Commented in issue 57 "@aleventhal is working on a test implementation without innerText in Chrome, and will comment or update the PR (to replace the innerText reference in the current PR) once that's reasonably complete." https://
aaron: that shouldn't complicate things too much implementation.
bryan: e.g., you could hear the hidden tooltip but when triggered, hear the rendered tooltip.
aaron: would like to make it deterministic. When you want to hide something "no matter what" you need to use aria-hidden. That would allow authors to write it in a way that works.
jnurthen: ok. next steps: move implementation forward, feed back.
[Clarify how "otherwise interactive" relates to overriding the none/presentation role](https://github.com/w3c/aria/issues/1628)
jnurthen: we have a PR. cynthia approved. Can we merge?
… [no disagreement]
… do we need tests for this?
… we probably should've had tests before.
… so it's probably fine.
… [no disagreement]
joanie: as jcraig said not testable
[summary element role mapping](https://github.com/w3c/html-aam/issues/345)
<jcraig> no way to test for the removal of ambiguity... no tests required.
joanie: what do we do with this?
carolyn: what do platforms do?
scott: button role (mostly)
bryan: button.
melanie: what's the work to be done here?
jnurthen: hard to say. I feel like we need to get html mapping sorted.
scott: because it's mapped to button is some cases, it's not working correctly in some combinations
… but in other roles it behaves better.
… we either need a role for nested interactive elements (which is the problem here, but HTML hasn't liked it in the past)
… it's also currently broken on some platforms.
jcraig: VO seems ok. only one?
scott: pretty much. JAWS, NVDA with virtual cursor they won't enter into the summary because it's treated as a button so content isn't there. You can tab into it, then focusable elements can be interacted with. With Chrome, e.g., a text field inside it, hitting space bar to enter text will trigger disclosure functionality.
jcraig: how does a regular link in an aria button behave?
… if we can't implement this in an aria-button, we can change it.
carolyn: meta question: we never finished role parity. should we try again?
melanie: I'd be interested.
… had interesting conversations with developers around it.
jnurthen: we stopped b/c we haven't had requests to do more. would want to know more use cases.
melanie: I can try to get input.
… will look to give some examples
jnurthen: that would be very helpful.
joanie: besides generic, we have cases like ul and ol mapping to list role.
… I'd like really compelling case before having a role for every element.
scott: find out what is really missing.
jnurthen: some hard ones like audio/video
jcraig: also some from DPUB perhaps.
[clarify img naming steps](https://github.com/w3c/html-aam/pull/322)
jnurthen: we seem to have a gap we can't bridge.
… the data is interesting. 1% seems like a large amount.
bryan: images from frameworks often have bad titles.
jnurthen: how do we deal with more philosophic problems?
… if we can't agree, what do we do?
scott: webkit and chromium follow the spec.
jcraig: a mild preference to Jamie's approach.
scott: also know cases where alt is used to counteract title outside people's control
bryan: alt='' is equivalent to role=presentation, no?
jnurthen: "alt='' makes image presentation" has been a long standing guidance. if we remove it, it's significant.
jcraig: we're not really going back to it. aria-hidden is still there.
jnurthen: but change will expose a lot of content suddenly
rssagent, make minutes