aria-autocomplete inline suggestion interaction causes potential OnInput violation and raise discoverability concerns

[mbgower]

The guide states

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.

This directive is open to interpretation and potentially problematic. First, when the paragraph states "appears in the field after the input cursor", it is not clear whether it is stating that when such text is appended 1) the cursor repositions to the end of the appended text, or 2) the input cursor remains in position and the appended text exists beyond the current insertion point. If the latter, the paragraph seems to direct that if I type a search for "yellow" and the inline suggestion becomes "yellowstone", the results for "yellowstone" would be posted if I pressed ENTER or TAB. That seems to be causing a change of context based On Input. The sighted user can neither predict nor assume this behaviour. (In implementations I've seen, this appended text is greyed in, implying it is impermanent.) The screen reader user or user with significant magnification may not even be aware this text has been appended, and will find their search for "yellow" altered to a completely different search. As well, there appears no way of overriding the suggestion.

I have seen examples of both of these interpretations, as well as implementations that provide what I would argue is a more reasonable implementation, given the lack of guidance. For the latter, Google appends text beyond the insertion point, and even updates the results in the background based on the appended text, but if the user presses ENTER, the results are based on the original string ("yellow").
I would request both clarity about inline suggestions, as well as urge suggested implementations which address OnInput changes, discoverability and cognitive load be captured in the APG.

[mcking65]

@mbgower,

So, this issue is only about the spec text ... not the APG. You will certainly have the opportunity to review what we do for the APG.

Do you have a proposal for the spec text?

BTW, I am not clear what you mean when you say that the sighted user cannot assume or predict this behavior ... which behavior?

It seems that the norm for inline is that selected text following the cursor is accepted unless removed.

An example of inline suggestion that I use daily is in e-mail clients like Outlook or previously Notes. I type a single letter and a suggestion appears following the cursor. I can keep typing and the suggested text after the cursor adjusts. I press tab and the value that is accepted is what I typed plus what was autocompleted. This is also how inline suggestions work in pretty much every code editor except in some cases you have to press a key to start the suggestion process. Or, consider how it works in something like the Firefox dev tools in the console. Soon as I type a "d", ocument immideiately appears. I press tab and the value in the field is then "document".

[mbgower]

@mcking65 , the behaviour you describe for Notes does not correlate with the visual use of inline for me. For me what is happening is that a list immediately appears below the input as soon as a I type a character, and the first item on this list is selected. As I type, the list updates based on my modified character string. So at no point does the actual text "appear" after the insertion point.
I did find I could replicate your experience in the Internet Explorer address bar IF I was entering in an address I'd already used in that session. I'm not using Outlook these days, but that is my recollection of how it behaved as well -- once I'd successfully sent an email to someone, I got it inline, otherwise, it offered a list of options from my address book.
So, I agree inline is used. But I'd like to list some important points to consider: 1) in IE, I get that inline autocomplete for URLS that I have previously used. It also provides suggestions in the form of a list for phrases I haven't used. So inline suggestions are only provided for terms I've previously used. Random suggestions are offered as a list.
Second, there are keyboard interactions considerations to support such an inline concept. How can the user accept or reject the added suggested text in the input? In IE, I can press END and move the cursor to the end of the suggested text. I can press DELETE to remove the suggested text. If I am not offered a means to both reject the suggestion or to accept it, it verges on a form of keyboard trap.
Finally, there are screen output considerations. How do I surface the suggestion? How do I indicate to the user what the interaction means? In IE, JAWS announces the appended inline suggestion as a chunk (i.e., if I've already gone to youtube, next time I type "y" I'll hear "y" then"outube.com" (out tube dot com).
So, I guess my perspective here is two-fold. The use of an inline suggestion exists, so it makes sense to define it in the standard. But I think some more language about the convention of only offering previously used terms is something to consider. No idea if that is overly perscriptive, but I'm foreseeing the potential for significantly inaccessible uses of the inline form. And then there are many considerations for authoring. Perhaps ALL these things can be tackled in authoring, but I would advocate some cautionary language, as there is for "assertive" in the aria-live property.

[mbgower]

I press tab and the value that is accepted is what I typed plus what was autocompleted. This is also how inline suggestions work in pretty much every code editor except in some cases you have to press a key to start the suggestion process.

Every coding tool I've looked at so far has not used the inline suggestion. They have used the list mechanism, with the first choice automatically being selected. That is a significantly different user experience, for which it is much easier to predict behaviour and which creates much less cognitive load.

[jnurthen]

@mbgower is this still an issue. I am closing please reopen if you would like.