SharePoint Theme Contrast Testing: A 30-Second Check

2026/04/14 by Stefan Bauer

Now that the SharePoint Hackathon is in the books, we saw genuinely stunning submissions. It is time to talk a bit about accessibility, specifically on color accessibility.

The hackathon showed that beautiful designs do not mean they are accessible.

The dark, gradient-heavy design looks risky but hides its flaws in small, label-like text and colored overlays.

The clean, light layout looks completely safe, but the body copy fails because dark blue on light blue doesn’t have the expected contrast ratio.

Often, I hear people say, “I always check the color contrast for accessibility”. That statement is about as useful as ‘I brush my teeth every morning.’

Let me show you the tool everyone can use, not only developers, to get a great overview.

Why accessibility in Brand Center does not count

When you create a pure red (#ff0000) and white (#ffffff), you do not meet the color contrast requirements.

Brand Center flags “Not enough contrast” but never tells you where the colors apply, what elements are affected, or what the actual contrast ratio is. A generalized statement you can dismiss and ship anyway.

The issue is in Brand Center, not your design. It never tells you where or how these colors actually apply.

The disconnect is in the user interface and the colors. The two selected colors are actually not foreground and background colors, as the indicator suggests. They are the background and accent colors, colors that only partially appear on the user interface. I won’t change the text color, which can either be black or white, due to SharePoint limitations.

Even though the color contrast is met here, it still can fail in your theme.

You can compare it: “I found a needle, so I conclude it was in a stack of needles, not hay.”

The previous version of the brand center hasn’t had that problem. It was not the gold standard either, but it made you aware that some combinations might not have been accessible.

Do not rely on the color contrast checker

Contrast checkers indicate whether a pair of colors is accessible; the actual accessibility is not binary.

Newer is not always better. A more clear direction where issues occured in the old Theme Designer

Fluent UI and SharePoint use those colors to create multiple different color variants for different use cases. Theoretically, you could end up with 462 possible color combinations to check for color contrast. Not include the 16,777,216 colors that the user can pick from a regular color picker on the web.

Theme color palette as it is still used today. Tones of options for accessibility checks.

The semantic slots also need to be checked for color contrast. Not just text against background, but background against its surroundings, and across every interactive state: default, hovered, pressed, checked. Each row in this table is not one check. It requires several checks.

When someone claims to check color contrast, they reduce it to a binary option. The trillions of real-world combinations are ignored.

How to check the color-contrast in SharePoint?

Since it is not sufficient to check trillions of color combinations, which would actually be required. There are two options you could use that give a better accessibility picture.

CSS Overview – Microsoft Edge / Google Chrome

The CSS Overview is a feature introduced in the developer tools for Microsoft Edge around 2020 by Christian Heilman, and later in Google Chrome.

Open and use it to do the following:

Open the page you want to check
Press F12
Click ⋮ (three dots menu, top right of the panel that opened)
More tools → CSS Overview
Click Capture overview

CSS Overview in Developer Tools give you great options to test the color contrast.

Don’t be scared by “Identify potential CSS improvements”; it is not all about CSS. Once the page is captured, you will find the contrast issues directly under “Colors”.

The full list of color contrast issues.

Right now, four contrast issues have been identified. When you click on one of the issues, you will see a list of all occurrences on the page.

Hero Accessibility issue pass WCAG AA but fails WCAG AAA

On the right, it shows the contrast ratio as defined by the success criteria. Hovering over a specific element highlights the precise spot where the issue occurs.

Full picture of this particular contrast issue

In our case, it is the hero element. It passes AA at 3.99:1 because large text only requires 3:1. The button labels fail at the same ratio because normal text requires 4.5:1.

Left passes WCAG AA,
Right button fails WCAG AA

Same color combination, different verdict. This is what “I checked the contrast” misses.

CSS Overview is a useful tool to check color contrast in real SharePoint use cases. The only issue is that it only checks the page, not the entire SharePoint. However, it is the right first step.

Since it is universal, you can use it to check your Power Apps or any website for contrast issues against WCAG success criteria.

Is the Accessibility Assistant in SharePoint there to help?

Truth be told, the out-of-the-box Accessibility Assistant is a nice gimmick.

SharePoint’s Approach to accessiblity – A gimmick that needs some work to function

It lists issues on the page, but it only tells you there is a problem, not where precisely it occurs. The text web part from earlier contains white text on a white background. The assistant labels that “Hard-to-read text contrast” and highlights the entire web part: no element, no ratio, no fix.

It gets better. Right above the issue list, the assistant shows a green checkmark: “Looks good. No issues found!” Two lines below that, it lists the issues it just said did not exist.

CSS Overview gives you the element, the contrast ratio, the success criteria, and a click to highlight the exact spot on the page. The Accessibility Assistant gives you a checkbox and a contradiction.

This is no longer just a quality argument

The European Accessibility Act has been in force since June 28, 2025. It applies to any business offering digital products or services in the EU, regardless of its headquarters. The referenced standard is EN 301 549, which maps to WCAG 2.1 Level AA. This post covers the same contrast ratios.

SharePoint is a SaaS product. Microsoft is the service provider. The EAA applies to all cloud software and web applications that EU citizens can access, including B2B platforms where employees are the end users. Microsoft acknowledges this. They publish Accessibility Conformance Reports for SharePoint against EN 301 549.

Those reports tell a selective story. Several EN 301 549 criteria are marked “Not Applicable” rather than met. WCAG criteria marked “Partially Supports” cascade into non-conformance across multiple EN 301 549 chapters. Classic SharePoint, SharePoint Lists, and the Stream web part are excluded entirely. And any SPFx customization voids the conformance statement.

A default Communication site on a teal theme ships with no contrast failures.

Existing service contracts agreed before June 2025 have a transition period until June 2030. New themes, new sites, and new customizations built after that date do not. Every custom theme you apply today is a new decision.

The moment you pick a color from the rich text editor, hardcode a value, or override a CSS variable, every additional failure is on you. Brand Center will not warn you—a 30-second CSS Overview check will.

SharePoint already has accessibility debt. Do not ship more on top of it.

Also to check

FIX Color Contrast – Accessibility in Web & UI Design – shows you more important insights on color contrast
Accessible Colors in Microsoft List Formatting
Mythbusting: Image Accessibility in SharePoint