How to Manage Colors for Different States: Web UI Color Rules

When a website uses different colors on every screen for selected, submitting, completed, or error states, people have to relearn what those colors mean. To manage state colors consistently, define more than just a palette: establish when each state applies, what text appears, and which actions are permitted. This article builds a practical color rule set for an internal office-equipment borrowing request form. UI means user interface—the parts of a web page people view and operate.

Keep interaction, processing results, and availability separate

Start by distinguishing states that may look similar. Selected means an equipment item has been chosen. Submitting means a request is being processed. Success means the server has confirmed the request was received. Clicking the submit button is not, by itself, evidence of success. Error points to information requiring correction. Disabled means an action is currently unavailable because necessary conditions have not been met.

Availability and the meaning of a result are separate concepts. For example, a particular equipment row may be selected while the submit button remains disabled because no quantity has been entered. Keyboard focus—the control ready to receive the next keyboard action—is also separate from whether an item is selected. Instead of treating each of these situations as one all-purpose color, define which component communicates which state.

Write down the conditions for transitions: pressing “Submit request” changes the process to Submitting; a confirmed server response leads to Success; a validation or communication problem leads to Error. Prevent repeated submissions through the actual application logic, not by changing the button’s color alone.

Six coordinated state rules for an equipment request form

Consider a page with white ■#FFFFFF cards on a pale background ■#F6F8FB. HEX is a hexadecimal notation for specifying web colors. The following example applies colors to different components—a submit button, a selected row, and status messages. It does not mean that one button needs all six appearances.

The default submit button uses blue ■#205B84 with white ■#FFFFFF text, yielding approximately 7.26:1 contrast. During submission, retain the same blue-and-white pair but change the visible label to “Submitting…”. The text and the actual application behavior, rather than a hue change alone, indicate that a second submission should not be allowed.

For a selected equipment row, use pale blue ■#EAF3FF with dark-blue text ■#1D426E. This text/background pair has approximately 9.12:1 contrast. However, the pale fill differs from white ■#FFFFFF by only about 1.12:1. Keep a “✓ Selected” label and add a darker ■#1D426E selection outline where necessary. That outline contrasts against white by approximately 10.21:1.

For confirmed success, use pale green ■#EAF7EF with deep-green text ■#176446, approximately 6.46:1. For an error, use pale red ■#FDEDED with deep-red text ■#A12634, approximately 6.51:1. Display a success message only after confirmation, and make the error message identify the relevant field—for example, the equipment quantity that needs changing.

The disabled submit button uses pale gray ■#E4E9EF and slate text ■#526275, which contrast by approximately 5.12:1. Explain nearby why the action is unavailable, such as “Select an item and enter its quantity.” Gray alone should not be the only explanation.

Record transitions, preserve non-color cues, and review contrast

Alongside the name and HEX codes of each state, maintain a simple rule table recording its trigger, visible label, whether interaction is available, and the screens where it appears. Decide what happens after a timeout, when an error is corrected, and when a user returns to edit a request. The word “Success” should represent the same kind of confirmed outcome throughout the product.

For native HTML form buttons, a real disabled attribute prevents the usual interaction; a gray appearance alone does not. WCAG contrast criteria include an exception for truly inactive UI controls, but that is not a reason to make explanatory text difficult to read. As an example, regular body text ■#253649 on a white ■#FFFFFF card has a contrast ratio of approximately 12.33:1.

Manage keyboard-focus indications independently from Selected, Success, and Error. On a white ■#FFFFFF card, an outer purple ■#6A398A focus outline contrasts with the white background by approximately 8.19:1. Recheck the actual neighboring colors where the outline is rendered and make sure it remains visible during keyboard navigation.

Under WCAG (Web Content Accessibility Guidelines) 2.2 Level AA, normal text requires at least 4.5:1 contrast with its background, and qualifying large text requires at least 3:1. Essential non-text information that identifies component states, such as some outlines and icons, generally requires at least 3:1 against adjacent colors. Do not rely on color alone to communicate meaning: include labels and other visible cues. The ratios here are calculations for opaque, solid-color pairs and do not prove conformance for an entire interface.

HueRoll lets you explore HEX codes, lighter and darker color suggestions, and contrast between a selected color and white or black. It cannot directly compare two arbitrary custom colors or automatically report AA/AAA conformance. Check the actual text, backgrounds, and selection outlines with another method as part of your state-rule review.