08:03:33 <RRSAgent> RRSAgent has joined #aria
08:03:37 <RRSAgent> logging to https://www.w3.org/2023/09/15-aria-irc
08:03:37 <Zakim> RRSAgent, make logs Public
08:03:38 <Zakim> please title this meeting ("meeting: ..."), jamesn
08:03:53 <spectranaut_> previous meeting on tooltips: https://www.w3.org/2023/09/11-aria-minutes#t07
08:04:07 <melsumner> melsumner has joined #aria
08:05:03 <jocelyntran> jocelyntran has joined #aria
08:06:46 <spectranaut_> matt_king: we don't have a purpose for the role tooltip, for static tooltips, we should use aria-describedby. it doesn't matter if it is tooltip role. even if it is, when you are using aria-describedby, you wouldn't know it was a tooltip role
08:06:47 <spectranaut_> scribe+
08:07:28 <spectranaut_> matt_king: the practices we have don't justify having a tooltip role. if we wanted to do something different, the role we currently have is a little bit like a blank slate. we won't break anything by adding new requirements or by changing the practices associated with that role.
08:07:36 <jamesn> q+
08:07:40 <spectranaut_> matt_king: I think apple is using it
08:08:09 <spectranaut_> jamesn: would it be useful for a screen reader use to know that some text about something was being displayed as a tooltip rather than some other kind of text on the screen
08:08:27 <spectranaut_> mario: that is not easy to answer... in some cases you need it, in other cases it's not important
08:09:27 <spectranaut_> matt_king: in my experience, when text is on the screen, and you encounter the text independent of hte element that triggered it, you  might wonder where it came from and what its relationship to other htings on the screen. the tooltip could appear anywhere in the dom. we don't have requirements that its a sibling or anything. but even just the fact its a tooltip wouldn't be helpful
08:09:45 <spectranaut_> jamesn: a tooltip associated with an input friend. if it said tooltip, would that be extra noise?
08:09:58 <jcraig> q+
08:10:11 <spectranaut_> matt_king: most likely. it might depend on how easy it is to discern the purpose of the text.
08:10:25 <spectranaut_> matt_king: if you use pronouns in your tooltip, like this or that
08:10:51 <spectranaut_> dmontalvo: in addition to that, the role is an annoyance, if the way to access is to press a dedicated screen reader key
08:11:56 <spectranaut_> matt_king: it strikes me as an engineery word, for the the most part, the words like slider or spinbutton, they are associated with an interactive widget, so you can get the control pattern. but tooltip is just a container. probably a group (my most despised word) would be just as useful
08:12:19 <spectranaut_> jamesn: I'm hearing on simple, non interactive tooltips, have the role is useless
08:12:40 <spectranaut_> matt_king: yes
08:12:59 <spectranaut_> mario: if you read visually, you have no idea where the tooltip is.
08:13:23 <jcraig> q+ to mention "help text" command, and to request the room manager turn off the camera auto panning
08:13:30 <Marcelo-Paiva> q+ to set some definition around the tooltip originated from the "title" attribute and interactive box-model tooltips (popovers) originated from CSS
08:13:48 <spectranaut_> mario: something different is if you read with the screen reader in reading mode, if you don't put the focus there (... missed this comment)
08:14:21 <spectranaut_> matt_king: we thought about putting strong language to not put tooltips on not interactive elements
08:15:02 <spectranaut_> matt_king: but why not aria-errormsg
08:15:05 <spectranaut_> melanie: thats the advice I give
08:15:07 <daniel-montalvo> daniel-montalvo has joined #aria
08:15:27 <spectranaut_> matt_king: if you have something that is the description, if you use aria-describeby or aria-errormsg, that would be sufficient
08:15:30 <jamesn> q?
08:15:36 <jamesn> ack me
08:16:14 <spectranaut_> jcraig: voice over does have a feature for reading the tooltip, called "help text"
08:16:39 <spectranaut_> jcraig: screen readers and at do separate the concept somehow
08:17:09 <spectranaut_> jcraig: between tooltip and other status text, and aria-errormsg
08:17:29 <spectranaut_> matt_king: ctrl-opt-shift-h reads aria-describedby
08:17:44 <spectranaut_> jcraig: describedby is a windows concept that was mapped to tooltip on mac
08:18:03 <spectranaut_> jcraig: we have special rules in voice over to squeeze the windows pattern into mac
08:18:24 <spectranaut_> matt_king: if there is a tooltip, description... there isn't a way to associate a tooltip with an element besides using aria-describedby
08:18:45 <spectranaut_> matt_king: is there a difference between a tooltip and something else pointed by aria-describedby
08:19:09 <spectranaut_> jcraig: there is a concepts of "custom context", which has priority and kinds, that depending on user it is surfaced differently
08:19:36 <Marcelo-Paiva> q?
08:19:45 <jamesn> ack jc
08:19:46 <Zakim> jcraig, you wanted to mention "help text" command, and to request the room manager turn off the camera auto panning
08:20:01 <spectranaut_> melanie: I was expecting the errormsg to be read in the order of the dom, but it was read before the input
08:20:05 <jamesn> ack Marcelo-Paiva
08:20:05 <Zakim> Marcelo-Paiva, you wanted to set some definition around the tooltip originated from the "title" attribute and interactive box-model tooltips (popovers) originated from CSS
08:20:13 <spectranaut_> Marcelo-Paiva: is the tableau attribute going away
08:20:47 <spectranaut_> jamesn: I don't think so
08:20:47 <jamesn> s/tableau/title/
08:20:51 <spectranaut_> Marcelo-Paiva: is the title attribute taken as priority
08:21:05 <spectranaut_> jamesn: the accessible description algorithm specifies when the title is used
08:21:33 <spectranaut_> Marcelo-Paiva: it would be good ot have a distinct definition for what is a tooltip native from the browser
08:22:24 <spectranaut_> Marcelo-Paiva: the box model tooltips from css and the code (not from the browser) on UI patterns we call those popovers.
08:22:24 <spectranaut_> Marcelo-Paiva: and tooltips generate from the browser
08:22:24 <spectranaut_> Marcelo-Paiva: separate these concepts
08:22:45 <spectranaut_> jamesn: most of the tech stacks I work on, we don't render browser tooltips, we render custom ones that we can style how we like
08:22:58 <spectranaut_> jamesn: so we don't want to differentiate browser native vs framework
08:23:49 <spectranaut_> Marcelo-Paiva: people need to know how to make a box model tooltip as accessible as a title attribute tooltip
08:24:21 <spectranaut_> matt_king: using the title attribute is itsself, the title attribute by itsself is not very accessible
08:25:10 <spectranaut_> Marcelo-Paiva: what is the goal? are we trying to decide if we change or add an ARIA attribute
08:25:31 <jamesn> q?
08:25:51 <spectranaut_> matt_king: the issue we started with was "lets have a definitive tooltip pattern" is an APG issue. the funniest thing is that there is no need for the tooltip rule to implemented what the APG says
08:26:01 <spectranaut_> matt_king: I don't want to tell people to write code that does nothing
08:26:54 <spectranaut_> jamesn: is the a use for the tooltip role that is more complicated... if we made the tooltip role do extra things -- currently people use a model for complicated "tooltip" patterns.
08:27:06 <Marcelo-Paiva> q+ to say that tooltip is a good "progressive disclosure" ui-pattern for users with cognitive disabilities
08:27:07 <spectranaut_> jamesn: maybe tooltip is a mixed model?
08:27:57 <spectranaut_> melanie: would we cause confusion by adding the ability to do a dialog like thing in a tooltip? because typically that is recommended against
08:28:43 <spectranaut_> matt_king: we could say, if we want to keep it simpler for authors, if you have aria-describedby pointing to a tooltip, if you want something interactive, add aria-modal=mixed and move focus
08:28:44 <jamesn> ack Marcelo-Paiva
08:28:44 <Zakim> Marcelo-Paiva, you wanted to say that tooltip is a good "progressive disclosure" ui-pattern for users with cognitive disabilities
08:29:25 <spectranaut_> Marcelo-Paiva: the tooltip is a good ui pattern for users with cognitive disabilities. instead of adding a lot of content, you can a icon with plan language description
08:29:34 <spectranaut_> Marcelo-Paiva: this is another pattern in the industry
08:31:20 <spectranaut_> jamesn: someone said they are working on stylable title attributes
08:31:32 <spectranaut_> jamesn: not structure content
08:31:36 <spectranaut_> jamesn: just how it looks
08:32:22 <spectranaut_> Marcelo-Paiva: one other case that hasn't been mentioned -- the content value could come from the css content property
08:32:30 <jcraig> q?
08:32:30 <spectranaut_> Marcelo-Paiva: how is that surfaced to an AT?
08:32:39 <spectranaut_> Marcelo-Paiva: that happens a lot with icons
08:33:28 <spectranaut_> matt_king: if you have an icon where you are using css content to label the icon, is that referenced in the name calculation
08:33:45 <spectranaut_> jamesn: I think we need to simplify that part of the name calculation, we should probably defer to CSS
08:33:56 <spectranaut_> jamesn: the browser is calculating it anyway
08:34:27 <spectranaut_> jcraig: I'm not sure if I missed it... but that is the goal of this meeting? better authoring practice guidelines?
08:35:31 <spectranaut_> matt_king: I'm getting concrete info from this for the APG, it sounds like there is a reasonable consensus, for static tooltip, aria-describeby is fine
08:35:57 <spectranaut_> matt_king: there is definately things to do to make the tooltip accessible. BUT we don't need to the tooltip role
08:36:06 <spectranaut_> matt_king: I think in the issue, we should say that
08:37:17 <spectranaut_> matt_king: where as for interactive tooltips, james n floated an idea, in summary, is that we would use the new aria-modal value that we have discussed in prior meetings with the tooltip role for the popovers that contain interactive or structured content
08:37:58 <spectranaut_> matt_king: in that case, should we not use aria-describedby, but use aria-details?
08:38:06 <spectranaut_> jamesn: maybe toggle tips
08:38:15 <spectranaut_> jamesn: if they are just structural, aria-details might be fine
08:38:24 <spectranaut_> jamesn: but if interactive, for a keyboard user, you need to move focus
08:38:33 <spectranaut_> matt_king: static structured content......
08:38:41 <spectranaut_> jamesn: adding three patterns is too many
08:38:43 <aaronlev> q+
08:38:49 <spectranaut_> jamesn: we an just say you have to move focus
08:39:20 <spectranaut_> daniel-montalvo: maybe the structure idea... i'm struggling to understand... it may not be obvious for people. where is the boundaries between something is structured or not structured?
08:39:34 <spectranaut_> jamesn: good question, there is definately going to be a line, where is that line?
08:39:45 <spectranaut_> matt_king: we try to draw those kinds of lines in the APG
08:41:13 <spectranaut_> matt_king: the APG tooltip issue has been open for 7 years
08:41:19 <jamesn> ack aa
08:41:19 <jamesn> q?
08:42:16 <jamesn> q?
08:42:29 <spectranaut_> aaronlev: if you use aria-details for popover... it should be visible
08:42:35 <spectranaut_> jamesn: so you focus this new thing when opening the toggletip, does using the mix fix the closing issue... or do you need to hack around to add invisible close buttons
08:47:25 <spectranaut_> (lots of stuff the scribe missed)
08:48:10 <spectranaut_> (discussion of the popover pattern from aaron)
08:49:00 <spectranaut_> aaronlev: to prong approach, informational stuff, use the existing options with more options to style
08:49:15 <spectranaut_> aaronlev: the other situation is where things are interactive
08:49:21 <spectranaut_> s/to prong/two prong/
08:50:02 <spectranaut_> matt_king: the constraints you just listed are what we want in the definitive tooltip pattern. sounds like agreement -- but it is more restrictive than what some people want, but how to do support accessibility?
08:50:02 <Marcelo-Paiva> * here are some use-cases aaronlev has mentioned https://mdn.github.io/dom-examples/popover-api/
08:50:12 <spectranaut_> aaronlev: touch is important too
08:50:21 <melsumner> q+ to say isn't title already in the hierarchy for an element's accessible name? I know in general authors are discouraged from using title attribute at all, it's just so inconsistent.
08:50:27 <spectranaut_> aaronlev: and there are lots of touch users
08:50:47 <spectranaut_> aaronlev: mason is using the popover stuff... we have discussed hint popovers should only be available on buttons.
08:51:12 <spectranaut_> aaronlev: but now I think he is leaning towards, if it is on the link, there is something in the context menu, but then people thing it comes from UA not from the page
08:51:20 <jamesn> q?
08:51:29 <jamesn> ack melsumner
08:51:29 <Zakim> melsumner, you wanted to say isn't title already in the hierarchy for an element's accessible name? I know in general authors are discouraged from using title attribute at all,
08:51:33 <Zakim> ... it's just so inconsistent.
08:51:43 <spectranaut_> melsumner: I wonder if your idea for using the title attribute... wouldn't overload the title attribute?
08:52:00 <spectranaut_> melsumner: I feel like the general advise is to not use the title attribute
08:52:15 <jcraig> q+
08:52:22 <spectranaut_> melsumner: this would change what it does... if the title value was used as the elements accessible name
08:52:29 <jamesn> q+ to say once the title attribute gets fixed we should encourage its usage
08:52:59 <Matt_King> Matt_King has joined #aria
08:53:04 <spectranaut_> aaronlev: I wasn't aware we suggest not to use the title attribute... also we only do that repair when something really needs an accessible name and doesn't otherwise have one. like a button with an image, if a user navigates to it
08:53:13 <Matt_King> present+
08:53:57 <jcraig> ack me
08:53:57 <jamesn> ack jcraig
08:53:59 <spectranaut_> aaronlev: would it be annoying if we use title too much? this was a consideration... for chrome what we do, when we provide the name or description, we tell the AT where we got that information from, so they have have filters or settings or whatever, they can chill out the screen reader in some cases
08:54:47 <spectranaut_> jcraig: in addition to what aaron said, title is use only in specific cases, it's only used for description if its not used for name
08:54:49 <spectranaut_> it
08:54:54 <spectranaut_> its the fall back for both situations.
08:55:23 <spectranaut_> it shouldn't be -- I don't think we are in danger of repeating the value of the title attribute in two places unless there is a rendering bug, or authoring bugs
08:55:24 <Matt_King> q+
08:55:42 <jamesn> ack jamesn
08:55:42 <Zakim> jamesn, you wanted to say once the title attribute gets fixed we should encourage its usage
08:56:08 <spectranaut_> jamesn: just flipping back to title -- once title gets fixed, we should encourage it's usage instead of writing there own
08:56:27 <spectranaut_> jamesn: seems superior to aria-describedby
08:56:29 <jamesn> ack Matt_King
08:57:04 <spectranaut_> Matt_King: question for jcraig if title is used for description, is the mapping of that description different than the mapping that would result from using aria-describedby pointing to a tooltip element?
08:58:00 <spectranaut_> jcraig: we don't want to hid things... so we have a way to surface things in different ways
08:58:33 <spectranaut_> jcraig: we try to not suppress author content, if available to sited user
08:59:38 <aaronlev> q+ just to say aria-descri* should override whatever is in the tooltip text, that is a feature
08:59:43 <jamesn> it says in core-aam for aria-describedby
08:59:43 <jamesn> "In the accessibilityCustomContent API, expose as an AXCustomContent object with { label: "description" } and `value` set to the description string.
08:59:43 <jamesn> See also: Name Computation"
09:00:04 <jamesn> ack ju
09:00:04 <Zakim> just, you wanted to say aria-descri* should override whatever is in the tooltip text, that is a feature
09:00:11 <jamesn> zakim, close the queue
09:00:11 <Zakim> ok, jamesn, the speaker queue is closed
09:00:25 <jcraig> q+
09:02:01 <spectranaut_> RRSAgent, make minutes
09:02:03 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/15-aria-minutes.html spectranaut_
09:05:41 <melsumner> melsumner has left #aria
09:20:20 <Matt_King> Matt_King has joined #aria
09:31:26 <daniel-montalvo> daniel-montalvo has joined #aria
09:40:48 <cabanier> cabanier has joined #aria
11:25:09 <Zakim> Zakim has left #aria
11:57:12 <daniel-montalvo> daniel-montalvo has joined #aria
12:36:51 <Matt_King> Matt_King has joined #aria
12:59:17 <Jem> Jem has joined #aria
15:02:27 <daniel-montalvo> daniel-montalvo has joined #aria