18:03:08 RRSAgent has joined #aria-apg 18:03:08 logging to https://www.w3.org/2019/09/03-aria-apg-irc 18:03:17 present+ jongund 18:03:26 CurtBellew has joined #aria-apg 18:03:34 MEETING: Spetember 3, 2019 Authoring Practices Task Force Telecon 18:03:41 CHAIR: Matt King 18:03:45 RRSAgent, make logs public 18:03:50 rrsagent, make log public 18:03:50 present+ 18:03:54 present+ 18:03:59 present+ Matt_King 18:04:06 rrsagent, make minutes 18:04:06 I have made the request to generate https://www.w3.org/2019/09/03-aria-apg-minutes.html mck 18:04:20 scribe: MarkMccarthy 18:05:18 present+ 18:07:16 present+ Jemma 18:07:21 https://github.com/w3c/aria-practices/wiki/September-3,-2019-Meeting 18:07:32 Agenda link is above 18:08:01 Agenda link: https://github.com/w3c/aria-practices/wiki/September-3%2C-2019-Meeting 18:09:09 mck: [going through agenda for the day] 18:09:35 mck: any additions? we have some room today 18:09:42 TOPIC: Future meeting agendas 18:10:13 mck: we will have a meeting next week Sept 10, but APG will not meet online on Sept 17. Only at TPAC 18:10:40 mck: On Sept 24, there's not really a reason not to have a meeting, just need to make sure agenda etc. is prepared before going to Japan for TPAC 18:11:00 mck: if anyone has agenda topics for Sept 24, please submit them 18:11:29 mck: hopefully we'll get some of Sarah's things covered by then 18:12:12 jamesn: our meeting in Japan next week will run from about 5p-2a Pacific Time 18:12:25 jamesn: Eastern time, 8p-5a 18:13:03 jamesn: I'll go through other things for ARIA WG on thursday, if there's things people for sure want to dial in for and need flexibility, let us know asap 18:13:17 TOPIC: Third Working Draft Milestone 18:13:28 https://github.com/w3c/aria-practices/milestone/10 18:13:36 mck: there's a link to the draft [above] 18:13:53 mck: we're about 50% done with the milestone! 18:14:04 mck: looking at the list, jamesn and I did some work on the first thing on the list 18:14:24 mck: what's weird is that our changing the HTML structure broke the keyboard listeners 18:14:31 jongund: what'd you change? 18:14:39 jamesn: i added a group around them 18:14:50 mck: basically nested in a list structure, they're grouped now 18:15:09 jongund: probably looking for specific child nodes, if it's deeper, maybe that's the issue. i can look 18:15:19 jamesn: that'd be good, I can't really see why it'd be an issue 18:15:24 jongund: okay, what branch? 18:15:29 mck: it's at the top of the PR list 18:15:41 https://github.com/w3c/aria-practices/pull/1160 18:15:41 jamesn: I was confused why you wanted it merged into 1.1 master, mck 18:15:55 mck: we can talk about that separately in an editors call, maybe 18:16:07 siri has joined #aria-apg 18:16:10 mck: master is now going to be 1.2 stuff except changelogs etc. 18:16:18 jamesn: so this is a 1.2 issue then, right? 18:16:31 mck: yes; we have a 1.1 branch if we need, but i'm pretty sure we're done with that 18:16:35 jamesn: okay 18:16:56 mck: i want the editors draft to reflect our recent work, but we can't merge everything into master without messing up some things 18:17:08 mck: jongund, it's PR 1160 18:17:10 jongund: I got it 18:17:18 mck: thanks! 18:17:23 There's a number of firstElementChild selectors in the menubar JS, guessing that's the root cause: https://github.com/w3c/aria-practices/blob/master/examples/menubar/menubar-1/js/MenubarLinks.js#L58 18:17:30 (also used in menubar-2) 18:17:39 mck: carmacleod made a bunch of progress on the next item, hopefully i'll get to it today 18:17:59 jamesn: why's this a dependency for 1.2? this is now merging the changes that were already made? 18:18:16 mck: there was something that wasn't consistent - carmacleod can you explain? 18:18:31 carmacleod: firstly, the files with _IDL are only in the 1.2 branch, so that's where I had to work 18:18:34 mck: that's fine 18:18:54 carmacleod: the only changes I did were to button_IDL.html and button_IDL.js 18:19:25 carmacleod: i only took the setting of attrs out of HTML; the elements were created there and set with role and aria-pressed 18:19:33 carmacleod: now that's being done in JS 18:19:39 carmacleod: I made comments on what I did 18:20:07 carmacleod: the other code was there, but I added comments. and I spruced up the comment at the top of the HTML file to say it's simple as possible, etc. 18:20:21 carmacleod: and I deleted some things that weren't relevant 18:20:45 carmacleod: question for mck - I put aria-hidden=true on the SVG in the mute button. i thought it was better. thoughts? 18:21:16 mck: shouldn't that be role=presentation or something? Why hidden? isn't it redundant? 18:21:28 jamesn: it's a child of the button, so should be presentatioal because of that? 18:21:40 mck: if it had a text equivalent, it should render, but otherwise... 18:21:52 carmacleod: it should be role=none because it's a child? 18:21:58 mck: unless it has an equivalent 18:22:09 carmacleod: either way you'd want it ignored and non focusable 18:22:16 mck: why would it be focusable? 18:22:18 carmacleod: IE11 18:22:26 mck: IE11 makes SVG focusable? 18:22:29 carmacleod: yep! yay... 18:23:03 mck: so... instead of aria-hidden, wouldn't role=none be better? if it's not being totally ignored ,that's the preferred technique? 18:23:25 carmacleod: okay, but isn't it role=none by defualt, because it's a button? 18:23:30 jamesn: it's a link with role=button 18:24:04 carmacleod: I can delete aria-hidden if need be 18:24:11 mck: we should use role=none 18:24:26 carmacleod: i can try it and see what the screen readers do, but aria-hidden seems to have the desired result 18:24:39 carmacleod: otherwise it tries to read the name of the SVG file 18:24:44 mck: weird... 18:24:56 carmacleod: yeah, tell JAWS and NVDA about it 18:25:14 mck: so for guidance, maybe let's say it's a last resort technique and shouldn't be overused 18:25:21 mck: it can have severe consequences 18:25:56 mck: I Feel like we should avoid and minimize the use of aria-hidden when we can, if the group agrees 18:26:00 MarkMccarthy: +1 18:26:17 mck: well =presentation on an image should hide the image, but... maybe SVG is weird 18:26:19 jamesn: it is 18:26:39 Sarah_Higley: would =none or =presentation prevent a screen reader from stepping into the SVG? 18:26:53 Sarah_Higley: because of that, I'd prefer aria-hidden 18:27:00 mck: to allow traversal for text nodes? 18:27:04 Sarah_Higley: yeah 18:27:22 mck: hmm. so when we say children presentational is true, is it implicit or explict? 18:27:36 mck: if browsers don't base on the role, a browser bug? maybe that's not an APG issue 18:27:45 mck: jamesn do you know? 18:27:52 jamesn: it's only an aria role 18:28:01 mck: so it should still be honored 18:28:04 carmacleod: i'd think 18:28:11 jamesn: that may not stop IE exposing the SVG 18:28:16 mck: true 18:28:36 carmacleod: it wasn't IE though, it was CHrome and the others where JAWS was tryign to read the name of the file 18:28:42 s/tryign/trying 18:29:03 carmacleod: the sublink of the SVG changes from mute to sound, and the screen reader would read the wrong information 18:29:21 mck: if it's a JAWS bug, I don't want to hide a bug... 18:29:43 jamesn: should we discuss this as part of _IDL ex or the main button ex? should we change both? 18:29:54 carmacleod: if we're discussing it, we need to change both, which I already did 18:30:21 mck: i just want to know if role=presentation does nothing. does this group think it's a bug in our code or the screen readers? 18:30:36 Sarah_Higley: is it a bug though? role=presentation strips the role, but the other info is still presented 18:30:52 mck: in accname calc, it doesn't matter, right bgaraventa? 18:30:59 jamesn: yeah, but this doesn't have text in it 18:31:10 Sarah_Higley: is the filename interpreted as text in an SVG? 18:31:50 present+ BGaraventa 18:32:11 BGaraventa: a presentational role in an SVG wouldn't do much because any text inside it would still be exposed 18:32:22 18:32:35 mck: so if there's no textual content, the screen reader doesn't present anything? 18:33:17 BGaraventa: well, it's a different naming calculation. if something was in a description it'd come through, but if it had a label, it's a probably 18:33:32 siri has joined #aria-apg 18:33:33 BGaraventa: either way, role=presentation on it shouldn't interfere 18:33:52 carmacleod: by the way, this is an SVG child we're talking about. the use href 18:34:03 BGaraventa: I'm not familiar with that, unfortunately 18:34:37 carmacleod: I'm just saying role=presentation or =none on the SVG won't have an effect on the child, whereas aria-hidden kills the whole thing 18:34:50 mck: so maybe this is a good example to explain -when- to use aria-hidden appropriately 18:35:13 mck: like a specific, good use of -hidden. this doesn't promote overuse, but rather is specific to the issue 18:35:31 mck: just want to make sure we're providing the best guidance. okay, let's stick with aria-hidden then 18:36:21 BGaraventa: I'm not sure who's working on the naming spec for some of these things we're talking about, but it's being worked on 18:36:57 mck: anything else for third milestone review? [laughs] 18:37:17 rrsagent, make minutes 18:37:17 I have made the request to generate https://www.w3.org/2019/09/03-aria-apg-minutes.html Jemma 18:37:17 mck: seems like everything else in there is pretty quiet in there 18:37:48 mck: okay cool, this is looking good. we don't necessarily need all of this ready for the WD jamesn 18:38:13 jamesn: yep it's good. essentially, group for listbox, meter, row/colindex won't go in 18:38:33 mck: suggesting we skip to tooltips if nothing for tab 18:38:37 carmacleod: I do 18:38:37 TOPIC: Tab carousel example 18:38:53 carmacleod: should the tabpanel take focus? right now it does, but it feels like an extra tab stop 18:39:10 mck: jongund? 18:39:19 jongund: that's what the tabpanel design pattern says 18:39:22 carmacleod: where? 18:39:38 mck: it's optional, when the tabpanel is static and has no interactive content or that content is at the bottom 18:39:40 jongund: let me look 18:39:50 carmacleod: not in the pattern, maybe the example 18:40:00 siri: the example has a tab stop on the panel 18:40:18 jongund: it's in the test cases for tabpanel, but i can change the tests 18:40:23 siri: no, i'd rather not 18:40:30 carmacleod: only if we all think it's a good idea 18:41:12 jongund: is there a way to test individual files now? seems I can only test directories 18:41:22 mck: that's a good question, i'm not sure 18:41:25 jongund: used to be able 18:41:33 mck: fixable if broken, we'll check into it later 18:41:59 mck: in any case, tabpanel shouldn't be a required part of the pattern, so not required here. question now is, should the tabpanel be focusable? 18:42:22 jongund: I didn't have it focusable until I did the tests valerie wrote, where there were errors thrown. then I added the focus 18:42:25 @jongund running `ava test/tests/path/to/file.js` isn't working to test a specific file? 18:42:50 siri: I would prefer to have a tabindex on the panel, so a screen reader user doesn't miss anything and they can choose how to interact 18:42:59 mck: that's assuming someone is tabbing though 18:43:37 siri: if there's no focusable element inside the panel, i'd prefer to have it so I know I'm starting to interact with it 18:43:45 mck: in this case there's links inside all of them etc. 18:44:05 siri: but if someone uses this code and there's nothing inside, that might be an issue 18:44:11 jongund: yeah, there's nothing in the pattern 18:44:15 carmacleod: only in the examples 18:44:21 mck: sounds like an issue to address 18:44:34 carmacleod: we should probably say something in the pattern, either optional or required 18:44:41 jongund: nothing in the spec either 18:44:47 carmacleod: i can open an issue 18:44:50 mck: that'd be great 18:45:01 jongund: should I take it out? or leave it in? 18:45:30 mck: we don't want to do stuff here if it's not something good for usability - siri? 18:45:58 siri: I wouldn't keep it as optional, i'd prefer always having the tabindex. 18:46:47 siri: in my opinion, i'd prefer to have it on the tabpanel 18:47:12 mck: speaking as a screen reader, it seems extra to me, but i'll defer to group 18:47:39 jongund: issue with the slider here, the images are a link, but sometimes they might not be. so, possible you can miss content if you tab through things 18:47:47 carmacleod: everyone's different, yeah 18:48:12 jongund: might see it if you're reviewing, but not tabbing. but if you're tabbing, maybe youre not looking for interactive content 18:48:21 jongund: i guess the real issue is consistency 18:48:44 BGaraventa: I recommend you make it focusable, if there's no interactive elements in it and so people don't miss it 18:48:51 s/you make/to make 18:48:59 carmacleod: i'll open an issue to add that advice to the pattern 18:49:14 jongund: so it'll be required or optional? 18:49:26 carmacleod: probably required, and keep it on this example 18:49:31 jongund: yep, planned on it 18:49:36 TOPIC: Tooltip conflict 18:50:20 mck: in summary - this is about specific language 18:50:54 mck: i think the issue is that our language doesn't say anything about mouse hovered on a tooltip; that we don't generally provide mouse guidance in APG patterns 18:51:08 mck: is this an actual conflict? should we change the wording? or say it's not an issue? 18:51:35 carmacleod: tooltip is REALLY complicated. mouse is integral to using tooltips, mostly, but depends. it's not something I've been easily able to resolve 18:51:55 Sarah_Higley: I'd be in favor of adding wording about mouse behavior for tooltips, becasue it's easy to get that wrong 18:52:29 mck: across most of WCAG we don't usually have mouse reqs, but for this specific instance, there's issues around pointers etc. 18:52:36 mck: that's an exception to the norm right? 18:52:38 carmacleod: yeah 18:52:59 git --help 18:53:10 github: 18:53:26 github: https://github.com/w3c/aria-practices/issues/811 18:54:06 mck: so what i'm hearing is we want to describe accessibility related pointer requirements in the APG pattern 18:54:08 carmacleod: i think so 18:54:12 Sarah_Higley: yes, definitely 18:54:35 Sarah_Higley: the difficulty is how to describe it, certain interactions, etc. but that can be part of another discussion 18:54:50 mck: i'd really welcome someone to draft some changes to the pattern in a PR, if someone can 18:55:22 Sarah_Higley: I can, i've been writing about tooltips lately. i think there's some stuff about dismissal that is controversial that'd be worth discussing before a PR 18:55:36 mck: a draft PR can contain anything, even if it'll go down in flames [laughs] 18:55:38 Sarah_Higley: okay 18:55:51 carmacleod: or add stuff to the issue before ready for the PR 18:55:58 group: thanks Sarah_Higley 18:56:17 Sarah_Higley: I planned on opening an issue anyway, so let's just go all in! 18:56:42 TOPIC: APG Language for new ARIA feature 18:57:17 mck: well jamesn put his name on this, so maybe we'll discuss next time. but a related question for the group 18:57:53 mck: we were talking about flagging things about what's new in 1.2, a paragraph etc. something. once a PR is available, we can discuss more 18:58:13 mck: but the rabbithole is about how well things are supported, kind of what aria-at is addressing 18:58:25 mck: question becomes where to draw the line of what we say and do 18:58:48 carmacleod: for instance, the slider role 18:58:54 carmacleod: increment and decrement 18:59:06 mck: so that's why jamesn said issue 8 was related, known gaps for mobile 18:59:38 mck: i was thinking of things like key shortcuts, where Apple explicitly said they weren't supporting it, so do we add something saying so to the APG, etc. 18:59:57 mck: and I worry a little about maintainence etc. unless we find a crafty way to automate 19:00:26 mck: it's a common question, wonder if anyone has any solutions without creating maintainence problem 19:00:32 s/problem/problems 19:01:05 carmacleod: i ran into the same issues - not everything works everywhere. where do we stop 19:01:09 mck: that's the golden question 19:01:43 mck: if we can come up with some criteria... like, if it's in 1.2 it's implemented in 2 browsers, etc. but that leaves a lot of room for lack of adequate support 19:02:28 mck: unless some support gap is blocked, then i'd think that's something we don't want to mention. but if there are major blockers we know about and when they're being worked on, that could be helpful 19:02:40 mck: but then i wouldn't want people to assume that everything else is supported 19:03:53 Jemma: Korea's certified accessibility dev group is asking the same questions, so like a survey or something may be useful. this is a global, complicated, problem 19:04:02 mck: well, more fuel for the aria-at fire I suppose 19:04:29 s/so like a survey or something may be useful/ according to the survey I did 19:04:58 zakim, who is here 19:04:58 MarkMccarthy, you need to end that query with '?' 19:05:01 zakim, who is here? 19:05:01 Present: jongund, CurtBellew, MarkMccarthy, Matt_King, carmacleod, Jemma, BGaraventa 19:05:03 On IRC I see siri, CurtBellew, RRSAgent, Zakim, mck, Jemma, jongund, Sarah_Higley, carmacleod, MarkMccarthy, MichaelC, github-bot, jamesn, yatil-away, ZoeBijl, trackbot 19:05:18 present+ Scott_V 19:05:34 present+ Siri 19:05:39 regret+ ZoeBijl 19:06:04 RRSAgent, make minutes 19:06:04 I have made the request to generate https://www.w3.org/2019/09/03-aria-apg-minutes.html MarkMccarthy 19:10:31 s/speaking as a screen reader/speaking as a screen reader user 19:11:32 s/CHrome/Chrome 19:11:48 s/defualt/default 19:11:55 https://github.com/w3c/aria-practices/issues/960 19:12:09 s/presentatioal/presentational 19:12:55 we just talking about the teststing 19:13:10 s/teststing/testing 19:13:18 RRSAgent, make minutes 19:13:18 I have made the request to generate https://www.w3.org/2019/09/03-aria-apg-minutes.html MarkMccarthy 21:05:36 Zakim has left #aria-apg