18:04:39 RRSAgent has joined #aria-apg 18:04:39 logging to https://www.w3.org/2021/05/11-aria-apg-irc 18:04:47 carmacleod has joined #aria-apg 18:04:48 Zakim has joined #aria-apg 18:04:51 https://github.com/w3c/aria-practices/wiki/May-11%2C-2021-Agenda 18:04:55 Meeting? 18:05:04 MEETING: ARIA Authoring Practices Task Force 18:05:08 zakim, start the meeting 18:05:08 RRSAgent, make logs Public 18:05:10 siri has joined #aria-apg 18:05:10 please title this meeting ("meeting: ..."), Jemma 18:05:17 CHAIR: Jemma 18:05:34 rrsagent, make log public 18:05:41 rrsagent, make minutes 18:05:41 I have made the request to generate https://www.w3.org/2021/05/11-aria-apg-minutes.html Matt_King 18:05:46 present+ 18:06:03 present+ 18:06:07 sarah_higley has joined #aria-apg 18:06:13 present+ jongund 18:06:14 present+ 18:06:21 present+ 18:06:53 Topic: Slider Example Update 18:07:44 Scribe: Sarah 18:08:05 Scribe: sarah_higley 18:08:11 https://github.com/w3c/aria-practices/pull/1867 18:09:05 MK: On this one, there's still conflicting files but I managed to get the conflicts resolved in the temperature one 18:09:45 MK: we still have four pending reviewers, including me 18:10:09 regrets+ CurtBellew 18:12:29 MK: I think there's nothing left to do on the reviews that have been done on the ratings slider, the changes have been done 18:14:23 Jemma: is there anything left on the other sliders? 18:14:33 Jon: as far as I know no, they're just waiting for merging 18:14:38 https://github.com/w3c/aria-practices/pull/1864 18:15:36 https://github.com/w3c/aria-practices/pull/1863 18:15:46 all: (organizing reviewers for 1864) 18:16:47 Jemma: I can send an email so that we can see where we are for reviewing, so we can merge the sliders 18:17:07 TOPIC: Radio button PR 1878 18:17:23 https://github.com/w3c/aria-practices/pull/1878 18:17:54 CM: I looked on Windows, it works great with edge, chrome, and firefox with HCM. I reviewed and approved. 18:18:04 https://github.com/w3c/aria-practices/pull/1878#pullrequestreview-656967525 18:18:16 CM: Jon, you had some issue with HCM support with firefox? Did you read the comment that you need to start HCM first, then restart Firefox? 18:18:26 JN: it used to be that you just had to reload the page, that's a regression in firefox 18:18:28 +jamesn 18:18:32 present+ jamesn 18:18:45 CM: you can't even switch from black to white, you have to start it again 18:19:12 CM: I thought it was so cool Chrome is now supporting HCM out of the box 18:19:36 MK: those radio changes, those obviously changed how it works with HCM. I assume other than that these are still the same, right? 18:20:22 Jon: for ARIA props and stuff there aren't any changes. I did change to use inline SVG images because I thought the CSS to create radio buttons was confusing and I thought the focus should be on making things more transparent and making it easier to understand how to use ARIA properties and states 18:20:41 Jon: and that also fixed the problem with Firefox with rendering the radios, and we're switching to SVG more and more anyway 18:20:52 Jon: so I think that makes the CSS an order of magnitude easier to read and understand 18:21:02 MK: Carolyn when you looked at this, did you test the codepen view? 18:21:09 CM: no, I just tested the function. I can do that 18:21:38 MK: just to make sure with the change to SVG that the codepen loads correctly 18:21:42 CM: oh yeah, that works 18:22:05 MK: OK, so Jemma could you request a review from Jes Daigle on this? 18:22:28 MK: there are no changes to the tests, right? 18:22:36 Jon: no, I didn't change any of the functionality 18:22:41 Jemma: the regression test was successful 18:22:45 MK: OK, no test review 18:23:00 MK: so this should actually be straightforward. We should be able to merge this 18:23:18 TOPIC: Switch 18:23:36 Jemma: James, I was wondering what you meant about the links 18:23:52 JN: We don't need to talk about this here 18:24:55 MK: I see we have one switch that's made with an HTML input type="checkbox" and one that's made with a div 18:24:58 Jon: and one with a button 18:25:06 MK: interesting 18:25:42 MK: for testing for aria-at I'm not going to complain that we have three switches. All of these are feasible, practical 18:26:09 Jon: I know that issues with button is people in the ARIA group we talked about think you should use aria-pressed instead of aria-checked because it's a button 18:26:30 Jon: in the ARIA group when talking about switch, they talked about people using aria-pressed instead of aria-checked 18:26:51 Siri: when do you use switch and when do you use a toggle butotn. I think people are getting confused about that, do we want to provide examples about that? 18:27:07 Jon: the purpose of ARIA switches is to communicate on or off instead of pressed or unpressed 18:27:36 MK: Functionaliiy in a user interface I think Siri's question is really good. Why is there any reason to use a switch over a toggle button? 18:27:45 SH: it's Apple, right? 18:28:15 MK: yeah, on iOS they didn't want to call their switches toggle buttons 18:28:44 CM: switches usually look like a little square or circle going back and forth in a horizontal area 18:29:23 Siri: even toggle buttons can look like that, e.g. if you go on amazon prime 18:30:05 JN: to me the visual difference is a toggle button goes in and out and a switch goes back and forth, but it doesn't really matter 18:30:19 SH: I don't want us to write guidance on one vs. the other, because I don't think good guidance exists 18:31:03 MK: in the english language, switch is more efficient because it's one syllable, and "on" is one, while "toggle" and "pressed" are two syllables, so it's half the syllables 18:31:14 Jon: so for the examples, do the examples work and are they the ones we want? 18:31:40 #1891 has the guidance in it 18:31:50 MK: so there's three examples, and four PRs 18:31:58 Jon: yup, just PR-happy last week 18:32:02 Jon: gotta get off this PR high 18:32:42 MK: we could merge one example, and then we'll have the guidance... so are these the three examples we want? Does everyone agree we want the three examples of div, button, and checkbox? 18:33:06 Jon: I think the checkbox is very important b/c it's not something we've illustrated in many other places because instead of using aria-checked it's just using the checked property and the role 18:33:29 Jon: I think it's something that's useful because in the aria spec it says aria-checked is required, but then there's this caveat somewhere else 18:33:47 Jon: and I referenced the caveat, and I think that's helpful to make more visible to people 18:34:15 Jon: I included some information about that in the guidance 18:34:29 MK: I'm not hearing anyone saying we don't need three examples 18:35:06 Jon: I think they're all valuable because the button one shows you don't need aria-pressed, and the input one shows checked and some styling around the label, and then a div shows the classic ARIA way of doing something 18:35:25 Jon: what do you call it when you only use divs to make everything? 18:35:29 SH: div-itis? 18:36:05 MK: I remember a conversation with someone at facebook where they said this was the first reason anyone had given them to use something other than a div or a span 18:36:18 (transcription note: 😭) 18:36:31 MK: they're identical in every way but how they're implemented, which is unique in APG 18:36:54 Jon: they also show differences in how to handle high contrast 18:37:16 Jon: the div uses spans to create the visual effect, the button uses an inline SVG, and the checkbox uses SVG and CSS 18:37:34 Jon: so for the section we'll make on high contrast support, this would provide three examples that are visually similar but done in three different ways 18:37:54 Jon: so that was my main motivation for working on switches, I thought it would be a way to create examples that would be easy to discuss in a high contrast section 18:38:01 MK: OK yeah, that's useful for that section 18:39:04 MK: when we title these things and when we reference them -- we have three sliders with different purposes that have reasons for the differences -- and so I'm not suggesting we have to have any kind of difference in purpose or function in these switches, but I'm thinking how we distinguish them 18:39:20 Jon: in the guidance pattern, I talk about how there's three main ways to implement this pattern 18:39:47 Jon: so I thought that it's not just about what it does for assistive tech, but it's also addressing issues developers need to talk about 18:39:57 Jon: and techniques for HCM support 18:40:23 Jon: especially as we're tranisitioning to this new APG format that's about more than just ARIA stuff, these three examples illustrate a lot of techniques related to HCM and coding techniques 18:40:40 MK: as long as we keep the discussion of the coding things focused on the accessibility implicatoins 18:40:46 MK: this raises some really good editorial questions 18:41:02 MK: so we'll get these other things merged so we can dive into this. This is a great set of examples 18:41:08 MK: I like the questions you're raising 18:41:32 Jemma: so we're going to work on these three examples, and we'll wait for the preview link so we can review it 18:41:58 MK: I think people should do some test driving and give immediate feedback before we jump into the review process. I'm wondering if we want to land the pattern first or one of the examples 18:42:11 CM: currently the pattern links to three examples. We could comment those out for now 18:42:48 CM: would it be too tough to review all three at once? For example, if I were doing macOS a11y, I could do all three, assembly-line 18:42:57 MK: yeah, maybe for such a simple component that's the best way to do it 18:43:49 TOPIC: Proposed Revision to Disclosure Pattern Intro 18:44:24 old text: "A disclosure is a button that controls visibility of a section of content." 18:44:33 new text: "A disclosure is a widget used to disclose additional information or controls. Typically, a disclosure button controls the visibility of a section of content." 18:44:46 Jemma: so there is a request asking for clarification for the control 18:44:54 MK: is there ever anything other than a button? 18:45:29 MK: our examples are all buttons, and I don't know any other way you'd make a disclosure. Unless you think a link is acceptable, but I don't actually think a link is acceptable 18:46:27 SH: I'm not sure I understand the problem, from the comment in the PR 18:47:12 MK: so a disclosure is both together, both the button and the panel. The whole widget is both parts 18:47:41 SH: I don't know why his update seems to imply you can use something other than a button, if the concern is clarifying button vs. widget 18:47:55 MK: I think if we remove te heord "typically" in the second sentence, it's fine 18:48:02 s/te heord/the word 18:48:35 MK: I guess the second sentence could just be clarifying that a disclosure has two parts: the button and the section of content 18:48:52 MK: I think the first sentence is fine, it's just the second sentence that makes you think it could be something other than a button 18:49:13 MK: and it sounds like some people also had the same sort of reaction to the new wording, it doesn't have all the clarity that he thinks is missing 18:49:46 Siri: (missed question about the accordion pattern) 18:49:57 MK: I think the accordion pattern explains that pretty well 18:50:11 MK: OK, I'll take on giving feedback. That was enough for me to move this forward 18:50:21 TOPIC: Codepen project update 18:50:45 Jemma: we are pretty close to implementing all the codepen buttons, but there was a question from Simon about the a11y implicatoins of using unicode symbols in CSS content 18:51:46 Jon: I think the one issue is to make sure that screen readers don't try to pronounce them, so they have aria-hidden on their container element 18:52:05 MK: so when you have CSS generated content... 18:52:13 Jon: that's part of what is sent to the screen reader 18:52:13 "The approach taken here with Unicode symbols in CSS generated content is different from what menubar-navigation.html does (which uses inline SVG, without any ARIA attributes). It's further possible to use SVG-in-CSS by using data: URLs, as menubar-navigation.css did for the separator (but this patch changes it to a CSS linear-gradient to be consistent with menubar-editor.css). 18:52:13 18:52:13 What are the accessibility implications of using Unicode symbols in CSS generated content? Is it good, acceptable, or bad?" 18:52:32 Jon: you'd usually have a span that you'd put it into, and then that span has aria-hidden on it 18:52:42 JN: but here we're just using an ::after for it, so that's not quite as eason 18:52:46 s/eason/easy 18:52:58 Jon: so we'd need to add a span 18:53:08 JN: or use an aria-label, or aria-labelledby with another span 18:53:11 CM: or use an SVG 18:53:34 MK: so we took out the SVG because in codepen they weren't getting rendered, right? Is that how this came up? 18:53:41 Jon: I don't think so, they work in other examples 18:53:49 MK: they have to be inline, right? Were these not? 18:54:12 Jon: they need to be inline SVG anyway, because we need to be able to style them. 18:54:30 Jon: when I tested that on other examples, when you use currentColor in other examples, they weren't adapting 18:54:52 MK: I"m looking at PR 1876 right now, and it has some failures, not sure what they are 18:56:01 MK: do we want to avoid external SVG by replacing it with unicode, or do we want to do something different with the editor menubar? 18:56:30 CM: we should generally use inline SVGs, just a quick google of font icons vs. SVGs, and you find people saying SVG is the way to go as far back as 2014 18:56:42 CM: and when we do the currentColor trick we get good HCM things going 18:57:48 MK: so to make a decision on 1876 right now, do we want to reject this one and start over, or what's the best feedback to give to Simon? 18:58:14 JN: I think we should test on a variety of user agents and see what happens. I think it's good to have a variety of ways to do things so people can see how to do different things 18:58:29 CM: maybe, but I think when you look at SVG vs. font icons, people say SVG is better in so many ways 18:58:45 CM: like the browser thinks a font icon is text, so it anti-aliases it, and the fonts aren't always getting loaded 18:59:10 JN: so this is different from a font, because this is just a unicode character that's in the standard font. So this isn't the same thing as a font icon. This is just part of the standard font on the page 18:59:25 CM: so the standard font will always have the same look? 18:59:36 JN: well, you know what font you've set for the page 19:00:06 Jon: I think the browser will always find a font, even if it's not the one set, that will have that unicode character. I agree, it's not the same as using a font icon font 19:00:29 Jon: I agree we should have techniques that illustrate different ways as long as they work. Especially if they require quirky things like putting it in a span and using aria-hidden 19:01:48 SH: if we're talking about an icon that's presentational, there isn't an accessibility implication really, since they're hidden either way 19:02:30 JN: putting a font icon somewhere without hiding it does need a bunch of cross-UA testing to see whether it's pronounced 19:02:47 JN: but if you have an aria-label on the menuitem as well, there's no question on what should be pronounced 19:03:08 MK: I want to figure out what to do with 1876, it seems we need some people to review it 19:03:21 MK: I'll look into whether the unicode characters are getting read here 19:03:25 Jon: I can review 19:03:38 MK: thank you. Jemma you might also want to send out an email to people to review 19:04:09 rrsagent, make minutes 19:04:09 I have made the request to generate https://www.w3.org/2021/05/11-aria-apg-minutes.html Matt_King 20:31:06 Zakim has left #aria-apg