040: CSS Accessibility, Performance, and Compatibility

Learning outcomes

By the end, you can audit CSS for keyboard focus, contrast, reflow, motion, forced colors, and touch; recognize expensive visual/layout patterns; reduce blocking/unused CSS concerns; use progressive enhancement and feature queries; and test compatibility without filling stylesheets with unnecessary hacks.

Prerequisites and retrieval

Retrieve the HTML accessibility lesson, 021 color, 022 typography, 030 responsive design, 031 media queries, and 036 motion.

Accessibility: CSS can help or harm semantics

CSS does not replace semantic HTML, but it strongly affects whether semantic controls are usable.

Focus visibility

css
:where(a, button, input, select, textarea):focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 3px;
}

Avoid:

css
*:focus {
  outline: none;
}

unless you provide an equivalent visible focus treatment.

Contrast and state

A control needs contrast in all states:

css
.button {
  color: white;
  background: #2563eb;
}

.button:hover {
  background: #1d4ed8;
}

.button:disabled {
  color: #475569;
  background: #e2e8f0;
}

Test text contrast, non-text UI boundaries where required, focus indicators, and error states.

Color must not be the only cue:

css
.error {
  color: #b91c1c;
  border-inline-start: 4px solid currentColor;
}

.error::before {
  content: "Error: ";
  font-weight: 700;
}

Better still, include the word “Error” in HTML if it is essential information.

Reflow and zoom

Avoid fixed-height text containers:

css
/* fragile */
.card {
  height: 180px;
  overflow: hidden;
}

Prefer content-driven size:

css
.card {
  min-block-size: 11rem;
}

Test at 200% zoom and narrow widths.

Touch targets

Do not rely only on tiny text/icon dimensions:

css
.icon-button {
  min-inline-size: 2.75rem;
  min-block-size: 2.75rem;
  display: inline-grid;
  place-items: center;
}

Actual target guidance depends on the standard/design requirement in use, but generous hit areas improve usability.

Motion

css
@media (prefers-reduced-motion: reduce) {
  .decorative-motion {
    animation: none;
    transition: none;
  }
}

Keep essential state feedback understandable.

Color scheme and forced colors

css
:root {
  color-scheme: light dark;
}

For Windows/high-contrast forced colors, browser/system colors may replace authored colors. Avoid decorative CSS that becomes the only visible boundary.

Example targeted enhancement:

css
@media (forced-colors: active) {
  .button {
    border: 1px solid ButtonText;
  }
}

Use system colors when specifically adapting to forced-color mode.

Performance mental model

CSS affects:

download/parse cost;
style calculation;
layout;
paint;
compositing.

Do not optimize by myth. Measure.

Selector complexity

Browsers are fast, but extremely broad/repeated relational selectors can increase matching work and maintenance cost.

Prefer clear component selectors:

css
.order-card__total {}

over remote dependency chains:

css
#app main .orders section article.order div.footer span.total {}

The main benefit is maintainability; performance is a secondary bonus.

Layout and paint

Repeated layout changes can become expensive when JavaScript reads/writes geometry, but CSS alone can also trigger costly rendering with large effects.

Potential hotspots:

huge blurred shadows;
filter/backdrop-filter over large regions;
very large fixed backgrounds;
animating layout dimensions on complex pages;
thousands of DOM elements with complex styling.

Critical and unused CSS concepts

Large applications may split CSS so that a route does not load every style in the entire product. Build tooling can help extract/minify code.

Do not hand-inline a huge “critical CSS” block without measurement and invalidation strategy. Performance work should use real metrics.

Font performance

css
@font-face {
  font-family: "SiteSans";
  src: url("/fonts/site-sans.woff2") format("woff2");
  font-display: swap;
}

Limit unnecessary font variants. Test fallback layout shift.

Image/background performance

CSS backgrounds do not get HTML responsive-image selection features like srcset in the same way. Use <picture>/img when the image is content and responsive source selection matters.

Progressive enhancement and `@supports`

css
.card-grid {
  display: flex;
  flex-wrap: wrap;
}

@supports (display: grid) {
  .card-grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
  }
}

Only write fallbacks that your browser support matrix actually needs.

Negated feature query:

css
@supports not (container-type: inline-size) {
  .component {
    /* fallback only if genuinely needed */
  }
}

Compatibility workflow

Define target browsers from actual users/product requirements.
Check current support for features you plan to use.
Prefer progressive enhancement.
Use automated prefixing/tooling when appropriate rather than hand-copying stale vendor-prefix recipes.
Test actual browsers/devices for critical flows.
Document intentional unsupported enhancements.

Worked example: accessible/performance-safe card hover

css
.card {
  border: 1px solid #cbd5e1;
  transition:
    transform 140ms ease,
    box-shadow 140ms ease;
}

@media (hover: hover) and (pointer: fine) {
  .card:hover {
    transform: translateY(-2px);
    box-shadow: 0 6px 18px rgb(15 23 42 / 0.12);
  }
}

.card:focus-within {
  outline: 3px solid #2563eb;
  outline-offset: 3px;
}

@media (prefers-reduced-motion: reduce) {
  .card {
    transition: none;
  }

  .card:hover {
    transform: none;
  }
}

Hover is optional, focus remains visible, motion can be reduced.

Deep dive: reflow, user overrides, and system colors

A page should remain usable when users enlarge text, zoom the page, or apply system accessibility settings.

Avoid fixed-height text containers:

css
/* fragile */
.alert {
  height: 3rem;
  overflow: hidden;
}

Prefer content-driven block size:

css
.alert {
  min-block-size: 3rem;
  padding: 0.75rem 1rem;
}

Users may override text spacing. Test increased line height, letter spacing, word spacing, and paragraph spacing without clipping.

Forced colors

css
@media (forced-colors: active) {
  .button {
    border: 1px solid ButtonText;
  }
}

Do not fight system colors unnecessarily. Native controls and system color keywords often adapt better than decorative custom paint.

Contrast preferences

css
@media (prefers-contrast: more) {
  .muted {
    color: CanvasText;
  }
}

Treat preference queries as enhancements; do not make baseline content low-contrast.

Deep dive: rendering performance

CSS performance problems often come from the total rendering workload rather than one “slow property.”

Potential costs include:

large DOM + broad selectors;
layout triggered by size/geometry changes;
large paint areas;
blur/filter/backdrop-filter effects;
huge offscreen content;
web-font delays and layout shifts;
unused blocking CSS.

`content-visibility`

For large offscreen sections, content-visibility: auto can allow the browser to skip some rendering work until content is needed.

css
.long-report-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

Use it only after measuring a real benefit. Skipped rendering can affect APIs that expect layout information, and accessibility/fragment navigation behavior must be tested.

Containment

css
.widget {
  contain: layout paint;
}

Containment can isolate work, but it also changes layout/paint relationships. Container queries already establish some containment behavior. Do not add contain as a generic optimization.

`will-change`

css
.drawer {
  will-change: transform;
}

will-change is a temporary hint, not a performance badge. Overusing it can consume extra memory and create unnecessary compositing layers. Add it only when profiling shows a repeatedly animated property benefits.

Font performance

Good typography and performance meet at font loading.

Consider:

limiting families/weights;
subsetting when appropriate;
font-display behavior;
fallback metric differences;
preload only for genuinely critical fonts;
avoiding a chain of CSS imports for fonts.

A visually perfect custom font is not a success if text remains invisible or layout shifts severely.

Measurement workflow

Use browser DevTools to answer:

Is the problem loading, layout, paint, compositing, or JavaScript?
Which element/property is involved?
Does the problem reproduce with throttling?
Does the proposed change improve the measured result?
Did the optimization introduce accessibility or visual regressions?

Performance work should produce evidence, not folklore.

CSS audit checklist

Accessibility

visible keyboard focus;
no hover-only essential controls;
contrast checked in all states;
no color-only meaning;
content reflows at zoom;
text is not clipped by fixed heights;
reduced-motion respected;
controls remain usable in forced colors.

Performance

no unused giant image effects;
font set is intentional;
CSS bundles are route/component appropriate for application scale;
no accidental expensive animation;
selector ownership is clear;
repeated visual effects are measured on target devices.

Compatibility

support matrix documented;
modern features checked before production use;
fallback is usable;
feature detection used where appropriate;
no stale vendor-prefix cargo cult.

Practice set

Audit an existing page at 200% zoom.
Navigate entirely by keyboard.
Enable reduced motion and forced colors.
Throttle network and observe font/image fallback.
Remove one expensive blur/shadow and compare rendering.
Add a feature query around a progressive enhancement.

Recap

CSS quality includes more than appearance. Accessible CSS preserves focus, contrast, reflow, preferences, and operability. Performant CSS avoids unnecessary work. Compatible CSS starts from a support policy and progressive enhancement rather than fear of modern features.

Official references

MDN: content-visibility — https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility
MDN: CSS containment — https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment
WCAG 2.2 — https://www.w3.org/TR/WCAG22/
MDN: CSS and JavaScript accessibility best practices — https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Accessibility/CSS_and_JavaScript
web.dev: CSS performance — https://web.dev/learn/performance/
MDN: @supports — https://developer.mozilla.org/en-US/docs/Web/CSS/@supports

040: CSS Accessibility, Performance, and Compatibility

Learning outcomes

Prerequisites and retrieval

Accessibility: CSS can help or harm semantics

Focus visibility

Contrast and state

Reflow and zoom

Touch targets

Motion

Color scheme and forced colors

Performance mental model

Selector complexity

Layout and paint

Critical and unused CSS concepts

Font performance

Image/background performance

Progressive enhancement and @supports

Compatibility workflow

Worked example: accessible/performance-safe card hover

Deep dive: reflow, user overrides, and system colors

Forced colors

Contrast preferences

Deep dive: rendering performance

content-visibility

Containment

will-change

Font performance

Measurement workflow

CSS audit checklist

Accessibility

Performance

Compatibility

Practice set

Recap

Official references

Progressive enhancement and `@supports`

`content-visibility`

`will-change`