-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review Example of ARIA 1.0 Combobox With Both List and Inline Autocomplete #553
Comments
Typo in last sentence of main paragraph: Change "arbetrary" to "arbitrary". |
FF 57.0 on Win10 Keyboard support > Textbox: Escape performs neither of these actions:
|
FF 57.0 on Win10 Keyboard support > Listbox pop-up: Escape performs none of these actions IF anything has been previously selected:
|
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: |
No other issues noted. |
… typo Per feedback from @annabbott in issue #553, fixed spelling of "arbitrary".
@annabbott commented:
Fixed in commit bf9a694.
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.
I cannot reproduce this. Maybe I am not following the same steps. Could you provide a step-by-step?
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! |
Per @mcking65
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. |
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 |
@accdc commented:
That is not what we have specified in the pattern. We can ignore the case of When
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 |
@annabbott commented:
@mcking65 wrote:
@annabbott wrote:
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. |
"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. |
The 1.0 pattern is now replaced with the 1.2 version of combobox; all the above have been addressed. |
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
The text was updated successfully, but these errors were encountered: