getting an implicit role (e.g. "group" instead of "generic") because then it would no longer be name-prohibited based on the generic role. 17:22:30 n: no meetings next week. 17:22:32 resolution: no meetings next thursday due to GAAD 17:22:39 zakim, next item 17:22:39 I see a speaker queue remaining and respectfully decline to close this agendum, Matt_King 17:22:53 q? 17:22:56 ack jc 17:23:03 zakim, next item 17:23:03 agendum 4 -- [TPAC 2021](https://github.com/w3c/aria/issues/1482) -- taken up [from jamesn] 17:23:26 jn: TPAC in October 17:23:58 There are either 2 or 3 weeks of meetings 17:24:01 https://www.w3.org/wiki/TPAC/2021 (not much info in the wiki yet) 17:24:15 Do we need need to have joint meetings with other groups? 17:24:32 Do we want to have ARIA meetings that we can invite a broader ayudience to? 17:24:39 https://github.com/w3c/aria/issues/1482 17:24:46 If anyone has ideas, please put them in this issue. 17:25:09 Is also useful if you think we should not have meetings, then please log that. 17:25:19 zakim, next item 17:25:19 agendum 5 -- [Mappings for body and html don't seem to match reality](https://github.com/w3c/html-aam/issues/330) -- taken up [from jamesn] 17:26:15 jn: This is an issue from Joanie. 17:26:33 Mappings for body of HTML don't seem to match reality. 17:27:07 Joanie: Updating maapings to reflect reality could work; could be generic. 17:27:16 but then body with label is no longer permitted. 17:27:23 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). 17:27:28 There are chromium tests with aria-label on body. 17:27:41 Group needs to decide if label on body should be supported. 17:27:51 Scott: in camp that would say no label on body. 17:28:12 Only webkit on MacOS and Narrator on windows expose it. 17:28:57 JC: we should only disallow things that are known to be a problem. don't want to overly limit the API. 17:29:20 Scott: not sure that labeling a body is doing something well. 17:29:30 present+ 17:29:37 present+ 17:29:42 JC: not sure how labeling a body good be net negative 17:29:45 chair: JamesNurthen 17:30:03 meeting: ARIA WG 17:31:41 Clarifying a previous comment: WebKit is exposing "No matching ARIA role" not "group" 17:31:44 WilliamTennisNFCU has joined #aria 17:31:47 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 17:32:01 mk: I think it would be a net negative b/c don't think we should expect AT to expose it. 17:32:44 MK: this is a real problem though, because if you label the body differently from the title tag, what the hell does that mean? 17:33:06 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 17:33:50 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 17:34:25 q+ 17:34:32 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 17:35:04 JN: so from my understanding, the body is not even exposed in some browsers, right? 17:35:43 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... 17:35:48 JN: with Edge Chromium, but not Chrome? 17:36:09 scott: I didn't try Narrator with Chrome itself, only Edge C. I only did NVDA and JAWS with Chrome and Firefox 17:36:22 issue 330 has all the testing results. 17:36:24 JN: in reply to James, the advantage of disallowing it is that validators can flag it as being an error. 17:36:38 q+ to state my philosophical objection to overly complicated restrictive API 17:36:43 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 17:36:45 ack jamesn 17:36:47 ack jamesn 17:36:47 Joanie: Already q+ 17:36:55 q? 17:36:56 ack me 17:36:56 jcraig, you wanted to state my philosophical objection to overly complicated restrictive API 17:36:58 ack me 17:37:02 q+ 17:38:00 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. 17:38:49 JC: and then authors could do a div with an aria-label just inside the body, and then you get the exact same problem 17:39:05 joanie: that's actually prohibited, 1.2 prohibits naming on generics 17:39:44 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 17:39:50 JC: I don't agree that it's generic 17:40:25 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 17:40:34 q+ 17:40:37 q+ 17:40:39 ack Matt_King 17:41:00 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 17:41:38 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 17:42:02 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 17:43:06 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 17:44:11 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. 17:44:43 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 17:45:11 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 17:45:18 ack me 17:45:22 JN: we're not going to get UAs to pass tests, so we shouldn't have it in there 17:45:29 ack jcraig 17:45:41 joanie: we could do the thing about "as long as it doesn't make the user experience worse" 17:46:02 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 17:46:12 JC: I think that just encourages UA interop problems 17:46:24 JC: to clarify, I don't think we should have an author must not, but I'm not going to fight it 17:47:50 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] 17:48:02 MK: and the AT exposes it, I think it's actually harmful 17:48:08 q+ 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) 17:48:29 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 17:48:41 MK: there's no benefit to the user, just like labelling on a paragraph 17:48:52 JN: OK so, we need to come to some conclusion on this 17:48:54 ack me 17:48:54 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 17:48:57 ... better block-list (only generic IIRC) 17:49:50 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 17:50:55 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] 17:50:58 JC: it's valid 17:51:16 MK: We can be very, very consistent with authors by saying body is generic, this is prohibited on generic 17:51:22 JC: I don't think body counts as generic IMO 17:52:02 pkra has joined #aria 17:52:12 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. 17:52:25 q+ what about not mapped, and mapped to (any container) 17:52:46 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 17:52:54 q- w 17:52:58 q- s 17:52:59 MK: so three choices: make a new role for body, map it to existing roles, or generic 17:53:00 q- a 17:53:03 q- s 17:53:07 q- see 17:53:12 q- a 17:53:18 MK: I'd like mapping to generic, because that's most like what it is today 17:53:25 q- < 17:53:30 q- 17:53:31 q- 17:53:31 JN: James I see you're still on the queue, but we need to move on 17:53:39 q- no 17:53:43 scribe: matt_king 17:53:44 q- map 17:53:52 q- to 17:53:58 q- (any 17:54:11 q- cont 17:54:20 q? 17:54:21 zakim, next item 17:54:22 agendum 6 -- [Detectability of assistive technology](https://github.com/w3c/aria/issues/1371) -- taken up [from jamesn] 17:54:38 jn: Made change to privacy text 17:54:50 created new pr 17:54:56 approved by Carolyn 17:55:09 James Craig, you are on review list. 17:55:16 Can we have a 3rd reviewer please? 17:56:08 JN: reads from the text about finger printing 17:56:20 sounds reasonable to me. Need comments from group. 17:56:33 Volunteers?? 17:56:47 JC: adding approving review 17:56:51 Scott: add me 17:57:07 jc: I like how it phrased now better. 17:57:19 jn: will merge in a few days 17:57:24 zakim, next item 17:57:24 agendum 7 -- [Attribute with natural language but no language metadata](https://github.com/w3c/aria/issues/1365) -- taken up [from jamesn] 17:57:38 jn: need to get this resolved. 17:57:49 based on comment from internationalization group. 17:57:57 Looking for suggestions. 17:58:01 I have some ideas. 17:58:19 Would like it in 1.3; don't think it will block 1.2. 17:59:11 The complex issue is where there is a relationship and potentially 2 languages are involved. 17:59:40 If there is a scenario that doesn't work, we need expected results. 18:00:11 This is not unique to ARIA; could happen in html where a label on an input could be different language from the input. 18:01:10 jc: Could happen in a native text view where there are two strings with different languages. 18:01:19 jn: on web, could use spans 18:01:47 jc: Might need concept of attributed strings on web 18:02:12 jn: there is a more complex issue underneath this 18:02:17 rrsagent, make minutes 18:02:17 I have made the request to generate https://www.w3.org/2021/05/13-aria-minutes.html Matt_King 18:02:42 rrsagent, make log public 19:02:19 jongund has joined #aria