The ARIA 1.1 Combobox design pattern endorses unlabelled form fields as normative spec.

[accdc]

Within the ARIA 1.1 Combobox design pattern, the following markup is specified as the proper syntax for the new 1.1 combobox structure.

<div aria-label="Tag" role="combobox" aria-expanded="true" aria-owns="owned_listbox" aria-haspopup="listbox"> 
    <input type="text" aria-autocomplete="list" aria-controls="owned_listbox" aria-activedescendant="selected_option">
</div>
<ul role="listbox" id="owned_listbox"> 
    <li role="option">Zebra</li> 
    <li role="option" id="selected_option">Zoom</li>
</ul>

Specifically, the following:

    <input type="text" aria-autocomplete="list" aria-controls="owned_listbox" aria-activedescendant="selected_option">

This is going to lead to major accessibility issues across devices since the combobox role is not a substitute for a labelling mechanism according to the AccName spec.

[carmacleod]

@accdc

the combobox role is not a substitute for a labelling mechanism according to the AccName spec.

Would it work if we add an item to the beginning of the list in AccName step 2E to say something like:

• If the embedded control has role textbox, and it is a descendant of an element with role combobox, then compute the text alternative for the combobox beginning with step 2, and set the result to that text alternative. Append the value of the textbox control to the result, with a space. Return the result.

@joanmarie Is this close? You are so good with AccName words! 😄

[carmacleod]

Here are 3 more combobox test cases that I would like to ensure would work with any accname changes that we make. Note that none of these have aria-autocomplete.

• Combo 1 is basically the same as @accdc's example, above, except with a visible label (and no autocomplete)
• Combo 2 is the same as Combo 1 except read-only
• Combo 3 is also read-only, but it uses a span for the textbox, tabindex="0" on the combobox div, and "pops up" a dialog instead of a listbox

One problem that is noticeable is that JAWS and NVDA don't even recognize Combo 1 and Combo 2 as comboboxes, let alone labelling them correctly. The same problem exists with the APG ARIA 1.1 combobox examples, but it is not as noticeable because those examples all have aria-autocomplete and they are spoken as "Edit, has autocomplete", so the user might miss that there's no mention of "combobox".

[stes-acc]

One problem that is noticeable is that JAWS and NVDA don't even recognize Combo 1 and Combo 2 as comboboxes....

This is something to file in Github of VFO-standards-support.

[carmacleod]

Good point @stes-acc. Also NVDA Github Issues.
However I think I will wait until after the 1.1 combobox pattern is discussed at the F2F.

[carmacleod]

Actually, there may already be an open issue for this against JAWS:

• JAWS auto-forms mode is not recognizing the comboboxes with list boxes.  FreedomScientific/standards-support#167

There are open JAWS issues for the labelling problem to keep in mind for the F2F discussion, because putting the label on the input results in unlabelled comboboxes in the JAWS Form Fields Dialog:

• Combobox with form fields dialog FreedomScientific/standards-support#77
• JAWS 2019 and Comboboxes with Grids and Listboxes have no label FreedomScientific/standards-support#171

[css-meeting-bot]

The ARIA Working Group just discussed ComboBox 1.1 pattern issues - how to resolve?.

The full IRC log of that discussion

<jamesn> TOPIC: ComboBox 1.1 pattern issues - how to resolve?
<jamesn> https://github.com//issues/893
<CurtBellew> mck: quick refresher of 1.1 srt combobox
<CurtBellew> mck an edit field like a text box and that text box could open a list box
<CurtBellew> and the list box was owned by the text box
<CurtBellew> the list box had to be inside the textbox
<CurtBellew> mck we wanted to fix it so the list box could be visible outside the txt box
<CurtBellew> mck then extend it to allow things like trees and grids in the lst box
<CurtBellew> mck: compromise 1.1 - a container would hold the two pieces
<CurtBellew> mck: eg spin button that would contain all the pieces
<CurtBellew> mck: container contains the text box and the list box
<CurtBellew> mck: label would go on the container
<CurtBellew> mck: the text box would inherit the label
<CurtBellew> mck: that doesn't happen right now. do we want to change the spec so that we just label each part in the wrapper ? <-option 1
<CurtBellew> option 2 -> change it so accname is retrieved from the wrapper.
<CurtBellew> and the components also have labels
<CurtBellew> option 3 -> change the accname calculation so that the contained inputs get their label from the container
<CurtBellew> mck: spinbutton can contain a button. most spinbutton are usually written so that the label is onthe input. but the spec has it so the label can be on the parent
<jamesn> q+
<CurtBellew> mck: there is a similar situation wrt to this proposal : spinbutton
<CurtBellew> bg: spin button is a composite widget? mck: yes
<CurtBellew> bg: the challenge from the name computation is to account for both that doesn' exclude one or the other
<CurtBellew> jamesn: simplest approach seems to be use the same text for the label
<jamesn> ack me
<CurtBellew> Glen: JAWS in browsers other than IE
<CurtBellew> Glen: we actually speak all the items in the hierarchy that are changed
<CurtBellew> Glen: works well for items in a grouping. if you want to hear the name of just the focused control adfter you have once heard the group name
<CurtBellew> jamesn: anything in the hierarchy is read if you change?
<CurtBellew> glen: yes
<CurtBellew> mck: @ glen: JAWS is coded that way - should it influence this decision?
<CurtBellew> glen: given the nature of the web it's a cause to pause for thought
<CurtBellew> glen: shouldn't impact this decision though
<CurtBellew> glen: drop down portion should get the same label
<CurtBellew> mck: isn't it really better for the user if the popup has a nice label
<CurtBellew> glen: why not leave the container and give it a layout role.
<CurtBellew> mck: keeping the combobox wrapper is almost like other comosite things like a grid
<jamesn> q+ to ask Joanie what orca does in this situation?
<CurtBellew> mck: similar to a table. rows and columns have labels also.
<CurtBellew> glen: requiring labels on all three will mean some 'creative' labeling
<CurtBellew> jamesn: what do other AT do?
<CurtBellew> joanie: same thing. read the hierarchy
<CurtBellew> mck: others seem to do the same thing
<CurtBellew> jamesn: so this isn't really a problem?
<CurtBellew> glen: the drop down portion won't have a unique label so that's an issue
<CurtBellew> mck: the wrapper pattern isn't really supported yet
<jamesn> ack me
<Zakim> jamesn, you wanted to ask Joanie what orca does in this situation?
<CurtBellew> bg: recommend the ability to label the input. one problem is that the combobox is written is that you could have anything in the drop down
<CurtBellew> bg: anything. radio buttons ,anything
<CurtBellew> bg: how to find and label the correct thing is difficult at best
<CurtBellew> bg: label the input and the combobox
<CurtBellew> bg: the combobox region and the listbox then are differentiated
<CurtBellew> bg: makes the most sense to me from a usability sense and wouldn't require a rewrite of the accname spec
<CurtBellew> bck: great example. in that all three things have a unique label
<CurtBellew> bck = mck
<CurtBellew> mck: the problem is in making the labels all unique
<CurtBellew> mck: what if all three were given the same label
<CurtBellew> bg: AT could filtre them out and say one instead of both
<CurtBellew> jamesn: maybe the recommendation to label them all the same isn't bad
<CurtBellew> bg: usability wise. the combobox is treated like a single line control. everything is flattened out to be a single form field.
<CurtBellew> bg: change it to be more like a region. you could use the arrow key to see the parts
<CurtBellew> mck: right, taht was the goal. to see them all separately
<CurtBellew> glen: what if the combobox isn't expanded
<CurtBellew> mck: then the combobox wouldn't be visible at all
<CurtBellew> mck: sounds like we're landing on changing the combobox spec slightly.
<CurtBellew> mck: the combobox has name required true. supports the aria-label and aria-labelledyby
<CurtBellew> mck: so maybe we just have to change the example
<CurtBellew> mck: if you were to read the spec for edit box and list box they already have it
<CurtBellew> jamesn: change the suggestion to make the labels all the same?
<CurtBellew> carolyn: AT don't even recognize that you've entered a combobox
<CurtBellew> carolyn: some detail comes through but that's not revealed to the user
<CurtBellew> mck: jsut an implementation detail now. we haven't worked with the AT developers to fix that so we can use that pattern
<CurtBellew> jamesn: we really need to do that
<CurtBellew> mck: yes
<CurtBellew> mck: no need to wait on that
<joanie> q+
<CurtBellew> jamesn: hopefully any example in the APG is now solid enough taht if you see it and feel it's not supportable by AT we need a bug
<CurtBellew> jamesn : that answer @ glen
<CurtBellew> jamesn: recommendation is to label all three with the same label
<CurtBellew> carolyn: we need to make sure that ATs understand the reason for redundency
<jamesn> q?
<CurtBellew> mck: we should do some examples of both same label and different labels
<CurtBellew> mck: we've seems examples where both are a good idea
<CurtBellew> mck: leave it to the ATs to decide how they want to handle it. if the labels are they same text they decide
<CurtBellew> joanie: it could be that the AT isn't getting the focus change event that carolyn is asking about
<jamesn> ack jo
<CurtBellew> bg: the way the combobox role currently works. if the events aren't correct then the AT won't know
<CurtBellew> bg: my concern is taht we don't want to break what works in 1.0
<CurtBellew> bg: my worry is about messing around with how the events are triggered
<CurtBellew> mck: @ bg - don't break backward compatability?
<CurtBellew> bg: yes
<CurtBellew> CurtBellew: a checker will test taht each field has an input. duplicates are definitely allowed but they have to exist? #@mck
<CurtBellew> mck: yes
<CurtBellew> mck: the tihng that triggers the events is the input.
<CurtBellew> mck: the aria expanded spec is pretty clear
<CurtBellew> mck: an input text field that controls a list box then the input has aria controls
<CurtBellew> mck: aria expanded should be on the edit
<CurtBellew> carlyn: be careful with that.
<CurtBellew> carolyn: we have them that are impleneted with a span instead of an input
<CurtBellew> carolyn: @glen works great with JAWS
<CurtBellew> mck: doesn't follow the spec for combobox
<CurtBellew> or aria expanded
<CurtBellew> mck: it's an accident that it works
<CurtBellew> carolyn: works within nvda as well.
<CurtBellew> mck: that's ok - the combobox role should be on the wrapper
<CurtBellew> mck: if you have a separate text box role then you aren't using the 1.1 pattern
<CurtBellew> mck: the 1.1 pattern aria expanded and aria controls are on the element with the text box role
<CurtBellew> mck: and focus
<CurtBellew> should go to the textbox role
<melanierichards> q+
<jamesn> q+
<CurtBellew> mr: looking at ui automation documentation and i don't think this change will work here
<CurtBellew> mr: the expand and collapse are expected on the main control. so I don't think this change will work
<CurtBellew> mck: @ how does that work? examples in other non-web places
<CurtBellew> mr: I'd have to find some examples
<CurtBellew> mck: in 1.0 there really isn't a text box because the text box is what has the combobox role
<CurtBellew> mr: in the tree it's combobox parent with listbox children. were you expecting a flatter structure?
<CurtBellew> mck: @melanie. 1.0 has a textbox with the combobox role
<CurtBellew> mck: it's all one thing. inside is a text box with the combobox role. inside it also is the listbox. so there is no textbox at all in side it (because the text box has the combobox role)
<CurtBellew> mck: in 1.1. The wrapper is the combobox. inside that is the text box and a sibling ot that is the listbox
<CurtBellew> mck: these are all distinct. individually labeled
<CurtBellew> mck: in 1.0 only the one thing is focusable - the combobox. that's where active descendant comes in here.
<CurtBellew> mck: in the case of 1.1. if aria expanded is on the outer wrapper - it doesn't control anything
<CurtBellew> glen: why can't the text box control the wrapper
<CurtBellew> mck: the popup isn't a descendent of the text box
<CurtBellew> mck: in teh case of the 1.0 combobox the list box is that aria active descendent of the text box
<CurtBellew> mck: 1.1 they are siblings. so we rewrote the active descendant spec to indicate that it can be a a child or a sibling
<jamesn> q?
<jamesn> ack me
<jamesn> ack me
<jamesn> ack mel
<CurtBellew> bg: what I've been telling people to do is if ou have a 1.1 design pattern and you change the aria controls it works
<CurtBellew> mck: if you do the 1.1 pattern without the combobox on it things work very well. but ...
<CurtBellew> mck: @ melanie - probably the reason why aria expanded is where it is because it causes problems for everyone other than UIA
<CurtBellew> mck: it really does work better on all the other platforms
<CurtBellew> glen: is there a prohibition on having aria expanded on both ?
<CurtBellew> bg: we have two different designs patterns. using aria active descendant on the input. using role list box have aria expanded on it
<CurtBellew> bg: you aren't actually setting focus to the role expanded element
<jamesn> cb: you were saying Matt that if you followed the 1.1 pattern and put all the stuff on combo it works well
<jamesn> mk: yes if you put it all on the edit box it works well
<jamesn> mk: aria-autocomplete tells you it has autocomplete
<jamesn> mk: to support mentions could have a multi-line input with autocomplete. Random places in a RTF with an @ sign
<jamesn> cb: when you enter the field AT will announce like in a standard list box
<jamesn> mk: select size 1
<jamesn> cb: one of things I come across are combos and have to check what kind of combo it is.... things which don't have baggage on them would be nice
<jamesn> ... I don't know that this is part of the design pattern though - it funxcitons but just kind of works
<jamesn> mk: we just haven't done it yet in the APG but have talked about things
<CurtBellew> mck: @mr. are you objecting?
<CurtBellew> mr: yes. there is a chance that we could talk to them and ask if things can be changed.
<CurtBellew> carolyn: formal objection
<CurtBellew> carolyn: my read only combobox pops up a dialog and the dialog will change the value of the input
<CurtBellew> jamesn: we don't have a formal proposal. so instead of saying we have objections on the table is inaccurate.
<CurtBellew> jamesn: they would be objections if we had the proposal
<CurtBellew> mr: yes
<CurtBellew> joanie: aria expanded is a state so AT can deal with that. but not everything can
<CurtBellew> mck: options button expanded and options button collapsed. that's how it works and that's what users expect
<CurtBellew> joanie: it's on the button yes
<CurtBellew> joanie: on other platforms that are not UIA. other platforms can deal with this is that we don't have a pattern. these are togglable things or expandable then the pattern isn't exposed
<CurtBellew> joanie: those are just states that can be checked for. there is no interface for the other platforms
<joanie> s/for the other platforms/for UIA, as I understand it/
<joanie> q+ Because I think I have an idea
<joanie> q+ to share a possible implementation solution
<CurtBellew> mr: combobox control with the input text with the aria expanded state would mean mapping something to an element that it's not on. the aria expanded isn't on the combobox but ont he text box
<CurtBellew> mr: I'd have to talk to developers about that
<joanie> ack me
<Zakim> joanie, you wanted to share a possible implementation solution
<CurtBellew> joanie: I think I have a solution
<bgaraventa1979> q+
<CurtBellew> joanie: for the expandable state for mr platform. if we ascend the hierarchy then we get the combobox. we then find the input with the aria expanded. go back up the hierarchy to the combobox role
<CurtBellew> jamesn: if it'sn ot found then it's an error case?
<CurtBellew> joanie: yes
<CurtBellew> jamesn: can it be with aria owns or not?
<CurtBellew> joanie: yes
<CurtBellew> mck: 1.0 pattern. nota problem because comboboxes are expandable
<CurtBellew> mck: multi line edit field.
<CurtBellew> something like a drop down that will show on a trigger. slack allows an @ to point to somone in particular and will provide a drop down
<CurtBellew> joanie: @mr - in that case what kind of api does exist in UIA?
<CurtBellew> mr: I'll have to look in to that
<CurtBellew> mck: @ joanie: from an implementation you tihnk we might be able to make the adjustment to the 1.1 pattern? aria expanded on the input that is
<CurtBellew> joanie: yes.
<CurtBellew> mr: consistency across everything that consumes this API. I'm worried. UAI now has a proxy that allows clients that are using UIA to interact with IA23
<CurtBellew> IA2
<CurtBellew> mr: does it create complications for AT clients as well
<CurtBellew> mck: one other question before going forward with this. a 1.0 pattern and a 1.1 pattern. rather call this a bug in the pattern and keep it as a 1.1 pattern. not the 1.2 pattern
<CurtBellew> jamesn: confusing to have a 1.0 and a 1.1 pattern. they all should work
<CurtBellew> bg: glad you brought up that. it is allowed just not documented. we have a lot of patterns that are allowed in the 1.0 spec
<CurtBellew> bg: We hav ethings that aren't documented because we aren't changing the 1.0 spec. people assume that the 1.0 spec and 1.1 spec are totally different. that's not true
<CurtBellew> jamesn: true we should document that
<CurtBellew> mck: we can document things that are hybrid but do actually work
<CurtBellew> mck: we didn't build APG with all of these examples
<CurtBellew> mck: can we consider this a bug in aria 1.1? the fact that aria expanded is on the combobox instead of the input
<carmacleod> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm
<CurtBellew> mck: the bug is to correct and put the aria expanded on the 1.1 spec
<CurtBellew> carolyn: link is to bg aria combobox read only. same as what I'm talking about
<CurtBellew> carolyn: this comcobox works perfectly with AT. we are talking about rewriting this one
<CurtBellew> mck: in 1.0 the combobox owns everything. so taht is the 1.0 pattern
<CurtBellew> bg: the reason this works is because it contains aria-owns. i use aria controls
<CurtBellew> bg: that's why it works
<CurtBellew> carolyn: @bg : so this example is a 1.0?
<CurtBellew> bg: yes
<CurtBellew> mck: move forward calling it a bug
<CurtBellew> jamesn: can you create a PR
<CurtBellew> mck: yes
<CurtBellew> mr: can we rewind to why we're doing taht?
<CurtBellew> mck: it's what has focus. and the spec says we put that on the controlling element
<CurtBellew> mr: the spec actually says you can it on both
<CurtBellew> mck: that's issue 681. we have an item to discuss that
<CurtBellew> CB: in the 1.1 pattern where does the aria owns go?
<CurtBellew> mck: implementation perspective it doesn't matter.
<CurtBellew> bg: if you're using the 1.0 pattern. don't use aria owns
<CurtBellew> mck: forward with the pr so support aria expanded on the text box
<CurtBellew> jamesn: for that we need to file implementation issues etc
<CurtBellew> carolyn: it'll be on the combobox for the 1.0
<CurtBellew> mck: yes
<CurtBellew> mr: we would need to file an issue on core aam
<jamesn> GitHub: https://github.com//issues/893

[jnurthen]

related #1046

[zcorpan]

#1051 is merged.