Meeting minutes
New Issue Triage
New PR Triage
WPT Open PRs
jcraig: Giacomo, are you ready for me to merge the ones that are ready?
giacomo-petri1: one is not complete and requires further discussion
jcraig: I'll do that (merge the ones that are ready)
scott: The "figure-name-no-figcaption" (WPT #49647) needs review
Deep Dive planning
jcraig: no deepdives currently scheduled; what about the whitespace deepdive?
melsumner: the whitespace deepdive is waiting to be scheduled
[\[AriaNotify\] Naming for the priority property](w3c/aria#2333 )
alisonmaher: we discussed this one; some of the naming for the property is being discussed, e.g., using "high" or "low". I like the idea of "normal" and seen it used in other APIs such as grid. Curious what others think before we finalize those names
jcraig: sounds good to me
jamesn: does anyone object to "high" and "normal"?
scott: could there be confusion around what "normal" means (not an objection)
jamesn: similar concerns have come up around the "disabled" property
jamesn: if we're anticipating disagreement, could we use "default"?
jcraig: these are technical terms for "non-human constructs"; can have that discussion when it comes up. Visual descriptions such as "did you see the movie" are not usually problematic
<melsumner> FWIW I think I'm saying, have a prepped statement and respond with it, I don't think it's productive to engage in those kinds of conversations in this context.
jamesn: consensus has been reached on "high" and "normal" (see ARIA #2333)
Consider ariaNotify being named a more general accessibility notification in HTML/DOM rather than an ARIA-specific mixin in the ARIA spec
alisonmaher: James C. brought up several topics; one is the naming for ariaNotify that was discussed in an issue linked by Clay. I'm open to renaming it (e.g., ATNotify may be unclear whereas ariaNotify is easier to type). The other open question is where this should live; currently in the ARIA spec but maybe this should live in the HMTL spec
jcraig: I get the spelling point; why wouldn't accessibilityNotify be as clear as ariaNotify?
… I agree that ATNotify would be ambiguous. Part of the reason I mentioned it (not ariaNotify) is that you can use it for a number of things that don't leverage ARIA, or use it in another host language, or another HTML feature. Number of scenarios that aren't ARIA specific
<jamesn> acj aaronlev
jamesn: I voice support for accessibilityNotify rather than ariaNotify. ARIA is used for many things, and it would be nice if it was reserved only for ARIA
aaronlev: I agree with ariaNotify; people thinking about accessibility will link it to ARIA and then look that up. It's a branding thing
… I think this is closer to what ARIA does, which does something specifically for assistive technologies
Clay: ARIA calls out accessible rich [internet] applications; is it valuable to call out ARIA?
keithamus: ariaNotify exists in lieu of the higher level tools that we have yet found a way to express in HTML and CSS
jamesn: I don't have a strong opinion either way; happy to go with ariaNotify if that's the consensus
jcraig: Kate asked if it could just be "notify"; it may not be clear enough and people may think it's not for accessibility purposes. My feeling is still that accessibilityNotify is better
<StefanS> since ARIA is already a synonyme for screen reader support and acc is broader, vote is for ARIA
<keithamus> atNotify?
jamesn: how should we achieve consensus? People don't seem to have strong opinions. Does anyone object to sticking with ariaNotify?
Matt_King: ARIA here is a stand in for filling in a gap for assistive technologies. ARIA is more equal to AT than accessibility, so I'm kind of leaning towards ariaNotify since ARIA is a good stand in for AT
jcraig: I would agree that aria is the appropriate name, if it was a stand in for a temporary gap that we could solve for later. Every non-web platform has capabilities unavailable in web (e.g., custom views, notifications) and ariaLive is kind of like that
Matt_King: I understand the native applications of this; e.g., AX has become shorthand for accessibility but more AT-focused. Would that be better?
… my question is, instead of accessibilityNotify, how about AXNotify?
… it's shorter and AX is also more often associated with accessible experience, which is more associated with AT rather than generic accessibility
<Zakim> jcraig, you wanted to react to jcraig
<melsumner> +1 to referencing prior art if possible
<sarah> "AX" is something I associate with the Apple accessibility API specifically at this point
jcraig: (continuing previous comment) I can think of scenarios where this goes more broadly to just the specific AT case. Even in the AT scenarios, this could be rendered to braille, speech, on-screen; we could use this (API) to render a badge on screen. There may be some scenarios, such as speech UIs, maybe there's this other notification that could be triggered in other contexts outside of AT so I still think accessibility is a better fit
(accessibilityNotify)
StefanS: I've seen ARIA prefixed on other APIs and this term is established indicating AT/accessibility support. Maybe something else could be better
aardrian: I'm fine with the other suggestions, except AX. Some people think that it relates to a particular product (e.g., Deque axe)
Brett-Lewis: I wanted to vote for ariaNotify. I think ARIA is identified with making something accessible, and I think ariaNotify would be the most discoverable choice. It's become more synonymous with accessibility, maybe even more than accessibility
keithamus: if we could all agree that ariaNotify is the least worst of the options, that would be good for a standards discussion
jamesn: any objections to ariaNotify?
… the consensus is that we will go with ariaNotify (nobody objects)
keithamus: it certainly wouldn't be the HTML spec. It could live in the DOM spec but it would be confusing because there's no existing precedent for the kind of mappings that require ariaNotify to function (only ARIA and related spec which feel like the best place)
jcraig: because it's being named ARIA, it should be left in the ARIA spec. There are some scenarios in CSS where it mentions accessibility expectations (but not mappings)
jamesn: It can live in ARIA, but the DOM spec should reference it
keithamus: not necessarily, it can live entirely in the ARIA spec. Unlike ElementInternals, it's explicit in the ARIA spec already
jamesn: if someone is implementing the DOM spec in the browser, they should be aware that they need to do this (ariaNotify) as well
jcraig: nice thing about putting it in DOM/HTML/ECMA is that you'd get other non-accessibility reviewers and good questions can come out of that
dmontalvo: should it be in the main spec, or in a separate module. Will see how we go about doing that
jcraig: don't have a strong opinion but we could break out this mixin (interface), such as how the accname spec was broken out because of it's complexity
jamesn: now that we're using a monorepo, it's easier to make changes to ARIA-related specs
Tentative: update point E. Host Language Label of the Acc Name algorithm
jamesn: agenda+ was added for this last week
Bryan: seems to be there was confusion, different understandings as to what presentational elements do. My understanding is that presentational = nullified in the a11y tree and no longer exists. If this is the case, and an element that doesn't exist has a name, not sure what the impact is
scott: I was part of this discussion; my read is that making as presentational (role=presentation) is that role semantics are removed but does not move that other accessibility/HTML semantics are removed. Because it's marked as presentational, don't believe that everything about it (semantics) goes away
Bryan: if I take a tabbed interface, e.g., tablist, and have intervening elements between those roles, they disappear in the a11y tree. If it's not disappearing, what would that be?
aaronlev: the reason that `<label for>` would work, it registers that relationship for what we call the relation cache which stores relationships in the tree
Bryan: if you have an input that uses aria-labelledby and points to an <img> and the image has role="presentation", what is expected to be exposed
Matt_King: For your reading of the spec Bryan, what do you expect
Bryan: I expect that role="presentation" nullifies the element
scott: I don't see role="none" as nullifying the element
Matt_King: in the case that Bryan just mentioned, <img> with role="presentation" and alt="foo", we do remove the element from the accessibility tree?
<Zakim> jcraig, you wanted to mention implementation differences and to ask about using labelledby on hidden elements that are NOT host language labels
jcraig: Thanks Matt for recognizing that Aaron's comment was an implementation detail; it should be called from the spec and now what happens to be easy to implement. WebKit does have differences; WebKit a11y tree usually goes off render tree
… the question that I wanted to ask is, what would you consider in the identical scenario for this `<label>` element that is labelled by a `<div>` that is hidden. I would expect that it would not have a label in that scenario, so don't think that it's a host language element should be any different in that scenario
aaronlev: it's very important that aria-labelledby/aria-describedby work with hidden elements
jcraig: I was thinking of scenarios where people have the contents of something, e.g., child content that was either shown or not
aaronlev: with regard to the comment about implementation, yes; I agree that it shouldn't be the guiding principle if it doesn't matter that much in terms of the author/user experience. Helps to be pragmatic to what the world (others) have already done
Matt_King: the reason I brought this up is, if the spec language makes the user expect one thing but implementation is different, we should look at implementations to determine what needs to change (potentially in spec)
giacomo-petri1: in the issue, wasn't clear if element was referring to current node; I clarified that second element is referring to current node. Potentially, an author might mark an element as presentational because it raises presentational roles conflict resolution. The element is ultimately marked but not exposed as presentational
… I've already created the WPT test and it is linked in the issue (ARIA PR #2405)
scott: for additional context, with the original WPT test Giacomo made, I was confused because he was testing role="none" on the `<label>` element but I would have expected it to be on the `<input>`; we should test both sides to ensure consistency
Bryan: what is the action here?
jamesn: can look at merging PR as is, or if we want this behavior specified (or change it [in spec])
jcraig: for WPT test results, go to "Checks" tab
… there was a testing gap here; WPT interface doesn't require that you get return value for something that is not rendered. Need to continue expanding test surface
scott: one more thing to consider for examples like role="none" on `<label>`, in both cases role semantics are being overwritten. It would be good to know what people should expect (e.g., getting rid of accessibility mappings)
jamesn: isn't that up to the HTML spec to specify what happens?
<melsumner> +1 to what Scott just said
scott: this seems to be central confusion here and it should agreed what the expected behavior should be
jcraig: that's why many tests are .tentative so determine what's there, not put in an expectation that implementations should change
[\[accname\] Explicitly state UAs must ignore “aria-label” for slots](w3c/aria#2385 )
jamesn: I want to clarify that you reviewed it because we should be doing this. We need a discussion on if we think this is the correct thing to do (i.e., `aria-label` for slots)
keithamus: I've raised an issue on this because slots don't have a role
jamesn: Anyone that understands web components want to take this up?
jcraig: add me to the reviewer list
melsumner: I added myself to this; my understanding is that slots are equivalent to generic (role) so `aria-label` shouldn't work