Revise combobox design pattern to reflect ARIA 1.2 requirements

[mcking65]

The combobox specification in ARIA 1.2
includes several changes. Revise the APG combobox design pattern
to reflect these changes.

• Revise intro to reflect the change that the input does not have to be a text box; it could be an input element that does not support editable text.
• Revise description of popup trigger conditions to reflect the change from textbox to input for some implementations
• Revise description of use cases to reflect change from textbox to input
• Revise description of autocomplete behaviors to reflect change from textbox to input
• Revise keyboard section to have an input section, with separate lists of interactions depending on whether the input is editable
• Revise states and properties section so there is no mention of versioning. There is just one list of requirements. At the end, add a note about the 1.0 pattern using aria-owns instead of aria-controls stating it is supported for legacy reasons but advises authors to remediate the implementations that use aria-owns to use aria-controls.
• Throughout entire pattern, ensure all mentions of textbox are either replaced with input, appropriately conditional, or removed.
  This page in the ARIA wiki may be a useful resource:
  https://github.com/w3c/aria/wiki/Resolving-ARIA-1.1-Combobox-Issues

[zcorpan]

Throughout entire pattern, ensure all mentions of textbox are either replaced with input, appropriately conditional, or removed.

I generally used "combobox" instead, since that is the role that is applied to what would be the textbox.

[zcorpan]

Revise states and properties section so there is no mention of versioning. There is just one list of requirements. At the end, add a note about the 1.0 pattern using aria-owns instead of aria-controls stating it is supported for legacy reasons but advises authors to remediate the implementations that use aria-owns to use aria-controls.

d04fa96

[zcorpan]

Revise keyboard section to have an input section, with separate lists of interactions depending on whether the input is editable

I've made the editing-specific interactions conditional on whether the combobox is editable.

What should the interactions be when the combobox is not editable? Should this be modelled after how <select> behaves?

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed ARIA 1.2 Combobox.

The full IRC log of that discussion

<MarkMccarthy> TOPIC: ARIA 1.2 Combobox
<MarkMccarthy> Matt_King: what we hope to have done for MichaelC this week - updating the examples, the grid pattern
<MarkMccarthy> Matt_King: and in doing so, there will no longer be any updates to another pattern - it'll be like any other part of the APG
<MarkMccarthy> Matt_King: just a "combobox" pattern, no 1.1, 1.2 etc.
<MarkMccarthy> Matt_King: i thought it'd be best to do this all in one PR just in case we need a rollback
<MarkMccarthy> Matt_King: because of that, it's a little bigger than planned. PR 1255
<MarkMccarthy> https://github.com//pull/1255
<MarkMccarthy> Matt_King: 2 goals. 1 - make sure people are ready to review this PR thoroughly (ideally in next 24-48hrs)
<MarkMccarthy> Matt_King: so we can respond and help quickly
<zcorpan> GitHub: https://github.com//issues/1250
<MarkMccarthy> Matt_King: there's some changes to wording I want to be able discuss
<MarkMccarthy> Matt_King: goal 2 - discuss any open issues that are there or if we ship them now as they exist
<MarkMccarthy> Matt_King: 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
<MarkMccarthy> zcorpan: thank you!
<MarkMccarthy> Matt_King: curious if people would be okay with code review and CSS issues being raised but addressed later, due to short time frame
<MarkMccarthy> Matt_King: after all, this is WD not a final release
<MarkMccarthy> Matt_King: any objections?
<MarkMccarthy> ZoeBijl: just this pattern or in general?
<MarkMccarthy> Matt_King: just this one
<MarkMccarthy> ZoeBijl: which is the new combobox pattern? as an exception it's fine
<MarkMccarthy> Matt_King: agree
<MarkMccarthy> s/an exception/an exception and not a rule
<MarkMccarthy> Matt_King: unless there's something monstrous, we should send it out. just this once
<MarkMccarthy> ZoeBijl: we should at least fix a11y issues we come across. code standards etc. can be done later
<MarkMccarthy> ZoeBijl: i think it's important for the WD to be accessible
<MarkMccarthy> Matt_King: 100%
<MarkMccarthy> carmacleod: i don't think we can fix that safari issue, it's a safari thing
<MarkMccarthy> Matt_King: we'll see what BryanG says, maybe he has some feedback
<MarkMccarthy> carmacleod: the bug is that listitems aren't being read, activedescendent isn't being read
<MarkMccarthy> carmacleod: might be an issue since aria-owns is gone?
<MarkMccarthy> jamesn: just a theory
<MarkMccarthy> carmacleod: yup
<MarkMccarthy> Matt_King: might be how we changed -owns in 1.1
<MarkMccarthy> carmacleod: true
<MarkMccarthy> s/-owns/-activedescendent
<MarkMccarthy> Matt_King: could be they did what you mentioned jamesn, that they forgot to implement something on textboxes etc.
<MarkMccarthy> Matt_King: unfortunate if it's a bug, no good way to workaround on our end really...
<MarkMccarthy> zcorpan: which example is this a problem in?
<MarkMccarthy> carmacleod: the one Matt_King first did
<MarkMccarthy> Matt_King: i'd imagine it's all of them
<MarkMccarthy> jamesn: worth checking
<MarkMccarthy> carmacleod: so are you adding reviewers Matt_King? let's get it done
<MarkMccarthy> Matt_King: yep
<MarkMccarthy> carmacleod: let's split a11y testing into two? one windows, one mac? I can do windows
<MarkMccarthy> Matt_King: great idea!
<MarkMccarthy> carmacleod: i'll edit the checklist
<MarkMccarthy> Matt_King: do we have a mac person?
<MarkMccarthy> sarah_higley: I can do both, in addition
<MarkMccarthy> carmacleod: sure!
<MarkMccarthy> Matt_King: prioritizing mac first
<MarkMccarthy> sarah_higley: yeah, or both in general
<MarkMccarthy> jamesn: fyi we found they work in chrome+vo but not safari+vo
<MarkMccarthy> sarah_higley: okay
<MarkMccarthy> Matt_King: a11y review doesn't necessarily need screen reader testing, but big tickets like kbd and color contrast, of course
<MarkMccarthy> Matt_King: excluding screen reader bugs, these work with all SRs
<MarkMccarthy> jamesn: that's why we did this, because they work with everyone. so that it doesn't in safari is worrying
<MarkMccarthy> sarah_higley: i have a version of 1.1 that works with safari+vo
<MarkMccarthy> Matt_King: so a11y review is covered
<MarkMccarthy> Matt_King: since simon and I did all the editorial work, we can't
<MarkMccarthy> MarkMccarthy: I can check out editorial tomorrow
<MarkMccarthy> jongund: i haven't read the changes to practices yet
<MarkMccarthy> carmacleod: me either
<MarkMccarthy> carmacleod: thanks MarkMccarthy
<MarkMccarthy> jongund: i also can
<MarkMccarthy> carmacleod: thanks!
<MarkMccarthy> Matt_King: functional testing? if the a11y testing doesn't cover it? can a11y testers also check w/ a mouse to cover that?
<MarkMccarthy> carmacleod: yes I can do that, agree, no big deal
<MarkMccarthy> sarah_higley: definitely
<MarkMccarthy> Matt_King: visual design
<MarkMccarthy> Matt_King: still want to find those issues even if we don't fix them all
<MarkMccarthy> zcorpan: give it to Matt!
<MarkMccarthy> [group laughs]
<MarkMccarthy> zcorpan: nah, I can do it, that's fine
<MarkMccarthy> carmacleod: so code review and test review are left
<MarkMccarthy> sarah_higley: i can do code review, unless I'm taking too much or should do it after a11y review?
<MarkMccarthy> Matt_King: you can do it after. we don't need to necessarily fix these until after
<MarkMccarthy> Matt_King: we want the tests to work but they're not really part of the publication. we just don't want regressions
<MarkMccarthy> Matt_King: let's assign spectranaut (Valerie) to test review
<MarkMccarthy> carmacleod: done
<MarkMccarthy> Matt_King: awesome!
<MarkMccarthy> Matt_King: everything done by EOD tomorrow if possible?
<MarkMccarthy> reviewers: yeah
<MarkMccarthy> 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
<ZoeBijl> q+ to ask which versions of macOS/Safari were used
<MarkMccarthy> sarah_higley: i'll check it out
<MarkMccarthy> Matt_King: we could go back to spinbutton PRs to check out some details
<ZoeBijl> ack
<MarkMccarthy> sarah_higley: maybe I missed something in my implementation
<MarkMccarthy> jamesn: I'll check it out
<MarkMccarthy> ZoeBijl: what versions were used?
<MarkMccarthy> jamesn: I was using catalina and latest
<MarkMccarthy> ZoeBijl: that just came out?
<MarkMccarthy> jamesn: yeah
<MarkMccarthy> ack zoe
<Zakim> ZoeBijl, you wanted to ask which versions of macOS/Safari were used
<MarkMccarthy> 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
<MarkMccarthy> Matt_King: one of my concerns is we don't fall into this thing of referring to a combobox as readonly
<MarkMccarthy> Matt_King: 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//pull/1255.html#combobox
<MarkMccarthy> zcorpan: this is the second paragrah in the intro
<MarkMccarthy> carmacleod: yeah, this all seems true. that's the way they've worked on desktops forever
<MarkMccarthy> Matt_King: i think HTML selects work that way when they're open but not closed, might depend on the browser
<MarkMccarthy> sarah_higley: i've seen comboboxes that include readonly items
<MarkMccarthy> sarah_higley: all over windows, not just desktop
<MarkMccarthy> Matt_King: so there's essentially these two forms. even when it's editable, well that opens up the door to many different type
<MarkMccarthy> s/type/types
<MarkMccarthy> Matt_King: and there's a bunch of types of autocomplete, autoselect, filtering, etc.
<MarkMccarthy> Matt_King: so the very first concept people need straight is these two basic flavors of comboboxes
<MarkMccarthy> Matt_King: editable and "select only"
<MarkMccarthy> Matt_King: don't want people to confuse non-editable with readonly
<MarkMccarthy> Matt_King: i'm anxious about a new term, but need something that's maybe an alternative to readonly
<MarkMccarthy> Matt_King: to me, readonly is one where you can't change anything, select anything, etc. it's literally read only
<MarkMccarthy> carmacleod: it does make sense to use a new term because until now there's only been arguments *chuckle*
<MarkMccarthy> Matt_King: nowhere in the APG have we tackled that. zcorpan did we include readonly in communicating widget states?
<MarkMccarthy> zcorpan: let me look
<MarkMccarthy> 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
<MarkMccarthy> Matt_King: right. --IF-- it's not editable/typeable, it's readonly --
<MarkMccarthy> siri: like a listbox then?
<MarkMccarthy> Matt_King: well an HTML select can be a combobx, or a custom element
<MarkMccarthy> 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
<MarkMccarthy> 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.
<MarkMccarthy> Matt_King: above is some info about comparing comboboxes to other widgets
<MarkMccarthy> [group reading]
<MarkMccarthy> sarah_higley: does this imply a menubutton can have a value?
<MarkMccarthy> 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
<MarkMccarthy> Matt_King: i personally dislike the pattern completely where you choose this and it changes the value of the menubutton
<MarkMccarthy> Matt_King: but we used that in our editor toolbar, particularly with font. communicate the chosen font in the name of the button
<MarkMccarthy> Matt_King: i'd rather have it be a select; it'd be a better experience
<MarkMccarthy> 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?
<MarkMccarthy> 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
<MarkMccarthy> carmacleod: that was my suggestion
<MarkMccarthy> Matt_King: well i don't think we'll ever get rid of this in the wild though
<MarkMccarthy> sarah_higley: maybe we clarify that people -don't- do that?
<MarkMccarthy> carmacleod: yeah
<MarkMccarthy> Matt_King: well we try to avoid antipatterns, and also try to advise against. in any case i'll try to reword that
<MarkMccarthy> zcorpan: so our listbox example that opens a popup is essentially equivalent to a readonly combobox
<MarkMccarthy> Matt_King: maybe we keep it for now for 1.2 but don't strike it. right?
<MarkMccarthy> zcorpan: well I was thinking of converting it to a combobox
<MarkMccarthy> Matt_King: might be possible, good idea
<MarkMccarthy> sarah_higley: kind of like the mac semantic way
<MarkMccarthy> carmacleod: a popup list
<MarkMccarthy> Matt_King: even an HTML select is called a menubutton on mac though
<MarkMccarthy> Matt_King: and it's the only way a menubutton could be required *chuckle*
<MarkMccarthy> Matt_King: I think that's a potential bug with the Mac axe api
<MarkMccarthy> ZoeBijl: a popup button
<MarkMccarthy> Matt_King: ah yes, not a menubutton
<MarkMccarthy> ZoeBijl: so a required popup button [laughs]
<MarkMccarthy> sarah_higley: has anyone found comboboxes on mac that are [phone buzzed]
<MarkMccarthy> sarah_higley: couldn't find any built into the platform that are
<MarkMccarthy> 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
<MarkMccarthy> Matt_King: VO says it's a combobox?
<MarkMccarthy> [Voiceover announced it as combobox]
<MarkMccarthy> Matt_King: oh my god!
<MarkMccarthy> ZoeBijl: the suspense!
<MarkMccarthy> [group laughs]
<jamesn> https://developer.apple.com/design/human-interface-guidelines/macos/fields-and-labels/combo-boxes/
<MarkMccarthy> jamesn: there's guidance on that ^
<MarkMccarthy> 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."
<MarkMccarthy> scribe: thanks for adding that jamesn
<MarkMccarthy> Matt_King: so reviewers are good, text was discussed - oh issues!
<MarkMccarthy> Matt_King: i'll put a link to the project in minutes so folx can scan through issues
<MarkMccarthy> Matt_King: we did close an issue though, now allowing esc to clear a combobox
<MarkMccarthy> Matt_King: works for some, maybe not all. should we fix before ship?
<MarkMccarthy> [silence]
<MarkMccarthy> Matt_King: a functional defect, then perhaps?
<MarkMccarthy> jamesn: yeah
<MarkMccarthy> Matt_King: I don't think i've opened a bug for it. are we okay with such a bug for the WD?
<MarkMccarthy> [silence]
<MarkMccarthy> Matt_King: silence = consent
<MarkMccarthy> Matt_King: on this
<MarkMccarthy> Matt_King: that's it for open combobox issues here