Skip to content

Implement dynamic APCA contrast calculation for primary color pair - #26

Open
google-labs-jules[bot] wants to merge 1 commit into
mainfrom
jules/fix-apca-contrast-logging-js1-73bf924d-5bf5-4e71-83da-7b7665a3293a
Open

google-labs-jules[bot] wants to merge 1 commit into
mainfrom
jules/fix-apca-contrast-logging-js1-73bf924d-5bf5-4e71-83da-7b7665a3293a

Conversation

@google-labs-jules

Copy link
Copy Markdown
Contributor

Why

The design simulator previously logged a static compliance success message for APCA contrast checks rather than executing actual calculation logic. While a prior fix attempted to replace this static log, it introduced a bug by using the document's global minLightness and maxLightness values. This meant that changing the primary color's lightness didn't accurately reflect in the contrast report unless they happened to be the absolute limits of the entire page.

To ensure high-integrity accessibility audits, we need to evaluate the actual primary foreground and background color pair dynamically.

What

We have updated the design simulator to target and parse specific design system tokens, providing accurate perceptual contrast metrics without impacting other systems.

  • Targeted Token Extraction: Introduced parsing logic in design-simulator.js to scan cssText and htmlContent for --color-primary and --color-background variables defined with OKLCH values.
  • Dynamic APCA Evaluation: The contrast calculation now directly uses the L (lightness) channel from the parsed primary and background pair.
  • Safe Fallbacks: If the specific primary variables are missing, the calculator falls back to the global overall minimum and maximum lightness values to prevent runtime crashes.
  • Cognitive Metrics Integration: Replaced the legacy static success strings in the Cognitive Metrics Report with the real-time calculated numerical APCA contrast score.

Constraints Addressed

  • No Side-Effects: The computed contrast result is strictly used for logging/auditing and has no influence on the final Taste Score calculation.
  • No External Dependencies: The implementation relies purely on the existing internal calculation utility and native parsing logic.
  • Scope Limiting: Auditing remains isolated to the primary pair (no recursive element scanning).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants