<MarkMccarthy> Scribe: We are removing the support gap warning from this meeting's agenda
<MarkMccarthy> Scribe: We are adding an update on Simon's guidance topics to the agenda
<MarkMccarthy> scribe: MarkMccarthy
Matt_King: Next meeting Nov 19, no Meeting Nov 26
Matt_King: two issues left,
related to combobox
... didn't create issues for updating branches etc., but I will
send a note to the list to have folx look at the appendix and
get feedback
... Other than that, I think this is ready to go. jamesn?
jamesn: I'll have to look in more detail. as far as I've seen, it's good
Matt_King: okay great, i'll send
a note to the list
... discussed with Jemma about the appendicies, a special
ackowledgements section. Where jongund's students etc. go. I
brought that forward to 1.2 WD, even though we didn't have an
equivalent in 1.2
... I thought it'd be good to preserve that
MarkMccarthy: +1
Matt_King: what we hope to have
done for MichaelC this week - updating the examples, the grid
pattern
... and in doing so, there will no longer be any updates to
another pattern - it'll be like any other part of the APG
... just a "combobox" pattern, no 1.1, 1.2 etc.
... i thought it'd be best to do this all in one PR just in
case we need a rollback
... because of that, it's a little bigger than planned. PR
1255
https://github.com/w3c/aria-practices/pull/1255
Matt_King: 2 goals. 1 - make sure
people are ready to review this PR thoroughly (ideally in next
24-48hrs)
... so we can respond and help quickly
<zcorpan> GitHub: https://github.com/w3c/aria-practices/issues/1250
Matt_King: there's some changes
to wording I want to be able discuss
... goal 2 - discuss any open issues that are there or if we
ship them now as they exist
... status as of now; i pushed some commits, made some changes.
looks like we're good to go for review. thanks to zcorpan and
jongund
zcorpan: thank you!
Matt_King: curious if people
would be okay with code review and CSS issues being raised but
addressed later, due to short time frame
... after all, this is WD not a final release
... any objections?
ZoeBijl: just this pattern or in general?
Matt_King: just this one
ZoeBijl: which is the new combobox pattern? as an exception and not a rule it's fine
Matt_King: agree
... unless there's something monstrous, we should send it out.
just this once
ZoeBijl: we should at least fix
a11y issues we come across. code standards etc. can be done
later
... i think it's important for the WD to be accessible
Matt_King: 100%
carmacleod: i don't think we can fix that safari issue, it's a safari thing
Matt_King: we'll see what BryanG says, maybe he has some feedback
carmacleod: the bug is that
listitems aren't being read, activedescendent isn't being
read
... might be an issue since aria-owns is gone?
jamesn: just a theory
carmacleod: yup
Matt_King: might be how we changed -activedescendent in 1.1
carmacleod: true
Matt_King: could be they did what
you mentioned jamesn, that they forgot to implement something
on textboxes etc.
... unfortunate if it's a bug, no good way to workaround on our
end really...
zcorpan: which example is this a problem in?
carmacleod: the one Matt_King first did
Matt_King: i'd imagine it's all of them
jamesn: worth checking
carmacleod: so are you adding reviewers Matt_King? let's get it done
Matt_King: yep
carmacleod: let's split a11y testing into two? one windows, one mac? I can do windows
Matt_King: great idea!
carmacleod: i'll edit the checklist
Matt_King: do we have a mac person?
sarah_higley: I can do both, in addition
carmacleod: sure!
Matt_King: prioritizing mac first
sarah_higley: yeah, or both in general
jamesn: fyi we found they work in chrome+vo but not safari+vo
sarah_higley: okay
Matt_King: a11y review doesn't
necessarily need screen reader testing, but big tickets like
kbd and color contrast, of course
... excluding screen reader bugs, these work with all SRs
jamesn: that's why we did this, because they work with everyone. so that it doesn't in safari is worrying
sarah_higley: i have a version of 1.1 that works with safari+vo
Matt_King: so a11y review is
covered
... since simon and I did all the editorial work, we can't
MarkMccarthy: I can check out editorial tomorrow
jongund: i haven't read the changes to practices yet
carmacleod: me either
... thanks MarkMccarthy
jongund: i also can
carmacleod: thanks!
Matt_King: functional testing? if the a11y testing doesn't cover it? can a11y testers also check w/ a mouse to cover that?
carmacleod: yes I can do that, agree, no big deal
sarah_higley: definitely
Matt_King: visual design
... still want to find those issues even if we don't fix them
all
zcorpan: give it to Matt!
[group laughs]
zcorpan: nah, I can do it, that's fine
carmacleod: so code review and test review are left
sarah_higley: i can do code review, unless I'm taking too much or should do it after a11y review?
Matt_King: you can do it after.
we don't need to necessarily fix these until after
... we want the tests to work but they're not really part of
the publication. we just don't want regressions
... let's assign spectranaut (Valerie) to test review
carmacleod: done
Matt_King: awesome!
... everything done by EOD tomorrow if possible?
reviewers: yeah
Matt_King: i remember we had issues in spinbutton where there was a ref issue that only affected safari, so it's very possible there's a bug in the code
sarah_higley: i'll check it out
Matt_King: we could go back to spinbutton PRs to check out some details
<ZoeBijl> ack
sarah_higley: maybe I missed something in my implementation
jamesn: I'll check it out
ZoeBijl: what versions were used?
jamesn: I was using catalina and latest
ZoeBijl: that just came out?
jamesn: yeah
<Zakim> ZoeBijl, you wanted to ask which versions of macOS/Safari were used
Matt_King: so only part of the content itself, I tried to address differently and more robustly. had to do with difference between comboboxes that support editing and input and those that don't
<jongund> I need to leave now
Matt_King: one of my concerns is
we don't fall into this thing of referring to a combobox as
readonly
... in one place i used select only but i'm reluctant. i'll
paste in some copy
<zcorpan> The combobox pattern supports several optional behaviors. The one that most shapes interaction is text input. Some comboboxes allow users to type and edit text in the combobox and others do not. If a combobox does not support text input, it is referred to as select-only, meaning the only way users can set a value is by selecting a value in the popup. For example, in some browsers, an HTML select element with size="1" is presented to assistive
<zcorpan> technologies as a combobox. Alternatively, if a combobox supports text input, it is referred to as editable. An editable combobox may either allow users to input any arbitrary value, or it may restrict its value to a discrete set of allowed values, in which case typing input serves to filter suggestions presented in the popup.
<zcorpan> https://pr-preview.s3.amazonaws.com/w3c/aria-practices/pull/1255.html#combobox
zcorpan: this is the second paragrah in the intro
carmacleod: yeah, this all seems true. that's the way they've worked on desktops forever
Matt_King: i think HTML selects work that way when they're open but not closed, might depend on the browser
sarah_higley: i've seen
comboboxes that include readonly items
... all over windows, not just desktop
Matt_King: so there's essentially
these two forms. even when it's editable, well that opens up
the door to many different types
... and there's a bunch of types of autocomplete, autoselect,
filtering, etc.
... so the very first concept people need straight is these two
basic flavors of comboboxes
... editable and "select only"
... don't want people to confuse non-editable with
readonly
... i'm anxious about a new term, but need something that's
maybe an alternative to readonly
... to me, readonly is one where you can't change anything,
select anything, etc. it's literally read only
carmacleod: it does make sense to use a new term because until now there's only been arguments *chuckle*
Matt_King: nowhere in the APG have we tackled that. zcorpan did we include readonly in communicating widget states?
zcorpan: let me look
siri: if you can't change something inside a combobox, then it's read only? Or if you can write in it, it's not? Trying to understand
Matt_King: right. --IF-- it's not editable/typeable, it's readonly --
siri: like a listbox then?
Matt_King: well an HTML select can be a combobx, or a custom element
sarah_higley: could have a listbox where you can't edit but can type characters etc. to jump to items
<sarah_higley> clarification on that ^ listboxes do not expand/collapse
Matt_King: so maybe it'll be useful for us to look at the paragraph right before the example section (pasting below)
<sarah_higley> haha didn't want anyone reading the notes to think I was advocating for <select> to map to listbox :D
<Matt_King> Two other widgets that are also visually compact and enable users to choose one value from a set of discrete values are listbox and menu button. One feature that distinguishes combobox from both listbox and menu button is that its value can be presented in an editable field, which gives users the ability to select some or all of the value for copying to the clipboard. Comboboxes and menu...
<Matt_King> ...buttons can be implemented so users can navigate and explore the set of allowed values in a combobox popup or menu and then decide to revert to the value the widget had before navigating by pressing escape. In contrast, navigating a listbox immediately changes its value, and escape does not provide an undo mechanism. Comboboxes and listboxes can be marked as required with aria-required="true",
<Matt_King> and they have an accessible name that is distinct from their value. However, a menu button cannot be marked required, and while it has an accessible name, it does not have a separate value so both the name and value need to be conveyevia the accessible name.
Matt_King: above is some info about comparing comboboxes to other widgets
[group reading]
sarah_higley: does this imply a menubutton can have a value?
Matt_King: i was trying to figure
out how to word that... technically it's not a value so maybe
it should be tweaked a bit
... i personally dislike the pattern completely where you
choose this and it changes the value of the menubutton
... but we used that in our editor toolbar, particularly with
font. communicate the chosen font in the name of the
button
... i'd rather have it be a select; it'd be a better
experience
sarah_higley: i agree, i think we should look at that again. but would you be up for choosing words that don't make people think they should choose a menubutton if they need a value?
Matt_King: well then we could say it lets you select something but it can't change after that. so maybe not a good alternative
carmacleod: that was my suggestion
Matt_King: well i don't think we'll ever get rid of this in the wild though
sarah_higley: maybe we clarify that people -don't- do that?
carmacleod: yeah
Matt_King: well we try to avoid antipatterns, and also try to advise against. in any case i'll try to reword that
zcorpan: so our listbox example that opens a popup is essentially equivalent to a readonly combobox
Matt_King: maybe we keep it for now for 1.2 but don't strike it. right?
zcorpan: well I was thinking of converting it to a combobox
Matt_King: might be possible, good idea
sarah_higley: kind of like the mac semantic way
carmacleod: a popup list
Matt_King: even an HTML select is
called a menubutton on mac though
... and it's the only way a menubutton could be required
*chuckle*
... I think that's a potential bug with the Mac axe api
ZoeBijl: a popup button
Matt_King: ah yes, not a menubutton
ZoeBijl: so a required popup button [laughs]
sarah_higley: has anyone found
comboboxes on mac that are [phone buzzed]
... couldn't find any built into the platform that are
ZoeBijl: connect to server. go into finder, press cmd+K, you get a connect to server window and there's a combobox popup thing you can type into
Matt_King: VO says it's a combobox?
[Voiceover announced it as combobox]
Matt_King: oh my god!
ZoeBijl: the suspense!
[group laughs]
<jamesn> https://developer.apple.com/design/human-interface-guidelines/macos/fields-and-labels/combo-boxes/
jamesn: there's guidance on that ^
Matt_King: really really good feedback on all of this everyone
<jamesn> "A view that displays a list of values in a pop-up menu where the user selects a value or types in a custom value."
<scribe> scribe: thanks for adding that jamesn
Matt_King: so reviewers are good,
text was discussed - oh issues!
... i'll put a link to the project in minutes so folx can scan
through issues
... we did close an issue though, now allowing esc to clear a
combobox
... works for some, maybe not all. should we fix before
ship?
[silence]
Matt_King: a functional defect, then perhaps?
jamesn: yeah
Matt_King: I don't think i've opened a bug for it. are we okay with such a bug for the WD?
[silence]
Matt_King: silence =
consent
... on this
... that's it for open combobox issues here
<zcorpan> https://github.com/w3c/aria-practices/pull/1109
zcorpan: so one PR that needs a
round of review is aria-level
... this was discussed on an earlier call. there were comments
that have been addressed so final review is needed
Matt_King: where we had feedback on sample code, added examples?
zcorpan: changed two samples
<zcorpan> https://github.com/w3c/aria-practices/pull/1057
zcorpan: there's another PR for
widget states that can be reveiwed if folx are able
... there's still some TODOs though
... planning more work this week, maybe formally ready for
review come thursday
<zcorpan> https://github.com/w3c/aria-practices/pull/1027
zcorpan: there's also a PR for
live regions
... this hasn't been changed in a while but it still needs
review
Matt_King: okay then. so I hope
everyone agrees we have lots of good nighttime reading material
*chuckles*
... cool cool, we'll wrap it here.
zcorpan: actually range related topic is another PR
<zcorpan> https://github.com/w3c/aria-practices/pull/1000
<zcorpan> Open PRs that need review: https://github.com/w3c/aria-practices/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3A%22Needs+Review%22
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/We may add/We are adding/ Succeeded: s/an exception/an exception and not a rule/ Succeeded: s/-owns/-activedescendent/ Succeeded: s/type/types/ Succeeded: s/example code/sample code/ Succeeded: s/two examples/two samples/ Succeeded: s/abl/able/ Default Present: MarkMccarthy, zcorpan, Matt_King, jongund, ZoeBijl, CurtBellew, carmacleod, SiriB, sarah_higley, jamesn Present: MarkMccarthy zcorpan Matt_King jongund ZoeBijl CurtBellew carmacleod SiriB sarah_higley jamesn Regrets: EvanYamanishi BryanGaraventa DorothyBass Found Scribe: We are removing the support gap warning from this meeting's agenda Found Scribe: We are adding an update on Simon's guidance topics to the agenda Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy Found Scribe: thanks for adding that jamesn Scribes: We are removing the support gap warning from this meeting's agenda, We are adding an update on Simon's guidance topics to the agenda, MarkMccarthy, thanks for adding that jamesn Agenda: https://github.com/w3c/aria-practices/wiki/November-12%2C-2019-Meeting 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]