– DRAFT –
ARIA Authoring Practices Task Force

<Jemma> https://github.com/w3c/aria-practices/wiki/May-17%2C-2021-Agenda

<Jemma> meeting?

<jamesn> https://www.w3.org/2021/05/18-aria-apg-irc

user research update

<Matt_King> Isaac: over last 2 weeks have been conducting stakeholder interviews. last one is today.

<Matt_King> Rest of week will be cynthesizings findings.

<Jemma> s/user reserach update/apg redesign project user research update

<Matt_King> from 10 people total.

<Matt_King> Will be working on use cases and user flows.

<Matt_King> Next will have more thorough report.

<Matt_King> Is there a place in repo where I should publish.

<Matt_King> mk: do we have separate repo for transform scripts

<Jemma> mck: has concern about mixing redesign project with apg isseus

<Matt_King> mk: would prefer separate repo

<Matt_King> jg: agree

<Matt_King> Isaac: will talk to seth.

<Matt_King> mk: should I ask michael to set up anothr.

<Matt_King> jg: will make easier for others who are not focused on current apg.

update on merging slider examples

<Matt_King> mk: I merged rating slider

<Matt_King> temperature slider has pending review from carolyn

<Matt_King> CM: will get to it later today

<Matt_King> jemma: seek slider just neds Matt and Jes.

<Matt_King> Jemma: still have a small android issue but good for now

switch

<Matt_King> PRs: 1891, 1892, 1893

<Matt_King> Carolyn approved

<Matt_King> mk: I haven't had time to read it yet

<Matt_King> jg: it talks about which element is used to create the switch; this deviates from other patterns.

<Matt_King> In this case, it talks about how it impacts AX.

<Jemma> can someone scribe while matt is talking?

<Matt_King> We don't necessarily enunmerate this well in other patterns.

<Matt_King> so interested in fqeedback on how we address this type of info in the pattern.

<Matt_King> CM: agree this kind of info is a good learning tool

<Matt_King> Jemma: can we have another reviewer?

<Matt_King> James: yes

<Matt_King> Jemma: pr 1892

<Jemma> https://raw.githack.com/w3c/aria-practices/switch/examples/switch/switch.html

<Matt_King> no reviewers assigned

<Matt_King> carolyn: can add me as functional reviewer

<Matt_King> Siri: accessibility review on mobile

<Matt_King> mk: sr review for mac and windows

<Matt_King> mk: should be same people on both 1892 and 1893

<Matt_King> should be quick

<Jemma> https://raw.githack.com/w3c/aria-practices/switch-button/examples/switch/switch-button.html

<Matt_King> jg: one of the other differences among the 3 examples is how they create the visual effects

<Matt_King> illustrates 3 different ways of creating visual effects in hcm

<Jemma> https://raw.githack.com/w3c/aria-practices/switch/examples/switch/switch.html

<Matt_King> Should be very useful to support our HCM documentation.

update on merging slider examples

tooltip

<Matt_King> Jemma: looking at youtube and found sara's talk

<jamesn> #deathtotooltips

<Matt_King> so asked her totalk about it.

<Matt_King> Sarah: we can show a tooltip on a pattern where it works well like a text input.

<Matt_King> Or, we could also show it on a button or link where it is a problem and do our best to make it accessible.

<Matt_King> but, it won't be totally accessible.

<Matt_King> it will alwys have problems.

<Matt_King> On text field, you can show it with a range of AT and it works fine because tapping the field does not have side effects.

<Matt_King> Button has problem that you have one pointer event that will activate the button.

<Matt_King> if we show that, it kinds of gives permission.

<Matt_King> but people will do it anyway.

<Jemma> https://github.com/w3c/aria-practices/issues?q=is%3Aissue+is%3Aopen+tooltip

JN: My opinion we shouldn't have examples that are bad examples, should not have tooltips on a button

JN: Things like a tooltip near the button

<Jemma> https://github.com/w3c/aria-practices/issues/128

JN: We should address the monster tooltips that are essentially a dialog, I don't linke, we need to help them

SH: Need to provide button to click

JN: We need to document that

SH: Tooltips on icon buttons, there is a case it is OK, say you have a navigation menu..

<Jemma> https://github.com/w3c/aria-practices/issues/85

MK: Are the ones in our tooltip example ok?

<Jemma> https://www.w3.org/TR/wai-aria-practices-1.2/#tooltip

SH: Yes, you need to read the tooltip, we could add a legend

SH: A navigation menu with icons that is partially closed...

MK: Are the tooltips... when we put tooltips with the toolbar, we did all the stuff for WCAG.

MK: I view them complementary as essential, is the main problem is with touch interfaces

SH: Other things like eye gaze and onscreen keyboard.

SH: I have not seen eye gaze with hover option

MK: The switch interface does not support hover

SH: There is mouse grid, but it is for clicking not hover

JN: There is also the voice recognition has the problem too

JK: There are hover and assistive technology issues, but where are we going with this issue

MK: We should have some kind of consensus, should we only include things that fully work

MK: We have made some things, like the toolbar

MK: I am thinking about putting in warnings, like for the slider examples

MK: We do have a plan going forward, like ARIA-AT that will provide support tables, right now that will focus on SR and not switch and eye gaze

MK: I take SH point that we give people permission to do something, is that the better approach

SH: Slider problems are AT support, tooltip it is the design of the component, it will always have problem, it will probably not improve

MK: When you think about it, a tooltip is triggered by hover, how are we soling the problem the tooltip is being used for

MK: One approach at Facebook, for touch users and screen reader users, you taap it and a hover card, make the hover card the default experience

MK: The solution is all design, nothing to do with ..., it could be on tap or hover, not just hover

MK: We might want to talk about alternative designs

BG: I had to do a buch of research on tooltips a while back, it took me a long time to to know how to do it, one size does not fit all

BG: It you have a standard tooltip, if it is in the DOM it doesn't matter

BG: When the tooltip is displayed in a delayed mannee there are timing issues with the screen reader

BG: There is like a help icon, and it doesn't appear until you click it

BG: aria-describedby doesn't work when there is a delay

BG: It will be hard to say just do that

<jamesn> +1 to toggletip

SH: Separating out tooltip from toggle tip, toggle tip, we could use this instead

Siri: A toggle tip is what we are using now, tooltips a failure for screen readers, it doesn

Siri: none of the screen reader do anythign with the tooltip role

SH: One thing is not just having example, but a decision guide, there are times when you can use a hover ...

MK: There is a help link in the toolbar

MK: There is one for navigation pattern, but I like the idea of a decision guide

MK: We do not have that in the APG yet, we are in a good place to start thinking about it again

MK: Tooltip and navigation are two areas

JK: I think this a tree to choose widget, what is out action item

MK: We have language problem in what we call things, we need something that illustrates and defines behvaiors

Siri: W have so many issues, for like different types of users and how it effects them

Siri: I agree with some examples ..., tooltip has a lot of issues, hover icon, use the title attribute

SH: The title attribute is worse that the tooltip role, it is often worse

MK: All of the WCAG exclusions that allow for bad browser behaviors, it is time to get rid of those

<Jemma> https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

MK: If HTML provides this functionality it should be an accessible experience, the issue of title attribute is a different issue, but as we expand the scope of the APG this might be one of the issues

SH: The naming description..

MK: To move forward on tooltip, if we were to have a tooltip example meeting 100% of all requirements, it would be on a input, input[type=text]

SH: I suppose a checkbox you can toggle it

SH: We can meet tooltips on button elements, have an example with the collapsable button, when the tooltip is not the sole source of the information, that they are helpful, but there is other informatino that is redundant

MK: The only solid guidance right now, only use tooltips with input type=text, and where it is redundant

MK: Give those two examples and then go beyond that like hover toggle (phase 2 of tooltip project)

MK: Does that seem reasonable

SH: Could we have toogle tip as part of the tooltip section

JN: Please!

MK: We need this strongly worded statement, we need some contrainsts

JN: We need to constrain the content in the tooltip

JN: Better to have a toggle tip ...

SH: I have done user research on tooltips and toggle tips

MK: We have some great discussion, I thnk we need to start with the pattern, is there someone who could start working on that