Search and Top Navigation
#9837 closed bug (wontfix)
Opened February 18, 2014 09:48PM UTC
Closed March 12, 2014 03:58PM UTC
Last modified April 24, 2014 01:52PM UTC
Autocomplete: JAWS is knocked out of forms mode when duplicate input value is passed
Reported by: | ethan | Owned by: | ethan |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.autocomplete | Version: | 1.10.4 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
When arrowing through autocomplete results, JAWS will be knocked out of forms mode if it passes through two duplicate entries. See example:
Tested in IE8-10, and JAWS 12-14.
This would be a major issue when autocomplete results are abbreviated and multiple duplicate values exist.
Attachments (0)
Change History (15)
Changed February 26, 2014 02:42PM UTC by comment:1
component: | ui.core → ui.autocomplete |
---|---|
summary: | JAWS is knocked out of forms mode when duplicate input value is passed → Autocomplete: JAWS is knocked out of forms mode when duplicate input value is passed |
Changed February 28, 2014 02:06AM UTC by comment:2
Replying to [comment:1 scott.gonzalez]: Scott, This is a known issue with JAWS. There are two ways to fix this - 1 short term and 1 long term.
1) Short term: I could add an IE-specific piece of code to execute the following code
select(input, length, length);
every time the input value is updated. I have used this trick in the past to stop JAWS popping out of forms mode. It is a bit of a hack and it is browser-dependent code but it will solve the problem when using JAWS with IE.
2) Long term: change the autocomplete to put the focus into the menu and actually traverse the menu after the down arrow is pressed. This would have the advantage of fixing all of the announcement quirks in all of the ATs but it is a significant change.
Thoughts?
Changed March 11, 2014 03:44PM UTC by comment:3
Thanks Dylan for the input. As far as I can tell, both your suggestion would have unreasonable drawbacks though. Your first one would imply that after making a selection, you end up with all text selected, you have to unselect first in order to continue typing, if you don't want to overwrite the existing value.
The second one would completely break "continue typing", since we can't replicate keyboard input while the menu has focus. If screenreaders would do a good job with the focus on the menu, this might indeed be a solution for the long term. I think the only way to pursue this is to build a prototype that shows if this can work and how much effort it would be.
All that said, the original issue is actually a duplicated value. In the given example, it doesn't really make sense. The description talks about "when autocomplete results are abbreviated and multiple duplicate values exist." - an actual example of that might be useful to see if there's a way to address this that avoids putting the same value into the input twice.
Changed March 11, 2014 04:54PM UTC by comment:4
_comment0: | Thanks for looking into this guys. We noticed the issue when working with values that needed to be truncated, see this updated example: \ http://jsfiddle.net/CfxPk/4/ \ \ It would be excellent if there were a reliable CSS-only method for truncating input text but we haven't found one ("text-overflow: ellipsis" seemed hopeful but doesn't apply until input is unfocused!) Otherwise it seems we are stuck the ugly overflow of severed characters. Any insight is much appreciated. \ \ -Ethan → 1394556997105170 |
---|
Thanks for looking into this guys. We noticed the issue when working with values that needed to be truncated, see this updated example:
It would be excellent if there were a reliable CSS-only method for truncating input text but we haven't found one ("text-overflow: ellipsis" seemed hopeful but doesn't apply until input is unfocused!) Otherwise it seems we are stuck with the ugly overflow of severed characters. Any insight is much appreciated.
-Ethan
Changed March 11, 2014 05:29PM UTC by comment:5
owner: | → ethan |
---|---|
status: | new → pending |
How is the user supposed to know which value to pick if the visible options are duplicated?
Changed March 11, 2014 06:58PM UTC by comment:6
status: | pending → new |
---|
That's a good point - perhaps the reasoning behind this seemingly odd JAWS behavior.
What we did is truncate the item.label rather than the item.value so that the full value is still read properly:
Which leaves us with the ugly input visual for sighted users.
Using a pseudo-input div above the real input might be the only other option to correct this.
Related to this - have you ever seen JAWS pop out of forms mode when two input values of ''equal character length'' are passed? This we've also come across in our tests, but is difficult to reproduce.
Changed March 12, 2014 12:55PM UTC by comment:7
status: | new → pending |
---|
I'm not really sure how most users are supposed to interact with that. This seems like really bad UX to me. Without a clear understanding of how this is better than showing the full option, I'm inclined to close this as wontfix.
Changed March 12, 2014 01:45PM UTC by comment:8
status: | pending → new |
---|
Let me clarify by saying the UX predicament lies in using much longer input values. For example:
"Wii Fit Plus (Also Available on Wii Fit): Strength Training (All Moves)"
"Wii Fit Plus (Also Available on Wii Fit): Strength Training (Specific Moves)"
So truncating or abbreviating needs to occur somewhere, either in the dropdown or in the input.
The way the ui.autocomplete works, one is forced to truncate dropdown labels and leave the input intact. In some cases the opposite might be desired, but it sounds like this would require an unreasonably high LOE.
Thanks for time though,
Ethan
Changed March 12, 2014 02:10PM UTC by comment:9
status: | new → pending |
---|
You can just have the longer items flow onto multiple lines. Here's an example where the menu never grows wider than the input: http://jsbin.com/xiroyoma/1/ You can of course have whatever logic you want for the menu sizing, or continue using the built-in sizing, but I think this addresses your issues.
Changed March 12, 2014 02:20PM UTC by comment:10
status: | pending → new |
---|
Sure, if that's an option. I would just imagine the need to visually abbreviate the input value comes up for developers from time to time.
Changed March 12, 2014 02:23PM UTC by comment:11
status: | new → pending |
---|
Abbreviating is fine, but if it results in duplicate visual values, that is pretty bad. Since this bug is specifically about duplicate values and not abbreviations, I'm not really inclined to make a change.
Changed March 12, 2014 03:51PM UTC by comment:12
status: | pending → new |
---|
Agreed. Just something to consider as a noted limitation.
Changed March 12, 2014 03:58PM UTC by comment:13
resolution: | → wontfix |
---|---|
status: | new → closed |
It seems to me like it would be very awkward to document that you shouldn't use duplicate values in the suggestions. If you have a proposal for how to word this, feel free to send a pull request against https://github.com/jquery/api.jqueryui.com.
Changed April 24, 2014 01:41PM UTC by comment:14
Hi Scott,
I've finally been able to reproduce the issue related to this ticket that I mentioned above:
''Jaws knocks out of forms mode when passing through two entries of equal length''.
I will start a new ticket unless you think this ticket should be amended instead.
Changed April 24, 2014 01:52PM UTC by comment:15
Please open a new ticket with a test case that reliably reproduces the behavior.