Combobox Examples with listbox popup: Fix Escape behavior, mouse interaction, visual design, and more #1276
Conversation
|
@jongund I noticed a focus issue in all 3 comboboxes:
I think focus needs to go back to the textbox after the listbox is closed. |
|
@carmacleod Carolyn I fixed the problem of the listbox not opening |
|
Thanks, @jongund ! One more weird case, only in the autocomplete=both example:
I was expecting it to behave the same as the autocomplete=list example, and open the popup even though there's only one item in it. |
|
@carmacleod I made some updates to fix the down arrow bug you found, please test |
Very nice, the combobox feels much less buggy to use now! I've reported a separate issue that I noticed while reviewing this: #1278 |
Fixed - thank-you, Jon! Much better. |
|
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<carmacleod> TOPIC: Combobox<zcorpan> GitHub: https://github.com//pull/1276 <Jemma> carmacleod: there is some info about fall back value for aria value min and max <carmacleod> carmacleod: Here is Fallback values table in ARIA spec: http://w3c.github.io/aria/#authorErrorDefaultValuesTable <carmacleod> jon: combobox Esc key behavior: Esc closes popup; 2nd escape clears textbox <carmacleod> mck: for autocomplete=both, enter and esc are essentially the same: value is chosen <carmacleod> mck: for autocomplete=list, enter and esc are different; typing "al" then down arrow, then esc, leaves "al" in combobox <carmacleod> zakim, who is on the call? <Zakim> Present: Matt_King, zcorpan, Jemma, MarkMccarthy, carmacleod, jamesn, jongund <carmacleod> zakim, bye <Zakim> leaving. As of this point the attendees have been Matt_King, zcorpan, Jemma, MarkMccarthy, carmacleod, jamesn, jongund <carmacleod> rrsagent, make minutes <RRSAgent> I have made the request to generate https://www.w3.org/2019/12/03-aria-apg-minutes.html carmacleod <carmacleod> regrets+ CurtBellew <carmacleod> rrsagent, make minutes <RRSAgent> I have made the request to generate https://www.w3.org/2019/12/03-aria-apg-minutes.html carmacleod |
|
Thank you @smhigley, I believe I have addressed all comments. |
Accessibility ReviewNotes per screen reader and browser combo. Narrator with Edge 44.1 on Windows 10 (1909)The comboboxes are announced correctly ("State, combo-edit", "Search, combo-edit, suggestions available"). But I can't select anything past the first suggestion. Not by pressing down arrow only. If there's another way to interact with comboboxes I'd like to learn about that. Alt+Down Arrow works 👍. VoiceOver with Safari 13.0.5 on macOS 10.14.6After you land on the combobox it's announced as "Menu pop-up combobox, type text or, to display a list of choices, press Control-Option-Space." This combination doesn't work in any of the examples. I take it this is down to the screen reader rather than our example. But I don't know that for sure. The "Both list and inline autocomplete" example seems to work OK. Can navigate into the auto complete and the options are announced. In the "With list autocomplete" example the options are shown, you can navigate into them, but they're not announced. Is this list defined differently? The search example options are announced as long as you didn't type into the field first. Not typing and then making a selection from the list results in the same thing. Alt+Down Arrow works 👍. Note: If anyone has 10.15 I would appreciate a retest there. JAWS 2020.1912.11 with Edgium on Windows 10 (1909)Perfect 🌟. Visual ReviewIn high contrast mode the drop down arrow disappears when the field is selected:
The select state within the dropdown is clear tho:
ConclusionI suggest we add a |
|
Note that you can use alt+downArrow to expand the combobox on Windows, if it’s expandable. Mac does this automatically, at least visually.
|
|
Thanks @sinabahram! This visually works in both Safari and Edge with VoiceOver and Narrator respectively. But the thing is that if I then press Down Arrow Narrator moves to the drop down arrow instead of the first result. |
|
You’re welcome, but please note, it is very much a work-around/advanced-user feature, and never should be relied upon. Comboboxes are not accessible if that’s the only way to get at their elements. It does come in handy, though, especially when debugging certain behaviors.
|
|
Thanks. I've updated my two previous comments quite extensively after your comment. Out of interest: how is GitHub about communicating those changes? If at all. |
|
Good question. It doesn’t over email, so I’d have to brows on the site. Looking on the site, at the absolute end of the heading announcement, and incorrectly marked up with inaccurate menu semantics (already fixing that with them) is “edited”, so if I know to listen for it, then I can at least check if something is edited, but it’s hardly surfaced as a primary thing. Call it a 3 out of 10 in terms of usefulness 😊.
The takeaway is that it’s most appreciated that you pointed out you edited something, because then I know to go look for it, so thank you for that.
|
| } | ||
|
|
||
| .combobox polygon { | ||
| fill: gray; |
There was a problem hiding this comment.
change this to fill: currentColor; to fix High Contrast Mode.
|
|
||
| .combobox polygon { | ||
| fill: gray; | ||
| stroke: gray; |
There was a problem hiding this comment.
change this to stroke: currentColor; to fix High Contrast Mode.
|
|
||
| .combobox button.open polygon, | ||
| .combobox .group.focus polygon { | ||
| fill: black; |
There was a problem hiding this comment.
change this to fill: currentColor; to fix High Contrast Mode.
| .combobox button.open polygon, | ||
| .combobox .group.focus polygon { | ||
| fill: black; | ||
| stroke: black; |
There was a problem hiding this comment.
change this to stroke: currentColor; to fix High Contrast Mode.
| } | ||
|
|
||
| .combobox button.open polygon, | ||
| .combobox .group.focus polygon { |
There was a problem hiding this comment.
Add color: black; to fix High Contrast Mode.
| width: 10.75rem; | ||
| border-right: none; | ||
| outline: none; | ||
| font-size: 87.5%; | ||
| padding: 0.1em 0.3em; | ||
| } | ||
|
|
||
| .combobox .group button { | ||
| .combobox button { |
There was a problem hiding this comment.
Add color: gray; to fix High Contrast Mode.
|
I finally got a chance to play with this ... Jaws 2020, latest, and Chrome latest. I tried the first preview link "both", and I came across several issues. but not sure if this should be tested in Chrome+Jaws yet? 1: the aria-expanded does not seem to be surfaced? I hit the open button, but it never says it's collapsed nor does it announce being in an expanded state. It does announce the transition between collapsed/expanded, which is super odd, but I didn't spend time to figure out if that was coming from an aria-live message on the page or from some native announcement of aria-expanded state change. 2: the button opens a listbox, which allows for no interaction. Instead, when one focuses it, it just kicks you out of forms mode ... I tried lots of times. 3: In the combobox, several things jumped out at me. 4: The button says "open", but open what? That feels a bit like "read more" to me, where more specificity is required. Anyways, I'm going to stop here. There are other issues as well. I'm actually somewhat concerned that I'm going down a rabbit hole because this is not meant to be tested in Chrome+Jaws yet? If not, sorry for wasting time, but if so, I think a detailed screen reader treatment may be in order here. |
|
While there are still quite a few bugs, the bugs targeted by this PR are resolved. I am merging. Then, I will respond to all the recent feedback and create separate issues as needed. Thank you everyone for all the work on this! |
mcking65
deleted the
issue1066-combobox-fix-escape-key-and-other-bugs
branch
Combobox Examples with listbox popup: Fix Escape behavior, mouse interaction, visual design, and more (pull #1276) Fixes #785, #982, #983, #988, #1261, #1265, and #1268 with the following changes: * updated JavaScript to use single prototype * updated escape key behavior * removed unused files * fixed regression issues for escape key * updated tests for single and double escape key tests * fixed focus bug on enter and removed use of keycode property * fixed bug in opening list and improved property names for visual focus flags * fixed bug in opening list with alt key pressed * fixed bug with enter key not updating aria-expanded * fixed bugs with down arrow * added documentation and tests for ALT Down Arrow * fixed some styling bugs * Use only one SVG image to show listbox state * updated CSS for styling listbox focus * fixed scrolling issue in listbox * adjusted position of svg image button * fixed onclik bug where not selecting options when autocomplete is list or none * updated test for autocomplete, list and none * fixed bug with onclick behavior and documented option filtering as users type * updated documentation about filtering of options * Typo: character -> characters * fixed option filter bug with autocomplete=none * improved description of when listbox opens * use lowercase "the" in sentence * Minor editorial revision to alt+down in textbox keyboard table * udpated test file to check for aria-selected on option when listbox opens * fixed aria-selected tests * add tests for aria-selected to key down tests * Add aria-hidden=false and focusable=false to svg in button * Use fewer descendant combinators in selectors * Call function instead of setting a property on elements * Don't call setValue() when hitting backspace, to avoid moving the cursor to the end * Remove superfluous isPrintableCharacter() call * Remove unused variable textContent * Declare option outside for loop. Also use null instead of false * Set scrollTop once * Declare index variable in the if block * Move isPrintableCharacter to ComboboxAutocomplete.prototype * Add information about the id attribute for all combobox examples; fixes #785 Co-authored-by: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com> Co-authored-by: Matt King <a11yThinker@Gmail.com> Co-authored-by: Valerie Young <spectranaut@gmail.com> Co-authored-by: Simon Pieters <zcorpan@gmail.com>
|
@sinabahram wrote:
Yes, it is ready for testing. Bugs can fall into 3 buckets: 1) APG example code, 2) browser, and 3) screen reader. If you haven't yet read it, the section of the APG titled Read Me First explains the scope of practices in this regard. In particular, section 2.2 addresses browser and assistive technology support. From a W3C perspective, browser bugs are the concern of the ARIA Working Group and screen reader bugs are the concern of the ARIA-AT community group.
Correct, there is a JAWS bug because JAWS does not announce the state of the combobox when you navigate to it or read it. When you click open with the virtual cursor, the mouse click event is causing DOM focus to move to the text input. JAWS announces the focus change event, then the expanded state changes, and JAWS announces the state change event. When the combobox is expanded, and you move the reading cursor back to the open button and click it again, the DOM focus is still on the text input. Sso, JAWS is announcing the state change from expanded to collapsed. The APG examples do not use live regions to compensate for anything that could be categorized as lack of screen reader support. Information about the state of the combobox, how many suggested values are available in a combobox popup, which suggestion is automatically selected if any, etc. is all available in the accessibility tree for any comboboxes that correctly implement the pattern. What assistive technologies do with that information is an assistive technology design decision. However, the aria-at project is seeking to build consensus around basic expectations for assistive technology behavior. I am writing combobox tests for the aria-at project right now. Combobox testing is part of the ARIA-AT project production system design phase, so those tests will be among the first we review with screen reader developers. ARIA-AT will have must have, should have, and nice to have expectations for screen readers. Announcements about suggestion availability may fall into one of the latter 2 buckets.
This is an issue that the ARIA-AT project should highlight for Freedom Scientific. To activate forms mode for a listbox, JAWS issues MSAA default action. In this case, that will generate a click event. Clicking an item in the listbox will close the listbox and put the clicked value into the combobox. Ordinarily, JAWS users will navigate the listbox by pressing down arrow from within the combobox. However, ideally, users would be able to operate the combobox in either reading mode or forms mode. I don't think there is anything we can do about this in the example code.
We do this because home and end move the caret in the edit field. BTW, do you think the edit field should be in the up and down arrow navigation? Or, should it keep focus in the list?
It looks like we still have some serious bugs related to typing, especially after deleting characters from the input. The suggestion list is borked. Thank you for pointing this out. I raised #1332.
Yap, and this is considered to be a screen reader shortcoming per the above. We will address this in the ARIA-AT project.
In the autocomplete both example, the first press of backspace will erase the autocompletion string -- the automatically suggested portion of the text. The second press would delete the last character typed. Compare tests 1 and 2 for the autocomplete both example with tests 3 and 4 for the autocomplete list example in issue #1332.
This is addressed by #1332.
You are right on this. It is worse than that because when the combobox is expanded, nothing about the button changes. For compatibility with touch-based screen readers and reading cursors, this button should be marked up more like a menu button with aria-expanded and aria-controls. I'm surprised that we didn't consider this already. Again, thank you for calling attention to it. I have opened #1333. Excellent feedback. Thank you!! |
|
Thanks for this amazing response. Some answers below.
You said
Announcements about suggestion availability may fall into one of the latter 2 buckets.
SB:
I hope not. That’s super-concerning to me, just to be frank. I hope we don’t start with limited expectations because they will only go down from there in practice, or at least the past 20+ years of having to depend on assistive technologies as informed me. If there are suggestions, this needs to be surfaced, full stop. But, that’s my opinion, so there you have it. My criteria is very simple, can someone who doesn’t depend on assistive technology and someone who does both achieve all the same results in an equitable way. Let me know if that criteria is either weaker than or far stronger than the expectations of the folks working on this, so I can calibrate appropriately. Note, I won’t actually back down from this position, but at least I’ll understand that other people are not there and attempt to kindly and respectfully convince instead of assume.
You asked:
We do this because home and end move the caret in the edit field. BTW, do you think the edit field should be in the up and down arrow navigation? Or, should it keep focus in the list?
SB:
This is an interesting question. I think we have a mixed metaphor happening here because one can iterate with up/down; one can type but not for type-ahead, instead it does filtering based on a starts-with approach or so it seems to be intended; and one can also backspace to remove the filter once that bug gets fixed, but at that point, the backspacing should only affect what has been typed, not what the value is, right?
So, before we talk about up/down, maybe we should talk about left/right? I’ve always been partial to the idea, which is in my opinion almost an unwritten standard approach, which is that you type characters into an edit field or editable combobox, depending on phrasing, and then all that is there is what you have typed in, but when you hit up/down then it highlights what is found, but if you backspace or use left/right, you are only exploring what has been typed so far, because we know with 100% certainty that this will match the user’s expectation of what is there, since they typed it. Once space or enter or what not is used to choose an item, then of course the previous rule can be updated to include that which has been selected.
To that end, I definitely don’t like this super-confusing partial selection thing going on, where the user has to pay such close attention to what is selected VS focused. You and I have complete mastery over such things, and we probably still make mistakes on this stuff, but I argue 90% of screen reader users do not at all. I know why it’s there, but the idea that backspace behaves differently the very first time is a huge flag for me on usability.
Here’s my proposed approach:
You get this list of states, and then you type ‘North’ or something like that. You are informed that there are two or three options, and you can arrow up/down on them, but if you hit backspace, you just erase the ‘h’ from ‘north’, nothing else. Once you hit enter, you have now selected that state. Allowing people to edit state names seems highly irregular to me, because presumably the whole point of having a dropdown is actually not for the human’s benefit, right? it’s so that we can force people to choose “North Carolina” in our data model instead of also having NC and nc and “north Carolina” and all those other variants in our eventual DB. So, why allow for the editing of these values at all?
Here is how I think of this visually.
Imagine an edit field with ‘North” and a blinking cursor after the ‘h’, but also a dropdown below it that filters based on the values of the above, therefore, it is super-clear that backspace, home, end, left, and right, as well as all character-input should affect the edit field, but ‘up/down’ should navigate within the list below.
That’s my mental model of such things, anyways.
If you absolutely must allow for editing because we also wish to make that pattern accessible, which I consider a completely different pattern, by the way, then I would suggest an affordance of space or something like that to select without closing e.g. space VS enter, and go at it that way, but I feel this would require standard help text to also be augmented, and this introduces interesting edge cases like entries with spaces in them.
hope this helps.
|
|
@sinabahram there are probably diminishing returns in debating combobox behavior in a merged PR thread :). If you feel like it's worth continued discussion, it would probably be better to open an issue. That said, here are a couple brief notes in response to a couple of your points:
|
I have updated the combobox autocomplete examples:
Preview links
Review checklist