would be mapped to group in HTML-AAM? 18:43:23 seems reasonable 18:43:28 q? 18:43:40 aaronlev: the other areas are the keyboard nav model for all 3 types, and the a11y model for all 3 types. I've marked all areas we need feedback on, TBD. We want feedback on everything 18:44:07 aaronlev: there's also reading order: it's possible to associate the popup with the trigger, and the DOM content of the popup could be anywhere, not necessarily after the triggering element 18:44:45 aaronlev: our suggestion is the tab order needs to reflect what the user sees, so it should go into the popup, regardless of where it is in the DOM. And aria-details can be used if the popup is not next to the trigger in the DOM 18:44:51 q? 18:44:54 cyns: anyone know how well aria-details is supported? 18:45:23 aaronlev: aria-details is still getting budding support. It's about 25% of the way we need to be. It's supported in ChromeVox, and some basic support in JAWS and NVDA 18:45:38 ack Matt_King 18:46:41 Supported in WebKit/VO. WebKit diff at https://bugs.webkit.org/show_bug.cgi?format=multiple&id=165842 18:46:48 Matt_King: I'm hoping we get to talk about how we will go about gathering feedback and making decisions because this reminds me of our convo earlier this morning. One of the things I think we don't do well as a working group is user research and understanding whether we are solving the problems of users or even creating more problems. I'm really concerned about some of the implications of the proposal because they will bake interaction into brows[CUT] 18:47:03 s/Supported in WebKit/aria-details supported in WebKit/ 18:47:23 Matt_King: term in the same way some people find frustrating today -- legacy decisions, for example the fact that you can activate a button with a spacebar, but when you hit space on a link, it scrolls the page 18:47:28 Matt_King: it just confuses the heck out of people 18:48:05 Matt_King: this proposal I'm especially thinking about all the tab key stuff related to hints and the reliance on aria-details, and the fact that we haven't really defined AT expectations for aria-details and how they can support details in ways users will understand 18:48:13 short link of above https://webkit.org/b/165842 18:48:21 q? 18:48:40 Matt_King: I'm just hoping we'll talk about the process of how we go about this. The other thing I'm hoping is maybe we could carve this up into things we know, go forward in little bits at a time rather than all at once 18:48:57 Matt_King: try to scope it in ways where we're making sure we're not introducing complex controversial or new long-term problems 18:49:15 aaronlev: I'll let Nicole talk about the user research part of it 18:49:57 aaronlev: we have a doc I think I've shared that defines AT responsibilities with aria-details, because we don't specify AT behaviors, so instead I wrote a doc and shared it with AT developers, browser, devs, stakeholders 18:50:17 q+ 18:50:29 q+ 18:50:41 aaronlev: I didn't initiate user research with all the AT users, I think that would be an amazing thing. I think going backwards in the web with even a static page and how hard screen readers are to use with it would've been good 18:51:11 aaronlev: I also want to address the collaboration bit, this is all rough, we're trying to be logical at this stage. We're creating prototypes, popup is still not out there on the web, so this is our chance to change everything 18:51:44 nicole: I can speak to the UXR part, This is the the part that worries me, especially as we're trying to bring a11y to users without more effort from devs. We want to make sure that what we're shipping is better than what we have now 18:52:32 nicole: I think the only way we know that is to test with users of AT. It wasn't clear that some of the patterns we're working on haven't been tested thoroughly. We want to do tests around different kinds of toggle and how meaningful that is to users, but I think there are tests we can do with popup too 18:52:54 Matt_King: I don't think it's just missing research, I'm thinking of the process of doing the research, for there to be discussion of the research design and goals that's open and thoughtful 18:53:41 q+ to ask to learn how to deal with the third use case of complex/interactive contents inside the dialog - like interactive grid, (ex: embeded tableau data) which may not be covered by aria-details. or will it be covered by aria-details? 18:53:47 Matt_King: I think in a lot of solutions we have a chicken and egg problem where take tooltips, as far as I'm concerned as a SR users, tooltips are just a SR nightmare, and there isn't a usable solution with any screen reader. Nobody's imagined a way to make the experience of tooltips as effective for screen reader users as it is for anyone else 18:54:02 Matt_King: ok, maybe no one likes tooltips :D 18:54:21 cyns: there's a user researcher on my team who has experience doing studies with users with disabilities who might have time 18:54:28 I liked the discussion of potential dom order. 18:54:30 cyns: that's a great way to affect desigs 18:54:31 q- 18:54:34 s/desigs/designs 18:54:38 ack scotto 18:55:42 scotto: I just wanted to add, one of the things about popup being an attribute and the fact it is three different behaviors. This makes things some devs are doing now a lot easier. I know one thing popups solves is it allows content authors are currently shoving to the end of the DOM for z-indexing and layer issues -- this allows those popups to be next to things in the DOM. That's something devs currently can't do right now. If used in this way,[CUT] 18:56:07 q+ 18:56:15 ack Jem 18:56:15 Jem, you wanted to ask to learn how to deal with the third use case of complex/interactive contents inside the dialog - like interactive grid, (ex: embeded tableau data) which may 18:56:18 ... not be covered by aria-details. or will it be covered by aria-details? 18:56:23 q? 18:56:27 scotto: problem that exists. But also, now authors can put things anywhere in the DOM. We now want to push the conversation in how to mitigate for less than ideal solutions now that there's a way to do this easier 18:57:00 q+ 18:57:12 TabAtkins has left #aria 18:57:31 Jem: I was just thinking about the third case, I see that in the university we use a popup, and they embed lots of tableau data inside popup. I think this is another example in addition to simple and rich text data that can be covered by aria-details. What about this third case with very rich data, grids, etc. inside of popups? 18:57:42 aaronlev: like an interactive grid? 18:57:43 Jem: yes 18:58:19 aaronlev: that should be OK, any kind of rich interactive content should work. THe user just needs to discover it, interact with it, using their screen reading commands. They also need to not fall out of it by accident, but other than that 18:58:24 ack chrishtr 18:58:36 zakim, close the queue 18:58:36 ok, jamesn, the speaker queue is closed 18:58:58 chrishtr: I wanted to respond to some of the comments about tooltip. I think you mentioned no one has come up with a reasonable way for SR users to use tooltips. It sounds like in practice it'd be better to have them filtered out, is that fair? 18:59:01 Matt_King: not necessarily 18:59:13 aaronlev: they are exposed in a way users can filter them out 18:59:27 chrishtr: they may not be, depending on how they're implemented 18:59:39 aaronlev: with the hint proposal, they'd be exposed in the same way as the title attr 19:00:04 chrishtr: so because the hint popup exposes the fact that it's a hint-based popup thingy, it probably makes it easier for a user to filter it out 19:00:15 Matt_King: I'm more concerned about the interactivity baked into this 19:00:17 ack Matt_King 19:02:42 aaronlev: with regard to usability testing, I think that'd be awesome. I'd have to talk to cynthia or others. WRT aria-details not being mature, there is another option, which would be to mutate the a11y tree to put the popup content next to the anchor. I wanted to avoid that because of how difficult it is to implement aria-owns in a stable consistent way 19:03:35 aaronlev: we're thinking we want to support a minimum role on popups. We want to implement aria-expanded where it makes sense. We may want to find something better than role=group to show to AT so users know they're escaping something. You don't want to accidentally let people leave or navigate somewhere else unintentionally 19:03:42 jcraig: role or something else? 19:03:48 aaronlev: I think an attribute 19:04:17 yes. I also heard a lot of complaints that people get lost a lot with pop up. 19:04:18 aaronlev: think something like aria-island, without getting hung up on the name. It'd be something that ATs would need to support, that would warn you when you leave, and you would have to verify the action somehow 19:04:31 rego_ has joined #aria 19:04:32 aaronlev: we have to talk about initial focus, F6 with async popups, what happens on page load 19:04:38 aaronlev: bikeshed aria-island 19:04:40 got it. a interaction primitive similar to modal 19:05:03 aaronlev: then there's keyboard nav, when does initial focus go into a popup. Is it when you explicitly opened it with the keyboard, or as long as the popup is not an async popup or on page load? 19:05:15 aaronlev: Let me go through some of the TBDs here 19:05:48 aaronlev: we have to consider implications for touch. Like you said tooltips are not ideal for SR users, they are also not ideal for keyboard or touch users currently. Finally we have to decide whether rich hint popups cause their triggers to be in the tab order so users can activate them 19:05:51 q+ 19:05:54 q+ 19:05:55 zakim, open the queue 19:05:56 ok, jamesn, the speaker queue is open 19:05:56 q+ 19:06:00 fq+ 19:07:00 q+ 19:07:14 Matt_King: I think one of the areas of biggest research I'm concerned about is related to focus and keyboard, in particular this area of light dismiss. I'm really concerned about tab principals for how it should work. I think one really important one that I find nightmarish when it's not followed is that shift-tab will undo what tab did. If you tab forward and backward, you shouldn't be going to a different place. 19:07:43 Matt_King: if you were in a popup and tabbing out dismissed it, tabbing backward won't get you into the same place. That feels like a true nightmare to me. I already experience this a lot. It's something for us to really think hard about. 19:08:13 aaronlev: It's a good point. As a sighted users, I can see visually when I'm at the end of it. It's not as obvious when you're at the end as an SR user, and the tab might close it. We should consider cyclical tabs 19:08:25 Matt_King: it's something to consider. But if you can't tab out, should you be able to tab into something. 19:08:41 ack scotto 19:09:20 scotto: I want to respond -- some of this behavior, like the ability to tab away from a popup. Think about a listbox that comes from a combobox -- tabbing away is expected behavior. i think it's important to not be too prescriptive because popup as an attribute needs different behaviors based on the underlying element it's applied to 19:10:11 scotto: everything you're saying Matt I absolutely agree with, but some of the behavior you're describing, I'd expect people to be using a dialog. I think we need to figure out what to do when someone is using this on a div with no other semantics. I think popup won't solve all these problems b/c there isn't only one solution 19:10:16 ack sarah_h 19:10:28 scribe+ 19:11:07 scotto: clashes with aria owns 19:11:13 sarah_h: I just want to register agreement w/ aaron that I don't think browsers should auto-move popups next to the button without authors having some way to undo it 19:11:15 can't reuse that code 19:11:20 aaronlev: yeah, I've spent a year fixing bugs with aria-owns 19:11:35 aaronlev: this seemed like a place to increase the value of aria-details, because we're going to need that 19:11:42 I am thinking that 'light dismiss" may violate WCAG in regards to conginitive disability although I cannot think of specific SC right now. 19:12:27 aaronlev: I moved this back to a google doc from the github discussion because otherwise it was unreadable. If anyone has issues reading it, I'm happy to move it back to a wiki. I found it a good way to collect feedback and improve the actual text 19:12:36 aaronlev: are there any objections to doing it this way for now? 19:12:53 Matt_King: the current explainer, is that on a wiki now? 19:13:05 aaronlev: I'm talking about the google doc I emailed earlier today to the public aria WG 19:13:10 what is this then, https://open-ui.org/components/popup.research.explainer? 19:13:25 https://docs.google.com/document/d/1umackdZ9wZsr0cJtM6IfpFLN0RJKCypdYiRe_nJuk8c/edit# 19:13:27 aaronlev: I've written a popup a11y proposal 19:13:31 jamesn: can you put a link in IRC? 19:13:50 Thanks for the google doc, @aaron 19:14:12 aaronlev: it has the collected wisdom we have on the a11y concerns. It links to the explainer and says given that, what's the best we can do for a11y 19:14:24 Matt_King: can we add a link to the google doc from the explainer? 19:14:38 scotto: I don't see why that would be a problem 19:27:51 howard-e has joined #aria 19:32:58 mbgower has joined #aria 19:51:12 howard-e has joined #aria 19:52:41 MichaelC has joined #aria 20:02:01 mbgower has joined #aria 20:05:00 present+ 20:08:43 howard-e has joined #aria 20:22:44 Matt_King has joined #aria 20:27:29 howard-e has joined #aria 20:43:54 TOPIC: How to handle unlabeled elements 20:46:08 Jamie has joined #aria 20:46:24 scribe+ 20:46:37 zakim, open the queue 20:46:37 ok, jamesn, the speaker queue is open 20:46:46 sarah_h has joined #aria 20:46:49 How to handle unlabelled elements 20:46:51 https://github.com/w3c/accname/issues/138 20:47:33 Holli has joined #ARIA 20:47:42 we can agree on some changes then discuss 20:48:06 user jumped into articles with article rotor 20:48:13 see a heading that would useful 20:48:16 makes sense 20:48:26 dissallowed to pass up in browser 20:48:30 CSS prevented 20:48:43 intial issue was heuristics will get better 20:48:50 is an auth error 20:49:03 ARIA wanted something rigid 20:49:13 name from heading is a good idea 20:49:17 jongund has joined #aria 20:49:17 everone agrees 20:49:42 ML heuristics should be better 20:50:00 Original Issue https://github.com/w3c/accname/issues/138 20:50:11 #138 in accname 20:50:11 https://github.com/w3c/aria/issues/138 : HTML-AAM: audio UIA should have localized control type 20:50:17 rragent, make minutes 20:50:19 aria issue #899 20:50:19 https://github.com/w3c/accname/issues/138 : ARIA Spec could be more flexible when elements with "nameFrom:author" are left unlabeled by the author 20:50:23 rrsagent, make minutes 20:50:23 I have made the request to generate https://www.w3.org/2022/09/15-aria-minutes.html jamesn 20:50:44 Old PR from Jon https://github.com/w3c/aria/pull/1018/files 20:50:49 repo accname 138 20:50:52 aria 1018 20:51:11 feedback on #1018 20:51:11 https://github.com/w3c/aria/pull/1018 : Issue899 accname from heading 20:51:15 s/we can agree/jcraig: We can agree/ 20:51:26 aaron will take over 20:51:37 couple of things need agreement 20:52:08 most cruft and whitespace diffs 20:52:08 BGaraventa has joined #aria 20:52:34 present+ bgaraventa 20:53:23 no nesting with landmark roles 20:53:33 think it is unecessary 20:53:36 leobalter has joined #aria 20:53:45 any objections? 20:53:57 "heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading, with landmark roles heading elements used for naming are restricted to first child node." 20:54:03 Matt_King: role=region object doing this at all 20:54:13 ok for other 20:55:09 https://raw.githack.com/w3c/aria/issue899-accname-from-heading/index.html#namecalculation 20:56:16 jamesn: why label complimentary? 20:56:28 or nav 20:56:36 if there is a label we can read that 20:56:57 Matt_King:useless to hear complimentary 20:57:12 jamesn: risk 1st heading could be halfway down 20:57:26 aaron, heuristics better than first child 20:57:31 come back to that 20:58:28 remove 'A heading can only be used to name its nearest ancestor element that follows from heading" 20:58:52 overcomplicates implementation causes slowdown 20:59:05 simplifying John's PR 20:59:14 Matt_King: what are the side effects? 20:59:28 if its a sloppy page or incomplete implementation 20:59:29 jongund has joined #aria 20:59:38 2 nested containers could share a label 20:59:40 A bit late here, but it's worth noting that the first child restriction on landmarks would solve the risk of the heading being half way down the landmark. 21:00:01 redundant for user in worst case 21:00:25 sarah_h: content region 1st article has a heading, 21:00:30 like and landmark region 21:01:20 jamesn: 6 roles to get name from heading 21:01:41 alertdialog,article, dialog,complimentary,navigation,region 21:02:04 aaron changing what name from heading means 21:02:21 aaron DPUB roles they want 21:02:39 jamesn: if you have a heading no need to provide a name 21:02:45 Matt_King: don't go down that path 21:03:08 Now I understand what two jamesn meant "simplify" 21:03:08 concensuss for removing 21:03:15 'A heading can only be used to name its nearest ancestor element that follows from heading" 21:03:21 s/jamesn/James/ 21:04:04 Matt_King: if you are using region you should know name is required 21:04:22 author should be listed before heading 21:04:31 big removal 21:04:59 Jon's proposal: "Authors MUST give each element with role dialog a brief label that describes the purpose of the content in the dialog. Authors SHOULD use the first visible element with role heading of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not 21:04:59 contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby" 21:05:22 My counter proposal: Authors SHOULD give each element with role dialog a brief label that describes the purpose of the content in the dialog. 21:06:47 aaron, this is for the authoring spec 21:06:55 Matt_King: if this is error correction we don't need this 21:07:20 why would'nt we allow authors to label with a child header 21:07:33 authors will accidentally get it right 21:07:34 If it's not error correction, then the possibility of a heading halfway down a landmark is pretty worrying. 21:07:47 Matt_King: what the specific requirements should be 21:08:01 what qualifies as label from child heading 21:08:20 dialog > p > heading a label will be needed 21:08:32 jamesn: entire

is meaningless 21:08:54 a "duh" requirement 21:09:04 concencus to remove? 21:09:05 yes 21:09:17 Matt_King: confused if we are going in 2 directions 21:11:01 line 6552 21:11:08 q? 21:12:23 jamesn: sections aren't landmarks unless they are labelled otherwise you have unintended landmarks 21:12:47 non proliferation 21:13:12 q? 21:13:26 Matt_King: dialogs 21:13:46 Matt_King: this isn't error correction 21:13:59 this becomes a name technique 21:13:59 Jamie_ has joined #aria 21:15:20 Matt_King: concerned about the ability to detect articles/dialogs that are missing labels 21:15:27 if the heading is not a good label 21:15:39 q+ 21:15:52 and we just pulled out the structural requirements 21:15:55 q+ 21:16:21 with no author MUST related to structure 21:16:31 you can't to check to see if is is labelled 21:16:42 aaron,you can check 21:16:51 Matt_King: not for an intentional label 21:17:12 jamesn: technically valid 21:17:25 same tool cannot check for correct img alt text 21:17:39 Matt_King: at least the author tried to specifiy alt text 21:17:46 in this case the author did nothing 21:17:54 aaron 21:18:03 golive required alt text 21:18:12 and authors used "." 21:18:33 cyns has joined #aria 21:18:39 Matt_King: we don't have a problem of "." for a dialog heading 21:18:50 q? 21:18:54 the heading may not be a good label 21:18:58 q+ 21:19:00 no author MUST 21:19:10 is a problem 21:19:18 aaron aknowledged 21:19:30 authors won't use checking tools 21:19:35 Matt_King: we build them 21:19:50 Matt_King: we could make our own internal rules but not a good idea 21:20:12 aaron, the reason this exists is the 99% is the best guess 21:20:28 Matt_King: satisfying name is requiered is what I'm talking about it 21:20:37 s/aaron,/jcraig:/ 21:20:37 aaron user over authors 21:20:53 still say the change is worthwhile 21:21:05 s/aaron user/jcraig:/ 21:21:12 ack sarah_h 21:21:24 sarah_h: scott tested role=region exposing nameless regions 21:21:44 don't think 1st heading is the right solution but it might be worth reconsidering 21:21:48 q- 21:21:49 s/jcraig:/jcraig: user/ 21:22:11 scott comment 8/1/2019 on the PR 21:22:15 Matt_King: going back 21:22:23 no longer agrees with concensus 21:22:47 agree with error correction 21:23:12 jamesn: authors must ensure the first header must be a meaningful name 21:23:23 naive checkers won't know what is meaningful 21:23:50 jamesn: article 1 article 2 is worse than first heading 21:24:13 aaron, not going to commit this 21:24:21 just clean up this diff 21:24:36 s/aaron, not/jcraig: not/ 21:24:48 Matt_King: there could be middle ground if we can get a preview working 21:25:00 back to original proposal 21:25:21 error scenario, name from heading solve these cases 21:25:23 q? 21:25:31 the reason I put this there 21:25:54 ML techniques are changing how AT accross the board 21:26:04 aknowledge in spec 21:26:23 to let browsers provide the best thing to the user 21:26:42 jamesn: can you provide the language that prevents this? 21:26:52 s/back to original proposal/jcraig: back to original proposal/ 21:27:14 Holli has joined #ARIA 21:27:15 jamesn: AT corrects things, why is this different? 21:28:24 webkit or VO has to cheat 21:28:37 jamesn: can solve without spec changes 21:28:45 expose as guessname 21:29:32 Matt_King: it should still have no name in the a11y tree 21:29:47 That also allows AT to differentiate a guess from reality, which could be useful to tell the user that it might be problematic. 21:29:55 ack cyns 21:30:53 scribe+ 21:31:04 topic: text separation 21:32:05 jamesn: PR is old and hasn't been merged, which makes me think it's not the right approach. I want to talk about what we were trying to solve 21:33:00 jamesn: I think we were trying to solve the issue where you have various text nodes that are either spoken together when they shouldn't be or they are separated out by AT when they shoudl be a single example. for example formatting inside a word 21:33:02 https://github.com/w3c/aria/pull/996 21:33:06 mbgower has joined #aria 21:34:10 jamesc: more history: div and span should use generic role they are the same presenation-wise. based on span being inline and div block, api stuff exxposed differently, and AT knows not to jam them together 21:34:39 jamesc: some ppl didn't think span and role should be the same, so we did text separation 21:35:01 jamesn: now that we have generic, what problem is text separation trying to solve that a real world developer has? 21:35:27 jamesn: solves teh same thing as text=static (sp?) changing how strings are read 21:35:55 jamesn: propose that we don't do aria text separation and bring back a form of role text status 21:36:21 matt: the problem is that a role change changes the role, but a property allows ... 21:36:34 jamesn: role=text is a specialized version of role=generic 21:36:52 jamesn: apple has role=text implemented in webkit. Have their been problems with it? 21:38:17 jamesc: we had role=text before it was proposed. there was a large set of contnent that relies on it not changing. Joanie had reasons why role=text is not the best. role=static would address that and Apple's backwards compat 21:39:23 jamesc: problem is with an implementation or role=text that makes children presentational. Changing behavior of role=text problem 21:39:37 matt: back to the problem 21:40:05 jamesn: where does text separation go? overly complex for the problem it's trying to solve 21:40:45 jamesc: problems with implementation with os accessibility apis having to look at sibilings 21:40:53 cyns: sounds like performance problem 21:41:19 jamesn: Only textual contents allowed (author error) 21:42:28 matt: role generic didn't solve the div and span problem. If you want to separate content that's in spans, you have to add additional space characters. Or if you want divs to be treated like spans (no pause) you have to change them to spans 21:42:41 matt: That is still the problem that we're trying to solve 21:42:52 matt: need to look at list of practical use cases 21:43:05 q? 21:43:09 q+ 21:44:00 ack cyns 21:44:31 cyns: I was in a meeting about pronounciation guidelines and it seems there is a lot of overlap, which I think is interesting -- pausing/adding pauses... 21:44:52 jamesn: maybe not, because that discussion was adding pauses on purposes 21:45:18 jamesn: where this is just a word getting put in different blocks unrelated to the author content 21:45:31 ok 21:45:58 matt: when you have a kbb element inside a sentence, you're reading the sentence and then it stops 21:46:08 jamesc: read from here can pass that 21:46:25 q+ to suggest a path forward 21:46:28 jamesc: kbb is there for a reason, which is why there's a pause to let the user know 21:47:05 ack me 21:47:05 jamesn, you wanted to suggest a path forward 21:47:19 matt: one example of a use case 21:47:49 discussion was about multiple interaction patterns for navigating inline content that is styled differently for a reason. like 21:47:53 jamesn: we should close the text separation issue, it's not useful or implentable. Anyone disagree 21:48:13 jamesn: open a new issue with the fundamental use cases we're trying to solve 21:48:37 I mentioned to Matt_King that VO+A (Ctrl+Opt+a or CapLock+a) continues reading a the end of each inline element 21:48:42 jamesn: create a draft PR for role=static 21:49:00 matt: didn't go to children 21:49:20 jamesn: could have test tools and maybe UA not expose if there are the wrong children 21:49:22 s/jamesc:/jcraig:/g 21:49:34 matt: we can look at the pr proposal 21:50:06 matt: one problem I remember was that it blocked access to content. Let's look at failure use cases where role=static blocked child content 21:51:47 matt: example I (heart emoji) NY got read as I love New York, no way to know that there was a heart emoji 21:52:26 jamesn: maybe we can find a way to resolve objections, or maybe not and it's still worth moving forward 21:52:48 matt: yes, but look out for side effects 21:53:27 jamesc: Jamie, last night we talked about Scotts PR suppressing role description. That is what it's doing. The primary benefit is simplifying implemntiona 21:53:46 jamie: commented on PR, it's ok 22:03:31 mbgower has joined #aria 22:05:24 mbgower has joined #aria 22:17:15 mbgower has joined #aria 22:30:32 topic: What to do with name prohibited? 22:33:52 Holli has joined #ARIA 22:34:35 cyns has joined #aria 22:34:39 scribe- 22:34:51 scribe+ 22:35:26 jamesn: in 1.2 we introduced a new category of roles, name prohibited 22:35:32 Matt_King has joined #aria 22:35:49 jamesn: for things that could not be names, like generic and paragraph, things that generally only contain text or are generic containers 22:35:59 jamesn: in 1.2 it wasn't a problem, it was only author requirements 22:36:28 jamesn: but in 1.3, for some reason I don't know, we prohibited user agents from exposing the name of something that is prohibited 22:36:58 Matt_King: the reason why is that we decided to add it in 1.3 when we were discussing it in 1.2. it was a timing issue with going into CR. we delayed the user agent requirements to 1.3 22:37:02 jamesn: but why? 22:37:04 sarah_h has joined #aria 22:37:44 Matt_King: I remember being a proponent of the user agent requirement because it the user agent surfaces as a name for an element where the name is prohibited then authors are not aware of the fact that they are creating a problem 22:38:14 jamesn: so we went down that path, but we got a lot of feedback, like the ones linked in the agenda 22:38:28 jamesn: some of the issues are when a generic or prohibited becomes focusable 22:38:43 jamesn: seems like name could be a good fallback in this scenario 22:39:05 jamesn: I believe the user agent implementors were reluctant to implement 22:39:46 aaron: I have a document that I wrote, I'm trying to find, the problem is inconsistent screen reader behavior. We haven;t found a good way around that. if you remove the name the expectation is that it breaks webpages 22:40:01 aaron: a lot of authors only know about aria-label and its a bandaid and they are trying to annotate 22:40:02 https://github.com/w3c/aria/issues/1487 22:40:10 aaron: it happens often enough I think we should allow it 22:40:32 aaron: now that we don't prohibit it, we have inconsistent screen reader behavior 22:40:56 jamesn: chrome started to implemented "do not expose name when prohibited" then it encountered problems, so they didn't implement 22:41:18 jamesn: so we don't have implementations of the 1.3 specification, unless implementors agree to implement, we have to remove it 22:41:19 https://github.com/w3c/aria/issues/1476 22:41:30 https://docs.google.com/document/d/1mcce70oxAl03_P6uzWldZ2nhGHoteaMlpVl5KWszFdk/edit?usp=sharing&resourcekey=0-zjDvv9ENpmNvJeX4TFTfsg 22:41:36 jamesn: all three linked bugs are essentially the same issue 22:41:48 aaronlev has joined #aria 22:41:54 https://docs.google.com/document/d/16AysDIyGt7IfazLmLP8wFsnTTBFKWPDBA50z9LDm6tA/edit# 22:42:24 aaronlev: I had some discussions with jamie about the problem and this is the result ^ 22:42:47 aaronlev: proposal, keep exposing it as an accessible name, and trying to convince ATs to expose 22:42:59 aaronlev: next proposal, ....? 22:43:10 aaronlev: next proposal, expose the name as "aria-description" 22:43:26 aaronlev: next proposal, if on a generic element, then do a repair and have a minimum role of group 22:43:36 Matt_King: I feel like all of those.... 22:43:44 Matt_King: I don't understand second proposal 22:44:12 aaronlev: second proposal... I can't quite remember, jamie do you remember you have a blog post 22:45:18 Matt_King: lets go to the beginning! we put name prohibited on certain roles for a reason, we don't want authors to name these things 22:45:30 Matt_King: we shouldn't change things so that authors can name them 22:45:41 jamesn: validators flag it as an error! 22:45:49 q+ 22:45:56 Matt_King: what do you mean keep on doing what we are doing? 22:46:12 aaronlev: we should be strict about what we require and loose in what we prohibit 22:46:27 aaronlev: and instead try to repair 22:47:28 jamesn: how are we going to move forward to get 1.3 out? 22:47:40 jamesn: we need to remove the user agents must not 22:47:59 jamesn: user agents need to do something for error correction purposes 22:48:18 Matt_King: can we say "may not" instead of "must not" because then they don't need to expose as an accessible name 22:48:50 jamesn: I'd like to remove the statement, add an authors notes about the discussion continuing, but we can't publish this in 1.3 because there are not plans 22:49:22 jamesn: that ok? 22:49:46 james: we won't forget about the issue and make it clear to readers of the spec that the discussion is on going 22:49:57 jamesn: also I'd like to have more editors notes to describe things that are in flux 22:50:07 Jamie: I would object to the statement remaining in the spec 22:50:33 jamesn: we almost got agreement to remove the statement in a previous meeting, I just wanted to confirm it with more people 22:50:53 no objections 22:51:15 jamesn: so lets discussion options for the long term solution? 22:51:49 jamesn: back to aaron's document 22:51:56 jamesn: three options 22:52:45 Matt_King: I think 1 and 3 are problematic 22:53:18 s/and 3/and 4/ 22:53:31 Matt_King: I think 3 is ok, with "name-from:prohibited-name" 22:53:54 Matt_King: one pro that is not listed is that the aria label will not be treated by name calculation as a name 22:54:20 Matt_King: so in the accessibility inspector will not show a name 22:54:45 aaronlev: it will show in the description, and under the reason it will say where we got it from 22:54:59 Matt_King: I like that because it is explicit 22:55:16 Matt_King: if that results in duplicative speech, that is an good result, because you did something you were not suppose to do 22:55:41 jamesn: if we are only talking about dev tools -- you could expose in the dev tools more clearly that this is a fallback and an error 22:55:56 Jamie: it is not a given that an AT will read a description 22:56:31 Jamie: it is not defined that a AT will handle a name in a particular way in the name prohibited case 22:56:55 Matt_King: if the browser exposes a name that is prohibited, it is more likely that the AT is going to treat it as a name 22:57:32 Jamie: it's tricky. if it is what the author misguidedly intented.... it seems like it is also misleading to expose as a description 22:57:39 q? 22:57:40 Matt_King: but we do that already with a whole bunch of stuff 22:58:05 Matt_King: some times a name is a name sometimes it is a description. I think we are talking more about authors than users 22:58:24 jamesn: this is like a guess. we should expose it as something different and AT can do what they want 22:58:37 Jamie: this is error correction, always carries some risk and is hard 22:58:54 jamesn: this is "an invalid name" should be exposed 22:59:25 aaronlev: if we move to aria description, ats are working on trying to do this consistently, 22:59:53 jamesn: so we should use description instead of making a new idea because that will take forever to get AT support 23:00:05 Matt_King: I think this is the best for users and lease confusing for authors 23:00:35 Jamie: as much as I expose to role="text" people use it because they want that behavoir 23:01:34 Jamie: an empty generic might not expose a description or a name to an AT -- the solution it solves a few use cases, there is still other issues we aren't discussing 23:01:44 ack Jamie 23:02:08 Matt_King: it is not our job to solve author errors. we want to prevent author errors and occasionally, when it is clear benefit to users, allow user agents to correct something 23:02:19 Matt_King: we don't want to fix every anti-pattern 23:02:32 jamesn: we don't want to prevent at and browsers repairing things 23:03:05 q+ 23:03:12 Jamie: do you have anecdotal evidence that empty divs and spans with aria labels are more or less common than divs and spans with content 23:03:17 zakim, close the queue 23:03:17 ok, jamesn, the speaker queue is closed 23:03:21 aaronlev: I'm pretty sure most of them are not empty 23:03:48 aaronlev: I wouldn't have thought of that so thanks for bringing it up. but with that in mind I think it is a still acceptable solution 23:04:18 jamesn: I think we are overloading annotations 23:04:32 s/jamesn/jamie 23:04:33 s/jamesn/jamie/ 23:04:40 q- 23:04:53 jamesn: thanks everyone! 23:05:02 TOPIC: dialogs 23:05:29 can I just ask "would you like me to get an answer to the previous question from the http archive dataset?" 23:06:04 scribe+ 23:06:23 Matt_King: there was homework for this 23:06:32 ... kind of long, so here’s some help 23:07:12 ... there is an issue in ARIA #708 referring to non-modal / modeless dialogs being treated by screen readers 23:07:13 https://github.com/w3c/aria/pull/708 : IDL attribute reflection branch 23:07:19 ... there was a proposal that they be recognized as landmark in regions 23:07:22 ... in #1708 23:07:23 https://github.com/w3c/aria/issues/1708 : tracking issue for