Currently we've got a few accessibility issues in our demos:
General
- font-size/line-height uses absolute px values on several elements, mainly headings besides already overwritten p
Button
- Default label text input needs implicit aria-label
Combobox
Dropdown icon-only button doesn't have a label. While the icon-only button label issue is still going to be tackled, there's another angle:
In the current functionality, we don't have to expose the dropdown button at all to screenreaders. We already skip it for keyboard users and always show (aria-expand) it when input is focussed. Why not aria-hidden on it then? It's an unnecessary step as long as we always show the menu when input is focused.
Filed at T311025
Lookup
- We should not feature Lookup components without a label, if for focus reasons better, at least an aria-label
Menu
- Menu demo inputs have to have role=combobox applied for aria-expanded to be valid set.
MenuItem
- Ensure that we not only use semantic HTML (ul is missing around li items), but also put role="listbox" on containing ul)
- props inputs all need aria-labels
Message
- props and slots inputs need aria-labels
SearchInput
- input demos need to have aria-label
Select
- props input need aria-label
Tab/Tabs
?Unclear if tab overflow icon-only arrow buttons are ever exposed to screenreaders?
- props inputs need aria-label
TextInput
- Demo TextInput need l`aria-label`
- props inputs need aria-label
ToggleButton
- props input need aria-label
ToggleSwitch:
- Put implicit aria-label on label input
- Ensure that “default” ToggleSwitch requires and gets a label, if nothing else an aria-label attribute.
✓ Checkbox, Icon, ProgressBar, Radio, TypeaheadSearch
No discovered issues.
General (lo priority)
- Handle header anchors for keyboard nav differently <a class="header-anchor" href="#button" aria-hidden="true">#</a>. Ensure that those aria-hidden elements are not focusable.
