Meeting minutes
<spectranaut_> remove item 8
[New Issue Triage](https://tinyurl.com/39cnyfep)
spectranaut_: a few issues from giacomo-petri
… #1981
scotto: raises an interesting quirk: since the title attribute can provide either a name or a description, in HTML you could use title but _not_ want it to be the accname
… I’ll take assignment
spectranaut_: will skip the next one
… #1973
pkra: can we transfer this to practices?
<spectranaut_> w3c/
spectranaut_: there’s already an issue there
jaunita_george: I’ll take a look
… I also have a question about #1948
… not sure what the call to action is
… it has a had a default value in the past, but do we not have a default in the newest spec?
spectranaut_: let’s agenda this
… #1971
<spectranaut_> w3c/
spectranaut_: #1972
pkra: let’s decide a milestone. 1.3 or 1.4?
spectranaut_: we’re trying to close 1.3, so let’s do 1.4
… we’ll agenda it later
… back to #1971
pkra: there’s parity for all users here: no implication of the context menu existing
scotto: yes, not sure what value this would bring
mario: yes, we have context menus on every object, every list, even in empty places, so this would not be helpful
spectranaut_: pkra, would you respond on this issue, and maybe close?
pkra: yes
spectranaut_: #184, core-aam
… seems straightforward
… last one, #1970
… scotto, I see you linked this to `aria-controls` issue
scotto: yes, we’ve discussed this before
spectranaut_: is someone working on language for that `aria-controls` issue?
pkra: needs input from an aom person
spectranaut_: the `aria-controls` issue was milestoned for 1.3 and this may just be a clarification
[New PR Triage](https://tinyurl.com/3z6dyvnx)
<spectranaut_> w3c/
spectranaut_: I’ve added scotto to review
CurtBellew: I’ll review as well
scotto: I’m a little worried that this emphasizes `aria-controls` too much
scotto: this doesn’t actually address the issue, let’s work on it offline
spectranaut_: #1977
spectranaut_: #1975
… scotto, you already reviewed
scotto: yep, this is a good correction
pkra: I’ll review
spectranaut_: #1965
… I left this in draft
… follow up from F2F discussion
… re: accessibility parent/child relationships
… there was some confusion over the definitions that sarah_higley added
… so I’d like some review of that
… and a new term was introduced: accessibility descendant
pkra: this is great
spectranaut_: I already added pkra and sarah_higely for review
scotto: I’ll review as well
Adam_Page: I’ll review also
[Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates)
spectranaut_: we have a deep dive planned for July 27
… summary role parity issue
… 2 weeks from now
… then we need to schedule a new one: use cases for aria-modal
<spectranaut_> w3c/
spectranaut_: we haven’t scheduled yet because we want to wait for aaronlev to be back
… so we’ll do that when he’s back
… any thoughts on either?
… nope
TPAC: Request for a combined meeting with APA on Accessibility Notifications.
spectranaut_: PSA: we got an email from APA that they want to collaborate with us on ARIA notifications
… would anyone like to attend that meeting remotely, and need to weigh in on scheduling?
<jaunita_george> I may have to attend remotely
spectranaut_: okay, stay tuned jaunita_george — there’ll be a draft agenda soon
[Could hyperlinks to the current page expose aria-current=page](https://github.com/w3c/html-aam/issues/494)
spectranaut_: scotto, this is yours?
… we talked about in triage a couple weeks ago
scotto: yes, I’d like to see if there’s any implementor interest in this
… seems feasible for Apple, at least
pkra: I think it’s JAWS that announces in-page anchor links as on the current page
… so, yes, this seems like a good idea
scotto: I mainly want this for links inside navigation
… those are typically already designed with a visual indication
… should be a simple change to the spec
… in html-aam for example, I’d add something like “if link contained within an element with role nav and link URL matches href attribute, then implementers SHOULD expose the hyperlink as current page”
… I acknowledge that this can’t always happen, such as in SPAs
spectranaut_: needs review from jteh, jcraig, and aaronlev
pkra: this would be a wonderful example on the editorial side for AT guidance
scotto: I’ll come up with a proposed edit to the spec
[Discussion tracking for ARIA Notification proposal](https://github.com/w3c/aria/issues/1957)
scotto: is there anyone here who’d like to discuss this?
[Rethink how "hidden" is aria-hidden content?](https://github.com/w3c/aria/issues/1951)
scotto: we need more people to discuss this, there are strong opinions
… JAWS developers recently asked if there are any cases where they can choose to not prune some elements with aria-hidden
… so that they’re still empowered to do good error detection
… aria-hidden has been misused by authors
… inert exists now, and it successfully hides content from all users
… I don’t have a strong proposal here, this is just a conversation starter
spectranaut_: it’d be a little bit of a shift for browsers and AT vendors
scotto: this is kind of what aria-modal does
… outside of Webkit, aria-modal doesn’t actually remove content from the a11y tree
… it just informs the screen reader not to expose it while the user in the dialog
… there is precedent for this, in that some browsers do keep aria-hidden content in the accessibility tree but inform AT not to expose it
cyns: we can’t afford to forget about other AT besides screen readers, as well as screen readers that are less sophisticated than NVDA and JAWS
scotto: agreed
CurtBellew: it sounds like your proposal doesn’t necessarily break what’s out there, it’s more about informing the user what is hidden rather than eliminating it from their visibility altogether
scotto: the intent is to allow for sensible error detection for author misuse of aria-hidden
CurtBellew: inert hasn’t been around that long
scotto: yeah, only a year or so
spectranaut_: let’s continue this discussion later
<Zakim> cyns, you wanted to say we'd need to think through how this would impact other AT besides screen readers, and screen-readers that are less sophisticated than NVDA/JAWS and to say it's a big, deep change that will require a lot of thought and testing
1948
jaunita_george: was the default value for aria-atomic removed?
… it does still seem to be in the editor‘s draft
… so wanting to know if a change was discussed
scotto: this was something that Anne did in a PR a few months ago
… so, yeah, very recent — it’d be good to track down that PR
spectranaut_: which PR?
<pkra> 1894 ?
<pkra> w3c/
scotto: yep, #1894 is the correct PR
pkra: Anne removed that it *has* a default value since it’s a computed value based on its ancestors
jaunita_george: ah, it‘s a computed value — so then it will need to change in a lot of places
… so this should go into 1.3
… maybe we should explain it a bit better; how does it compute the value?