a11y.md flagged --yj-text-tertiary on --yj-bg-surface as 'borderline
(~4.1:1) but that needs a real measurement', and plan 007 parked it as
'worth measuring before planning'. Measured, against the rendered app
and then across all three background ramps: it failed AA in nine of
twelve text/surface combinations, as low as 2.31:1 on dark's overlay
and 2.55:1 on light's -- the app's most-used secondary text colour,
failing on every view. Not borderline. 110 failing nodes across twelve
views, now 0 of 659.
Three separate mechanisms, and only the first is the finding:
- The ramps. Tertiary is raised per ramp (#a6a6a6 dark, #949494 darker,
#5c636a light), sized to the lightest surface it actually sits on and
keeping its hue. Sizing it to bgOverlay too would need a grey lighter
than secondary, so bgOverlay is documented as not a text surface and
the one component that put text there uses primary.
- The avatar generator. hsl(hue, 45%, 35%) behind white initials failed
for 35 of the 360 hues -- the yellow-green band -- so which artists
were unreadable depended on how their names hashed. The two a sweep
found were not the finding. 32% clears every hue.
- Jobs' local #ff6b6b, at 4.15:1 on elevated.
Pinned by a unit test over the palette table rather than a DOM sweep:
the ramps are pure data, and checking only what happens to be on screen
is exactly how the light ramp went unexamined. Note that make ui-visual
cannot see any of this -- the component tier renders the fallbacks,
because theme-store sets :root only in the real app.
logan
533c084f8a