Color Scheme Tips for Using Green in Website Success and Completion Messages

Websites often use green to indicate that a form or other task has been completed successfully. Green can help distinguish this state, but a change of color alone does not explain what has been completed or what the visitor should do next. Showing success as soon as someone presses Submit is also misleading if the request later fails. This article uses a community seedling-swap event’s application form to show how green backgrounds, readable text, confirmation details, and the actual submission result should work together.

Use green to support the result, not to replace a clear confirmation

Consider a form that displays “We received your request to offer seedlings. We’ll provide more information about participation later.” This makes an important distinction: the visitor’s request was received, but their participation in the exchange event has not yet been confirmed. The page should say “Your participation is confirmed” only when that outcome has actually occurred. The visible result must agree with the response from the backend, meaning the system that processes or stores the submitted information.

Pair the success color with a heading such as “Request received,” a checkmark, and a specific description of what happens next. WCAG 2.2 (Web Content Accessibility Guidelines) requires that color not be the only visual means of conveying information. Green is useful here because it has a consistent role alongside the site’s ordinary notices, progress state, and errors, not because the same color necessarily creates the same emotional response for everyone.

Sending and completion are separate states. Show “Sending your request” while the operation is in progress. Show “Request received” only after a successful response, and provide an explanation and recovery path if sending fails. Do not change the interface to a completed green state before the server has confirmed the result.

Example green success-message palette for a seedling-swap form

Imagine a hypothetical form where visitors submit the type of seedlings they can offer and a preferred date. HEX means the hexadecimal notation used to specify colors on the web. Choose separate treatments for the ordinary form, a pending request, a successful submission, and a failed submission.

• Page background and body text: Place instructions in charcoal ■#2B3A39 on off-white ■#F8F7F2 for about 11.08:1 contrast. Deep green ■#265846 headings against that same background have approximately 7.63:1 contrast.
• Form card: Use white ■#FFFFFF with charcoal ■#2B3A39 field labels for about 11.88:1 text contrast. White ■#FFFFFF differs from the off-white page ■#F8F7F2 by only about 1.07:1, so add a gray-green ■#74847C outline if needed to identify the form fields. The outline has about 3.94:1 contrast against white ■#FFFFFF.
• Message while sending: Use a pale blue-gray ■#EAF1F5 panel with deep blue ■#2A566B text reading “Sending your request.” Text contrast is approximately 6.96:1. Since the panel differs from the off-white page ■#F8F7F2 by only about 1.06:1, include clear words and an appropriate progress cue. Do not show a completion message yet.
• Successful submission panel: After the server confirms that the request was received, change the message area to pale green ■#E3F1E8. This surface differs from the surrounding off-white ■#F8F7F2 by only about 1.09:1. A clearly labeled heading and a visible outline help identify the message without depending on the green background alone.
• Confirmation heading and checkmark: Show “Your seedling offer request was received” and a checkmark in deep green ■#24553D against pale green ■#E3F1E8. Both the lettering and the symbol have about 7.38:1 contrast with the background. Make the same result understandable in words for visitors who do not recognize the symbol or distinguish the color.
• Explanation of what happens next: Use charcoal ■#2B3A39 for “Participation will be confirmed separately,” providing about 10.19:1 text contrast against pale green ■#E3F1E8. Supporting instructions in gray-green ■#52645D still provide about 5.39:1. Describe the actual communication method and timing used by the organizer rather than promising an email or confirmation the service may not provide.
• Outline around the success message: Use subdued deep green ■#4D7860 against the pale green ■#E3F1E8 for about 4.32:1 contrast. The same border differs from neighboring white ■#FFFFFF by about 5.03:1, helping define the success panel on a light page.
• Summary of the submitted request: If the form can display details it actually saved, group the seedling type and preferred date on pale gray-green ■#EEF3EE with charcoal ■#2B3A39 text. Their contrast ratio is about 10.58:1. The summary surface differs from the green success panel ■#E3F1E8 by only about 1.04:1, so include a heading such as “What you submitted” and clear spacing. Do not present unsaved details as verified.
• Next-step button or link: An action such as “Return to event information,” rather than “Submit again,” can use deep teal ■#245E70 with white ■#FFFFFF text. Text-to-button contrast is approximately 7.22:1, and the button contrasts by about 6.19:1 against the pale green success area ■#E3F1E8. An underlined text link in deep teal-green ■#235C56 also has about 6.58:1 contrast against that panel.
• If submission fails: Use pale reddish beige ■#F7EBE7 with deep reddish brown ■#874233 text such as “We couldn’t send your request. Keep your entries and try again.” The text contrast is approximately 6.30:1. The pale error surface differs from the off-white page ■#F8F7F2 by only about 1.09:1, so include a visible error heading and a recovery instruction. Do not show the green success state after a failed attempt.

The palette separates data entry, progress, successful receipt, and failure. Colors help visitors scan those states, but the precise wording tells them what has happened, what remains undecided, and what they can do next.

Confirm the result, announce updates accessibly, and prevent duplicate requests

If a page updates a success message in place without moving focus or navigating elsewhere, visitors using a screen reader also need to receive that status change. One approach in HTML (HyperText Markup Language) is to update an already-present region with role="status" after the server responds. This type of live status region announces routine updates politely. The more interruptive role="alert" is not necessary for every success message. If the application navigates to a dedicated confirmation page instead, review that page’s heading and focus behavior.

Do not dismiss the confirmation automatically before visitors have a chance to read it, or claim that information was saved without confirming the actual result. Test whether retrying a failed submission preserves the entered data and whether repeated submissions could create duplicates. On mobile and with keyboard navigation, make sure the completion text and next action remain easy to find.

Under WCAG 2.2 Level AA, normal-sized text generally needs at least 4.5:1 contrast against its background, large text at least 3:1, and essential non-text indicators of controls or states generally at least 3:1 against adjacent colors. HueRoll can compare a selected color against white or black, but it cannot directly compare arbitrary pairs of custom colors or automatically determine WCAG AA or AAA compliance. The custom-pair ratios in this article were calculated separately.