-
Notifications
You must be signed in to change notification settings - Fork 355
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
Draft combobox design pattern #31
Comments
From @jnurthen on April 25, 2016 18:21 Keys: |
From @jnurthen on April 25, 2016 18:24 the button needs to be mentioned that it should not be in the tab sequence (probably) |
From @jnurthen on April 25, 2016 18:27 What does "Provide a label for the combobox by referencing the text field in the combobox. You can use an aria-label to associate this label with the combobox or you may use the HTML element and its for attribute to reference the text field." mean.... needs changing or clarifying. |
From @carmacleod on April 25, 2016 18:46 Example 5 for combobox in ARIA 1.1 shows the aria-label case, and a similar example with Tag would work for "the HTML element and its for attribute" case. |
In addition to the below, This commit also moves the landmark section after the example section. Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html and created associated issues for drafting new versions. 1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue #73. 2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section. 3. Section "Relationships" and raised issues #74, #75, #76, and #77. 4. Section "Managing Dynamic Changes" and created issue #78. 5. Section "Presentation Role" and created issue #79. 6. Section "Form Properties" and created issue #80. 7. Section "Drag-and-Drop Support" and created issue #81 8. Section "Math" and created issue #82. 9. Section "Reusable Component Libraries" and created issue #83. 10. The following 4 Appendix sections related to background on ARIA and created issue #84 A. Background on WAI-ARIA B. Filling the Gaps for Content Delivered to Desktop Browsers c. Building Accessible Applications with WAI-ARIA D. Reasons for Adopting WAI-ARIA 11. The following design patterns: A. Accordion and updated issue #53. B. Autocomplete and updated issue #31. C. Combobox and updated issue #31. D. Datepicker and updated issue #57 E. Dialog (Non-Modal) and updated issue 59. F. Dialog (Tooltip) and added issue #85. G. Landmarks and added issue #86. H. Popup Help (aka Bubble Help) and added issue #87. I. Rich Text Editor and added issue #88. j. Site Navigator - General and added issue #89. K. Site Navigator - Tree and added it to issue #89. L. Site Navigator - Tabbed Style and added it to issue #89. M. Tree Grid and added issue #91. N. Wizard and added issue #92.
In addition to the below, This commit also moves the landmark section after the example section. Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html and created associated issues for drafting new versions. 1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue w3c#73. 2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section. 3. Section "Relationships" and raised issues w3c#74, w3c#75, w3c#76, and w3c#77. 4. Section "Managing Dynamic Changes" and created issue w3c#78. 5. Section "Presentation Role" and created issue w3c#79. 6. Section "Form Properties" and created issue w3c#80. 7. Section "Drag-and-Drop Support" and created issue w3c#81 8. Section "Math" and created issue w3c#82. 9. Section "Reusable Component Libraries" and created issue w3c#83. 10. The following 4 Appendix sections related to background on ARIA and created issue w3c#84 A. Background on WAI-ARIA B. Filling the Gaps for Content Delivered to Desktop Browsers c. Building Accessible Applications with WAI-ARIA D. Reasons for Adopting WAI-ARIA 11. The following design patterns: A. Accordion and updated issue w3c#53. B. Autocomplete and updated issue w3c#31. C. Combobox and updated issue w3c#31. D. Datepicker and updated issue w3c#57 E. Dialog (Non-Modal) and updated issue 59. F. Dialog (Tooltip) and added issue w3c#85. G. Landmarks and added issue w3c#86. H. Popup Help (aka Bubble Help) and added issue w3c#87. I. Rich Text Editor and added issue w3c#88. j. Site Navigator - General and added issue w3c#89. K. Site Navigator - Tree and added it to issue w3c#89. L. Site Navigator - Tabbed Style and added it to issue w3c#89. M. Tree Grid and added issue w3c#91. N. Wizard and added issue w3c#92.
Please also flesh out the case of a read-only combo box. There's several things to consider:
Also please think about about readonly combo boxes that look like/use a button instead of a textbox. |
Hmmm... VoiceOver actually calls these "pop up button". So perhaps they are not readonly combos at all... I may have to rethink this. Although for the native readonly combo Windows example, JAWS says: Anyhow, I think some fleshing out of readonly combobox is needed. |
Under "keyboard interaction" can I please request an addition to include what happens when shifting focus away using the Tab key mid-selection - i.e. the combo box retain the currently highlighted selection and the focus shifts to the next focusable element (unlike Enter, where focus is retained on the same element). I understand this to be the standard native behaviour. |
@cyberseraphic on macOS tab doesn’t do anything when a popup button is open (like a preventDefault()). Haven’t tested on other platform yet. Ah, this is combobox, sorry, got confused. @carmacleod those are indeed popup buttons. This would be a native combobox (go to folder in Finder): |
@MichielBijl I guess Mac doesn't exactly have a native read-only combo. The "read-only combo box" pattern I am trying to describe is like an HTML select element. If you give focus to an html select, you can:
But the default ARIA role for an HTML select element is (oddly enough?) "listbox", which doesn't have pop-up behavior. Sorry, I'm not being very helpful here (just pointing out inconsistencies with no real answers), but I do think it would be useful to add some more thoughts/words to the readonly combobox pattern. |
Redesigning the |
FYI: This blog post contains a short list of examples of listbox/combobox implementations: |
Matt, I read through the Combobox design pattern intro text as you asked and it all looks good to me as is. I can't think of anything that is missing. |
Closed with commit a2af4b3. Will now open a new issue for the task force review. |
Locking comments on this issue; please provide feedback on the current draft in issue #464 or raise a new issue. |
Copied from original issue: w3c/aria#349
From @jnurthen on April 25, 2016 17:47
Merge Combo and autocomplete
Rewrite description based on ARIA 1.1 spec definition
When working on this issue, there is some old content that may be useful in the file aria-practices-DeletedSectionsArchive.html.
The relevant sections can be seen here:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#combobox
And at:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#autocomplete
The text was updated successfully, but these errors were encountered: