Why We Refuse a Brand Palette That Fails Contrast

A request that looks like friction for no reason

When a tenant is onboarding onto a hosted login page, one of the first things they ask for is their own brand on it: their logo, their primary accent color, sometimes a background tint lifted straight from their marketing site. It is a small, reasonable-sounding request, and refusing part of it looks, on the surface, like unnecessary friction from a vendor being precious about its own design system. In practice, refusing it is one of the more consequential decisions we make about how the product behaves, because the request that looks small is actually a request to change the readability of a page where someone is about to type a password.

The failure shows up in a specific, boring way. A tenant submits a light gray as their primary accent, intending it for buttons and links, and the color sits against a white or near-white background at a contrast ratio of roughly 2:1. It looks fine to whoever chose it, on whatever monitor, in whatever lighting, at whatever time of day they happened to be looking at it. It does not look fine to a user with low vision, a user in bright sunlight on a phone, or a user on an older laptop screen with drifted color calibration. Three responses are possible once that failure is detected: ship it as requested and let it be the tenant's problem, quietly nudge the color toward something that passes without telling anyone, or refuse to publish the branding until it clears the bar. We do the third one, every time, with no override.

Contrast is arithmetic, not a design opinion

The reason we can refuse without an argument is that contrast is not subjective. The Web Content Accessibility Guidelines define relative luminance for a color from its color channels, and a contrast ratio between two colors as (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter of the two computed luminances. WCAG AA requires at least 4.5:1 for normal text, 3:1 for large text (roughly 18-point, or 14-point bold), and 3:1 for the visual boundaries of user interface components and graphical objects (the outline of a button, a focus ring, an icon that carries meaning on its own). AAA raises the bar further, to 7:1 for normal text. These are published, testable thresholds, not house style.

That arithmetic is what makes enforcement possible without a design review meeting. A color submitted for a hosted login page is checked against every surface it will actually render on: button text against the button fill, placeholder text against the field background, a focus indicator against the chrome around it, and the check either passes or it doesn't. There is no version of this where a reasonable person could look at the number and disagree. That is precisely why it belongs in a gate rather than a guideline: guidelines get argued with under deadline pressure, gates don't take the meeting.

A login screen is not a marketing page

Poor contrast on a marketing page costs you a bounce. Poor contrast on the one screen a person must get through to prove who they are costs them access to whatever is behind it (a payroll system, a clinical record, a bank account). The population affected is larger than 'people who use a screen reader.' It includes anyone with age-related vision loss, anyone with a temporary impairment like a migraine or dilated pupils after an eye exam, and anyone dealing with ordinary situational impairment: glare on a phone screen outdoors, a cracked display, a monitor nobody has recalibrated in years. Authentication surfaces get used by everyone, under worse conditions than any other screen in the product, because people don't choose when they need to log in.

There is a second-order effect that rarely makes it into an accessibility discussion: when a login screen is hard to read, the workaround is often a human one. Someone asks a colleague to read a one-time code off their screen, or reads their own password aloud so a family member can type it for them. Both of those are security failures dressed up as accessibility failures: a shared credential, an overheard code, a second person now able to reproduce a login they were never issued. An accessible login screen is not a nice-to-have layered on top of security; for a real portion of the user base, it is a precondition for the security model working as designed.

The gate we run, not the guideline we hand out

Any color submitted for hosted login branding (accent, text, background) is evaluated against the specific surfaces it will render on before it ever reaches a real user. A failing submission is rejected with the measured ratio and the nearest value that would pass, so the tenant can make an informed adjustment. It is not auto-corrected on their behalf. Silently shifting a color a tenant chose, without telling them, is its own kind of dishonesty about what shipped. It also hides the failure from the one person positioned to notice it was a failure in the first place. There is no exception workflow, because an exception process for a hard requirement is just a documented way of not having a hard requirement.

What refusing one small thing tells you about everything else

The reason this is worth writing about at all is not the contrast math: any reasonably competent engineering team can implement WCAG's formula in an afternoon. It's what the willingness to enforce it, without exception, under commercial pressure, predicts about everything else a vendor says it does. A brand palette request is low-stakes and highly visible: a tenant asks for it directly, and the cost of saying yes looks small in the moment. If a vendor will bend a published, testable, non-negotiable requirement for a paying account on a request that visible, it is reasonable to ask what happens to the requirements nobody is watching: default session lifetimes, how long a support log line sits before it's purged, whether a rate limit stays on during a big customer's traffic spike.

Enforcement discipline on a low-stakes, highly visible requirement is a usable proxy for enforcement discipline on the high-stakes, invisible ones, because both come from the same organizational habit: does a requirement get enforced by something that can't be argued with, or by a person's judgment under pressure. Ask any identity vendor not 'do you care about accessibility,' which everyone will answer yes to, but 'show me what happens when a customer asks you to ship a color that fails contrast.' The answer is a better predictor of their security posture than their security page.

It isn't only about text

Contrast enforcement gets discussed as though it only applies to body copy, and that undersells what a real gate has to check. WCAG's 1.4.11 requirement covers non-text contrast: the 3:1 minimum for the boundaries of interactive components and the graphical objects needed to understand content, which means a checkbox outline, a toggle's on/off state, and a required-field asterisk all have to clear a bar too, not just the label next to them. A field that turns red to flag an error and provides no other signal fails a related requirement, 1.4.1, because color alone is carrying information that a color-blind user cannot receive. A branding submission that only checks the accent color against the page background and stops there hasn't actually verified the login page is usable. It's verified one sentence of it. The gate has to walk every state a real user hits: default, focus, hover, disabled, error, because a color that passes at rest can still fail the moment it needs to communicate something urgent, which is usually the moment it matters most.

The question worth asking

Every vendor will tell you accessibility is a priority. Fewer will show you the gate that makes it non-optional, and fewer still will tell you they've said no to a paying account over a hex code. If a vendor can't point to a specific requirement they enforce without exception, regardless of who's asking, that's the answer to a more important question than the one you asked.