Meeting minutes
<jamesn> /me regrets - swamped
<sarah_higley> does anyone have a direct zoom link? I'm getting security errors trying to access the w3c meeting info page
one sec!
<sarah_higley> thanks so much! ♥
Modal dialog questions
mck: we have a couple issues out there, but there are 2 that are pressing
<Jemma> https://
<Jemma> dialog issue
Matt_King: issue 1615 - saying our dialogs don't close when you click outside of them... not sure if this was itentional or an oversight
Matt_King: seems like we should just make it part of the implementation
sarah_higley: i also noticed these don't have close buttons...so lets add both. there's a cancel button but not a close button
Matt_King: seriously?!
sarah_higley: i know!
Matt_King: well last time we checked on these, it was more about technical issues related to iphones, so that's fair I guess. good catch Sarah!
<carmacleod> https://
Matt_King: so we'll add close button AND that.
ZoeBijl: well i have some conflicts about it. if you click outside of the modal, is the data you already put in saved? or deleted?
sarah_higley: it should be saved
ZoeBijl: yes, but is that what people will do? not sure this is the place to do that
Matt_King: so then in that case, is "cancel" different than "close"?
ZoeBijl: doesn't WCAG say...
Matt_King: right, easy undo would cover that
ZoeBijl: what i find (elsewhere) is that i'd click outside it accidentally and it wouldn't save the data - it's frustrating!
Matt_King: so there's a couple choices - have the X icon for mouse users, and have that exactly duplicate the cancel button. OR distinct functionality where "close" doesn't remove the data but "cancel" does
Jemma: yep, and they each have their own tab stops
Matt_King: right
MarkMccarthy: +1
sarah_higley: another possibility is to get rid of cancel entirely and just change it to a close button
Matt_King: i like that too!
Jemma: yeah!
Matt_King: maybe we'll have to look at the project to make sure we're covering all bases, but that make sense
MarkMccarthy: i think that's a better UX
Matt_King: yeah, less complexity
<ZoeBijl> For the minutes, this is the WCAG criteria that Matt and I were discussing: https://
thank you Zoe!
Matt_King: so then, any objections to removing the cancel button and replacing with a close icon/button in the upper right?
Jemma: and saving the data?
[no objections]
Matt_King: [committing the actions to an issue]
Matt_King: our actions are in a comment in issue 1615!
Modal Dialog - Tab Ring
<Jemma> https://
Matt_King: next item, issue 1772. Says APG should allow focus to go outside the dialog. After many other comments... Sina is asking if this is anything for ARIA to handle or not.
Matt_King: but sarah_higley's last comment was suggesting not putting as much onus on authors
<Jemma> sarah's comment https://
sarah_higley: the reason i put that in is that when i've suggested using inert to handle focus managment, i've had pushback citing ARIA practices.
Matt_King: does our break anything really?
sarah_higley: so this isn't exactly about our example, but the wording in practices. generally, active focus management tends to be buggier
sarah_higley: basically, it just seems like inert is making things funky
Matt_King: this is one of those reasons the APG redesign project is discussing scope increases, so we can better test and write for things like this. this'd be lovely for something like that
<Jemma> sarah -"Could we have some wording along the lines of "Tab does not move focus into the inactive parts of the page while the modal is open", then follow up with browsers and the HTML spec?"
Matt_King: in the meantime, do you think we should add a note to the pattern, if so what to add? or what to do?
sarah_higley: could we have something in the language like, "we think the best UX is to keep focus trapped in the dialog, but this should be handled by browsers..." etc etc. lots of wordsmithing, of course
Matt_King: i think it'd be better if we raised the issue to the right places first. as well as some broader consensus - I don't want APG to seem so monolithic
Matt_King: maybe something like "Do your best to make this work, we know it's rough in spots" or something similar
sarah_higley: Alice basically mentioned it'd be hard for browsers to make this change because people are used to it, but seemed a little optimistic
Matt_King: Well, I'd love to see it be more general, so tabbing stays in the webpage completely regardless of a dialog. it'd be so much easier in so many ways
Matt_King: especially on Mac, it's so hard to skip the browser chrome
sarah_higley: I thought that was just me!
[various comisserating about tabbing in browser chrome]
Matt_King: i don't have a good answer about _that_, but I'm hopeful we could find some consensus about the modals
sarah_higley: so HTML doesn't specify how browsers handle their chrome, right?
carmacleod: yep
Matt_King: could it be part of spec for a dialog element?
sarah_higley: _that_ could be part of HTML, though I don't think i've seen it. but adding something specific for browser modals and webpage modals?
sarah_higley: to be clear, i don't think we need an HTML change or addition, i think it'd be a behavior thing. (and I don't think we need a specific example for each either)
Matt_King: what spec does tabindex live in? i vaguely remember something about that, some stuff to do with tabindex=-1 and ARIA...but I don't remember the spec. Maybe this would go in _that_ spec
<carmacleod> https://
carmacleod: maybe it'd go in this one (pasted above)
Matt_King: so i'd support that proposal, adding some language around inert. then we can publically try to rally support
sarah_higley: sounds good to me!
Matt_King: i'll get to this unless anyone else wants to file that issue
Slider pull requests
Matt_King: so, focusing on the thermostat slider - let's start with Jemma's questions
Jemma: been testing these examples with TalkBack, finding repeated problems in reading the value on sliders. i'm getting percentages, not any other values
Matt_King: on iOS, the color view slider was reading the number correctly. i didn't check the theromstat one with iOS yet
carmacleod: i think Patrick L. did some testing and came to the conclusion that that Android needs work, not our code.
https://
jongund: iOS is reading the aria-valuetext, so that's working okay
Matt_King: does color viewer have -valuetext?
jongund: i found the same issues with TalkBack, just telling me percentages
Jemma: it seemed like the math was off too
Matt_King: so my questions - in the thermostat description it says there's 3 sliders but there's only 2, is that right?
Jemma: yes
Matt_King: cool that's an easy change. so, next: do we want to mix buttons into this? it feels like adding complexity that doesn't necessarily help the example; i feel the buttons are a distraction
Matt_King: they _do_ add a lot of aural clutter, for what that's worth
carmacleod: did we add them originally because we thought that was the mobile solution?
Matt_King: i think...
carmacleod: so now that they work pretty well, at least on iOS and iPadOS, maybe we can remove them
jongund: they're labels, so i think when you press a label (like on a radio button) it should change it
carmacleod: so then maybe it doesn't need to be a <button>?
Matt_King: yeah... and does it need all the words, or could it be more graphical?
jongund: the labels need to be visible since they correspond to the slider
carmacleod: i think they're nice, but they don't _have to_ be buttons
Matt_King: they could be clickable and tappable
Matt_King: **pointerable** [laughs]
Matt_King: that should simplify the documentation and aural experience
Jemma: so i have a minor issue with the fan speed example - i can set the speed but can't confirm that it was set successfully. does it matter that a screen reader wouldn't get that confirmation?
Matt_King: if it was working correctly, it'd tell you what the current setting is - probably also a TalkBack problem
jongund: did you want me to update the links in master etc. when I have a PR?
Matt_King: we should update the link to the one that's already merged, and this one
jongund: but the other examples should be updated
Matt_King: yes, for the one that's already merged
jongund: i haven't been updating those, you have, so I wanted to check
Matt_King: if you'd like to, go for it!
Matt_King: so, after I do editorial review...
Jemma: only code, test, and Windows a11y reviews are left
Jemma: what to do about TalkBack then?
carmacleod: open bugs with them?
Matt_King: for extra credit
Matt_King: it'd save work from the ARIA-AT project
<Jemma> https://
carmacleod: one thing - I did create a PR for updating the link in aria-practices.html, 1803, for the color slider. that's already done, just needs to be merged
Matt_King: i'll take care of that, thanks!
Matt_King: multi-thumb slider is next, 1758
<Jemma> PR 1758
https://
Matt_King: can someone take on visual design review in the next two weeks?
Jemma: I can if no one else is available
Matt_King: i'll put Jess on this as well (for code and test)
Jemma: shall we split accessibility testing again?
MarkMccarthy: yeah that'd be good
carmacleod: i can do MacOS testing again
Jemma: and I can do TalkBack again
<Jemma> zoe, would you like to try talkback testing as third attempt?
<ZoeBijl> ]/
jongund: i like the idea of having another example that doesnt have valuetext
Matt_King: that would be nice, but isn't exactly necessary right now