<scribe> scribe: melanierichards

New Issue Triage

<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

No mention of aria-placeholder in name/description calculation algorithm

<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)

<jamesn> https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation

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

need role for sub and sup

<joanie> https://github.com/w3c/aria/pull/904

Sub and Sup

<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

Issue 876: add draft specification for role label

<jongund> https://raw.githack.com/jongund/aria/issue876-role-label/index.html#label

Label role

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?

end

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.)