– DRAFT –
aria WG

[New Issue Triage](https://bit.ly/3wyDMtO)

https://github.com/w3c/core-aam/issues/96

jamesn: Name and Description change events do not provide a mechanism for optionally cancelling the firing of these events when needed

jamesn: would need a spec change

joanie: would be some implementation impacts... if name changes aren't fired, the AT representations may get stale

jamesn: @@@ should be live region at that point

<jcraig> s/livr/live/

jamesn: transferring to ARIA repor in 1.4 milestone

aaronlev_: should find more use cases

https://github.com/w3c/aria/issues/1640

jamesn: "mixed state for aria-checked at option and treeitem?"

1.3?

mk: what is the scope of 1.3 vs 1.4?

jamesn: was just thinking small scope for 1.3, but I agree we shouldn't pile on. moving to 1.4

https://github.com/w3c/aria/issues/1636

jamesn: "Hyperlinks, scrollbars or pagination inside role=document"

soh: either 1.4 or closed? Need to re-review.

don't think it's a problem. but leave open in 1.4 for now.

[New PR Triage](https://bit.ly/3n2gnhh)

https://github.com/w3c/html-aam/pull/355

soh: hold off on review

https://github.com/w3c/aria/pull/1639

jamesn: "role=note fleshed out a little."

adding James Craig and Aaron as reviewers

jamesn: https://github.com/w3c/aria/pull/1638 is editorial...

https://github.com/w3c/aria/pull/1637 also editorial

[Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates)

another one re: "update spec text wrt hidden elements"?

Dec 2 is next open opportunity

mk: is this blocking an AccName release?

bg: need to finish some PRs before moving to next publish state...

jamesn: so not blocking

cyns: accname versioned or living spec?

jamesn: versioned... no current plan to make it living spec.

perhaps after re-charter approved... don't recall if that's one of the ones mentioned.

Dec 2 is sight tech global

<jamesn> https://github.com/w3c/aria/issues/788

Dec 9: aria-hitpoint #788 https://github.com/w3c/aria/issues/788

Holiday Meeting plans. No meeting Nov 25, 2021.

meeting on Nov 18, but not Nov 25

no meeting Dec 23 or 30th

Ali: APA next meeting on Dec 1... 10 EST (Pac 7 AM PST)

pronunciation deep dive

Avneesh Singh in Delhi may want to be there too.

<jamesn> close this item

Ali: keeping at 7 AM Pac, but we can delay the topic til 7:10 or 7:15

Also George Kerscher

[Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?)](https://github.com/w3c/aria/issues/1598)

<jamesn> https://raw.githack.com/w3c/aria/noEnumerated/index.html

<jamesn> https://github.com/w3c/aria/commit/05e3980f1dca08bc6491fa07f682d3645fb9d0b0

made a new PR (not yet linked) that replaces "enumerated" with "multi-value" etc based on feedback

<cyns> +1

would like feedback

jamesn: left in use of "enumerated" in a note that explicitly references HTML's "enumerated attribute"

<cyns> <dd>One of a limited set of allowed values. The default value is defined in each attribute's Values table, as specified in the <a href="#enumerated-attribute-values">Attribute Values</a> section.</dd>

jamesn: will add this to the PR for 1598

James: "Multi-Value Attributes"

<Jemma> https://www.w3.org/2021/09/draft-wai-glossary

<Jemma> https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#enumerated-attribute

[editorial discussion re: PR]

<Jemma> https://w3c.github.io/aria/#idl-reflection-attribute-values

to be continued on Slack

[Proposal: do not follow aria-labelledby/aria-describedby into content-visibility:hidden](https://github.com/w3c/accname/issues/146)

aaronlev_: content-visibility: hidden somewhat like display none, but if rendered before, doesn't throw away the rendering work for perf reasons

jamesn: MDN references not supported in Firefox and WebKit

<Jemma> https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility

<Jemma> see the bottom table for compatibility

aaronlev_: could wait for further update from implementors... Since in Chrome, we can prototype support and advise at a later date

[Clarify how "otherwise interactive" relates to overriding the none/presentation role](https://github.com/w3c/aria/issues/1628)

<div role="none" onclick="alert('Hello world');">Test</div>

<harris> jcraig: the text is "If an element is focusable, or otherwise interactive, user agents MUST ignore the presentation role and expose the element with its implicit role, in order to ensure that the element is operable."

<harris> jcraig: we've got a div with a role of "none" and a click event on it. It seems like this one is obvious that it should be interactive. Aaron came up with some examples of event delegation - we'd effectively override everywhere

jcraig:

<jcraig> https://www.irccloud.com/pastebin/ik53pKRG/

<jcraig> <div role="none" onclick="foo()">

<jcraig> <div role="button>button 1</div>

<jcraig> <div role="button>button 2</div>

<jcraig> <div role="button>button 3</div>

<jcraig> </div>

<jamesn> https://github.com/w3c/aria/issues/1628#issuecomment-961287860

aaronlev_: you don't want the toolbar in the example to be tab stop

jcraig: I think we could probably ignore any delegation.

<jcraig> <div role="none" onclick="alert('Hello world');">Test</div>

<cyns> what about <div role="none" onclick="alert('Hello world');">Test <b>me</b></div>

Matt: you have to know everything that is inside that element in the tree

jcraig: should we ignore the role of none in this case?

<jcraig> if we ignore all event delegation... should we ignore role=none on the same element with the handler if it is a leaf node?

Matt: if this is in the ARIA spec and we're talking about a very dom/html specific case...is this a matter of actually defining the term "otherwise interactive"?

jcraig: I don't think it is HTML-specific

jcraig: in the case of this div, we would just call it "clickable". We don't know what the div is

Matt: with VoiceOver on Mac, you see 3 things: you see the group, then you see the text, then the end of the group

jcraig: I don't think that is the case.

jcraig: a div with an aria-label might do that

Matt: I've observed it with no other properties other than it being clickable

<jcraig> matt is likely right

Bryan: We flag this kind of thing all of the time as violations

Matt: this is more of a recovery thing

jamesn: I'm a little concerned that we might end up exposing a ton of things that weren't meant to be exposed on web pages

jamesn: what about rolling it back to generic?

jcraig: that is fair. In the case of an image, it would effectively be exposed as "clickable"

comment from github: "Another case might be where the author has the same functionality available on a nearby widget, and doesn't want to expose it in the tree twice (e.g. there's a separate thumbnail and caption that you can click on)."

Matt: aria-hidden doesn't affect role=presentation. It takes precedence

jamesn: firefox exposes an image with a title on it even if it has alt=""

jcraig: that is because there is technically interactivity there - hover to get title tooltip

aaronlev_: aria-hidden is a fair point when we want to avoid redundant verbalizations

aaronlev_: unless a person can actually move to the element, I feel like it is a good time to respect the author

aaronlev_: I'm not sure the author would know why one would work and one wouldn't

jcraig: you've convinced me that we should not override the role on any element where event delegation may be used

siri: what is the default role for div

jcraig: generic

jamesn: the div was just an example. This could apply to many different things

Matt: we should continue this discussion next week

jcraig: let's get to this earlier in the call next time