Meeting minutes
<Jemma> https://
<Jemma> Meeting?
Slider Example Update
<Jemma> https://
MK: On this one, there's still conflicting files but I managed to get the conflicts resolved in the temperature one
MK: we still have four pending reviewers, including me
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
Jemma: is there anything left on the other sliders?
Jon: as far as I know no, they're just waiting for merging
<Jemma> https://
<Jemma> https://
all: (organizing reviewers for 1864)
Jemma: I can send an email so that we can see where we are for reviewing, so we can merge the sliders
Radio button PR 1878
https://
CM: I looked on Windows, it works great with edge, chrome, and firefox with HCM. I reviewed and approved.
<Jemma> https://
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?
JN: it used to be that you just had to reload the page, that's a regression in firefox
<Jemma> +jamesn
CM: you can't even switch from black to white, you have to start it again
CM: I thought it was so cool Chrome is now supporting HCM out of the box
MK: those radio changes, those obviously changed how it works with HCM. I assume other than that these are still the same, right?
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
Jon: and that also fixed the problem with Firefox with rendering the radios, and we're switching to SVG more and more anyway
Jon: so I think that makes the CSS an order of magnitude easier to read and understand
MK: Carolyn when you looked at this, did you test the codepen view?
CM: no, I just tested the function. I can do that
MK: just to make sure with the change to SVG that the codepen loads correctly
CM: oh yeah, that works
MK: OK, so Jemma could you request a review from Jes Daigle on this?
MK: there are no changes to the tests, right?
Jon: no, I didn't change any of the functionality
Jemma: the regression test was successful
MK: OK, no test review
MK: so this should actually be straightforward. We should be able to merge this
Switch
Jemma: James, I was wondering what you meant about the links
JN: We don't need to talk about this here
MK: I see we have one switch that's made with an HTML input type="checkbox" and one that's made with a div
Jon: and one with a button
MK: interesting
MK: for testing for aria-at I'm not going to complain that we have three switches. All of these are feasible, practical
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
Jon: in the ARIA group when talking about switch, they talked about people using aria-pressed instead of aria-checked
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?
Jon: the purpose of ARIA switches is to communicate on or off instead of pressed or unpressed
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?
SH: it's Apple, right?
MK: yeah, on iOS they didn't want to call their switches toggle buttons
CM: switches usually look like a little square or circle going back and forth in a horizontal area
Siri: even toggle buttons can look like that, e.g. if you go on amazon prime
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
SH: I don't want us to write guidance on one vs. the other, because I don't think good guidance exists
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
Jon: so for the examples, do the examples work and are they the ones we want?
#1891 has the guidance in it
MK: so there's three examples, and four PRs
Jon: yup, just PR-happy last week
Jon: gotta get off this PR high
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?
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
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
Jon: and I referenced the caveat, and I think that's helpful to make more visible to people
Jon: I included some information about that in the guidance
MK: I'm not hearing anyone saying we don't need three examples
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
Jon: what do you call it when you only use divs to make everything?
SH: div-itis?
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
(transcription note: ðŸ˜)
MK: they're identical in every way but how they're implemented, which is unique in APG
Jon: they also show differences in how to handle high contrast
Jon: the div uses spans to create the visual effect, the button uses an inline SVG, and the checkbox uses SVG and CSS
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
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
MK: OK yeah, that's useful for that section
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
Jon: in the guidance pattern, I talk about how there's three main ways to implement this pattern
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
Jon: and techniques for HCM support
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
MK: as long as we keep the discussion of the coding things focused on the accessibility implicatoins
MK: this raises some really good editorial questions
MK: so we'll get these other things merged so we can dive into this. This is a great set of examples
MK: I like the questions you're raising
Jemma: so we're going to work on these three examples, and we'll wait for the preview link so we can review it
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
CM: currently the pattern links to three examples. We could comment those out for now
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
MK: yeah, maybe for such a simple component that's the best way to do it
Proposed Revision to Disclosure Pattern Intro
old text: "A disclosure is a <a href="#button">button</a> that controls visibility of a section of content."
new text: "A disclosure is a widget used to disclose additional information or controls. Typically, a disclosure <a href="#button">button</a> controls the visibility of a section of content."
Jemma: so there is a request asking for clarification for the control
MK: is there ever anything other than a button?
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
SH: I'm not sure I understand the problem, from the comment in the PR
MK: so a disclosure is both together, both the button and the panel. The whole widget is both parts
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
MK: I think if we remove the word "typically" in the second sentence, it's fine
MK: I guess the second sentence could just be clarifying that a disclosure has two parts: the button and the section of content
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
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
Siri: (missed question about the accordion pattern)
MK: I think the accordion pattern explains that pretty well
MK: OK, I'll take on giving feedback. That was enough for me to move this forward
Codepen project update
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
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
MK: so when you have CSS generated content...
Jon: that's part of what is sent to the screen reader
<Jemma> "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).
<Jemma> What are the accessibility implications of using Unicode symbols in CSS generated content? Is it good, acceptable, or bad?"
Jon: you'd usually have a span that you'd put it into, and then that span has aria-hidden on it
JN: but here we're just using an ::after for it, so that's not quite as easy
Jon: so we'd need to add a span
JN: or use an aria-label, or aria-labelledby with another span
CM: or use an SVG
MK: so we took out the SVG because in codepen they weren't getting rendered, right? Is that how this came up?
Jon: I don't think so, they work in other examples
MK: they have to be inline, right? Were these not?
Jon: they need to be inline SVG anyway, because we need to be able to style them.
Jon: when I tested that on other examples, when you use currentColor in other examples, they weren't adapting
MK: I"m looking at PR 1876 right now, and it has some failures, not sure what they are
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?
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
CM: and when we do the currentColor trick we get good HCM things going
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?
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
CM: maybe, but I think when you look at SVG vs. font icons, people say SVG is better in so many ways
CM: like the browser thinks a font icon is text, so it anti-aliases it, and the fonts aren't always getting loaded
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
CM: so the standard font will always have the same look?
JN: well, you know what font you've set for the page
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
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
SH: if we're talking about an icon that's presentational, there isn't an accessibility implication really, since they're hidden either way
JN: putting a font icon somewhere without hiding it does need a bunch of cross-UA testing to see whether it's pronounced
JN: but if you have an aria-label on the menuitem as well, there's no question on what should be pronounced
MK: I want to figure out what to do with 1876, it seems we need some people to review it
MK: I'll look into whether the unicode characters are getting read here
Jon: I can review
MK: thank you. Jemma you might also want to send out an email to people to review