Meeting minutes
previous meeting on tooltips: https://
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
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.
matt_king: I think apple is using it
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
mario: that is not easy to answer... in some cases you need it, in other cases it's not important
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
jamesn: a tooltip associated with an input friend. if it said tooltip, would that be extra noise?
matt_king: most likely. it might depend on how easy it is to discern the purpose of the text.
matt_king: if you use pronouns in your tooltip, like this or that
dmontalvo: in addition to that, the role is an annoyance, if the way to access is to press a dedicated screen reader key
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
jamesn: I'm hearing on simple, non interactive tooltips, have the role is useless
matt_king: yes
mario: if you read visually, you have no idea where the tooltip is.
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)
matt_king: we thought about putting strong language to not put tooltips on not interactive elements
matt_king: but why not aria-errormsg
melanie: thats the advice I give
matt_king: if you have something that is the description, if you use aria-describeby or aria-errormsg, that would be sufficient
jcraig: voice over does have a feature for reading the tooltip, called "help text"
jcraig: screen readers and at do separate the concept somehow
jcraig: between tooltip and other status text, and aria-errormsg
matt_king: ctrl-opt-shift-h reads aria-describedby
jcraig: describedby is a windows concept that was mapped to tooltip on mac
jcraig: we have special rules in voice over to squeeze the windows pattern into mac
matt_king: if there is a tooltip, description... there isn't a way to associate a tooltip with an element besides using aria-describedby
matt_king: is there a difference between a tooltip and something else pointed by aria-describedby
jcraig: there is a concepts of "custom context", which has priority and kinds, that depending on user it is surfaced differently
<Zakim> jcraig, you wanted to mention "help text" command, and to request the room manager turn off the camera auto panning
melanie: I was expecting the errormsg to be read in the order of the dom, but it was read before the input
<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
Marcelo-Paiva: is the title attribute going away
jamesn: I don't think so
Marcelo-Paiva: is the title attribute taken as priority
jamesn: the accessible description algorithm specifies when the title is used
Marcelo-Paiva: it would be good ot have a distinct definition for what is a tooltip native from the browser
Marcelo-Paiva: the box model tooltips from css and the code (not from the browser) on UI patterns we call those popovers.
Marcelo-Paiva: and tooltips generate from the browser
Marcelo-Paiva: separate these concepts
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
jamesn: so we don't want to differentiate browser native vs framework
Marcelo-Paiva: people need to know how to make a box model tooltip as accessible as a title attribute tooltip
matt_king: using the title attribute is itsself, the title attribute by itsself is not very accessible
Marcelo-Paiva: what is the goal? are we trying to decide if we change or add an ARIA attribute
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
matt_king: I don't want to tell people to write code that does nothing
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.
jamesn: maybe tooltip is a mixed model?
melanie: would we cause confusion by adding the ability to do a dialog like thing in a tooltip? because typically that is recommended against
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
<Zakim> Marcelo-Paiva, you wanted to say that tooltip is a good "progressive disclosure" ui-pattern for users with cognitive disabilities
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
Marcelo-Paiva: this is another pattern in the industry
jamesn: someone said they are working on stylable title attributes
jamesn: not structure content
jamesn: just how it looks
Marcelo-Paiva: one other case that hasn't been mentioned -- the content value could come from the css content property
Marcelo-Paiva: how is that surfaced to an AT?
Marcelo-Paiva: that happens a lot with icons
matt_king: if you have an icon where you are using css content to label the icon, is that referenced in the name calculation
jamesn: I think we need to simplify that part of the name calculation, we should probably defer to CSS
jamesn: the browser is calculating it anyway
jcraig: I'm not sure if I missed it... but that is the goal of this meeting? better authoring practice guidelines?
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
matt_king: there is definately things to do to make the tooltip accessible. BUT we don't need to the tooltip role
matt_king: I think in the issue, we should say that
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
matt_king: in that case, should we not use aria-describedby, but use aria-details?
jamesn: maybe toggle tips
jamesn: if they are just structural, aria-details might be fine
jamesn: but if interactive, for a keyboard user, you need to move focus
matt_king: static structured content......
jamesn: adding three patterns is too many
jamesn: we an just say you have to move focus
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?
jamesn: good question, there is definately going to be a line, where is that line?
matt_king: we try to draw those kinds of lines in the APG
matt_king: the APG tooltip issue has been open for 7 years
aaronlev: if you use aria-details for popover... it should be visible
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
(lots of stuff the scribe missed)
(discussion of the popover pattern from aaron)
aaronlev: two prong approach, informational stuff, use the existing options with more options to style
aaronlev: the other situation is where things are interactive
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?
<Marcelo-Paiva> * here are some use-cases aaronlev has mentioned https://
aaronlev: touch is important too
aaronlev: and there are lots of touch users
aaronlev: mason is using the popover stuff... we have discussed hint popovers should only be available on buttons.
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
<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, it's just so inconsistent.
melsumner: I wonder if your idea for using the title attribute... wouldn't overload the title attribute?
melsumner: I feel like the general advise is to not use the title attribute
melsumner: this would change what it does... if the title value was used as the elements accessible name
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
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
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
it
its the fall back for both situations.
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
<Zakim> jamesn, you wanted to say once the title attribute gets fixed we should encourage its usage
jamesn: just flipping back to title -- once title gets fixed, we should encourage it's usage instead of writing there own
jamesn: seems superior to aria-describedby
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?
jcraig: we don't want to hid things... so we have a way to surface things in different ways
jcraig: we try to not suppress author content, if available to sited user
<jamesn> it says in core-aam for aria-describedby
<jamesn> "In the accessibilityCustomContent API, expose as an AXCustomContent object with { label: "description" } and `value` set to the description string.
<jamesn> See also: Name Computation"
<Zakim> just, you wanted to say aria-descri* should override whatever is in the tooltip text, that is a feature