<AnnAbbott> scribe: AnnAbbott
<scribe> Agenda: https://github.com/w3c/aria-practices/wiki/June-4%2C-2019-Meeting
<zcorpan> GitHub: https://github.com/w3c/aria-practices/issues/986
jg: added labelledby to div
Carolyn: controversial because could be announced twice
jg: role=tooltip on actual content
Carolyn: Narrator will announce when navigated to
jg: used as both tooltip and label
mck: if used as descendent of button, shouldn't have role=tooltip
Dorothy: adding more stuff and getting confusing
Carolyn: if only using kbd, title doesn't appear
jn: except Edge and IE 11 running on Win8 and above
mck: agreed lasts week that not
relying on title attribute
... part of question is whether using tooltip role on
button
... screen reader always sees the text, ignoring tooltip
... text is always hidden except on hover or focus
<CurtBellew> +1
<MarkMcCarthy> WCAG 2.1 SC 1.4.13 https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus
mck: remove role=tooltip, make hover be persistent and hide font icons from accessible name
<jemma_> "If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;"
<mck> Making tooltip persistent on hover is for WCAG 2.1 compliance.
Curt: tooltip goes away unless hovering over tooltip
Carolyn: copy/paste/cut buttons are different
mck: that's classic tooltip
implementation
... using describedby
... remove title attribute from cut/copy/paste and help
buttons
jn: Bold is wrapping weird
<MarkMcCarthy> Nice work Jon!
<MarkMcCarthy> Dorothy: possible to change the width? thinking about somebody changing the size
<MarkMcCarthy> Jon: I made some adjustments, I'll send out a new link and comments can be made on the list
<MarkMcCarthy> mck: here's a link to the branch
<MarkMcCarthy> scribe: MarkMcCarthy
<zcorpan> GitHub: https://github.com/w3c/aria-practices/pull/994
<Sarah_Higley> https://github.com/w3c/aria-practices/wiki/June-4%2C-2019-Meeting#draft-aria-labelledby-guidance
mck: going to discuss each of BGaraventa' caveats to make sur we all understand
<mck> i. The aria-labelledby referrals can only be followed once, and not on any subsequent elements if encountered there such as by chaining aria-labelledby
mck: i think I'm understanding this, but when saying "any subsequent elements", are you talking about a single element getting referenced more than once? or...
BGaraventa: basically, this is
going back to f2f meeting, where it's only allowd to follow one
iteration of aria-labelledby. so labelledby can't reference
another element that has labelledby. BUT there can be more than
one element with labelledby under one parent
... for instance, a button and two spans where the spans are
siblings. each span can have labelledby and then move on to the
next element
... but they can't be chained as you drill down
mck: okay, let me paste in the first warning, which is hopefully easy enough for anyone to understand
<mck> 1. The aria-labelledby property cannot be chained, i.e., if an element with aria-labelledby references another element that also has aria-labelledby , the aria-labelledby attribute on the referenced element will be ignored.
carmacleod: i think that makes sense
mck: bryan, do you think that covers it?
carmacleod: [reading warning text]
BGaraventa: yeah, that's the same thing
mck: exactly
Dorothy: does "referenced" mean the parent or child?
carmacleod: so, whichever it's referring to
Dorothy: so, we're talking about nesting?
BGaraventa: essentially, only one
traversal of aria-labelledby is allowed per process, accname
process
... the reason it works when you put it on separate elements or
siblings is because those are separate elements
mck: in the phrase here,
"References another element...", would that be better saying
something like "references another element that already has
aria-labelledby"?
... doesn't necessarily have to be on the referenced element,
right bryan?
BGaraventa: yes
mck: so you could reference an element that does have labelledby but a descendent does...
<Dorothy> which is ignored.. the first reference or the second reference
mck: let's say something with role=region, if there's an element inside it that has labelledby, you'd never get to it right?
BGaraventa: it does begin to matter when it gets to child nodes, or with forms for instance. essentially, when you put a labelledby reference on something, you're essentially treating it as a child of it's referee
mck: if node 1 has labelledby and it references node 2; node 2 is parent of node 3 which has aria-labelledby, then whether or not node 3 is read depends on role of node 2?
BGaraventa: I'd have to check
<zcorpan> accname spec has this: "if computing a name, and the current node has an aria-labelledby attribute that contains at least one valid IDREF, and the current node is not already part of an aria-labelledby traversal, process its IDREFs in the order they occur:" - https://w3c.github.io/accname/
zcorpan: looking at the accname
algorithm, it doesn't check the role of what's referenced
[pasted above, reading spec]
... so it's not super clear what part of an aria-labelledby
traversal is
mck: in this case [node example above], this is part of a labelledby traversal
BGaraventa: im going to have to
do some experI'menting to see where it applies. presumably,
you're using labelledby on an element to be labelled
... when computing the child nodes, algorithm checks roles to
see if the name comes from that or not as well
mck: yeah, it does have to do
that
... i think the current wording will keep people from making
mistakes even if it's not comprehensive
BGaraventa: maybe we could provide a couple really basic examples, like a button with two spans, etc.
mck: potentially, but the way
this is written... if the warnings also need examples, maybe we
need to reference the name calc section if we want folks to
read more.
... zcorpan, we might have to do some research on "has"
<zcorpan> (Step 2.F says "Otherwise, if the current node's role allows name from content," to drill down for name from content)
mck: Next item from Bryan
<mck> ii. You cannot nest aria-labelledby references, where you have aria-labelledby on the root node as well as on a child node of the root node. In this last case, only the root node will be traversed and none of the child nodes will be parsed.
BGaraventa: So if the first node returns a value, that becomes the name regardless, kind of like when you put aria-label on it
mck: so this isn't chaining then;
I don't have a warning for this in guidance
... so warning 2 I guess we've agreed is incorrect
... Okay, I have to change number 2 then, in the guidance
... okay, let's talk about BGaraventa's third point
<AnnAbbott> iii: Any node that is parsed in the tree as a child or owned element via aria-owns, or as part of an aria-labelledby or aria-describedby traversal, can only be processed once and will be ignored by any other references to itself later by any other attribute or process during this computation. This prevents infinite loops from occurring. So, only the first instance of this node will be processed when encountered in the order of the naming computation[CUT]
mck: so, bryan, I have a hard time parsing this one
BGaraventa: basically, an element
name/node can only be computed once
... so if you had labelledby referencing the same ID, that
wouldn't work, since that node has already be computed
mck: ah, okay.
Sarah_Higley: does this have any issues with self-referencing IDs? would that technically violate this even if it's allowed?
BGaraventa: I'd have to run the
code to check, but seems likely you'd chop up the label that's
returned
... technically, for example, a button with aria-labelledby
pointing to itself, it'd be parsed as if it had labelledby
pointing elsewhere, and it'd default to aria-label or label
Sarah_Higley: it's a technique I've used in a few places, I've seen it in spec. but that's parsing that node twice, right?
BGaraventa: basically, it's likely the button content wouldn't be included but all surrounding content would be. i know what technique you're talking about it
mck: it's in the section. where
the label on the link is "Read more" and it references the
heading on the article. so uses ID of the link and ID of the
article
... whether or not this wording makes that clear...
zcorpan: the thing that isn't allowed is traversing the node twice.
<AnnAbbott> two minute warning
Sarah_Higley: what if the traversal doesn't start at the button. wouldn't the self referencing ID work still?
<jemma_> oh ok
mck: hmm. so this is more complicated than it seems, maybe this wording says that's not allowed?
<AnnAbbott> one minute warning
BGaraventa: basically, starting with a heading and then a button that maybe says expand...
Sarah_Higley: i think we're getting a little confused... let me give a better example
mck: Sarah, if you have some specific examples, can you share them on the list? I need to make sure I understand
<zcorpan> ( https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_with_child_content has a list of name-from-content roles)
mck: so we'll make some changes, but we need feedback from everyone so this is correct and understandable!
siri: if there could be examples of what not to do, that'd be helpful
mck: that's what the section in
the APG is for, where it says preview link
... i appreciate the help and support, I know this is a
lot
... i'll try and prompt people to continue discussion
BGaraventa: please comment on the list, I might not see it on the PR
siri: carmacleod, who asked about the tooltip?
carmacleod: Scott O'Hara
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/1.4.10/1.4.13/ Succeeded: s/dowon/down/ Succeeded: s/[pasted above]// Succeeded: s/im/I'm/ Present: AnnAbbott Matt-King BryanGaraventa SB MarkMcCarthy zcorpan carmacleod CurtBellew jemma_ Found Scribe: AnnAbbott Inferring ScribeNick: AnnAbbott Found Scribe: MarkMcCarthy Inferring ScribeNick: MarkMcCarthy Scribes: AnnAbbott, MarkMcCarthy ScribeNicks: AnnAbbott, MarkMcCarthy Agenda: https://github.com/w3c/aria-practices/wiki/June-4%2C-2019-Meeting WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]