Fix combobox issues #1051
Fix combobox issues #1051
Conversation
|
I wont be at TPAC, so i'll leave my comments here. Changing combobox this way worries me, as Salesforce has already followed the 1.1 spec and created both design system guidelines and web components using this structure. https://www.lightningdesignsystem.com/components/combobox/ The 1.1 structure makes perfect sense as combobox is a combination of an input and a list, tree, grid, etc. Also, in the case where we are mimicking an html we place readonly on the so that users cannot type. In this case the input is readonly, but the combobox is not, and therefore should communicate that it can take input. Can we not move the AT vendors to move towards 1.1? |
|
"Changing combobox this way worries me, as Salesforce has already followed the 1.1 spec and created both design system guidelines and web components using this structure." This is what always worried me about this design pattern, and why I pushed for adding the criteria in the APG Read Me section saying that all web components need to be tested for sufficient accessibility support before adding them to production environments. This is why I'm seeing so many inaccessible combobox implementations across public sites like GitHub and others, and yes Salesforce too, where it is extremely difficult to accessibly use them now, and this is harming accessibility everywhere as a result. |
|
I understand this perspective, but major accessibility auditing companies (Level Access included) often point to the APG when bugs are found during evaluations. We also regularly get customer feedback in the form of "bugs" citing our ARIA 1.0 components as inaccessible, with remediation guidance to move to 1.1. For many, APG is the source of truth for accessible component development. For this reason, we've adopted an approach where we follow APG and wait for AT to catch up. If things are egregiously inaccessible, we'll make adjustments, but no one wants to support all the browser/AT and versions that exist. Regarding Combobox specifically, we have found that our 1.1 comboboxes see much better support than our older 1.0 combos. |
There was a problem hiding this comment.
Thank you for putting the time into improving the combobox.
First time reviewing one of these so please forgive me if I made some false assumptions about the usability of these when using mouse pointers:
-
When the listbox is open clicking outside the combobox won't close it but clicking inside the textfield will
-
first click will open the listbox, second will close it but subsequent clicks will toogle to open state in rapid succession
-
when to menu is opened mouseleave will only close if the listbox has been mouseentered. This is confusing if the listbox is opened by clicking the textfield and mouseleaving the widget will only close it after the listbox has been entered. I would suggest not closing the listbox after mouseleave. I find these behaviors very frustrating personally.
-
Hovering/clicking the label opens the listbox which is nice but can be confusing in this case since it covers the full line resulting in a noticeable invisible hitbox.
|
Thanks, it's true that Level Access points to the APG for general guidance, but not for the combobox widget. All of the reasons why are discussed in the following article, which I've instituted as a company policy for Level Access. If your 1.0 comboboxes were constructed using this criteria, they would not be inaccessible. These have been tested across all mainstream AT and browser combinations on all supporting platforms to ensure this. |
index.html
Outdated
| </p> | ||
| <p> | ||
| Elements with the role <code>combobox</code> have an implicit <pref>aria-haspopup</pref> value of <code>listbox</code>. | ||
| If the <code>combobox</code> popup element has a role other than <rref>listbox</rref>, authors MUST specify a value for <pref>aria-haspopup</pref> that corresponds to the type of its popup. |
There was a problem hiding this comment.
Maybe change:
corresponds to the type of its popup.
to:
corresponds to the role of its popup.
(because it feels more precise)
index.html
Outdated
| <ul role="listbox" id="owned_listbox"> | ||
| <li role="option">Zebra</li> | ||
| <li role="option" id="selected_option">Zoom</li> | ||
| <input type="text" aria-label="Tag" |
There was a problem hiding this comment.
This example would be friendlier if it used a <label for="the-text-input">Tag</label> instead of an invisible aria-label="Tag". :)
There was a problem hiding this comment.
Curious why not? As a sighted user, I prefer when a combobox has a visible label. I think we should model the most inclusive behavior?
There was a problem hiding this comment.
That was supposed to be a thumbs up ... guess I somehow chose wrong emoji. Making the change.
index.html
Outdated
| The ARIA 1.0 specification describes a <code>combobox</code> pattern where the input element with the <code>combobox</code> role references the popup element with <pref>aria-owns</pref> instead of <pref>aria-controls</pref>. | ||
| <a>User agents</a>, <a>assistive technologies</a>, and conformance checkers SHOULD continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional. | ||
| The ARIA 1.1 specification describes a <code>combobox</code> pattern where the element with role <code>combobox</code> is a composite container instead of a focusable input. | ||
| <a>User agents</a> and <a>assistive technologies</a> did not adequately support the ARIA 1.1 pattern, and this pattern supersedes the ARIA 1.1 pattern, which authors SHOULD abandon. |
There was a problem hiding this comment.
Not sure if "this pattern" is specific enough in the following phrase:
and this pattern supersedes the ARIA 1.1 pattern
Consider changing to:
so the ARIA 1.2 pattern supersedes the ARIA 1.1 pattern
| @@ -2163,15 +2198,7 @@ <h2>Definition of Roles</h2> | |||
| </tr> | |||
There was a problem hiding this comment.
Weird typo in "Related Concepts:" row (was there before, but trivial to fix):
- Delete
/a>after[[HTML]]
|
Hi @eps1lon Thanks for the good feedback on mouse behavior problems in the combobox example! The current issue is about updating the ARIA combobox specification. The above Example Implementation was based off of an APG combobox example. Issues can be opened in the APG issue tracker. I suspect that the mouse problems you are experiencing may exist in some of the other APG combobox examples as well. |
|
@jhausler1266 commented:
I get this point totally ... there is a logiclal appeal to it. It is that logical appeal that convinced me to write the 1.1 structure into the spec even though I didn't really want to do so. 3 years later I am kicking myself for not pushing back harder, which would have probably meant we would have not made changes and stuck with 1.0 structure. maybe that would have been better than being in the position we are in now.
I hoped 1.1 would help with this, but in reality there is no way that it can. Since the mid-90's, screen readers have presented the textbox as the combobox, not as something separate or as something inside the combobox.
It is not impossible to get some of the bugs fixed. However, I don't think we will ever get screen readers to present the combobox as a composite widget -- never. I think the primary argument will always be that it will be really confusing for users because it has never been a true composite. It would also mean we have to also change how html:select@size=1 gets presented, which is also not proving straightforward. On the other hand, changing a combobox from a composite to an input has pretty much 0 inertia on the screen reader side because it has always been presented that way. |
|
In case it's interesting, NVDA merged a PR 3 days ago to support ARIA 1.1 comboboxes in Chrome and FF. Not saying this changes anything. Just for info. |
… focus in section with id managingfocus_authors
…that the active descendant is always a DOM descendant of the element with DOM focus.
…s not describe textbox as contained by a combobox
mcking65
force-pushed
the
fix-combobox
branch
from
0dd6179
to
a971358
Compare
|
With input from Microsoft and Freedom Scientific, I've been investigating and reviewing other ways of resolving the above listed issues. They get pretty complex. The changes in this pull request still seem to be the most straightforward. Please read this wiki page: |
| <p>The <code>aria-autocomplete</code> property describes the type of interaction model a <rref>textbox</rref>, <rref>searchbox</rref>, or <rref>combobox</rref> employs when dynamically helping users complete text input. It distinguishes between two models: the inline model (<code>aria-autocomplete="inline"</code>) that presents a value completion prediction inside the text input and the list model (<code>aria-autocomplete="list"</code>) that presents a collection of possible values in a separate element that pops up adjacent to the text input. It is possible for an input to offer both models at the same time (<code>aria-autocomplete="both"</code>).</p> | ||
| <p>The <code>aria-autocomplete</code> property is limited to describing predictive behaviors of an input element. Authors SHOULD either omit specifying a value for <code>aria-autocomplete</code> or set <code>aria-autocomplete</code> to <code>none</code> if an input element provides one or more input proposals where none of the proposals are dependent on the specific input provided by the user. For instance, a combobox where the value of <code>aria-autocomplete</code> would be <code>none</code> is a search field that displays suggested values by listing the 5 most recently used search terms without any filtering of the list based on the user's input. Elements with a role that supports <code>aria-autocomplete</code> have a default value for <code>aria-autocomplete</code> of <code>none</code>.</p> | ||
| <p>When an inline suggestion is made as a user types in an input, suggested text for completing the value of the field dynamically appears in the field after the input cursor, and the suggested value is accepted as the value of the input if the user performs an action that causes focus to leave the field. When an element has <code>aria-autocomplete</code> set to <code>inline</code> or <code>both</code>, authors SHOULD ensure that the automatically suggested portion of the text is presented as selected text. This enables assistive technologies to distinguish between a user's input and the automatic suggestion and, in the event that the suggestion is not the desired value, enables the user to easily delete the suggestion or replace it by continuing to type.</p> | ||
| <p> If an element has <code>aria-autocomplete</code> set to <code>list</code> or <code>both</code>, authors MUST ensure both of the following conditions are met:</p> | ||
| <ol> | ||
| <li>The element has a value specified for <pref>aria-controls</pref> that refers to the element that contains the collection of suggested values.</li> | ||
| <li>Either the element or a containing element with role <rref>combobox</rref> has a value for <pref>aria-haspopup</pref> that matches the role of the element that contains the collection of suggested values.</li> | ||
| <li>The element has a value for <pref>aria-haspopup</pref> that matches the role of the element that contains the collection of suggested values.</li> |
There was a problem hiding this comment.
Should we be changing this? While I get that we don't want people using the 1.1 combobox pattern this would make them invalid and I'm concerned about that
There was a problem hiding this comment.
Since this an authoring requirement, not a browser requirement, making the 1.1 implementations invalid is helpful. The few existing implementations of 1.1, which already do not work well, will become invalid. That will promote fixing them so they work better for more users in more browsers. And, at the same time, nothing here changes browser behavior in a way that would make the existing implementations of 1.1 worse than they already are.
|
Unfortunately I do not understand the following explanation in the WIKI page
If a |
@JAWS-test wrote:
This is a way to recreate the functional and accessibility equivalent of a
Exactly the same way it is done today . Compare the experience of this combobox with a textbox implemented using the pattern in this PR with the experience of a |
|
@mcking65 Thank you very much for your explanation. I assumed that when using an ARIA role, the screenreader always outputs the same role regardless of the HTML element used (ARIA roles override HTML semantics). I have tested the new example in Chrome with JAWS and it is indeed the case that at the However, it might be necessary to update Core Accessibility API Mappings to reflect the different output depending on the HTML element. The same applies to the following sentence in Using ARIA, which in my understanding would then also no longer be valid:
And maybe also the ARIA specification:
|
|
The new 1.2 combobox pattern is supported by JAWS and NVDA as follows:
However, in all browsers with JAWS and NVDA there is the problem that in the combobox without text input the value of the combobox cannot be output by the screenreader because it is not transmitted. This is a problem with the ARIA specification, which does not specify how a value is defined for the |
|
Actually I like the ARIA 1.2 combobox design. However, I think there are 2 problems:
|
See https://github.com/w3c/aria/wiki/Resolving-ARIA-1.1-Combobox-Issues for full description of changes and motivations * Revise description of user agent responsibilities for aria-activedescendant * Remove combobox from list of composites for which authors must manage focus in section with id managingfocus_authors * Revise prose of section managingfocus_authors to remove implications that the active descendant is always a DOM descendant of the element with DOM focus. * Revise combobox example in aria-activedescendant definition so it does not describe textbox as contained by a combobox * Add editor's note * Revise aria-autocomplete description to match new combobox structure * Add extra combobox warning
|
@JAWS-test wrote:
It does override the role of the element just like every other ARIA role. Putting role combobox on an input:type=text overrides the textbox role. Lots of ARIA roles effectively extend or enrich native semantics. The grid role can be used to extend or enrich table. The searchbox role can be used to extend or enrich textbox. I'd say it is the case for the majority of widget roles.
It would be a lot more work to make an editable combobox in any host language that does not have a text input that supports the accessible text interface. But, that was just as true for ARIA 1.1 and 1.0. And, it is just as true for creating an element with the searchbox role in one of those languages. However, if you wanted to make a combobox that does not support editable text, it is now supported with ARIA 1.2. And, that is a big advantage if your host language does not have an element that supports the accessible text interface. |
|
@JAWS-test wrote:
I don't think we need those updates. It is up to the assistive technology to decide how they want to present the availability of editable text. It doesn't have to be part of the role announcement. Of course, we always have the option of doing something in ARIA to specify what AT should do when the input is editable. I'd rather let AT attempt to solve this without specific direction from the ARIA specification. I think there is plenty of history that shows they will because it has been done in native applications. Apple's native approach is distinctly different from Microsoft's, and I don't see a reason to force them to be the same. |
As far as I have understood, each ARIA role overrides the HTML element. I can use With
These are two different elements with different operation modes, but with the same ARIA role |
|
@JAWS-test wrote:
Not quite, but pretty close.
Correct if size=1 and the operating system is Windows or Linux.
Whether the element with role combobox is an HTML input or a span, the ARIA role overrides the implicit semantics and makes the element into a combobox. This is identical to other ARIA roles. The interactions conferred by the combobox role are identical regardless of whether the input is editable. The combobox role communicates that the input controls a popup and the value of the input can be set via the popup. And, like other ARIA roles, ARIA properties are used to add additional information about the interactions supported for a particular combobox, e.g., aria-haspopup and aria-autocomplete. This is like the button role. If you add aria-haspopup or aria-pressed, it adds additional information about supported interactions for the widget. Similarly, aria-haspopup adds interaction information to the menuitem role and aria-multiselectable adds interaction information to widgets with a variety of roles. |
I don't think I get it yet. Because role=combobox at the input element leads to the output of "edit combobox" in the screenreader and role=combobox at the span element leads to the output of "combobox". Those seem to be two different roles to me. In my opinion these are relatively different elements with different operation. |
See https://github.com/w3c/aria/wiki/Resolving-ARIA-1.1-Combobox-Issues for full description of changes and motivations * Revise description of user agent responsibilities for aria-activedescendant * Remove combobox from list of composites for which authors must manage focus in section with id managingfocus_authors * Revise prose of section managingfocus_authors to remove implications that the active descendant is always a DOM descendant of the element with DOM focus. * Revise combobox example in aria-activedescendant definition so it does not describe textbox as contained by a combobox * Add editor's note * Revise aria-autocomplete description to match new combobox structure * Add extra combobox warning
The purpose of this pull request is to revise a collection of combobox issues by better aligning the specification with what has been long supported by both browsers and assistive technologies.
The rationale for these changes and an explanation of how they resolve the issues listed below are available on this wiki page about resolving ARIA 1.1 combobox issues.
Summary of changes in this pull request
Issues resolved by this pull request
<select>* [HTML-AAM: select element should map to listbox role regardless of presentationExample Implementation
View an test an example implementation of the new pattern in the Authoring Practices Guide
Preview Changes
View the rendered changes in the compare branch for this pull request
Preview | Diff