Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Button components inconsistent and not properly accessible

See original GitHub issue

Issue Description

Summary 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: Kapture 2019-04-04 at 17 54 48 (

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 becomes pointer that differs from the actual area of the button.
  • Only PrimaryButton and LinkButton 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 its linkTo prop is defined, because it becomes wrapped within an <a> which is natively accessible on all browsers.
  • SecondaryIconButton still changes the cursor to pointer on hover even when disabled, whereas all the other buttons do not.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

montezumecommented, Apr 5, 2019

@jonnybel have you taken a look at this similar issue?

There was a lot of discussion here as well.

To be frank, I’m leery of touching button refactoring.

tdeekenscommented, Apr 5, 2019

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).

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found