Meeting minutes
APG redesgin project update (Rich Noah)
Rich_Noah: we've looked at all the feedback we've gotten so far and tried to separate between functionality, usability, and content
Rich_Noah: we've got the timing set, for how long it'll take to accomplish each goal, and Isaac is going to have to go through and see what he'll need to change. looks like we can start changes next week, after which Isaac can start usability reviews
Rich_Noah: he may start those the week of 13 September
Matt_King: did you list the changes you'll be making?
<Jemma> https://
Rich_Noah: not yet, we're still sorting out some details. once we do that, it'll be included in the issue
Matt_King: awesome, thanks so much!
jongund: what will people be asked to do in the usability study?
Rich_Noah: it'll follow the normal path of giving a task and recording what barriers or detractors exist. Isaac will define that
Matt_King: they'll all be related to the information architecture
Rich_Noah: yep that's right
Matt_King: so essentially top level nav, how that's represented, and general layout. we're not going very deep
Rich_Noah: correct
Matt_King: so we're not looking _specifically_ at the example pages or jump to functions, it's just the presentation
jongund: that makes sense, I was just curious about the tasks
Matt_King: would Isaac be able to give us an update on that next week, Rich_Noah?
Rich_Noah: I can ask him, sure!
Matt_King: we should note that there's US holiday weekend coming up, so we may want to shift around the 7 September meeting. Should that be another topic Jemma?
Jemma: sure
<Zakim> Jemma, you wanted to ask who will be the testers and how they will be recruited.
Jemma: I was wondering who the target testers are?
Rich_Noah: Last I heard from Isaac, APG members, Slack a11y group participants (if they choose) as 3rd party input
Jemma: that's right, cool,, thanks!
Meeting for 7 September?
Matt_King: 6 September is Labor Day in the US.
Jemma: Objections to no meeting on 7 September?
Matt_King: I'd like to have a meeting if there are enough people to do so, unless lots of folks with extended plans
Matt_King: if we didn't meet, the next meeting would be 14 Sept
Jemma: Let's decide next week
Tooltip design meeting Update (Sarah Higley)
sarah_higley: we got time to talk about behavior but not semantics, yet
sarah_higley: looking at the error example, conclusion was that "people do it, but should we?"
<Jemma> feedback "Notes from the meeting on 8/17:
<Jemma> Example brainstorming:
<Jemma> example of double-tooltip: info and error on the same input at the same time (had pushback on showing this as an example, question of whether it's actually a common enough pattern to warrant showing it + it has a lot of drawbacks)
<Jemma> Show both an icon button toolbar w/ tooltips and a single icon tooltip
<Jemma> form field tooltip
<Jemma> toggletips and non-modal dialogs
<Jemma> Need to make sure it's clarified that a toggletip is not a tooltip, and be very clear on which examples don't use the tooltip role
<Jemma> Guidance section:
<Jemma> General guidance section:
<Jemma> clearly define traditional tooltip, and what that is vs. toggle-tips/dialogs
<Jemma> a traditional tooltip supposed to replicate the host tooltip/title attribute
<Jemma> that's why there's no interactive content or structured content in a tooltip
<Jemma> segue to next section: if you need anything that couldn't be covered in a title attribute, you also shouldn't put it in a custom tooltip. You'd actually want toggletip/dialog
<Jemma> Behavior:
<Jemma> dismiss on delay: stay away from auto-dismissal entirely -- because if APG shows it, people will complain that their tooltip fails WCAG. APG should not show WCAG-failing examples (Scott, Eric, Jerra all agree)
<Jemma> dismiss on ctrl AND escape (optional) in our example, specify why escape has issues (e.g. in a modal)
<Jemma> (OPTIONAL): delay to show (browsers do)
<Jemma> two examples, toolbar w/ bunch of icon buttons = delay, tooltip on form field = no delay
<Jemma> needs note that explains why optional, why one person might want a delay but another might not, but be internally consistent
<Jemma> Touch:
<Jemma> apple has done some work on this, e.g. first tap shows tooltip, second performs action
<Jemma> apple again: title attribute shows on long press (don't think we can replicate this?)
<Jemma> should we actually do the one touch to show tooltip, second to perform action (straw poll: don't do this, seems counterintuitive)
<Jemma> Suggestion: show the tooltip on touchstart, dismiss on touchend
<Jemma> Voice: doesn't work with this
<Jemma> Need to check with reader view, HCM (e.g. does a tooltip get inserted into the text in reader mode? Does using HTML hidden fix it if it does?)
<Jemma> Doesn't work on a static element either, need to specify that it's bad practice and why (keyboard triggering and screen reader support). Good place to note that one would need a toggle tip instead.
sarah_higley: it's important to clarify what a traditional tooltip is vs. some alterations. It was clear traditional tooltip should emulate browser behavior (title)
sarah_higley: it's important to show a few different examples because people may be familiar with different styles
sarah_higley: another behavior that might be optional is delaying to show, which browsers sometimes do
sarah_higley: and clarify why you might want delay or not
sarah_higley: we talked about touch a bit. what seemed the most promising was "show on touch start, hide on touch end" which shouldn't interfere with mouse, keyboard, eye control, voice, etc.
sarah_higley: we should double check with reader views and HCM, and if focus behaves weirdly. guidance should be provided for each of those too
sarah_higley: some specific examples we talked about were form fields
siri: you're not talking about tooltips on non-focusable elements, right?
sarah_higley: we did in the sense of "don't do that"
siri: ah ok, I see lots on non-focusable elements which causes issues
siri: what about browse mode with screen readers?
sarah_higley: generally or specifically on non-interactive elements?
sarah_higley: it depends on if focus follows the virtual cursor, and if they work with hover or focus
sarah_higley: the cool thing that came from the meeting was touch start/end
sarah_higley: which could extend to on.focus and on.blur
Matt_King: is there any discussion about the relavance of the tooltip role itself, and whether or not it's helpful or useful? i'm wondering if, when we test this with a screen reader in ARIA AT, are we going to have an assertion related to the role itself?
Matt_King: also, do we even need the tooltip role? is that on the agenda to discuss?
sarah_higley: yes, i'm also interested in that. we didn't get to semantics last time, but hope to this time.
sarah_higley: i'm guessing that'll be the main thing we need to figure out now
<Jemma> pleses join the second last tooltip meeting today at 2pm in cst
Matt_King: so we haven't written assertions for aria-describedby yet, but as we all know it's supported differently across screen readers
Matt_King: it won't be a trivial discussion to get screen reader devs to agree
Matt_King: i don't know if tooltips are a special case and should be treated a special way, like error messages and aria-errormessage
<Jemma> https://
<Jemma> tooltip zoon meeting link is above.
Matt_King: for instance, what if a tooltip contains an error message? we'll need to think about how to give a hint whether something should be automatically announced, and when
Matt_King: i feel like we don't have enough expressions of intent in ARIA for how to deal with some of this stuff, and what should be automatically done, etc.
<Jemma> +1 for discouraging tooltip for error message
sarah_higley: a few things: for the error message, good guidance might be "dont use tooltips for error messages," because those messages are critical and tooltip behavior is inconsistent
sarah_higley: relavent to tooltips specificially, the text in it probably can't be reached with virtual cursor so therre's not necessarily another mechanism to reach it
sarah_higley: generally, the text isn't "on" the page - opposed to a form field with a static description, that's _on_ the page
sarah_higley: maybe hammer in the guidance that "aria-description/-describedby is inconsistent, so don't use for critical behavior"
Matt_King: I don't want to teach people not to use something because ARIA is messy. rather, I want our guidance to be focused around how ARIA should be rendered
Matt_King: maybe it's temporary guidance. something that'd probably be useful to come out of this group is a clear statement of where ARIA falls short WRT tooltips
Matt_King: if we can get some help defining ideal tooltip behavior, that'd give us some more info about what's missing from ARIA to make that work in the real world
<Jemma> +1 to matt
sarah_higley: not just ARIA, the interaction is also very inconsistent. so even ironing out ARIA won't make something foolproof
Matt_King: if we had more consistent behavior in browsrs and AT it'd be clearer to people how these things should work, and would help with more long-term approaches
sarah_higley: i think so too
Matt_King: thank you so much Sarah, I super appreciate your effort
Jemma: any other feedback for Sarah?
siri: how many words are we allowing in a tooltip, or recommendations for something like?
sarah_higley: not sure how we're going to determine the recommended number of words, but that's a good point
sarah_higley: no interactive items for sure, that's a toggle tip
Jemma: can you share who was in the first meeting?
sarah_higley: I didn't note who was there, but 8 people
Jemma: do you expect the same people or different?
sarah_higley: maybe some others in addition, as they couldn't attend this one
sarah_higley: are there strong opinions on the tooltip role from this group? I don't have any, and not sure if anyone who comes will have any
jamesn: if we recommend it, it should *do* something
Matt_King: i think that if we were going to recommend it, it should be with the idea in mind that it does something for AT. a suggestion for "this is what it should do" and a good reason for why
Matt_King: I don't want to put us in the spot of having a solution looking for a problem
Matt_King: jamesn, is there a strong reason not to deprecate a role?
jamesn: it _does_ have mappings to things in AT, it's just that AT chooses not to do anything with them. I'd have a hard time justifying deprecation
jamesn: there's a lot of things in ARIA we don't really want people to use, but deprecating is a bit of a nuclear step
Matt_King: another thing to keep in mind then - just because we have a role it doesn't have to be directly surfaced to users
Matt_King: if AT can benefit from knowing which element is a tooltip and it can do something under the hood, then sure, that's neat
jamesn: maybe something like screen magnifiers could use it to make sure to show the tooltip if it comes into view, just spitballing an idea
jamesn: they were created for a reason in the past, i'm just not sure what or why
Matt_King: I'm not sure what system developers would do if that role wasn't there, that's important too
sarah_higley: maybe guidance saying "it's not used, but it's present in the API, and it's not doing harm, and it may be helpful in the future" -- or something like that
Switch pattern
<Jemma> https://
Matt_King: here's a link to a preview of Jon's pattern
Matt_King: it feels like the description ("A switch is a type of checkbox that has on/off values...") isn't something we want in the APG. Everyone's thoughts?
jongund: that's how it's described in ARIA spec
jongund: it has true and false, the mixed value is invalid. Not sure we want to veer too far away from spec
Matt_King: to me, it doesn't convey an answer to "why use a switch instead of a checkbox?"
Matt_King: we can't say that an AT would say "on/off" vs "checked/not checked," right?
Matt_King: in other words, and simply, how is a switch different from a checkbox?
jongund: basically it comes down to the visual rendering
jamesn: normally the difference is that switches change a state immediately whereas checkboxes often-but-not-always require a submission. this may not always be the case but is often the case
Matt_King: because there's no switch state property in ARIA, and because it's a subclass of checkbox, does that mean if an AT reads it as "switch checkbox, checked," should that pass as a support for switch?
jongund: i'd say no
jamesn: i'd say intermediate. it's a "pass with exceptions" kind of thing
sarah_higley: well, why wouldn't that pass? if a screen reader decides to announce it as a checkbox, say for intution sake, why should that be incorrect?
jongund: to that, if checked/not checked is the same, why have the switch role at all?
Matt_King: Apple wanted something that allowed web UIs to work like iOS UIs, so we made it a subclass of checkbox as a compromise. now we're running into this issue in real life, that's a bit confusing
Matt_King: because the ARIA spec doesn't have anything in it that says the checked attribute should be annonuced differently if that attribute is on a switch...
jongund: i still think that, because it's a switch, it should say "on/off."
Matt_King: what do we tell authors about why a switch should be used? if it behaves like a checkbox, then use a checkbox. if it's about visual rendering, that goes _against_ what we've written in the APG
Jemma: i think writing a note for the spec would be helpful
sarah_higley: the trouble is that it _is_ a visual rendering thing. what jamesn was saying isn't always true anymore. functionally, people use the switch role if it looks like a switch. things like that aren't often used in forms, whereas checkboxes can be used anywhere.
sarah_higley: tl;dr - people use the switch if the thing is supposed to look like an Apple switch
sarah_higley: NVDA moved to announcing switches as checkboxes, right? I don't think it'd be good to say they're wrong, they did that for a reason
jamesn: that's their decision though. if they want to do that, fine. but if a user is reading "click on the switch" and NVDA says it's a checkbox, the user should be aware of those difference
jongund: the competitor to using aria-checked was aria-pressed, right?
siri: a togglebutton, right
jongund: so say for instance, I decided to use a button with aria-pressed to make my switch, instead of a switch role, but it visually looks like a switch. is that wrong?
sarah_higley: i don't think so. we do have 3 different things that have significant overlap, and they all work. so... [chuckle] if they all work in practice, then...
jamesn: right
Jemma: let's call things here --
Matt_King: we'll continue next week. I have a lot of other questions, and am more conflicted about this. it's a good discussion!
Update on Merged and Open PRs
Matt_King: basically, jongund has already responded to feedback on radios, that's awesome thanks so much!
Matt_King: i'm working on burning down this list, we're getting there. jesdaigle is working on some things too.