Review Example of ARIA 1.0 Combobox With Both List and Inline Autocomplete

[mcking65]

The ARIA 1.0 Combobox With Both List and Inline Autocomplete Example developed for issue #99 is ready for review.

Task Force Member Reviews Requested as of Nov 29, 2017

• Review by Ann (@annabbott)
• Review by Bryan (@accdc)
• Review by James (@jnurthen)
• Review by Job (@jkva)

[annabbott]

Typo in last sentence of main paragraph:
"...but it does not prevent input of any other arbetrary value."

Change "arbetrary" to "arbitrary".

[annabbott]

FF 57.0 on Win10

Keyboard support > Textbox:

Escape performs neither of these actions:

• Clears the textbox.
• If the listbox is displayed, closes it.

[annabbott]

FF 57.0 on Win10

Keyboard support > Listbox pop-up:

Escape performs none of these actions IF anything has been previously selected:

• Clears the textbox.
  

• Closes the listbox.
  

• Sets visual focus on the textbox.
  

[annabbott]

FF 57.0 on Win10

Keyboard support > Listbox pop-up:

There must be preconditions for these actions as I'm unable to make the example perform these actions:
Right Arrow | Moves visual focus to the textbox and moves the editing cursor one character to the right.
Left Arrow | Moves visual focus to the textbox and moves the editing cursor one character to the leftt.

[annabbott]

No other issues noted.

[mcking65]

@annabbott commented:

Typo in last sentence of main paragraph:
"...but it does not prevent input of any other arbetrary value."
Change "arbetrary" to "arbitrary".

Fixed in commit bf9a694.

FF 57.0 on Win10
Keyboard support > Textbox:
Escape performs neither of these actions:

• Clears the textbox.
• If the listbox is displayed, closes it.

In the pattern, when focus is in the textbox, we marked clearing as optional but didn't mark closing the popup optional. So, that part of this would be a bug. Raised issue #559.

Keyboard support > Listbox pop-up:
Escape performs none of these actions IF anything has been previously selected:

• Clears the textbox.
• Closes the listbox.
• Sets visual focus on the textbox.

I cannot reproduce this. Maybe I am not following the same steps. Could you provide a step-by-step?

Keyboard support > Listbox pop-up:
There must be preconditions for these actions as I'm unable to make the example perform these actions:
ight Arrow | Moves visual focus to the textbox and moves the editing cursor one character to the right.
Left Arrow | Moves visual focus to the textbox and moves the editing cursor one character to the leftt.

I think the left/right arrows are working OK, at least from a screen reader user perspective. I will add this to a future agenda for discussion.

@annabbott, Thank you for the review!

[annabbott]

Per @mcking65

Keyboard support > Listbox pop-up:
Escape performs none of these actions IF anything has been previously selected:

    Clears the textbox.
    Closes the listbox.
    Sets visual focus on the textbox.

I cannot reproduce this. Maybe I am not following the same steps. Could you provide a step-by-step?

TAB to listbox, type an 'a' and select "Alabama" from listbox, TAB out of listbox to next focusable element on page, shift-TAB back to listbox and press ESCAPE = does not clear textbox/listbox entry.

[accdc]

For this one, it looks like the use of aria-autocomplete doesn't match the focus functionality.

When aria-autocomplete is set to "inline" or "both", then when the associated control such as a listbox is rendered then focus should stay on the input, and the input value of the edit field should be set to reflect the change as the arrow keys are pressed. The use of aria-activedescendant should not be present.

The 1.0 spec states the following for this implementation:

"• If an author sets a combobox's value of aria-autocomplete to 'inline' or 'both', authors MUST update the value of the focused textfield, so assistive
technologies can announce the currently selected value."

[mcking65]

@accdc commented:

For this one, it looks like the use of aria-autocomplete doesn't match the focus functionality.

When aria-autocomplete is set to "inline" or "both", then when the associated control such as a listbox is rendered then focus should stay on the input, and the input value of the edit field should be set to reflect the change as the arrow keys are pressed. The use of aria-activedescendant should not be present.

That is not what we have specified in the pattern.

We can ignore the case of aria-autocomplete="inline" since that does not apply to a combobox. A combobox always has a popup so there are no implementation patterns for combobox where autocomplete is set to inline.

When aria-autocomplete="both", aria-activedescendant is set when the focus is in the listbox and not set when the focus is in the textbox. So, when assistive tech users are scanning through values with the up and down arrow keys, they get information that focus is moving through a list of possible values and will hear which value in the list is focused and how many values there are. But, when reading across a value with left/right, the focus is in the textbox. And, in that circumstance, aria-activedescendnat is not present. In that case, the current value of the textbox is what is enabling the assistive technology user to read the value.

The 1.0 spec states the following for this implementation:

• If an author sets a combobox's value of aria-autocomplete to 'inline' or 'both', authors MUST update the value of the focused textfield, so assistive technologies can announce the currently selected value."

Correct, but that does not require disabling reading a listbox popup by keeping the assistive technology focus in the textbox even when the user is changing the selected value in the listbox with the up and down arrow keys. It only requires the value of the textbox to match the selected value in the listbox. Keeping the focus in the textbox even when navigating the list of options would make it far more difficult for assistive technologies to make awareness of the number of options and the index of the current option available to assistive technology users. By default, with most screen readers, it would essentially remove awareness of the list when autocomplete is both.

I understand why some people would interpret that text as implying that aria-activedescendant is not part of the implementation of aria-autocomplete="both". But, such an implication is not normative even if it is permitted. It does not seem to me like such an interpretation would be a best practice due to the way it limits the experience.

[mcking65]

@annabbott commented:

Keyboard support > Listbox pop-up:
Escape performs none of these actions IF anything has been previously selected:

   Clears the textbox.
   Closes the listbox.
   Sets visual focus on the textbox.

@mcking65 wrote:

I cannot reproduce this. Maybe I am not following the same steps. Could you provide a step-by-step?

@annabbott wrote:

TAB to listbox, type an 'a' and select "Alabama" from listbox, TAB out of listbox to next focusable element on page, shift-TAB back to listbox and press ESCAPE = does not clear textbox/listbox entry.

Right, that is when focus is in the textbox, and we have issue #559 for that. However, when focus is in the listbox popup, all three of the above listed actions are getting executed when escape is pressed.

[accdc]

"As an aside, looking back at the ARIA 1.0 spec, there appears to be a normative requirement for the combobox role to set DOM focus in the listbox if aria-autocomplete is none. That is truly bizarre. I am amazed the spec got out the door with such a pointless and restrictive implementation detail in it. There is literally no need for such a requirement in order to achieve the autocomplete none effect. But, at the same time, the 1.0 spec also contradicts itself by defining aria-autocomplete inline as part of the combobox specification in a way that directly conflicts with the definition of the combobox role itself. Such confusion is part of the force that drove me to clear all this up in ARIA 1.1."

I understand, which goes back to my point regarding the 1.0 design pattern. The improvements that are now mapped as part of the 1.1 pattern for supporting attributes are equally applicable in the 1.0 design pattern. I remember us talking about that last year during the ARIA call, and you agreed that this was a benefitial aspect of the update.

For example, though the 1.0 design pattern states that aria-haspopup is optionally set to "true", now as part of the 1.1 design pattern update, it is equally supported with token values on the 1.0 design pattern too. E.G Including aria-haspopup="listbox", aria-haspopup="tree", aria-haspopup="grid", and even aria-haspopup="dialog". I can use any of these right now in combination with aria-activedescendant on the 1.0 design pattern and make any of these widget types accessible; I've already done so for clients.

I also remember us talking about the role of aria-owns and how this doesn't make any sense as part of the accessibility tree when applied like this, and that the change to aria-controls makes more sense.

These design patterns are not just for backwards compatibility, but are available so people can learn how to program these widgets accessibly in the future going forward, and the only sensical way of doing this here is to use aria-controls instead of aria-owns so that the updates like aria-controls and aria-haspopup are consistent across both design pattern paradigms.

I don't understand why some changes like the use of aria-activedescendant can be considered a reasonable exception based on interpretation even though the 1.0 spec says something different, where this regarding aria-owns cannot.

[mcking65]

The 1.0 pattern is now replaced with the 1.2 version of combobox; all the above have been addressed.