<scribe> scribe: melanierichards
<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-02-14+
jamesn: [based on discussion], I put https://github.com/w3c/aria/issues/907 on 1.3 for now
<jamesn> https://github.com/w3c/accname/issues/45
jamesn: can this just be closed?
bryan: I think so, if that's good with everyone
jamesn: can you close with tentative comment of, "it doesn't answer please reopen?"
bryan: sure, I can take care of it
<jamesn> https://github.com/w3c/accname/issues/17
joanie: what happened is, a long
time ago filed an issue to get the HTML placeholder attr
properly exposed. People got around to it last week. Chrome
uses placeholder in name calculation, Firefox decided to do it
too, it's not in HTML-AAM, so everyone thought it should be
part of name calculation. Now in HTML-AAM.
... aria-placeholder doesn't participate in name calculation,
now we are out of sync. We need to find a way to get in
sync.
carmacleod: how far down in the stack is placeholder for name?
joanie: before title, I think (off top of my head, not sure)
jongund: HTML AAM has own name calc?
joanie: overrides ours in certain conditions
mck: in some places, you don't use AccName, use HTML AAM rulels
jamesn: it's after title in HTML AAM name calculation
<carmacleod> HTML AAM https://w3c.github.io/html-aam/
jamesn: it's on [reads out various input types]
<jamesn> input type="text", input type="password", input type="search", input type="tel", input type="email", input type="url" and textarea Element Accessible Name Computation
mck: does it use placeholder attr whether visually displayed or not?
joanie: doesn't say, but I would do if that if I were an implementer
bryan: placeholder visually disappears when placing focus
joanie: my guess is a lot of implementers don't do that yet
<Devarshi> I think it reappears when focus shifts from the control that had focus
joanie: some screen readers will use placeholder to provide info if the input doesn't have a name
bryan: I think we need to have something in there that references aria-placeholder. I don't see issue after title
joanie: I'm going to file an
issue about it. title is often used for sole purpose of, you
hover mouse over it and you get information about it. It can be
a big long wordy thing, that should not be the name
... the title by default is exposed on most platforms as
description. So placeholder would be used for name in that
instance, and user can get all of it if they want. Instead of
long wordy name
carmacleod: I have to disagree, sometimes placeholder you get example text, like DD-MM-YYY, I'm not sure placeholder should win in that instance
jongund: I have some concerns over placeholder, it may be an unintentional name. Author didn't intend it to be accessible name
<Zakim> jamesn, you wanted to say I prefer after title
jamesn: I'd prefer title to win over placeholder. Both are repair mechanisms, not ideal situations. Might not make a great deal of difference which order, I've seen title winning in the past, so putting placeholder first could cause things to change in negative way
bryan: I'd have to agree with that
<Zakim> joanie, you wanted to say as a reminder that this only applies when there is NOT a proper name and to add in response to carmacleod that in the date example, MM-DD-YYYY might suck,
joanie: let's say there's no aria-label, -labelledby, or label. Let's say at most we have placeholder and/or title. The author has not done good authoring. The MM-DD-YYYY is not great, but at least I know it's a date. Do we really think title will have better content? Might be really wordy
mck: I hear the arguments on both
sides, validity in all of them. Strongest argument for using
title before placeholder is potential for changing something
that's out there. I do tend to still agree with Joanie, since
we're talking about fallbacks, there is no other access to
placeholder at all. Probability that it's more helpful than
title is relatively high. Reason that it's often shorter than
title is good. And that every SR has...
... ...way of accessing title
<HarrisSchneiderman> sorry all, I have to drop off
mck: I think Jon brings up good
separate issue, and it's purely acc name, that people can think
they have a valid name when it gets back to the crappy fallback
techniques. I wish Acc Name would say there is a fallback name
calculation that is specced out so that browsers support in
same way, but from accessibility checker, says that these are
bad ways of providing acc name
... that's probably a separate issue from this discussion
<Zakim> jamesn, you wanted to ask if we should be solving why there is no access to placeholder
melanierichards: generally support use of placeholder for acc name, helps repair cases where there is no name and some SRs are reducing verbosity (providing description only on demand) so some inputs are silent when placeholder doesn't participate in name. Would support updating Acc Name to be in sync w HTML-AAM and placeholder
Devarshi: one quick question, let's say there's no visible label or aria-label. We only have placeholder and aria-describedby. Would placeholder be accessible name?
joanie: the placeholder would be the accessible name, aria-describedby would be description
jongund: I think there needs to
be some discussion on whether something can populate an acc
API, and whether we want accessibility checkers to consider
things a pass. title and placeholder often unintentional
accessible names, and check out who is already using title
because they understood the algorithm
... need to look at authoring experience, user experience, not
just a question of populating APIs
jamesn: can you let us know when you raise the issue on HTML-AAM so we can all add comments?
joanie: will do
<joanie> https://github.com/w3c/aria/pull/904
<jamesn> github: https://github.com/w3c/aria/pull/904
joanie: [reads from diff in the linked pull]
<jamesn> "<p>The <code>subscript</code> role is intended to be used only to mark up typographical conventions that have specific meanings; not for typographical presentation for presentation's sake. In general, authors SHOULD use this role only if the absence of the subscript would change the meaning of the content.</p>"
mck: that's very good. Is that kind of text in the HTML spec?
joanie: pretty much, only difference is I made it an author should
<pkra> +1 merge
mck: what's parent role?
carmacleod: section
mck: that's kind of interesting
joanie: section is parent role of all our text-y things
mck: we don't have an equivalent
of HTML's "phrasing content" in our ontology
... I wonder if, in doing role parity under structure, we ought
to have something along those lines. Not sure if "phrase" would
be right abstract role. Section has meaning and I don't think
this should be there.
jamesn: let's think about
that
... could we create a new issue for that and merge this?
mck: yes
carmacleod: it has name from author, should it have name from content too?
joanie: if there's no accessible name, ATs will back onto text. What if author wants to make sure we say "squared" instead of "superscript...."
mck: do we already put name from author para?
joanie: yes, right now we don't have unnameable things
mck: I thought that was name from content
joanie: no, imagine a paragraph with 1000 words. Not a good acc name
<jamesn> "5.2.7.4 Roles Supporting Name from Author
<jamesn> All roles support name from author with two exceptions. The roles that do not support name from author are presentation and none."
mck: but that's essentially how SRs treat contents of text node, it is essentially "is" the name
joanie: if you arrow down on a paragraph you want to hear that line of text, but you don't want this as acc name
mck: this should have name from content
jamesn: I disagree
mck: you think people should put aria-label on it?
jamesn: I don't think we
generally want to do that, but we do need to support author
name
... when we want to change and have non-nameable things, this
may be a good candidate for that
mck: but wouldn't you get
"squared, 2" if you put a label on it?
... ok so we do have to circle back, this is a separate
issue
<Zakim> janina, you wanted to suggest that we might be able to rely on the output of the APA Pronunciation Task Force for specific pronunciations
janina: specific to this issue, on how presentation is pronounced, APA has a task force specifically for this. ARIA could punt and say "rely on APA spec for how to pronounce this"
<janina> https://www.w3.org/WAI/APA/task-forces/pronunciation/work-statement
janina: this will be a more global approach than ARIA, which relies on ATs
jamesn: knowing there are things we need to change, this PR is currently consistent w/ other things we have in ARIA w/ regards to the issues raised. Objections to merging?
(agreement from a few folks on merging)
joanie: I'll merge later today in editors' draft, then work on getting implementations
bryan: wanted to add re: name from content, I wanted to point out that as far as acc name goes...in the case of nested widgets, if you don't support "name from contents" that won't be supported in the parsing algo going down
<jongund> https://raw.githack.com/jongund/aria/issue876-role-label/index.html#label
jongund: I created 4 groups of widget roles and put it in the PR. I thought it would make it easier to see different options
<jamesn> github: https://github.com/w3c/aria/issues/876
jongund: 1st group (missed), 2nd
is where native label is helpful, checkbox and radio, 3rd and
4th groups encapsulation not as useful
... main advantage from authoring standpoint is not having to
add IDs in order to label things
mck: the probability that there isn't other junk in there that you don't want included in the name...our original goal here was role parity and this might be an extension of functionality. Not sure if this is part of the slow, careful extension idea
jamesn: I would say tree and treegrid would be part of that
mck: tree, treegrid, grid should
go to last group of widgets you have
... I'm a little nervous about combobox still
james: me too
mck: listbox is a slam dunk, that's easy, same with spinbutton...combo, I feel it should be in 4th group
jamesn: I'd like to see it in the first list but it may cause pain to put it there
mck: yeah, I think we need to resolve the other open combobox naming issue first
<pkra> bye
jamesn: are you ok with those changes and want to bring it next week?
jongund: sure
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/james/jamesn/ Succeeded: s/james/jamesn/ Default Present: Stefan, Joanmarie_Diggs, jamesn, pkra, MarkMcCarthy, janina, melanierichards, CurtBellew, jongund, MichaelC, HarrisSchneiderman Present: Stefan Joanmarie_Diggs jamesn pkra MarkMcCarthy janina melanierichards CurtBellew jongund MichaelC HarrisSchneiderman carmacleod matt_king Bryan Garaventa Found Scribe: melanierichards Inferring ScribeNick: melanierichards WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 21 Feb 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]