A feature that was sold to clients long before I joined was enabling use of custom primary and secondary colors in our mobile app. This allows their branding to be communicated to users for a more white-label experience. However, a few things happen as a result of this feature:

  • Not always great for accessibility. Some customers are adamant on sticking with their brand colors even if it doesn't pass contrast ratios.
  • I use more neutral colors for functional design elements such as forms, copy, containers, etc.
  • But our buttons are still currently in variable primary colors. Which means if a customer has grey as their primary color, a button essentially looks disabled (no good). Or if their brand colors are red or green, it can also be problematic when asking to confirm an action or perform anything destructive.

My question is, does anyone know examples of other products that handle a similar issue? Where custom colors are allowed, but without significant impacts to accessibility and general functionality? Trying to figure out where best to inject these colors/branding so clients can be happy and users won't be confused.

Thank you!

5 Answers 5


We offer a product that does this, both the primary colour only change (which is generally applied to buttons as you describe) or a much more comprehensive theming solution for clients that want it.

Here's what I've learned over the last 3 years dealing with this.

  1. Designing with more neutral colours by default is a great start place. Arguably this should be the base anyway.
  2. Start thinking less about client primary colours but more about an "accent" if you design thinking about accents, you can use things like decorative underlines, background colours (with neutral foreground overlays) etc to make it "feel" like the client colours without affecting the core UI elements in a way which harms accessibility. It's surprising how little primary you actually need to achieve this.
  3. Brand primary vs app colours - it's not uncommon for a brand agency to define the client primary colour, often this is for print, logos and the suchlike. Often these agencies have either a) designed in a way which ignores accessibility b) designed in a way which is accessible, but doesn't apply colour in the way your app does (see point 1-2) or c) the colours you've been given don't reflect the way they would have been used in app (similar to b). Look for examples of the clients own website/apps if they have any and how they apply the colours there. If there isn't one, you need to work really closely to help define a more accessible palette. Explain that using a different shade of their primary to pass a11y checks doesn't mean changing their brand colour (often a tough sell!) - I often use the example of states (when considering buttons) - They wouldn't complain if you have to darken or lighten their primary to indicate a hover state, so why should they worry if the base colour is different.
  4. Colour shades - Take their base primary, create a 8-10 shade palette from it to handle the use cases (light backgrounds, accessible text, dark backgrounds, decorative elements). Show how you can use different shades of their primary to create the feel, without it being "exactly" their colour.
  5. Use dark mode as a catalyst. Even if you don't offer it, ask to client to consider their primary colour in light/dark mode. If it's really light/dark as a primary how this wouldn't work and would need to change may help land your point. Harder if it's a non-accessible mid-range colour. Ask them if they have a logo for use on light and dark backgrounds or for black and white print, often this shows how they already change their brand colour based on environment and can help back up your request to change it in your app.
  6. Ignore the secondary! blunt yes, but focus on solving the primary problem first.
  7. Education, if none of the above work, you're likely need to educate the client on the importance and legality of having an accessible product. Offer to work with them to create an "application colour palette" and show how it offers them value. Work really hard to differentiate this from "I want to change your brand".

One thing we have been working towards is a validated kitchen sink. What this would be is an interactive webpage with components in the patterns they are commonly used. The client would be able to enter their colours and only submit then once a11y checks are passed.


I don't know any app that allows massive color change beyond what we all know as normal: light mode & dark mode.

I think offering a client the possible arbitrary color change according to their preferences has several disadvantages, of which only a couple come to mind at first glance.

  1. Allow an application to accept an arbitrary change of colors, if this has no limit, there are 16 million possibilities, each one of the coordinates a screen color palette has. This makes it impossible to have control over the future contrasts produced, forcing the company to make personalized adjustments for each client.
  2. At the design level, offering the possibility of choosing colors arbitrarily is underestimating the power of one of the key compositional elements in graphic design: color. It's exactly the same as offering the client the possibility of placing their institutional typography throughout the application, screens, menus, buttons, etc. Not impossible but unlikely to work. Changing the color of an entire app is not the same as – Insert your logo here –.

Now, if this is actually one of the features of the application and the company prefers to keep it, I would propose some adjustments:

  • Offer a limited color palette, so these colors have already been tested beforehand, and give to the customer the possibility of choosing within this palette the colors that "best fit" their preferences.

  • Place the key elements of the use of the application in frames, so that the customizable part is outside these elements.

  • Reduce the area of ​​affectation of the personalization, maintaining a neutral color in the entire application, with customizable details.

From all the options, in my opinion, the most notable is unfailingly reducing the customizable color palette. I think a thirty colors palette can easily be tested with satisfactory results. If the client doesn't find a color that matches their own in a palette of thirty, it may not be a color, but a color combination that they should choose.


I unfortunately don’t have examples either. I believe the key is to balance the one user’s want to enforce their branding with the need of the many users to identify buttons.

A good orientation might be WAI’s Authoring Tool Accessibility Guidelines

These are criteria to be applied to applications that allow producing web content, which your customisation tool does, even if limited to colours. The interesting part is Part B: Support the production of accessible content

As you will see in the standard, it’s not the authoring tool’s responsibility to forbid inaccessible content, but to identify and explain problems and suggest solutions.

To take a UX perspective (to be verified in research, of course): The user configuring the theme is usually not the one who cares most about the company’s branding. Neither do they have the authority or the knowledge to change colours. They are often told to take the style guide and pick some colours for the theme.

You would have most success probably with an educational approach:

  • Provide a live-preview of the theme for the user to realise problems right away by themselves
  • Provide warnings or error messages based on contrast checks
  • Add help articles that go into details about the issues
  • Make it easy to accept a suggested colour that offers enough contrast, a similar one or a neutral one

The help articles might go further and explain what brand experience is and that colouring everything extensively while producing usability issues will actually reinforce the association between frustration and the brand’s color. (;


Chrome does something kind of along those lines with different accounts, but it is selecting from a range of colour themes

I think there either needs to be a set of themes that are defined in the app (and pass usability standards), or there needs to be much more customisation available beyond primary and secondary colours (so essentially proper white labelling).

Anything in between is just chaos as there is no way you will be able to account for all edge cases, unless you are severly restricting what elements get the custom brand colours.


If you're certain you can't go with limited palettes, you're up for some extra work on your side.

Using colors ir always about color combinations, not just single separate colors, so if you're letting users change primary and secondary colors, you should also make them change background and text colors (ultimately - all of the color tokens that are being used in your app). That way they'll have control over the combinations and can adjust their branding accordingly.

Next step would be to validate their color combinations and tell them if they're doing bad (against the WCAG recommendations, for example). For example, there could be a form for changing the colors and on pressing "Save" you could validate the color combinations and not let them save bad combinations.

This way you'd be able to validate against improper primary and secondary color (those that look like disabled).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.