<scribe> scribe: carmacleod

New Issue Triage

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Aissue+repo%3Aw3c%2Faria+created%3A%3E%3D2019-11-21+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

https://github.com/w3c/aria/issues/1121

carmacleod: I'll take this

https://github.com/w3c/aria/issues/1123

scott: he brings up some good points; meter doesn't align with html meter
... took away that authors MUST give min, max, and gave default values
... 0 to 100 should be fine

marking it as 1.3; would need tests if 1.2

https://github.com/w3c/aria/issues/1126

jamesn: wouldn't want screen reader to say anything for aria-invalid=false

<CurtBellew> +!

<CurtBellew> +1

jamesn: #1000 might fit in to aria-invalid, but #1126 doesn't. can anyone take these 2 on for 1.3?
... I will respond to this

stefan: is this a planned extension of the aria-invalid token list?

jamesn: #1000 is

New PR Triage

https://github.com/w3c/aria/pull/1124

https://github.com/w3c/aria/pull/1127

<jamesn> https://tools.ietf.org/html/rfc2119

<jamesn> Imperatives of the type defined in this memo must be used with care

<jamesn> and sparingly. In particular, they MUST only be used where it is

<jamesn> actually required for interoperation or to limit behavior which has

<jamesn> potential for causing harm (e.g., limiting retransmisssions) For

<jamesn> example, they must not be used to try to impose a particular method

<jamesn> on implementors where the method is not required for

<jamesn> interoperability.

jamesn: RFC2119 contains non-normative "must" :)

scott: I looked through it and it mostly seems ok, perhaps some instances where the best word is "may"

jamesn: Everyone, please look at the 3 PRs and add a review

Future meetings (No meeting - Dec 12, 26, ??Jan 2??)

jamesn: no meeting next week; we WILL be meeting on the 19th; no meeting Dec 26
... meeting Jan 2?
... based on response, no meeting Jan 2

brailleroledescription update

<pkra> https://github.com/w3c/aria/pull/1097

https://github.com/w3c/aria/pull/1097

pkra: this PR is basically done; we had a review from the first PR

<pkra> The element to which aria-brailleroledescription is applied has a valid WAI-ARIA aria-roledescription that is identical to a WAI-ARIA role or an implicit WAI-ARIA role semantic.

pkra: Apple had a question about ^^ because "user agents must not expose the property if any of the following conditions exist"

mck: seems like a good idea to me, because if the screen reader has a way of abbreviating a role, i.e. say "listbox" is "lbx",
... if you put brailleroledescription on that element, then you force the screen reader to write out the whole word instead of using lbx.
... adds an extra layer of processing

pkra: already says "must not expose brailleroledescription if there's not a valid roledescription"
... this says to ignore brailleroledescription if it's identical to roledescription
... maybe we should also say (in roledescription) that if roledescription is identical to role, then ignore

mck: could also say "if brailleroledescription is identical to implicit or explicit role, then ignore"

<Zakim> jamesn, you wanted to note extra comment in https://github.com/w3c/aria/pull/924#issuecomment-561968850

pkra: neil suggests that if unicode braille patterns are used, they should not include any .0 (which sort of corresponds with not having a space in a roledescription)
... is space character permitted in aria-roledescription?

jamesn: I think so

pkra: I thought so too

<vsorge> Space should be included!

Consider prohibiting accessible name for listitem, rowgroup, term, time

<jamesn> https://github.com/w3c/aria/issues/1117

jamesn: listitem, rowgroup, term, time

mck: compare with paragraph: label should not override content

<Scott_O> comment i mentioned in the issue regarding list item from James Teh - https://github.com/w3c/aria/issues/833#issuecomment-446830597

bryan: I'm not in favor of globally prohibiting naming on something without a really good reason

scott: jamie's potential use case was the reason we didn't remove label from listitem in 1.2

mck: we have so much complexity in the naming and describing space; simplifying would give clarity
... the content of a list item should be the name of the listitem

bryan: I've seen this on twitter

jamesn: sounds like we need to split this issue up

mck: we are going to have to deep dive into this

jamesn: good first item for F2F discussion

mck: when it comes to naming, need to do everything possible to eliminate complexity and ambiguity

jamesn: authors need to know whether name will override content or augment it

mck: need to have this discussion with multiple screen reader developers

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/ role/ implicit or explicit role/
Succeeded: s/space in a role/space in a roledescription/
Default Present: MarkMccarthy, carmacleod, Scott_O, pkra, jamesn, CurtBellew, Stefan, MichaelC, Bryan_Garaventa, janina, harris, !, Matt_King
Present: MarkMccarthy carmacleod Scott_O pkra jamesn CurtBellew Stefan MichaelC Bryan_Garaventa janina harris ! Matt_King
Regrets: joanie jongund
Found Scribe: carmacleod
Inferring ScribeNick: carmacleod
Found Date: 05 Dec 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.)