W3C

- DRAFT -

June 4, 2019 Authoring Practices Task Force Telecon

04 Jun 2019

Agenda

Attendees

Present
AnnAbbott, Matt-King, BryanGaraventa, SB, MarkMcCarthy, zcorpan, carmacleod, CurtBellew, jemma_
Regrets
Chair
Matt King
Scribe
AnnAbbott, MarkMcCarthy

Contents


<AnnAbbott> scribe: AnnAbbott

<scribe> Agenda: https://github.com/w3c/aria-practices/wiki/June-4%2C-2019-Meeting

Values of haspopup other than true for ARIA 1.0 comboboxes will be moved to next week's call

Toolbar tooltip implementation

<jongund> https://raw.githack.com/w3c/aria-practices/issue986-toolbar-button-tooltips/examples/toolbar/toolbar.html

<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

https://raw.githack.com/w3c/aria-practices/issue986-toolbar-button-tooltips/examples/toolbar/toolbar.html

<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

aria-labelledby guidance

<mck> https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_with_aria-labelledby

<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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/06/04 19:05:55 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]