Found while an accessibility review looked over a story map rendered by @windyroad/itil in an adopter repo, against story-map.css as vendored.
The finding
story-map.css sets link colour and nothing else:
a { color: var(--focus); }
The string text-decoration does not appear anywhere in the file. Links are underlined only because nothing switched the browser default off. That inheritance is load-bearing, because colour alone would not carry the distinction:
| Theme |
Link |
Body text |
Ratio |
| Light |
#0b3a66 |
#1a1a1a |
1.50:1 |
| Dark |
#97c6f5 |
#f2f3f5 |
1.62:1 |
SC 1.4.1 (Use of Color) needs 3:1 between link text and surrounding text when colour is the only differentiator. Both are well under it.
Why it is worth fixing even though it currently passes
It passes by inheritance, not by declaration. A CSS reset, a Preflight-style normalisation, or any future rule setting text-decoration: none on anchors turns a silent inheritance into a real 1.4.1 failure, with no local declaration to point at when someone goes looking for the cause.
Suggested fix
a { color: var(--focus); text-decoration: underline; }
Making the underline explicit costs nothing visually today and removes the dependency on a default.
Context
This is the same class as the #ccc slice border at 1.61:1 against white that was raised previously: a value that reads fine until the thing holding it up moves.
Adopters cannot fix either locally. The stylesheet is vendored and guarded by a byte-identity test, so a local edit either fails the test or gets overwritten on the next render.
Reported from https://github.com/mountain-pass/addressr. I can open a PR for this if you would rather review a diff than a description.
Found while an accessibility review looked over a story map rendered by
@windyroad/itilin an adopter repo, againststory-map.cssas vendored.The finding
story-map.csssets link colour and nothing else:The string
text-decorationdoes not appear anywhere in the file. Links are underlined only because nothing switched the browser default off. That inheritance is load-bearing, because colour alone would not carry the distinction:#0b3a66#1a1a1a#97c6f5#f2f3f5SC 1.4.1 (Use of Color) needs 3:1 between link text and surrounding text when colour is the only differentiator. Both are well under it.
Why it is worth fixing even though it currently passes
It passes by inheritance, not by declaration. A CSS reset, a Preflight-style normalisation, or any future rule setting
text-decoration: noneon anchors turns a silent inheritance into a real 1.4.1 failure, with no local declaration to point at when someone goes looking for the cause.Suggested fix
Making the underline explicit costs nothing visually today and removes the dependency on a default.
Context
This is the same class as the
#cccslice border at 1.61:1 against white that was raised previously: a value that reads fine until the thing holding it up moves.Adopters cannot fix either locally. The stylesheet is vendored and guarded by a byte-identity test, so a local edit either fails the test or gets overwritten on the next render.
Reported from https://github.com/mountain-pass/addressr. I can open a PR for this if you would rather review a diff than a description.