<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

Future Meetings

Matt_King: Next meeting Nov 19, no Meeting Nov 26

Third WD Milestone

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

ARIA 1.2 Combobox

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

Summarizing help items for Simon

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