Improve default reset of button styles for high contrast mode

[jiri-thiemel-te]

What version of Tailwind CSS are you using?

For example: v3.3.1

What build tool (or framework if it abstracts the build tool) are you using?

For example: Next.js 13.3.1

What version of Node.js are you using?

For example: v17.9.1

What browser are you using?

Chrome, Firefox, Edge

What operating system are you using?

Windows

Reproduction URL

https://play.tailwindcss.com/4DgqvH5JDl

Describe your issue

Buttons that don't have a border defined won't be recognizable as a button in high contrast mode. Each button should have a border, even though it would be a transparent one. In high contrast mode background colours are overridden and buttons without border are very hard to identify in many scenarios as they look just like a regular text. Any border is also overridden with a custom contrast colour even the transparent one, which solves the issue. The problem is that many developers know about this issue and won't set a transparent border or custom appearance for high contrast scheme. And even those that do about this issue don't want to do this every time. There definitely should be reasonable defaults.

Solution

Change the default button reset to include a transparent border.

If you consider this change problematic because of backwards compatibility, let's discuss alternative approach.

Related issues

#2460

[adamwathan]

Hey thanks for the feedback on this!

Just to make sure I understand your concern here:

In high contrast mode background colours are overridden and buttons without border are very hard to identify in many scenarios as they look just like a regular text.

Is there anything unique about high contrast mode that makes buttons without borders harder to identify as buttons than they are for people who don't use high contrast mode?

For example, in this screenshot from Shopify, "Refund" is a <button> that opens a dialog but has no visible border or special button styles even for people not using high contrast mode:

My instinct is that if Tailwind is willing to let you do that, then I don't think we should make special changes for high contrast mode unless there's something unique about high contrast mode that makes it important to show a border there, but not important to show it to people not using high contrast mode.

Not trying to be dismissive at all to be clear — we already include some tweaks for high contrast mode like making outline-none actually set the outline to transparent, since most people are using that to hide native focus styles and replace them with custom focus styles implemented with box-shadows that are completely invisible in high contrast mode, completely breaking keyboard accessibility for those users.

That situation feels pretty black and white though whereas this one feels more subjective to me right now based on what I know so far at least.

[jiri-thiemel-te]

Hi,

I've noticed the ticket for the outline in high contrast mode and thanks for that! 🙏

High contrast mode isn't about design anymore. It's about usability only. Without the border the information that it's an active element is conveyed only via colour, which is not enough. In many cases the information can be easily missed. The user might be completely colourblind. Or the colour of the button can be the same as the colour of the text in this mode as well. Links should have an underline and buttons should have borders, that's what's expected.

Also in high contrast theme the colour of an element is based only on the actual element which is used. You support also [role=button] by default (native elements should be always preffered, but as this is already supported). So imagine div[role=button] - this will look exactly like default text, it will have text colour.

You've sent an example where the user will probably decipher that these are active elements even though these look like text. Sure, there are scenarios like that. But there also are many scenarios where it wouldn't be noticeable without it. And if the developer will set the background colour of the button and no border, this information will be lost in high contrast theme. And I have a reasonable concern how many developer do actually know they should care about high contrast theme and how to handle them. Therefore I believe that reasonable default style here is a transparent border and explanation in the documentation why this was added and why the transparent border should not be removed. This framework is based on a CSS reset. And that reset should work in a accessible way.

(The border could be also set via media query targeting high contrast mode. But as this is a change that also slightly changes the layout I don't suggest it as the primary way how to do that. Even though high contrast mode isn't about pixel perfection anymore, this approach seems potentially more problematic than the suggested one.)

Here are picture of how that repro link I've attached to the issue looks when viewed with some built-in contrast themes. And how it would look after implementing the transparent border. Also I should point out that some users of contrast theme actually use it lower the contrast because of migraines, headaches etc. The distinction in colour between button and the text is definitely not guaranteed, very often there is none. (And even if there was, having colour as the only clue is not enough.)

Standard mode

Built-in Aquatic theme - completely irrecognizable

Built-in Desert theme - completely irrecognizable

Built-in Dusk theme - I have good eyes but still I'd struggle a lot to recognize active elements with this slight colour difference

Please, give this topic some time and make no hasty decisions here. We should get more feedback from people who depends on this feature. 🙏

[thibaudcolas]

Partly related feature request: Windows High Contrast mode support with forced-colors modifier and system colors #7839.

My two cents is that Tailwind fixing this with reasonable defaults would involve too much magic. There are plenty of cases where a button has a background utility class and no border is required for identification in high contrast mode, and a 1px border in the button reset, even transparent, would go against lots of people’s expectations.

Having said that, it’s indeed a big gotcha for frameworks like Tailwind where you can indeed make something that looks like a very prominent CTA with just a background and a bit of padding; and disappears in WHCM. So – perhaps this could be addressed with documentation? For example… as part of documentation for a new forced-colors variant (😬).

[Liammiah]

Thanks for the information. TellTims Survey

[lukewarlow]

#11694 and #11931 should provide the neccesary built ins to address this as an author.

I agree that unfortunately dealing with forced-colors as part of a reset would probably be unintuitive unless it was a style that only applied when the media query matched.

I think it would be much better to push the docs towards informing people of potential issues and giving them the necessary built ins to address it.

This goes for accessibility in general not just this issue. We already have contrast and reduced motion, #11692 adds reduced transparency

[lukewarlow]

Further to my above comment #11930 as I raised here I think Tailwind should add CSS system colors built in for use in forced colors mode.

[adamwathan]

Coming back to this one — I definitely think it would be a better default for Tailwind to include borders on buttons and other form elements by default. Because it's a breaking change it's not something we can change easily or quickly, but I've added it to my list of changes to explore for v4.0. Thankfully the upgrade path wouldn't be too painful because users could just throw a line or two of extra CSS into their base styles to bring back the current default behavior.

So I'm going to close this for now as I don't really look at this one the same way as a regular black and white bug and instead just as an improvement I'd like to explore in the future, and we try to treat GitHub issues strictly as a bug tracker that we can work through day-to-day.

In the mean time, end users can explicitly add borders where it's important, which is what we do for our own projects generally. For example in the new UI kit I've been working on for Tailwind UI we include a transparent border on buttons specifically for this reason.

I think either way it's going to be best to try and educate people on this, because even if/when we do change the defaults, I suspect most people who want to remove the border will remove it with border-0 rather than border-transparent, and they'll be right back to having this problem in their projects anyways (like so many existing non-Tailwind CSS sites already do due to the same lack of awareness around Windows High Contrast mode and user expectations there.)

So thanks again, on my list of things to explore improving 👍

[jiri-thiemel-te]

Thanks, this sounds reasonable. But please, try to prioritise adding info about this to your docs. I agree educating devs is the most important part. And you have the power. (And as you're removing the default styles, I also believe you actually have the responsibility 😉.)

Thank you for all your amazing work and keep it up!