Meeting minutes
slider PRs
<Jemma> PR 1755 and PR 1758
https://
<Jemma> https://
<Jemma> https://
<Jemma> have a concern about aria hidden mentioned by Jscholes
<Jemma> sarah: Matt's concern makes sense
+1 to Matt
<siri> like for decorative glyhs
<siri> It is recognized by JAWS/chrome too
<Jemma> jon: what is role =none vs aria=hidden?
<Jemma> jamesn: we usally use aria hidden for svg
<Jemma> car: I also recomend the same thing.
<siri> I don't think so
<Jemma> car: I think there should be text of label
<Jemma> mck: we will take off aria hidden
<Jemma> jon:another issue is HCM
<Jemma> mck: the approach jon took sounds reasonable.
<siri> Chrome HCM won't work until there is addons
<Jemma> https://
siri: i remember HCM being discussed before, i think Chrome was getting the color from elsewhere, it might need a gradient to help it
Matt_King: siri, you mean to determine if HCM is on?
siri: yes
Matt_King: that's an older, hacky way if you don't have a media query
jamesn: we do have a query that works on chrome and edge
jongund: that's a separate setting from HCM with windows
jamesn: you could try canvas text, that provide s the same thing as text color, i'll add a blog post with the information
sarah_higley: i also figured out why everything's black - the parent of the SVG is a div with color:black
sarah_higley: the current color is inherting from color:black
jongund: it has to inhert from somewhere, otherwise there's no way to have current color
sarah_higley: it'd use the color of the page if nothing is set? HCM should be overriding that though, you're right
jongund: it does in firefox but chome behaves differently
jongund: forced colors, is that widely supported now?
jamesn: works in windows in edge, i presume chrome (haven't tested HCM in chrome for a while). doesn't do anything in firefox for now, but if it doesn, great!
jongund: so canvas text is like current color, canvas is like background color?
jamesn: canvas is the main thing, canvas color is whatever the text color is
jongund: this looks like it might be better than what we're doing now...
sarah_higley: i wonder if the change that broke it is SVG getting forced-color:none from the UA stylesheet. changing to forced-color:auto seems to fix it
jongund: okay, so it looks like if we override _that_ then we shouldn't have to do anything else?
jamesn: yep, windows will take care of it then
jongund: i'll try that!
jamesn: don't even need a media query, so it might be simpler
Matt_King: sounds like we have a great option to try!
Matt_King: isn't this just quite the learning experience??
jongund: i'm getting too old for all this learning!
Matt_King: so that and the aria-hidden things are the only outstanding concerns, so we're getting close i think!
jongund: do we need to mention that in the a11y features?
Matt_King: maybe we'll have a note about that, or link to what sarah's writing
Matt_King: should we?
MarkMccarthy: why not share what we learned?
Matt_King: right
jongund: the example continues!
Matt_King: another chapter!
Matt_King: so the only other one immediately affected is the two tumb slider right?
jongund: the one we just merged probably has that problem too, since this change to chrome is so new
carmacleod: right
jongund: we've got lots of SVG examples that will be broken, but if this works, i can go back and make new PRs for each thing affected (that I worked on)
sarah_higley: i'm gonna raise an issue on edge too, i don't think this is great behavior
sarah_higley: HCM is such a weird thing already, so making people remember to put this :auto on everything to make it work isn't awesome
sarah_higley: when it's using current color it should refer to the parent, and if the parent is adjusted the current should adjust too
jamesn: there could be some heuristics applied too, but that might be out of our purview
<Jemma> s/zoey/zoe
carmacleod: a quick note on the multithumb, on chrome it has that auto-alt-image annoucement
carmacleod: that's on the parent so you can't aria-hidden, but using role=none makes that bit go away. just making sure that's the right thing to do?
Matt_King: i think so. it definitely fixed the problem here, so probably
revisit accordion behaviors on demo page
[aside discussion about zoom transcripts - resuming item 2 shortly]
<jamesn> https://
<siri> Issue #1819
<Jemma> https://
<siri> sara: explaining the issue 1819
<siri> Moving series of steps which our example won't show it.
<siri> sara: having button being disabled, Jaws test feeled it it as weired
<siri> Matt: Like how Sara did for disclosure nav menu and have optional key behaviour
<siri> Sara: Don't know when to have arrow keys
<siri> I Matt: Fine to remove arrow keys from the pattern as they are not for screen reader user any way. Looking for simplicity
<siri> Matt: We can have arrow keys as optional but not having an example of it
<siri> Sara: Favor of removing it out of functional example and making it as optional
<siri> Matt: Byran had it in default as we want to demonstrate the aria-disabled behaviour
<siri> Car: As the accordion example is not step related we can remove arrow.
<Jemma> +1 to James having two issues
<Jemma> +1 for removing arrow key from Zoe
<siri> James: Getting rid of arrow keys will resolve the Sarah issue and we can open other bug to address another issue
<siri> Car: thinks to have both in the same PR
<siri> Matt: Does any one like default behavior to force one accordion to be opened all time
<siri> Sarah: Can also remove forcing to open an accordion and add a checkbox for another varient
<siri> Sarah: will fix the default one and will create another example for forced opening of an accordion