<Jemma> Hi
<scribe> scribe: carmacleod
<Jemma> https://github.com/w3c/aria-practices/wiki/May-12%2C-2020-Meeting
<MarkMccarthy> https://github.com/w3c/aria-practices/pull/1396
mck: nothing starts with "be" so
if I type "be", it just goes to "banana"
... so this is feeling really nice now
carmacleod: it feels good to me
also
... MarkMccarthy reviewed screen readers and says it doesn't
work with VO
<Jemma> brian:there was a report regarding VO that active descendant does not work reliably.
<MarkMccarthy> github: https://github.com/w3c/aria-practices/pull/1396
MarkMccarthy: right, the "control+option" keys don't work
bryan_garaventa: that may be aria-activedescendant?
mck: it's working great with JAWS
and NVDA
... need to also try aaron's change in canary to see if
acc_value support works
curt: click to open and click again should close
mck: yes, we should support that because it's expected behavior
<Jemma> https://github.com/w3c/aria-practices/pull/1396#issuecomment-627433935
<Jemma> car: autocomplete discussion
<Jemma> do we need autocomplete for select only example?
<Jemma> it is not editable
<Jemma> mck: we can consider that autocomplete= none can type the letter but it does not change nor add things
<Jemma> mck: let's remove autocomplete=none from the example
<Jemma> car: should the listbox have a label? (i.e. we use aria-label[ledby] on all of the other combobox examples)?
<Jemma> group agreed to add the label.
<Jemma> like "fruit"
<Jemma> car:should the listbox use ul/li instead of divs? (I think the "progressive enhancement" folks would say yes, but I actually like divs here, because it feels like it's acknowledging that the popup could have been a tree, grid, or dialog instead...)
<Jemma> car: I am asking making list box div as ul/li
<Jemma> mck: in case of grid, there is inheritance for ul/li under div or there is difference between using tr/td
mck: leaning towards leaving this as divs
<Jemma> car:should we mention the places where this diverges from html select behavior? Perhaps in an Accessibility Features section? Yes, the first paragraph does say, "functionally similar to an HTML select element" so we never said it was exactly the same, but maybe we want to explain/justify some of the choices? i.e.
<Jemma> mck: adding accessibility feature sounds like a good idea.
<Jemma> mck: I like the feature that it keeps the value even when it is closed.
<Jemma> car: we can document at alt up arrow
<Jemma> at design pattern
<Jemma> mck: we also add those to change request in the example as part of accessiblity feature
<Jemma> car:down arrow and alt+down arrow seem to work exactly the same, but the keyboard support notes for them are different?
<Jemma> brian: in my example, I made down arror and alt down works the same way.
<Jemma> it is kind of fall back feature.
<Jemma> mck: down arrow goes back to last selection when it closes and it opens again, not first option.
<Jemma> brian: alt down arrow tend to shows all the list items.
<Jemma> the rest of comments from Car was agreed on.
<Jemma> car will request changes in pr.
<Jemma> https://github.com/w3c/aria-practices/pull/1279
Preview link: https://raw.githack.com/w3c/aria-practices/zcorpan/range-related-properties-2/aria-practices.html#range_related_properties
Jemma: I updated the table according to Jon's suggestions
mck: I think we should change "Yes, if it is not exactly known." and "Yes, if known" to "No".
carmacleod: from the ARIA spec: Authors SHOULD set the aria-valuenow attribute when the spinbutton has a value. Authors SHOULD set the aria-valuemin attribute when there is a minimum value, and the aria-valuemax attribute when there is a maximum value.
mck: I'll rewrite it to use "imperative voice", i.e. "the spinbutton's value is set with aria-valuenow"
jemma: the word "indeterminate"
fails the language level validation in our build
... so I changed it to "not exactly known"
carmacleod: the spec for https://w3c.github.io/aria/#aria-valuenow says "If the current value is not known (for example, an indeterminate progress bar)"
mck: I might try rewording to something like that.
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/well/reliably/ Succeeded: s/box dive /box div / Succeeded: s/evn/even/ Succeeded: s/opens/opens again/ Present: Matt_King Jemma MarkMccarthy carmacleod bgaraventa Siri Curt_Bellew Regrets: JonGunderson SarahHigley jamesn Found Scribe: carmacleod Inferring ScribeNick: carmacleod 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: 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]