Combo examples 1.0: Fixed selection bugs for inline autocomplete and updating aria-activedescendent

[jongund]

Matt,

I think I fixed the issues you identified in your last e-mail.

[mcking65]

@jongund, I am confused by what this diff is doing. I looked only at the autocomplete="list" and autocomplete="both" example pages.

In the list autocomplete example, It now seems that the list is expanding as soon as the combo gets focus and that activedescendant is pointing to alabama even before typing. Immediately after tabbing into the list example, JAWS says the combobox contains alabama (read current line). If I press right arrow, it reads "A". This doesn't happen on the version in master.

If I then type "c", California is selected. And, pressing left arrow says "c", but current line says "c alabama".

I don't think these are JAWS problems. I get similar behavior when using NVDA.

I can't inspect because opening the developer tools collapses the combo.

Unfortunately, I don't have time right now to read through the code and figure it out.

The List example in master is working better than this version. Overall, it is working pretty well. The main thing it is not doing is setting activedescendant to "" if you press left/right or a printable char. Actually, if there is any key other than up/down, page up/down, activedescendant should be set to "" in that example.

[jongund]

Matt,

I did an extensive update of the combo 1.0 examples based on the combo 1.1 listbox example. Please review and let me know if the behavior is working better and what still doesn't seem right.

Also one question I have is if you just type in the letters "al" and hit tab key to leave the combobox, it should select the "Alabama" option right, since it is the first match for "al"?

[jongund]

Matt I have updated my branch to fix the problems with aria-activedescendant and other behaviors and ready for your review.

[mcking65]

@jongund, thank you! This is much, much better! 95% of the way there.

The autocomplete="none" example is working correctly.

The autocomplete="list" example is also working correctly.

The autocomplete="both" example is very close to correct.

Issue 1: Screen readers are not detecting the inline autocomplete text. Maybe it is not there. Or, maybe you are using a method to display it that is not compatible with screen readers. By inline autocomplete text, I mean text that appears in the textbox after the caret. So, if I type "m", the carret is after the "A" and immediately following the caret, the characters "aine" should be present with visual styling that indicates they are suggested and selected. Now, if i type "i", the inline suggestion of "aine" should be replaced with "nnesota". As far as i can tell, the inline part of the suggestion is not present in the textbox.

The top item in the listbox is getting automatically selected just as it should. So, if I type "A" and press enter, the value of the textbox is set to "Alabama". That behavior is correct. Also, the focus is moving correctly in the list. So, if I type "A" and press down, activedescendant points to "Alaska", which is also correct behavior.

Issue 2: However, the selected item is not accepted as the value when focus leaves the text box. So, if I type "A" and press Tab, the value of the combobox is just "A". It should be set to the automatically selected value from the listbox -- "Alabama".

Issue 3: When arrowing through the list, the values are being displayed in the textbox, which is expected. However, it is being displayed as if the value is already fully accepted. That is, there is no distinction between what the user typed and the part of the value that is suggested. The part of the value that the user did not type should remain as only a suggestion until the user presses enter or tab. So, for example, if I type "Al" and then press down arrow to highlight Alaska, the "Al" should be normal text and the text after the cursor should be "aska". If I then type "i", the letter "i" should replace "aska" and the value in the box would be "Ali" and the list would be collapsed.

The current behavior is in fact how some implementations should work, but only if they restrict input to the set of suggested values. If the combobox will accept any arbitrary value, then the textbox should maintain a distinction between what the user typed and the suggested text. Even though we are using states as our suggestions, we are demonstrating the kind of combobox where the user could make up their own state.

I really hope that this is sufficiently clear and that I have not inspired you to want to make a state named "confused". It is late. So, it is possible that my explanation is not optimally coherent.

[jongund]

@mcking65

Matt I fixed the bug for autocomplete=both.

The option should be in the text box as you type characters.

Jon

[mcking65]

@jongund, all 3 examples are working exactly as specified!

However, there is one simple edge case bug in the autocomplete="both" example where I think the code is retaining a variable value that shouldn't be retained.

To reproduce:

1. Put focus in the combobox.
2. Type "A"
3. Arrow down to "Arkansas
4. Press Enter. So far, everything is perfect.
5. Delete the content of the combobox, e.g., shift+home and delete if on Windows.
6. Type "A".

Bug: the inline completion is "rkansas"

Expected result: inline completion is "labama"

[jongund]

@mcking65

Matt I am not seeing Arkansas in the sequence of keys you outlined, I am getting Alabama.

What combination of AT are you using to do the testing?

Jon

[mcking65]

@jongund, I have tested using JAWS and NVDA with both Firefox and Chrome.

[jongund]

@mcking65

Matt I believe I fixed the bug related to when content is deleted from the textbox (e.g. empty string) not reseting the aria-activedescendant pointer.

Jon