Button components inconsistent and not properly accessible
See original GitHub issueSummary of the Problem
The button components are showing a lot of inconsistencies regarding sizings and hover/focus states.
See here, all the buttons inside the same container and using their default props as much as possible:
(https://codesandbox.io/s/34vv1j1jz6)
Some of them are also not properly accessible in regards of displaying a focused and active states. This can be reproduced by trying to navigate through the buttons using the Tab key and “clicking” them using the Space key (or Enter key for the LinkButton because it’s an anchor).
List of the Identified Problems
- Some buttons fill the available space differently within the same container.
SecondaryButton
has an area where the cursor becomespointer
that differs from the actual area of the button.- Only
PrimaryButton
andLinkButton
display any kind of visual feedback when where are focused or clicked through the keyboard (tab and space keys). All the remaining buttons are not accessible.SecondaryButton
actually becomes accessible when it has itslinkTo
prop is defined, because it becomes wrapped within an<a>
which is natively accessible on all browsers.
SecondaryIconButton
still changes the cursor topointer
on hover even when disabled, whereas all the other buttons do not.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:6 (6 by maintainers)
Top Results From Across the Web
A Complete Guide To Accessible Front-End Components
An up-to-date collection of accessible front-end components: accordions, form styles, dark mode, data charts, date pickers, form styles, ...
Read more >Select input box / combobox gets inconsistent internal state in ...
Using 0.14 on latest Firefox. Given the following: getInitialState: function () { return {select: 'a'}; }, handleChange: function (event) ...
Read more >I've been doing buttons wrong! Have you? - UX Planet
Buttons styles in which primary button has a high contrast fill, secondary button has a. When it comes to accessibility, it's important that...
Read more >Button has non-empty accessible name - ACT-Rules Community
This rule checks that each button element has a non-empty accessible name. Applicability. This rule applies to elements that are included in the ......
Read more >Building Accessible Buttons with ARIA: A11y Support Series
However, on mobile both VoiceOver iOS 10 and Android TalkBack/Chrome do not support the aria-pressed attribute unless the additional role=” ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@jonnybel have you taken a look at this similar issue?
https://github.com/commercetools/ui-kit/issues/29
There was a lot of discussion here as well.
To be frank, I’m leery of touching button refactoring.
Personally, I would actually call in a meeting with them to generally raise awareness for these kind of accessiblity concerns so that they’re incorporated in any future elemment and can be strategically adressed in existing ones (from important to less important elements).