This issue came out of the discussion in #63856.
There are a couple of details about the secondary button appearance it could be good to address.
Lack of clear hover style
Users with low vision might have difficulty distinguishing buttons from static content. A distinct hover style helps these users identify buttons as interactive elements.
Relatedly, a clear hover style will be critical if the button cursor ever changes from pointer to default, as discussed in #63856. There's an interesting article on this subject here, the upshot being:
pointer is for links. Note that default browser styles do not apply it to buttons, radios, inputs, or any other interactive elements.
- A well designed button (with clear hover state) should not require a cursor change to indicate interactivity.
There are also cursor-less environments to keep in mind like Spatial Computing, or devices that use different cursor sets, e.g. an iPad with Magic Keyboard:

Visual overlap with inputs
Text inputs and secondary buttons have a very similar footprint, visual weight, and general style treatment. As an example here's a screenshot from the Block Inspector:
If you squint, or find yourself in certain lighting conditions, it's kind of hard to tell the input / button apart. This is even more pronounced for sufferers of monochromatic color blindness (simulator):
Coupled with the lack of clear hover style this makes for a situationally poor UX.
Additional considerations
It's important to acknowledge that any new design should retain the a11y features of the current design. Specifically:
- Contrast ratio: The button text and any icons should have a contrast ratio of at least 4.5:1 with the button background.
- Clarity vs Surrounding Content: Whichever detail is used to distinguish the button as an interactive element (e.g background color, border, font-weight, combination thereof) should also meet contrast requirements. For borders and backgrounds that is typically a contrast ratio of at least 3:1 against the surrounding UI. For font weight the text should differ from regular body copy.
- Shape and Size: The button should have a clearly defined shape and size, making it easily recognizable as a button.
This issue came out of the discussion in #63856.
There are a couple of details about the secondary button appearance it could be good to address.
Lack of clear hover style
Users with low vision might have difficulty distinguishing buttons from static content. A distinct hover style helps these users identify buttons as interactive elements.
Relatedly, a clear hover style will be critical if the button cursor ever changes from
pointertodefault, as discussed in #63856. There's an interesting article on this subject here, the upshot being:pointeris for links. Note that default browser styles do not apply it tobuttons,radios,inputs, or any other interactive elements.There are also cursor-less environments to keep in mind like Spatial Computing, or devices that use different cursor sets, e.g. an iPad with Magic Keyboard:
Visual overlap with inputs
Text inputs and secondary buttons have a very similar footprint, visual weight, and general style treatment. As an example here's a screenshot from the Block Inspector:
If you squint, or find yourself in certain lighting conditions, it's kind of hard to tell the input / button apart. This is even more pronounced for sufferers of monochromatic color blindness (simulator):
Coupled with the lack of clear hover style this makes for a situationally poor UX.
Additional considerations
It's important to acknowledge that any new design should retain the a11y features of the current design. Specifically: