Meeting minutes
[New Issue Triage](https://bit.ly/3hmIANA)
<jamesn> https://
jn: very similar to issue 113 that we have already discussed and have consensus from prior mtg
this new issue may be worth keeping, the other was a discussion.
Leaving untriaged; unsure what milestone.
<jamesn> https://
Issue 1480 from last week's meeting
jn: sounds like possible in 1.3
jc: not strong preference
[New PR Triage](https://bit.ly/2RP1Ecx)
Deprecate aria-level on listem is a draft not ready for review.
<jamesn> https://
jn: Maybe put reviewers on list item deprecation so people are lined up when it is ready.
jc and cm volunteered
[Meaty topic for next week](https://bit.ly/3y8QboT)
jn: can't remember what is scheduled for next week?
Joanie: Is it related to divs with contenteditable or tabindex 0 and what accessible name should be
Is a div with no aria role and contenteditable a section?
What the implicit role should or should not be in those cases.
<jamesn> https://
Scott: can attend
Siri: GAAD next week and could be conflicts
jn: should we cancel next week's aria meetings?
Jemma: +1
<pkra> +1
jn: any votes against cancelling
scott: not sure about able to attend following week
jn: should we have a one offto discuss this contenteditable issue?
scott: contenteditable is not mapped consistently across platforms
<Jemma> "remap ‘no corresponding role’ elements (i.e., role=generic or inline generic-ish elements) to role=group if they have contenteditable or tabindex set."
There are 2 ideas of what to do.
One is to provide an implicit role so it could be named; div is name prohibited.
How do we expose div with contenteditable or tabindex 0 is added in a consistent way.
Any element in html can be given contenteditable attrib
It is a bit of a mess.
James: same thing with spans
I do not necessarily have to attend meeting on this; I am fine with most proposals from Scott and Joanie.
Slight preference for specifying a consistent implicit role for a generic with contenteditable.
mk: Could we have an issue where axync discussion can take place?
Joanie: this is no longer blocking name prohibitted.
jn: Let's punt it now then
scott: good with that
<jcraig> I think any of the options Scott and Joanie mentioned are fine... slight pref for <div contenteditable> getting an implicit role (e.g. "group" instead of "generic") because then it would no longer be name-prohibited based on the generic role.
n: no meetings next week.
Resolution: no meetings next thursday due to GAAD
[TPAC 2021](https://github.com/w3c/aria/issues/1482)
jn: TPAC in October
There are either 2 or 3 weeks of meetings
<Jemma> https://
Do we need need to have joint meetings with other groups?
Do we want to have ARIA meetings that we can invite a broader ayudience to?
<Jemma> https://
If anyone has ideas, please put them in this issue.
Is also useful if you think we should not have meetings, then please log that.
[Mappings for body and html don't seem to match reality](https://github.com/w3c/html-aam/issues/330)
jn: This is an issue from Joanie.
Mappings for body of HTML don't seem to match reality.
Joanie: Updating maapings to reflect reality could work; could be generic.
but then body with label is no longer permitted.
<Jemma> TL;DR: Everyone is essentially exposing html as the document (i.e. it's mapped). Most are exposing body as a generic child thereof -- except Firefox which is pruning it (causing the author's aria-label to be discarded).
There are chromium tests with aria-label on body.
Group needs to decide if label on body should be supported.
Scott: in camp that would say no label on body.
Only webkit on MacOS and Narrator on windows expose it.
JC: we should only disallow things that are known to be a problem. don't want to overly limit the API.
Scott: not sure that labeling a body is doing something well.
JC: not sure how labeling a body good be net negative
<jcraig> Clarifying a previous comment: WebKit is exposing "No matching ARIA role" not "group"
<sarah_higley> MK: coming from the perspective of aria-at, we should make sure everything should be testable with ATs. Then we'd need to expose the body, and that would be a net negative for AT users
mk: I think it would be a net negative b/c don't think we should expect AT to expose it.
<sarah_higley> MK: this is a real problem though, because if you label the body differently from the title tag, what the hell does that mean?
<sarah_higley> JC: I don't think we can talk about this in generalities, because in one app this might be a mistake, but in another it might make sense
<sarah_higley> MK: I think it's a net negative because we can label the entire page with the title tag. The body is already labelled via the title tag. I don't see how it's actually possible to add any value with aria-label, I can only see how it would be a negative
<sarah_higley> JC: if an author has provided multiple strings via aria-label on body, I'd think as an AT, you'd want to expose one or a combination to the user. So if we prohibit it, we'd be masking something the author has provided for the user
<sarah_higley> JN: so from my understanding, the body is not even exposed in some browsers, right?
<sarah_higley> scott: Joanie went through and found how it's actually being exposed, I did the screen reader tests, and yeah it's only in Safari on macOS and Narrator with Edge that anything's exposed. iOS, Android, Windows...
<sarah_higley> JN: with Edge Chromium, but not Chrome?
<sarah_higley> scott: I didn't try Narrator with Chrome itself, only Edge C. I only did NVDA and JAWS with Chrome and Firefox
<Jemma> issue 330 has all the testing results.
<sarah_higley> JN: in reply to James, the advantage of disallowing it is that validators can flag it as being an error.
<sarah_higley> JN: so we'd then given guidance to people that they'd done something wrong. And if it's allowed, we can't give that guidance
Joanie: Already q+
<Zakim> jcraig, you wanted to state my philosophical objection to overly complicated restrictive API
<sarah_higley> JC: I guess this is more of a philosophical objection to overly complicating restrictions on APIs. I think it's fine to call out a warning, so Authors SHOULD NOT, so then you can get that validation, though I think there's a lot of authors who would never see that validation error. But in the context of a scenario where the author has provided something to the user, I don't see the benefit of requiring that AT not expose that to the user.
<sarah_higley> JC: and then authors could do a div with an aria-label just inside the body, and then you get the exact same problem
<sarah_higley> joanie: that's actually prohibited, 1.2 prohibits naming on generics
<sarah_higley> MK: you're making my point for me, we disallow name on a whole bunch of generics, and if we treat body like a generic, then what we're saying is it's a presentation container just like a div or any other generic. It doesn't carry semantic meaning, which is true
<sarah_higley> JC: I don't agree that it's generic
<sarah_higley> MK: it's no different than a div in that the body doesn't implicitly distinguish itself from any other element, it is the entire page, but it itself doesn't carry a semantic meaning that differentiates itself from any other div
<sarah_higley> MK: I can't imagine any scenario where you would put a div inside the body around the entire page, because the title tag already does that
<sarah_higley> MK: I see this as just like labelling a paragraph, all it does is create a problem for screen readers to solve, that has no benefit to them for solving it. And it creates a guidance problem for authors, when do you label body or not, when do you label a paragraph or not
<sarah_higley> MK: if you're going to label a paragraph, make it visible with a heading element. If you're going to label body, you must make it visible to all people, so use the title tag
<sarah_higley> JC: I think my example stands if you have region or section or main as the only contents of the DOM as the container as something someone could put a label on. I think what we could talk about is the compromise -- I don't have a strong opinion about an author MUST NOT. I think there shouldn't be a UA MUST NOT for the body
<sarah_higley> JC: Because I think that's going to be more common accidentally than a generic div, and we do have several examples for why divs missing a role should not be labelled. And there's a very clear path to the author for what to do, add a role. For the body I don't want a restriction on UAs, because priority of constituencies. As an AT vendor we have a responsibility to try to provide the best experience to the user.
<sarah_higley> JC: and if there's something an author has done that is probably a mistake, we're still going to try to expose it to the user. If you want to make an author must not I'm fine with it, just not a UA must not
<sarah_higley> JN: so in the current draft but not 1.2, we have a UA must not. I think we need to remove this from 1.3 because we're not going to get UAs to do that
<sarah_higley> JN: we're not going to get UAs to pass tests, so we shouldn't have it in there
<sarah_higley> joanie: we could do the thing about "as long as it doesn't make the user experience worse"
<sarah_higley> MK: would there be an objection for UAs SHOULD NOT, because then it doesn't fall under testable areas, but then encourages browsers in that direction
<sarah_higley> JC: I think that just encourages UA interop problems
<sarah_higley> JC: to clarify, I don't think we should have an author must not, but I'm not going to fight it
<sarah_higley> MK: if we don't have the author must not, then I am concerned about what labelling guidance we will provide for body. The APG labelling guidance for every role -- it needs to match what is actually useful in reality and if there's no value and if there's negative impact from labelling something we should be explicit about that in authoring guidance. And the same goes for AT expectations -- I actually think that exposing something , if i[CUT]
<sarah_higley> MK: and the AT exposes it, I think it's actually harmful
<sarah_higley> MK: that creates interop issues where the experience is really different from one AT to another. So to avoid AT iterop issues, i don't think any AT should expose a label on a body
<sarah_higley> MK: there's no benefit to the user, just like labelling on a paragraph
<sarah_higley> JN: OK so, we need to come to some conclusion on this
<Zakim> jcraig, you wanted to draw an analogy to my same objection re: limits discussed on aria-roledescription... Original proposal was for an allow-list, but I think we settled on a better block-list (only generic IIRC)
<sarah_higley> JC: I made a similar objection when we were talking about aria-roledesc a few years back. THere was a proposal about only allowing on specific container elements, and I made the point that there are new container els coming out, and odd ones like video that don't map to anything specific. I think we came to a blocklist solution instead of an allowed list solution, and I think we're only blocked on generic, which is reasonable
<sarah_higley> JC: so in ARIA, I don't think we should have something like aria-label should only be allowed on this, and also this, and this, and this case. I think if there are good examples of where if this causes problems in a lot of cases, we should disallow it. We're doing this for aria-hidden, adding rules where there are very specific scenarios where they cause real harm. I don't think we're there with body, where it's causing real harm. There[CUT]
<sarah_higley> JC: it's valid
<sarah_higley> MK: We can be very, very consistent with authors by saying body is generic, this is prohibited on generic
<sarah_higley> JC: I don't think body counts as generic IMO
<sarah_higley> scott: basically what we'll be doing with this, we need to decide whether or not body maps to a group or something that could be named, because right now it should be mapping to generic. Whether or not that's the semantics behind it, as mappings go, it's not a nameable thing right now. It's not being exposed by AT right now. If we make this change, we may well find out quickly whether or not it's a bad idea.
<sarah_higley> scott: right now it's named, so it's not exposed except in those few cases, so if we continue on that path we're not changing anything. If we go that way, we make it fall into what Matt's talking about, where the body is now named for users, whereas now it's not
<sarah_higley> MK: so three choices: make a new role for body, map it to existing roles, or generic
<sarah_higley> MK: I'd like mapping to generic, because that's most like what it is today
<sarah_higley> JN: James I see you're still on the queue, but we need to move on
[Detectability of assistive technology](https://github.com/w3c/aria/issues/1371)
jn: Made change to privacy text
created new pr
approved by Carolyn
James Craig, you are on review list.
Can we have a 3rd reviewer please?
JN: reads from the text about finger printing
sounds reasonable to me. Need comments from group.
Volunteers??
JC: adding approving review
Scott: add me
jc: I like how it phrased now better.
jn: will merge in a few days
[Attribute with natural language but no language metadata](https://github.com/w3c/aria/issues/1365)
jn: need to get this resolved.
based on comment from internationalization group.
Looking for suggestions.
I have some ideas.
Would like it in 1.3; don't think it will block 1.2.
The complex issue is where there is a relationship and potentially 2 languages are involved.
If there is a scenario that doesn't work, we need expected results.
This is not unique to ARIA; could happen in html where a label on an input could be different language from the input.
jc: Could happen in a native text view where there are two strings with different languages.
jn: on web, could use spans
jc: Might need concept of attributed strings on web
jn: there is a more complex issue underneath this