Glassmorphism Text Contrast: How Opaque the Glass Must Be

Glassmorphism Text Contrast: How Opaque the Glass Must Be

WCAG 1.4.3 asks for 4.5:1 between text and its background (3:1 for large text), and on frosted glass that background changes from one corner of the panel to the next. Tested against the worst backdrop, a black glass panel under white text needs 54% opacity to clear 4.5:1 over any image at all. White glass under white text never helps: the panel can only lighten the backdrop, so the text does no better than it would on the bare image.

A common frosted-glass recipe, such as the white 20% panel in MDN's backdrop-filter demo (rgb(255 255 255 / 0.2)), shows how little a single sample proves once white text goes on it. Over the indigo end of a sunset hero (#2b1b5a) that card measures 8.00:1 for white text. Over the amber end (#ffd27a) of the same hero it measures 1.33:1. Both numbers are correct, and only the lower one describes what a reader sees after the image is cropped, scrolled or swapped for another.

The 1.4.3 text, its Understanding page and Technique F83 give no test for a panel like this, so the method used throughout is labelled as this article's own: the worst-case backdrop test. Take the lightest colour the panel can sit over if the text is light, or the darkest if the text is dark. Composite the panel's colour and alpha over that colour. Compute the WCAG ratio for the result.

What 1.4.3 requires, and what it leaves open

The text of Success Criterion 1.4.3 Contrast (Minimum), Level AA, in the WCAG 2.2 Recommendation of 12 December 2024, reads in full: "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement. Logotypes: Text that is part of a logo or brand name has no contrast requirement."

None of the three exceptions covers a headline, a label or an active button caption on glass. The "significant other visual content" exception concerns pictures that contain text, such as a street sign in a photograph; W3C's Understanding document says it separates such pictures from "images of text that are done to replace text in order to get a particular look". Text you place over a photograph is not text inside a picture.

The Recommendation defines large-scale as "at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts". The Understanding document converts with 1 pt = 1.333 px and calls the two sizes "approximately 18.5px and 24px". The exact 4/3 conversion gives 18.67 px for 14 pt, so a bold 18.5 px heading falls just short of the line on the exact figure; treat borderline sizes as body text. Fonts with extraordinarily thin strokes or unusual features are harder to read at low contrast, and the definition's first note says so.

The ratio itself is (L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter colour and L2 of the darker. Relative luminance is 0.2126 R + 0.7152 G + 0.0722 B, with each 8-bit channel divided by 255 and then linearised: divide by 12.92 when the value is 0.04045 or less, otherwise raise ((value + 0.055) / 1.055) to the power 2.4. White against black gives 21:1. Understanding 1.4.3 adds that the 3:1 and 4.5:1 figures are thresholds, and that "the computed values should not be rounded (e.g., 4.499:1 would not meet the 4.5:1 threshold)". Every pass and fail in this article uses unrounded ratios for that reason.

The gap shows up in the definition of contrast ratio. Its Note 3 says: "For the purpose of Success Criteria 1.4.3 and 1.4.6, contrast is measured with respect to the specified background over which the text is rendered in normal usage. If no background color is specified, then white is assumed." A glass card has two specified colours, the panel's rgba value and whatever sits behind it, and the colour a reader sees exists in neither declaration. In the 1.4.3 text and its glossary entries, in the Understanding page for 1.4.3 and in Technique F83, the words gradient, translucent, transparent, opacity and blur do not appear. None of them gives a rule for text on a translucent layer.

The closest W3C text is Technique F83, a failure technique for background images. Its quick check compares the text with "the area of the image that is darkest (for dark text) or lightest (for light text)", and continues: "If the contrast meets or exceeds the specified contrast, then there is no failure. If the Quickcheck is false, then check to see if the background behind each letter has sufficient contrast with the letter." Its expected result is that "if Quickcheck is false and #2 is false as well then this failure condition applies and the content fails the contrast Success Criterion." W3C labels techniques as examples of ways to meet WCAG that are not required, so F83 is guidance and not part of the criterion.

The worst-case backdrop test borrows F83's choice of extreme and adds one step that F83 does not contain: it composites the panel over that extreme before measuring. The compositing, the percentages and every verdict in the tables below are this article's own calculations. A panel that fails the worst-case test has failed F83's quick check, which is a prompt to look letter by letter or to raise the opacity. It is not by itself a finding of non-conformance. Raising the opacity is the sturdier answer, because the letter-by-letter route passes only while the photo, the crop, the scroll position and the breakpoint stay as they were on the day someone tested.

Compositing the panel in three steps

CSS Color Module Level 4, section 10.13, says implementations "must handle alpha according to the rules in Section 5.1 Simple alpha compositing" of the Compositing and Blending specification. That section gives the formula co = Cs × αs + Cb × αb × (1 − αs), where Cs and αs are the colour and alpha of the element being drawn, Cb and αb belong to what is behind it, and all values run from 0 to 1. Behind a hero image the backdrop is opaque, so αb is 1, the result is fully opaque, and each channel of it is the panel channel times its alpha plus the backdrop channel times one minus that alpha.

One assumption sits under every number in this article. The Compositing specification gives the formula but does not name the colour space in which it runs. The tables blend the stored 8-bit sRGB channel values directly and round the result to whole 8-bit values, because that is what a screenshot eyedropper reports. The assumption matters: blending 50% black over #ffd27a in linear light would give a much lighter patch and a ratio of 2.67:1, where blending the stored values gives 5.24:1. A one-minute check removes the doubt for your own browser. Black at 54% over pure white should sample as #757575, since 255 × 0.46 = 117.3, which rounds to 117, which is 75 in hex. If your eyedropper reads something else, trust the eyedropper and adjust the method.

The three steps, using a black panel at 46% over the amber end of the hero (#ffd27a):

1. Take the backdrop colour at the worst point. For white text that is the lightest area the panel will ever cover, here #ffd27a, which is 255, 210, 122.
2. Composite each channel. Multiply the backdrop channel by 0.54 (the share that shows through a 46% black panel) and round. The result is 138, 113, 66, or #8a7142.
3. Convert to relative luminance and take the ratio. Linearise the three channels, weight them and add. Compare with the text colour.

At 45% the composite is #8c7443, luminance 0.18471, and the ratio is 4.4735:1, which fails. At 46% it is 4.645:1, which passes. That is how the 46 in the minimum-opacity table below is found: step the opacity down one whole percent at a time until the unrounded ratio drops under 4.5. Over pure white the same procedure gives 53% at 4.4151:1 (fail, #787878) and 54% at 4.6075:1 (pass, #757575).

One frosted card, both ends of the backdrop

The next table runs the arithmetic on a hypothetical hero whose lightest colour is amber (#ffd27a) and whose darkest is indigo (#2b1b5a). Both are chosen inputs, not measurements of any real photo. Each row gives the composited panel colour at each end and the contrast ratio of two text colours: white and a near-black, #111111.

The rows follow a pattern. The text colour that contrasts with the panel fails at one end of the backdrop while the panel is thin: white text on black glass up to 40%, #111111 text on white glass up to 40%. From 50% on black and 60% on white, it passes at both ends. The text colour that matches the panel fails at one end in every row. On the white panel, white text scores 11.13:1 at the indigo end when the panel is thin (10%) and collapses toward 1.50:1 as the panel thickens, while at the amber end it is 1.37:1 at 10% and only falls from there. Dark text on the same white panel behaves the opposite way: easy over amber, and only at 40% opacity does it approach 4.5:1 over indigo (4.49:1, a fail by 0.01).

The reason is mechanical. A translucent panel drags the backdrop toward its own colour. A white panel raises the backdrop's luminance at every point, which helps text that is dark and hurts text that is light. A black panel does the reverse. Because contrast with light text falls as the background gets lighter, the lightest part of the backdrop is where light text fails first, and the darkest part is where dark text fails first. A scan of every whole-percent opacity from 0 to 100, for each text and panel pairing and each of the four backdrops used below, found no case where the other end was the worse one.

The black rows carry a warning for dark-themed glass. A black 40% panel gives white text 17.93:1 at the indigo end and only 3.86:1 at the amber end, which is enough for large text and short of body text. A mock-up judged over the dark half of the wallpaper looks safe while the bright half fails.

Minimum panel opacity for 4.5:1 and 3:1

The table below answers the practical question: how opaque must the panel be? Each cell gives the smallest whole-percent opacity at which the unrounded ratio reaches 4.5:1, then the same for 3:1, at the worst end of the backdrop for that text colour. S1 is the backdrop-independent floor: the lightest possible colour is #ffffff and the darkest is #000000, so the S1 numbers hold for any image, any gradient and any video frame, and with or without a backdrop-filter, since a filter's output cannot be lighter than white or darker than black. S2 to S4 are illustrations with chosen inputs.

Each cell reads "opacity for 4.5:1 / opacity for 3:1". "None" means no opacity from 0% to 100% reaches the threshold. White text is tested against the lightest end and #111111 text against the darkest, so the worst end differs from column to column. The bare backdrop, with no panel at all, already scores 3.09:1 for white text at the lightest end of S3 and 8.93:1 for #111111 text at the darkest end of S4, which is why the 3:1 cells in S3's white-text columns, and both cells for S4's dark text, say 0%.

Four findings come out of the table.

The floor is about half. Over pure white, black glass needs 54% for body text and 42% for large text. Anything under those numbers relies on the actual image being darker than white at the spot where the text sits, which is exactly the thing the worst-case test refuses to assume. Read the S1 row as the answer to "what can I ship without ever opening the final photo".

A coloured panel costs a few points. Navy #0f172a needs 59% where black needs 54% over white, and 51% against 46% over the amber hero, because navy is lighter than black and so darkens the backdrop less. For white text, any panel colour lighter than black needs more opacity than black does, never less.

Dark-on-white and light-on-dark are not mirror images. #111111 text on a white panel needs 49% over pure black, against 54% for white text on a black panel over pure white, so a figure from one case cannot be carried to the other. Over the dark photo S3, white glass for dark text needs 45%, while black glass for white text needs only 20%. Choose the glass colour to match the backdrop's range: where the image's lightest area is only mid-grey, as in S3, black glass with white text starts close to a pass.

White on white is not a tuning problem. A white panel can only lighten what is behind it, so white text over it never scores better than the bare backdrop does (1.42:1 at the amber end of S2, 1.08:1 at the lightest pastel of S4), and at 100% opacity it is 1:1. Over the lightest regions in the table no opacity gets white text on a white panel to 4.5:1. For 3:1 only S3 qualifies, and only with no panel at all. The fix is a different text colour or a different panel colour, never a higher alpha.

Whole percentages are rounded up, so a cell can pass by very little: the S4 entry for black glass, 52%, scores 4.5003:1. Treat the table as the floor and add a few points of headroom, because a different eyedropper reading of the same photo, a slightly warmer screen profile or a re-exported image can move the lightest sample.

For large text the second figure in each cell applies. That means at least 18 pt regular, which is 24 px, or 14 pt bold, which W3C approximates as 18.5 px. A card with a 28 px headline and 16 px body copy needs the 4.5:1 opacity for the body copy, and the panel is one surface, so the body copy decides.

Semi-transparent text on glass

Frosted-glass designs often soften secondary text with an alpha, such as rgba(255,255,255,0.7) for captions. That text is composited over the panel, so its effective colour is a mix of white and the panel colour, and the ratio is measured on that mix.

Take the black panel at 46% over the amber end, which gives the panel colour #8a7142 and, for fully opaque white text, 4.645:1. Set the text to 70% white and its effective colour becomes #dcd4c6. The ratio against #8a7142 drops to 3.157:1, a fail for body text. To pass 4.5:1 with 70% white text the panel has to rise to 60% over the amber end, or 66% over pure white. The next table gives the minimum black-panel opacity for several text alphas.

Every step of text transparency has to be paid for with panel opacity. The cheaper route is to keep text opaque and express hierarchy with size and weight, or to use a solid lighter grey for captions that is verified against the composited panel colour rather than against the page.

The same logic applies to anything else drawn at partial alpha on glass: placeholder text, labels that look disabled but are active (only genuinely inactive components are exempt), and icon strokes. Understanding 1.4.3 says the criterion applies to placeholder text and to text that appears on hover or keyboard focus. Test the hover and focus colours of a glass button as separate pairs.

What backdrop-filter changes, and what it does not

The Filter Effects Module Level 2 draft describes how an element with backdrop-filter is drawn. The renderer copies the backdrop root image, applies the filter operations to the copy, clips the result to the element's border box including its border-radius, and only then draws the element itself, with its background, border and children, on top. The filter runs first and the panel colour is composited afterwards. So the order in the arithmetic above is right: backdrop, then filter, then the panel's alpha over the filtered result. The same draft notes that the effect is invisible unless part of the element is semi-transparent, and that any opacity applied to the element is applied to the filtered backdrop as well.

That last note has a contrast consequence. Fading a glass card with opacity: 0.9 instead of putting alpha in its background colour fades the text too, so the text colour is no longer the colour you tested. Put the translucency in the background (rgb(0 0 0 / 0.58)) and leave the element's opacity at 1.

Blur does not move the bounds for light text. Blur averages neighbouring pixels. The Filter Effects draft says filter functions operate in the sRGB colour space, so the average is taken over the stored channel values. Relative luminance is a convex function of those values, so the luminance of an average can never exceed the average of the luminances, and a blurred pixel is never lighter than the lightest pixel that went into it. For light text the unblurred lightest point is therefore a safe input. This is the article's own reasoning, not a statement from a standard. It covers blur only. Filters that rescale values, such as brightness() above 100% or contrast(), can push past the original lightest point, so sample the filtered result for those.

For dark text, blur can go the wrong way. Average pure red (#ff0000, luminance 0.2126) and pure green (#00ff00, luminance 0.7152) 50/50 and you get channel values of 127.5, 127.5 and 0, which display as #808000. The luminance is 0.1986 before rounding to 8 bits and 0.2003 for #808000 itself, either way below red's. A blurred region can be darker than any pixel in the source. If the text is dark, sample the filtered result, not the original image.

Blur is a texture tool, not a contrast tool. The worst-case numbers in the tables do not depend on the blur radius, so a larger radius earns no lower opacity. Softening sharp detail behind the letters is a design judgement made here, not a WCAG requirement. Technique F83 does describe what background features do when contrast is poor: "When there is not sufficient contrast between the background image and the text, features of the background image can be confused with the text making it difficult to accurately read the text." F83 ties the problem to insufficient contrast, so contrast is the fix and blur is a supplement. No radius is recommended here, because none of the specifications or MDN pages cited sets one. MDN's examples use blur(10px) as a demonstration value, not as a guideline.

Filters that change brightness do change the numbers. Filter Effects Level 1 defines brightness() as a linear transfer function with the amount as slope, applied per channel, and says filter functions operate in sRGB. So brightness(0.8) multiplies each stored channel by 0.8, and because the filter runs before the panel is drawn, it lowers the lightest backdrop the panel has to cover. The next table applies it to the S1 and S2 lightest colours with a black panel and white text.

A darkening filter is a legitimate lever: backdrop-filter: blur(var(--glass-blur)) brightness(0.7) lets a black panel over a bright hero drop from 46% to 22% for body text. But the saving comes from altering the picture behind the glass, so the lightest point to test is the filtered one, and the whole effect disappears in any browser that does not apply the filter. Brightening a dark backdrop for dark text is much weaker: at 150% the S2 darkest end rises from #2b1b5a to #412987 and the white panel needed for #111111 text only drops from 41% to 35%.

The cost of the filter itself is a separate question. Large blurred areas can be expensive to paint, which the web animation performance guide covers in the context of animation traces.

Backdrop roots: when the glass looks at the wrong thing

A backdrop-filter does not see the whole page. MDN states that the property "applies filter effects to the pixels painted behind an element, up to the nearest ancestor that is a backdrop root". Per MDN, these elements are backdrop roots:

• the root element (<html>)
• an element with a filter value other than none
• an element with an opacity value less than 1
• an element with a mask, mask-image, mask-border or clip-path value other than none
• an element with a backdrop-filter value other than none
• an element with a mix-blend-mode value other than normal
• an element with will-change set to any of those properties

MDN's worked consequence is this: "if a parent element has opacity: 0.9, it becomes a backdrop root and any child's backdrop-filter will only blur the content between that parent and the child - not the content behind the parent." It calls this "a common source of confusion when backdrop-filter appears to have no visible effect despite being correctly applied."

The Filter Effects Level 2 draft lists the same triggers and adds what does not create a root: elements with z-index, fixed or sticky positioning, or transforms. A wrapper that only animates with a transform is safe; a wrapper that fades with opacity is not. The draft also says elements with a computed backdrop-filter other than none create a stacking context and a containing block for absolute and fixed descendants, which can shift layout when you add the property to an existing component. And it records that the specification "does not yet have Working Group consensus, specifically on the definition of Backdrop Root", with an Editor's Draft dated 2 October 2026. Browsers have shipped the behaviour, but the exact list is still open to change.

For contrast, the root matters in two ways. First, a glass card nested in a faded wrapper blurs only what is painted inside the wrapper, which may be nothing but the wrapper's own background, and the panel is drawn inside the wrapper's group before the group's opacity is applied. The colour that reaches the screen is then a mix of two layers that no single-layer table describes, so sample the rendered pixel. Second, every glass element is itself a root, because MDN's list includes any element with a backdrop-filter. A glass button inside a glass card sits over the card's composited colour, so test the button's panel against the card's result rather than against the page photo.

Browser support, from the caniuse dataset

The caniuse database stores each feature as a JSON file in the Fyrd/caniuse repository. Its data for CSS Backdrop Filter was last updated on 29 October 2026 and reports 97.08% of global usage as supporting the feature. That total counts browser versions that need the -webkit- prefix. Computing it from the dataset's per-version usage figures, 1.69 percentage points of the 97.08 are Safari and iOS Safari versions that support only the prefixed property (0.69 desktop Safari, 1.00 iOS Safari). Another 0.41 points are marked unsupported, mostly Internet Explorer 11 (0.21) and QQ Browser for Android (0.13). The dataset assigns usage to 97.49% of global traffic in all.

MDN's page for the property carries a Baseline 2024 badge with the label "Newly available", and the explanation "Since September 2024, this feature works across the latest devices and browser versions. This feature might not work in older devices or browsers." For this article's numbers that has two consequences. About 1.7% of usage needs -webkit-backdrop-filter written alongside the standard property. And 0.41 points of usage sit on browsers that lack the property altogether, out of the 97.49% the dataset classifies, so a no-blur fallback serves a small audience and not an empty one.

The second consequence is the one that matters for contrast. Without the filter, the panel is the same colour over the same backdrop. The worst-case numbers hold, because they never depended on blur. What changes is that sharp detail sits behind the letters, which F83 describes as a hazard when contrast is poor. The contrast floor stays the same; this article's own design judgement is to put the panel alpha above that floor in the no-blur case:

.glass {
  color: #fff;
  background: rgb(0 0 0 / 0.80);              /* no blur available: heavier panel */
}
@supports ((-webkit-backdrop-filter: blur(1px)) or (backdrop-filter: blur(1px))) {
  .glass {
    background: rgb(0 0 0 / 0.58);            /* 54% floor over any image + 4 points */
    -webkit-backdrop-filter: blur(var(--glass-blur));
    backdrop-filter: blur(var(--glass-blur));
  }
}

The 0.80 in the base rule is a judgement call about busy images, not a computed value; the contrast floor is the 54% from the table. MDN lists @supports as Baseline Widely available since September 2015 and documents the not, and and or operators used above. The prefixed query is there because Safari before 18 supports only the prefixed property.

Reduced transparency: the media query and how far it reaches

The Media Queries Level 5 working draft (published version of 19 February 2026; the editor's copy is headed 19 October 2026) defines prefers-reduced-transparency as a feature "used to detect if the user has requested the system minimize the amount of transparent or translucent layer effects it uses". It takes two values: no-preference and reduce. MDN adds: "Switching on such a setting can help improve contrast and readability for some users." It lists where operating systems expose it: Windows 10 and 11 under Settings, Personalization, Colors, Transparency effects; macOS under System Settings, Accessibility, Display, Reduce transparency; iOS under Settings, Accessibility, Display & Text Size, Reduce Transparency.

MDN's page tells you the media feature is not safe to depend on: it is marked "Limited availability", "not Baseline because it does not work in some of the most widely-used browsers", and "Experimental". MDN builds that table from its browser-compat-data project (query css.at-rules.media.prefers-reduced-transparency), and the project's data records:

The record carries no platform note for Chrome. Whether a given browser reads a given operating-system setting, and on which platform, is not visible in that data, so the only dependable test is to switch the setting on and look.

Two design rules follow. First, the default panel must pass without the query. Apple's Reduce Transparency setting will not trigger it in Safari, since Safari does not implement the feature, so a Safari user who turned the system setting on gets whatever the base CSS draws. Treat prefers-reduced-transparency as an upgrade for browsers that support it, never as the thing that makes the panel accessible.

Second, when the query matches, make the panel solid. MDN's example changes the element's opacity property, which scales the text along with the panel. Replacing the background with an opaque colour and removing the filter changes only the panel:

@media (prefers-reduced-transparency: reduce) {
  .glass {
    background: rgb(15 23 42);                /* solid: white text is 17.85:1 */
    -webkit-backdrop-filter: none;
    backdrop-filter: none;
  }
}

A solid navy #0f172a with white text scores 17.85:1, and a solid white panel with #111111 text scores 18.88:1, both independent of whatever is behind. Put this block after the base rules so it wins the cascade. Its sibling feature, prefers-contrast, which Media Queries Level 5 defines as detecting "if the user has requested more or less contrast in the page", is the right place to go further for users who ask for more contrast. The dark mode design guide covers the neighbouring prefers-color-scheme query and the contrast targets for dark themes.

A starter token set and an audit routine

The values below carry the S1 floor for light text on black glass, plus four points of headroom. They need no image-specific sampling, which makes them the right default for user-supplied or frequently swapped backgrounds.

For an image you control, the audit takes five steps.

1. List every position. The panel can sit over different parts of the image at each breakpoint, at each scroll offset if it is sticky, and in each state of any carousel behind it. The worst case is the lightest (or darkest) value across all of them.
2. Sample the backdrop without the panel. Hide the glass element and eyedrop the lightest pixel in its footprint at each position, or sample the filtered backdrop if you use brightness() or saturate(). Use the pixel value after any blur has been applied if the text is dark.
3. Run the arithmetic. Use the compositing formula and the WCAG ratio. Any contrast checker that accepts two opaque colours will do once you have the composited hex; the work is in producing that hex.
4. Confirm with the real render. With the panel visible, eyedrop the panel at the worst point and compare it with the computed hex. A mismatch means a backdrop root, an extra opacity somewhere up the tree, or a different compositing space.
5. Re-run when the image changes. Marketing teams swap hero images far more often than they edit components, and the panel tuned for one photograph is the wrong panel for the next.

The accessible color systems guide covers the neighbouring case of plain scrims over photographs, and the APCA versus WCAG contrast guide shows how a second contrast method scores the same pairs, which is worth running on text that lands close to a threshold.

Cases the opacity tables skip

The worst-case backdrop test measures a ratio, and a ratio is not legibility. Text size and weight matter beyond the 18 pt and 14 pt bold thresholds, and Understanding 1.4.3 warns that anti-aliasing can make particularly thin or unusual fonts render "with a much fainter color than the actual text color defined in the underlying CSS". It recommends choosing stronger strokes or aiming above the minimum.

Video and animated backdrops multiply the sampling problem: the lightest frame is the one that counts, so use the S1 row unless you have reviewed every frame. A fixed-position glass header over a long page has a different worst case at every scroll position, which is another reason to use the S1 floor for site chrome.

The tables cover text. The border of a glass card, an icon on it, a focus ring or the edge of an input field fall under other criteria, notably 1.4.11 Non-text Contrast, which has its own thresholds that these tables do not compute. The WCAG 2.2 compliance guide lists the other criteria designers own. The dark-text figures use #111111, a near-black; recompute for your own text colour. The calculation is short: one function that composites, one that linearises, and a loop over whole percentages.

Finally, a contrast ratio from a calculation is not a conformance claim. Whether a given page meets WCAG, or a legal standard that references it, depends on the exact rendered pages and the evaluation method that applies to you. Treat these numbers as a design floor to build and test above.

Glassmorphism contrast questions

Does glassmorphism fail WCAG contrast?

Not by nature, but a white panel with white text fails over light backdrops. White text on a white panel at 10 and 20% opacity scored 1.37:1 and 1.33:1 at the amber end of the example hero, and a white panel under white text reaches 4.5:1 at no opacity. A dark panel with white text can pass, at 54% opacity over any image or less over a known darker one.

What opacity does a glass card need for white text?

At the backdrop-independent floor, a black panel needs 54% for 4.5:1 and 42% for 3:1, and a navy #0f172a panel needs 59% and 46%. Over a known backdrop the figure can be lower: 46% over the amber hero and 20% over the dark photo in the examples above. Add a few points of headroom, because several results pass by under 0.1.

Does blur improve contrast?

The WCAG ratio compares text with its background colour, so blur does not lower the opacity a panel needs. For light text the tables hold, because a blur cannot make the backdrop lighter than its lightest source pixel. For dark text, sample the backdrop after the blur, because a blur can produce a colour darker than any source pixel. Softening detail behind the letters is a design judgement made in this article, not a requirement of F83. A filter that changes brightness is different: brightness(0.7) over amber lets a black panel drop from 46% to 22% for body text, in browsers that apply the filter.

Is backdrop-filter safe to use in 2026?

caniuse reports 97.08% global support for the property, and MDN gives it Baseline 2024 status. Safari and iOS Safari before 18 need the -webkit- prefix, which accounts for 1.69 points of that total, and Firefox before 123 does not support it on systems with an unknown GPU vendor. Write the base panel so the text passes without the filter, and add the blur as an enhancement.

Does prefers-reduced-transparency work in Safari?

According to MDN's browser-compat-data, Safari does not support it, so the setting in macOS or iOS does not change a page's CSS through this query. Chrome records support from 118, and Firefox only behind a preference. Ship a panel that already passes, and use the query to switch to a solid colour where it is available.

Do I have to test every pixel behind the text?

The 1.4.3 text and its Understanding page give no rule for translucent layers. Technique F83 starts with the lightest area for light text, or the darkest for dark text, and goes letter by letter only if that fails. Testing the worst point once, with headroom, is faster and holds when the image changes.

W3C, MDN and caniuse sources

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation 12 December 2024: Success Criterion 1.4.3 text, definitions of contrast ratio (Notes 1 to 6), relative luminance and large scale; checked November 3, 2026.
• W3C, Understanding Success Criterion 1.4.3: Contrast (Minimum), page updated 06 September 2026: point sizes, unrounded thresholds, placeholder and hover text, thin fonts and anti-aliasing; checked November 3, 2026.
• W3C, Technique F83: Failure of Success Criterion 1.4.3 and 1.4.6 due to using background images that do not provide sufficient contrast, updated 09 March 2026: description, quick check and expected results; checked November 3, 2026.
• W3C, Compositing and Blending Level 1, Candidate Recommendation Draft 21 March 2024: section 5.1 simple alpha compositing; checked November 3, 2026.
• W3C, CSS Color Module Level 4, Candidate Recommendation Draft 3 November 2026: section 10.13 simple alpha compositing; checked November 3, 2026.
• W3C CSS Working Group, Filter Effects Module Level 2, Editor's Draft 2 October 2026: backdrop-filter rendering steps, backdrop root and its triggers; checked November 3, 2026.
• W3C CSS Working Group, Filter Effects Module Level 1, Editor's Draft 22 September 2026: brightness() definition and sRGB operation of filter functions; checked November 3, 2026.
• W3C, Media Queries Level 5, Working Draft 19 February 2026 as published, and the editor's copy at drafts.csswg.org headed 19 October 2026; the quoted prefers-reduced-transparency and prefers-contrast sentences are identical in both; checked November 3, 2026.
• MDN Web Docs, backdrop-filter, last modified April 20, 2026: syntax, Baseline 2024 status and backdrop root list; checked November 3, 2026.
• MDN Web Docs, prefers-reduced-transparency, last modified April 20, 2026: status, operating-system settings and example; checked November 3, 2026.
• MDN Web Docs, @supports, last modified September 14, 2026: Baseline status and operators; checked November 3, 2026.
• MDN, browser-compat-data, files css/properties/backdrop-filter.json and css/at-rules/media.json on the main branch: version data for both features; checked November 3, 2026.
• Fyrd, caniuse, features-json/css-backdrop-filter.json and data.json, dataset updated October 29, 2026: global usage and per-version support; checked November 3, 2026.