HTML-AAM: select element should map to listbox role regardless of presentation

[jasonkiss]

From @mcking65 on May 2, 2016 2:6

The html AAM maps the select element differently based on the size and multiple selection values.

This seems like using role to describe presentation rather than interaction model.

HTML select has the interaction model of a listbox regardless of the value of size.

ARIA combo is defined as a composite that includes a textbox and a separate popup element. HTML select does not include a textbox that instantiates a separate popup element.

In the APG, when describing how to build a custom element that is a single-select list, it seems strange that we would tell authors to use combobox when presenting the widget one way and listbox when presenting it another, even if both presentations have the same interaction model.

I propose that HTML select should always map to listbox.

Copied from original issue: w3c/aria#359

[jasonkiss]

From @asurkov on June 21, 2016 12:9

You're not arguing for having both combobox and listbox roles, right?

On semantic level HTML:select is a combobox widget, and HTML:select@size>1 is a listbox widget. At least I'm not sure I follow "interaction model" argument, because HTML:select looks and behaves like a combobox. On API level the browser exposes these widgets (presentations) differently too, for example, it creates different accessible trees for them.

Also this is definitely a legacy issue, and the proposed changes are not backward compatible.

[mcking65]

@asurkov

No, listbox role only.

I have never seen a html select that works like a combobox. They work only like listbox.

The legacy native platforms also have confusing semantics. In native apps, for many years, there have been elements called comboboxes but they work just like a single select listbox. That is, they do not have a edit input where you can type a value to filter the suggestion list.

ARIA has defined combobox as the combined presentation of an input and a suggestion list. If there is no input, then it is just a suggestion list, which is the description of combobox.

The role tells the assistive technology what the interaction model is. For example, a desktop screen reader can provide keyboard interaction hints to the user based on the role. Calling a select element a combo is problematic because it does not have the keyboard interaction model of a combobox. It works like a listbox regardless of the size attribute value.

[asurkov]

On Sat, Oct 15, 2016 at 2:55 PM, Matt King [email protected] wrote:

@asurkov https://github.com/asurkov

No, listbox role only.

I have never seen a html select that works like a combobox. They work only
like listbox.

Could you link me please to definitions of combobox and listbox widgets?

The legacy native platforms also have confusing semantics. In native apps,
for many years, there have been elements called comboboxes but they work
just like a single select listbox. That is, they do not have a edit input
where you can type a value to filter the suggestion list.

ARIA has defined combobox as the combined presentation of an input and a
suggestion list. If there is no input, then it is just a suggestion list,
which is the description of combobox.

The role tells the assistive technology what the interaction model is. For
example, a desktop screen reader can provide keyboard interaction hints to
the user based on the role. Calling a select element a combo is problematic
because it does not have the keyboard interaction model of a combobox. It
works like a listbox regardless of the size attribute value.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#46 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABdnqfPG2zBNY2sSyru_UTntQijT-K5dks5q0SGUgaJpZM4KUU-j
.

[asurkov]

I'm not following the arguments why HTML:select@size="1" is a listbox widget. @jasonkiss do you have opinion on this issue? how do we want to proceed with it?

[jasonkiss]

I think I agree with @mcking65, that select should always be listbox regardless of presence of multiple or size attributes, given its behaviour and the definitions of combobox and listbox.

[asurkov]

I'm not sure if ARIA definitions are relevant here. I argue that HTML:select@size=1 is a combobox widget from the user perspective, i.e. it has a look and feel of a combobox widget. Note, from AT perspective, HTML:select@size=1 is exposed as a combobox widget too, i.e. it has combobox role and contains a listbox child, which more or less matched to ARIA combobox definition.

[mcking65]

@asurkov

The purpose of role for assistive technology users it to describe the interaction model.

I believe the ARIA definition is relevant. The HTML-AAM section 4.4 starts out by stating the requirement to follow mappings in core ARIA. And, the second column of the table is the corresponding ARIA role, which is an explicit statement that the ARIA definition of the role is relevant.

HTML:select@size=1 and HTML:select@size=2 have exactly the same interaction model. Neither has an edit box like an ARIA combobox. Because there is no edit box, you can not use the left/right arrow inside the HTML:select@size=1 to read through the characters of the current value or select them for copy/paste. HTML:select@size=1 does not have the look or feel of a combobox from the perspective of a screen reader user or anyone else using a keyboard.

HTML:select@size=1 works exactly like HTML:select@size=2, which is mapped to a listbox. And, HTML:select@size=1 and HTML:select@size=2 both work exactly like the way ARIA describes a listbox.

I believe the current difference in mapping between HTML:select@size=1 and HTML:select@size=2 is based on an insignificant difference in visual appearance that has no baring on the functional capabilities of the element.

[asurkov]

@mcking65 are we on the same page that HTML:select@size="1" is a combobox widget in its user perception, but your point is that ARIA role='listbox' definition feels closer for the HTML:select@size='1'? Or do you claim that HTML:select='1' is a listbox widget in general?

I wouldn't say that their visual difference of HTML:select widgets is insignificant, HTML:select@size='2' is a classic listbox (which doesn't have any popups), while HTML:select@size='1' is a drop-down widget.

My point is HTML:select@size='1' is a non-editable combo box; both on AT API mapping level and in its visual appearance. If we choose ARIA listbox role for its mapping, then it'd be rather confusing, even its description feels closer to HTML:select='1'. Actually I think that ARIA combobox definition should be changed to allow non-editable combo boxes to not have underlying editable textboxes. @jasonkiss ?

[stevefaulkner]

I thought a combobox has an editable text box, which the HTML select element does not.

…

-- Regards SteveF Current Standards Work @w3c <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>

On 9 January 2017 at 14:50, Alexander Surkov ***@***.***> wrote: @mcking65 <https://github.com/mcking65> are we on the same page that ***@***.***="1" is a combobox widget in its user perception, but your point is that ARIA role='listbox' definition feels closer for the ***@***.***='1'? Or do you claim that HTML:select='1' is a listbox widget in general? I wouldn't say that their visual difference of HTML:select widgets is insignificant, ***@***.***='2' is a classic listbox (which doesn't have any popups), while ***@***.***='1' is a drop-down widget. My point is ***@***.***='1' is a non-editable combo box; both on AT API mapping level and in its visual appearance. If we choose ARIA listbox role for its mapping, then it'd be rather confusing, even its description feels closer to HTML:select='1'. Actually I think that ARIA combobox definition should be changed to allow non-editable combo boxes to not have underlying editable textboxes. @jasonkiss <https://github.com/jasonkiss> ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAzBE4ioFVpm5BqJdi-uMwg8n1K5ssw5ks5rQkkugaJpZM4KUU-j> .

[asurkov]

@stevefaulkner I'm not sure why it has to be necessary condition, because both MSAA and ATK use successfully combobox role for these widgets, but otherwise ARIA probably need a new role for dropdowns.

Anyway ARIA role='listbox' is not a match for HTML:select='1' even if ARIA role='combobox' doesn't work either.

[mcking65]

@asurkov wrote:

are we on the same page that HTML:select@size="1" is a combobox widget in its user perception,

No; I do not believe it is a combobox at all because it does not have an edit box.

@asurkov continued:

but your point is that ARIA role='listbox' definition feels closer for the HTML:select@size='1'?

Yes; it feels closer because HTML:select@size='1 does precisely what ARIA says a listbox should do.

@asurkov continued:

Or do you claim that HTML:select='1' is a listbox widget in general?

Yes, I assert that from an API mapping perspective, it should be classified as a listbox. It is most likely legacy Windows definitions of combo that created lots of flavors of combo, several of which are simply redundant with what is adequately described by the ARIA listbox role.

@asurkov continued:

I wouldn't say that their visual difference of HTML:select widgets is insignificant, HTML:select@size='2' is a classic listbox (which doesn't have any popups), while HTML:select@size='1' is a drop-down widget.

If you are using an assistive technology that relies on role values for rendering interactions, the way you operate a select is exactly the same regardless of the value of the size attribute.
So, the differences are purely visual presentation, not function. ARIA roles are not for describing visual presentation unless that presentation carries semantic relevance.

@asurkov continued:

My point is HTML:select@size='1' is a non-editable combo box; both on AT API mapping level and in its visual appearance.

A non-editable combobox would have a read-only edit that supports moving a caret and selecting all or a portion of the value.

@asurkov continued:

If we choose ARIA listbox role for its mapping, then it'd be rather confusing, even its description feels closer to HTML:select='1'.

By changing the mapping, my aim is to remove confusion. The current situation is confusing because screen reader users hear combobox, but there is no edit box. Super subtle distictions based on visual presentation are confusing to people who cannot see the screen. Two things that work exactly the same way should have the same role so their assistive tehcnology can provide them with reliable instructions for operation.

@asurkov continued:

Actually I think that ARIA combobox definition should be changed to allow non-editable combo boxes to not have underlying editable textboxes.

That would make combobox definition unnecessarily complicated and make it redundant with listbox. I would not support this because it would be an attempt to convey visual presentation instead of meaningful interaction.

[mcking65]

@asurkov wrote:

I'm not sure why it has to be necessary condition, because both MSAA and ATK use successfully combobox role for these widgets, but otherwise ARIA probably need a new role for dropdowns.

I maintain it is not successful; it is complicating. It prevents assistive technologies from doing a really good job of making combobox easier to use and understand because there are forms of it that are redundant with listbox. It is persisting legacy complications for no gain.

@asurkov wrote:

Anyway ARIA role='listbox' is not a match for HTML:select='1' even if ARIA role='combobox' doesn't work either.

In what way is the interaction of HTML:select@size=1 not described by ARIA listbox?

[asurkov]

Let me try to summarize, please correct me I'm wrong.

There's only one difference between HTML:select@size=1 and non editable ARIA combobox, which is the user cannot select a text of a selected option in HTML:select, and thus you think that HTML:select is not a combobox. Then, you state that UI and behavioral difference between HTML:select='1' and ARIA listbox is rather minor, which is HTML:select@size='1' has a popup, but ARIA listbox doesn't have it, and the user has to click a HTML:select control to show all options of the popup before the user can click an option to select, but in case of ARIA listbox the user just clicks an option.

I would say that the existing description of ARIA listbox may be used to describe HTML:select@size='1' at some extent, but it won't be exhaustive, because of popup thing, and that's a key difference between ARIA listbox and HTML:select@size='1' controls. It affects on the user experience and the way the control is exposed to AT.

[jasonkiss]

I agree with @asurkov that HTML:select@size='1' is not sufficiently described by ARIA listbox, since the popup/dropdown menu behaviour, which is included in the HTML5 spec for select@size='1', is not at all part of the ARIA listbox pattern. While listbox works for select@size>1 or select@multiple, I'm not sold on it for select@size='1'. But I don't think combobox works for select@size='1' either, because there's no edit box, which is important and core to the definition of ARIA combobox.

@mcking65 is correct about the legacy confusion in the use of the word combobox. Note, for instance, that the definition of MSAA's ROLE_SYSTEM_COMBOBOX is "an edit control with an associated list box that provides a set of predefined choices." So here combobox jives with the ARIA definition. While the definition of ATK_ROLE_COMBO_BOX is simply a "collapsible list of choices the user can select from". So here combobox really means collapsible listbox.

Safari and Chrome on MacOS render HTML:select@size='1' as AXPopUpButton with AXValue set to the currently selected option. Each option element is mapped to AXMenuItem. When the AXPopUpButton is pressed, or you start using the arrow keys to review the options, it presents a popup menu (role AXMenu) containing the menu items. So select@size='1' works differently here from other browsers where arrow keys alone, without also pressing ALT, do not cause the list of options to popup/dropdown like a menu. And so mapping it to listbox in AXAPI doesn't fit.

But listbox doesn't quite fit for select@size='1' in ATK either, according to the definition of ATK_ROLE_LIST_BOX, because it is explicitly a "non-collapsible list of choices the user can select from."

Meanwhile, UIA's ComboBox Control Type sounds applicable to either select@size='1' or select@size>1 and select@multiple:

A combo box is a list box combined with a static control or an edit control that displays the currently selected item in the list box portion of the combo box. The list box portion of the control is displayed at all times or only appears when the user selects the drop-down arrow (which is a push button) next to the control. If the selection field is an edit control, the user can enter information that is not in the list; otherwise, the user can only select items in the list.

I prefer the AXAPI approach of rendering and accordingly mapping select@size='1' to a button that presents a popup menu of choices, but given the variation across the browsers and a11y APIs, both in terms of implementation and their role definitions, we don't have a corresponding ARIA role that suits across all APIs. And I would say the Core-AAM mappings for combobox need to be reviewed in light of the above (CC @joanmarie @klown)

But there are instances in the HTML-AAM where an element has a default corresponding ARIA role, but one or more of the APIs specify different mappings, so we could specify a corresponding role, then indicated exceptions as applicable.

Based on the existing UA behaviour, a11y API role definitions, and Core-AAM mappings, I'm seeing something like this for select@size='1':

-MSAA+IA2: map to ROLE_SYSTEM_LIST with IAccessible::accSelect() and IAccessible::get_accSelection() methods [same as ARIA listbox mapping in Core-AAM]
-UIA: map to ComboBox Control Type [same as ARIA combobox mapping in Core-AAM]
-ATK: map to ATK_ROLE_COMBO_BOX [same as ARIA combobox mapping in Core-AAM]
-AXAPI: map to AXPopUpButton [with option elements mapped to AXMenuItem, which is contrary to the AXAPI mapping for the ARIA option role as suggested in HTML-AAM and Core-AAM]

So who's got a good solution here?

[mcking65]

@jasonkiss wrote:

I agree with @asurkov that HTML:select@size='1' is not sufficiently described by ARIA listbox, since the popup/dropdown menu behaviour, which is included in the HTML5 spec for select@size='1', is not at all part of the ARIA listbox pattern.

The "popup" behavior is pure presentation. The keyboard interaction of select is identical regardless of the value of the size attribute.

As I am now working on drafting the APG combobox pattern, this confusion introduced by select mapping is gaining new urgency.

In case anyone is interested, the
combobox design pattern
is now in the master branch of the editor's draft of the Authoring Practices.

[mcking65]

At the May 2018 meeting of ARIA WG at Mozilla in Toronto, we discussed this issue. Unfortunately, I cannot find where in the minutes:

• Day 1
• Day 2
• Day 3

It's quite odd that the discussion was not captured. There is the possibility that I'm overlooking it. So, the following is from memory.

Conclusion was to work on solving by:

1. In ARIA 1.2, Add support for aria-expanded to listbox (Add aria-expanded as a supported property of listbox aria#722).
2. In ARIA 1.2, consider adding support for aria-valuetext to listbox if needed for listboxes when in collapsed state; I think actual need here is TBD (Add aria-valuetext as a supported property of listbox aria#721).
3. Change html-aam to map select@size=1 to listbox with aria-expanded false when options are hidden and true when options are shown (this issue once 1 and 2 are done).

[carmacleod]

@mcking65

The "popup" behavior [of HTML:select@size='1'] is pure presentation.

Not quite. Sure, if you give focus to an html select, you can use the up/down arrow keys (or type the first letter of an option) to choose a value, and this behavior is identical to listbox. However, there are additional keystrokes for HTML:select@size='1' that do not apply for listbox:

• drop down the list by typing alt+up/down or the space key
• then select an option with up/down (or type first letter)
• close the list with alt+up/down (or enter, tab, shift+tab or esc).

Note specifically that alt+up/down in a listbox will change the selection, but alt+up/down in select@size='1' will not.

[JAWS-test]

The select element (size=1) and the input element with a list attribute are different elements, but have the same role: combobox. The problem should be fixed so that select elements are always output as listbox (or with another role), but never as combobox.

Examples of differences:

• input with list attribute: free text input possible, filtering of entries after text input, no navigation possible in closed state, visually indistinguishable from an input field in most some cases (IE, Edge, Firefox, Chrome; in Chrome and the future Edge, the triangle is only faded in when the field gets the focus), no quick navigation; once a value has been entered or selected, the remaining list entries are no longer displayed.
• select: No free text input possible, no filtering of entries possible, navigation through list entries possible in closed state, visually always recognizable as select by triangle, quick navigation by entering a character; even after selecting an entry all other entries are visible

For blind users there is hardly a difference in functionality and operation between select size=1 and select size > 1, but a difference to input with list attribute.

Note: JAWS, for example, outputs the elements with different role names.

Note: The W3C does not use the combobox role in the ARIA Practices, but a button and the listbox role to build a select size=1 with ARIA (http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-collapsible.html).

Note: According to the ARIA specification, role=combobox can be used together with a read-only input field and then resembles a select size=1. However, this is no longer equivalent to input with list-attribut, because readonly attribute causes the whole element to be read-only.

In my opinion, all the confusion with combobox results only from the fact that in desktop applications from e.g. Microsoft the drop-down lists that correspond to select size=1 are called combobox.

[craigkovatch]

It may shed some light to consider the simple etymology of the word "combobox" -- "combo" refers to the combination of an editable text field and a list of options. If there's no text field, there's no combination of controls, so there's no combobox.

So I agree with @mcking65 that a size-1 HTML select is a (visually-collapsed) listbox.

Just stumbled on this thread while researching another pattern, apologies to randomly barge in :)

[JAWS-test]

If select is not associated with listbox as it used to be, several documents still containing the old assignment would have to be revised, e.g. https://www.w3.org/WAI/WCAG21/Techniques/html/H91, example 6: "Example 6a has a role of list box from the select element."

[melanierichards]

My vote is we should keep the mappings as-is for now. Excellent example of mismatched paradigms between HTML and native platfrom APIs, unfortunately. ☹

For UIA specifically, the expectation is that a ListBox supports multiple selections, Combobox supports singular selections, has an expand/collapse paradigm, and can take 0 or 1 edit boxes (the description actually describes pretty well a <select>). If anything, always mapping to Combobox would be interesting, if that pattern supported multiple selections.

I think the user experience problems would be best addressed by AT. Perhaps future exploration of the paradigm can occur on the native API layer, at least with modern APIs. But I don't believe the best place to start is by changing HTML mappings, because we'll still have issues, just different ones.

[eps1lon]

I struggled with this issue the past few days. Especially because the different specifications (and versions) directly conflict with each other.

Using editors drafts

A composite widget containing a single-line textbox and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the textbox.

-- https://w3c.github.io/aria/#combobox

Clearly not a <select />

select (with NO multiple attribute and NO size attribute having value greater than 1) | role=combobox

-- https://w3c.github.io/html-aria/#el-select

Collapsible Dropdown Listbox Example: Single-select collapsible listbox that expands when activated, similar to HTML select with the attribute size="1".

-- https://w3c.github.io/aria-practices/#Listbox

And then how Chrome 77 currently displays this in their a11y tree:

<label>
  Use release channel
  <select>
    <option>canary</option>
    <option selected>alpha</option>
    <option>beta</option>
  </select>
</label>

Those are actually menuitems with a selected state.

Using working drafts

A composite widget containing a single-line textbox and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the textbox.

-- https://www.w3.org/TR/wai-aria-1.2/#combobox

select (with NO multiple attribute and NO size attribute having value greater than 1) | role=combobox

-- https://www.w3.org/TR/html-aria/

A combobox is a widget made up of the combination of two distinct elements: 1) a single-line textbox, and 2) an associated pop-up element for helping users set the value of the textbox.

-- https://www.w3.org/TR/wai-aria-practices-1.1/#combobox

And this is IMO the strongest argument for a listbox:

Allowed ARIA role attribute values:
listbox (default - do not set) or menu.

-- https://www.w3.org/TR/html50/forms.html#the-select-element

Summary

As I interpret this the governing spec (as I see ARIA) disagrees with the mapping and the example implementation as well. Only the spec about the mapping from spec to implementation defines a <select /> as a combobox. IMO the middleware should concede this point until this issue is discussed again. Right now this is the most confusion part of a collection of documents that is very clear to me as a component author.

PS: Fairly new to W3C specs but why is this even discussed in HTML-AAM? The current spec does not contain any section describing how native HTML elements map to ARIA. I only found sections about this in HTML-ARIA.

[mcking65]

With the combination of w3c/aria#1051, w3c/aria#1223, and w3c/aria#1225, the ARIA 1.2 combobox no longer needs to include or be made from an element with the textbox role, and it can expose a value to assistive technologies without an editable input element. Thus, the ARIA 1.2 combobox can perfectly emulate a select@size=1.

With these changes, the HTML-AAM mapping of select@size=1 to the combobox role makes perfect sense. So, assuming these ARIA changes make it all the way through to rec, we can close this issue.

[eps1lon]

@mcking65 Is there a working example of the 1.2 pattern in the APG? I can't make heads or tails off all the contradicting SHOULD statements in the ARIA 1.2 combobox. Specifically, I'm not understanding how you can say with such a confidence that the combobox "no longer needs to include or be made from an element with the textbox role". The ARIA 1.2 combobox mentions an input multiple times and a select@size=1 does not have an input but a button.

[JAWS-test]

@eps1lon:

ARIA 1.2 says:

A combobox input MAY be either a single-line text field that supports editing and typing or an element that only displays the current value of the combobox

The second part of the definition (after the "or") applies to select size=1.

I suppose that there is nothing to change. I also consider the current solution inappropriate (see w3c/aria#1051 (comment)).

[craigkovatch]

I too am struggling to understand why a select size 1 would be a combobox and not a button with-a popup.

[eps1lon]

The second part of the definition (after the "or") applies to select size=1.

Sure, I'm not saying that there are sentences from which I can derive a markup that implements select@size=1. It's just that sentences contradict each other. First a combobox always has an input and in the next sentence it doesn't need one. Maybe I'm reading the spec wrong? Does the last sentence always override previous ones?

[JAWS-test]

@eps1lon

It's just that sentences contradict each other. First a combobox always has an input and in the next sentence it doesn't need one.

You're right. The first sentence should be reworded. It is currently:

A combobox functionally combines a named input field with the ability to assist value selection via a supplementary popup element

This contradicts the second sentence. Sorry, I had not read carefully enough

[JAWS-test]

@craigkovatch

I too am struggling to understand why a select size 1 would be a combobox and not a button with-a popup.

The problem with a button is that it cannot have most of the important properties of a form field, such as invalid, required, errormessage, etc. Also it cannot have a label and a value at the same time.

[carmacleod]

APG example: https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html

The word "input" in the combobox spec refers to the abstract "input" role.
Which is obviously a source of confusion because of HTML input... (and also because a button isn't an ARIA input... but a combobox is...).
Agree that some wordsmithing is required here.

[JAWS-test]

@carmacleod

The word "input" in the combobox spec refers to the abstract "input" role.

I think this is only valid for the first sentence (input is also linked there):

An input that controls another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the input.

But I don't think it applies to the second sentence (different name and formatting):

A combobox functionally combines a named input field ...

Not to mention that "input field" is wrong, because it is not always an input field, but just a div or any other element without role, if select@size=1 is to be emulated.

I think that the sentences should be reformulated (w3c/aria#1349).

[scottaohara]

Let's please not get off topic with commenting on ARIA/APG wording in this issue.

Per the issue that @JAWS-test just opened, any ARIA wording discussion can move there.

To tie up some lingering comments about misalignment is specs / how browsers expose element roles, there is no misalignment (save for the reference to the HTML 5.0 spec, which is outdated when compared to the 5.2 spec... which that information is redundant to ARIA in HTML which is what the HTML Living Standard references). HTML AAM indicates the current mappings correctly. ARIA in HTML says similar. The ARIA spec is talking about the input abstract role, not the HTML element (again, discussion about this confusion can move there). Browsers may expose roles differently in their a11y panels than how they consume the platform mappings (defined either here for HTML elements, or in CORE AAM which this spec references for such elements). That can be confusing, but is not relevant to this issue or how the elements are defined in this spec.

[mcking65]

I think we can close this issue now. It is essentially overcome by events -- the changes in ARIA to accommodate existing mappings.

[scottaohara]

Agree @mcking65, thanks