<scribe> scribe: carmacleod
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
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
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
<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!
<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.)[End of scribe.perl diagnostic output]