fix(a11y): zet het contrast van de app zelf in de repo, en repareer drie plekken (#606) #682

Merged
brenno merged 1 commit from fix/donker-thema-contrast-606 into main 2026-07-22 20:25:24 +00:00
Owner

Werkt aan #606. Het issue blijft open — zie Wat er niet in zit.

OciDeck rekent het contrast van jouw dia's na en meldt wat zakt. Dat de app zelf die lat niet haalt is de makkelijkste "physician, heal thyself" die een reviewer kan vinden, en de rekensom kost hem vijf minuten.

Eerst het getal

Zonder meting is de rest een mening. test/app_theme_contrast_test.dart meet elk kleurtoken dat de interface als tekst gebruikt tegen het oppervlak dat de modus werkelijk schildert (AppTheme.paper), in beide modi, met de uitkomst als basislijn — precies stap 1 uit je voorstel.

De ratchet klapt twee kanten op: een nieuw geval erbij faalt, en een geval dat gerepareerd is maar in de lijst blijft staan faalt óók. Zo kan de lijst alleen korter worden.

De meting corrigeert het issue op twee punten.

  • Donker telt 17 tokens onder 4,5:1, niet 21. Het verschil zit in vul- en randkleuren, die de tekstlat niet hoeven te halen; ik heb alleen gemeten wat ergens als tekst- of icoonkleur op het papieren oppervlak landt.
  • Licht is niet in orde. severityHigh (#EA580C) haalt 3,6:1 op wit en severityMedium (#D97706) 3,3:1. Jouw meting ging alleen tegen de donkere achtergrond en noemde licht impliciet goed. Een basislijn die alleen de helft opschrijft die je toevallig gemeten hebt, is erger dan geen basislijn — dus staan die twee er nu bij.

Dan de drie plekken die je bij naam noemt

De zegel-indicatie in de statusbalk, de waarschuwing in de asset-overzicht-editor en de foutkleur in het kwaliteitspaneel gebruiken nu dangerFg/successFg in plaats van danger700/success700. Die mode-afhankelijke varianten bestonden al; er hoefde geen kleur bij verzonnen te worden.

Wat er niet in zit, en waarom het geen kwestie van tokens omzetten is

Jouw voorstel was "geef de vier ergste tokens een _m()-tegenhanger". Dat kan niet zomaar: die tokens zijn bewust vast. Een bevinding moet in een headless export-isolate identiek renderen aan de preview (PENTEST_MIAUW §11), en een kleur die met de app-modus meebeweegt breekt dat — dan gaat het zegel over twee verschillende PDF's.

Elk van de ~200 gebruiken moet dus gelezen worden als óf dia-inhoud (laten staan) óf interface-chrome (mode-afhankelijk maken). Dat is de eigenlijke klus, en die is niet af. docs/ACCESSIBILITY.md zegt dat met zoveel woorden, mét de getallen, zodat de stand in de repo staat en niet in een notitieboekje.

Poort

make check groen (niet door tail gepijpt). Geen nieuwe zichtbare tekst, geen afhankelijkheid erbij.

Werkt aan #606. **Het issue blijft open** — zie *Wat er niet in zit*. OciDeck rekent het contrast van jouw dia's na en meldt wat zakt. Dat de app zelf die lat niet haalt is de makkelijkste "physician, heal thyself" die een reviewer kan vinden, en de rekensom kost hem vijf minuten. ## Eerst het getal Zonder meting is de rest een mening. `test/app_theme_contrast_test.dart` meet elk kleurtoken dat de interface als **tekst** gebruikt tegen het oppervlak dat de modus werkelijk schildert (`AppTheme.paper`), in beide modi, met de uitkomst als basislijn — precies stap 1 uit je voorstel. De ratchet klapt twee kanten op: een nieuw geval erbij faalt, en een geval dat gerepareerd is maar in de lijst blijft staan faalt óók. Zo kan de lijst alleen korter worden. **De meting corrigeert het issue op twee punten.** - Donker telt **17** tokens onder 4,5:1, niet 21. Het verschil zit in vul- en randkleuren, die de tekstlat niet hoeven te halen; ik heb alleen gemeten wat ergens als tekst- of icoonkleur op het papieren oppervlak landt. - **Licht is niet in orde.** `severityHigh` (#EA580C) haalt 3,6:1 op wit en `severityMedium` (#D97706) 3,3:1. Jouw meting ging alleen tegen de donkere achtergrond en noemde licht impliciet goed. Een basislijn die alleen de helft opschrijft die je toevallig gemeten hebt, is erger dan geen basislijn — dus staan die twee er nu bij. ## Dan de drie plekken die je bij naam noemt De zegel-indicatie in de statusbalk, de waarschuwing in de asset-overzicht-editor en de foutkleur in het kwaliteitspaneel gebruiken nu `dangerFg`/`successFg` in plaats van `danger700`/`success700`. Die mode-afhankelijke varianten bestonden al; er hoefde geen kleur bij verzonnen te worden. ## Wat er niet in zit, en waarom het geen kwestie van tokens omzetten is Jouw voorstel was "geef de vier ergste tokens een `_m()`-tegenhanger". Dat kan niet zomaar: **die tokens zijn bewust vast.** Een bevinding moet in een headless export-isolate identiek renderen aan de preview (PENTEST_MIAUW §11), en een kleur die met de app-modus meebeweegt breekt dat — dan gaat het zegel over twee verschillende PDF's. Elk van de ~200 gebruiken moet dus gelezen worden als óf dia-inhoud (laten staan) óf interface-chrome (mode-afhankelijk maken). Dat is de eigenlijke klus, en die is niet af. `docs/ACCESSIBILITY.md` zegt dat met zoveel woorden, mét de getallen, zodat de stand in de repo staat en niet in een notitieboekje. ## Poort `make check` groen (niet door `tail` gepijpt). Geen nieuwe zichtbare tekst, geen afhankelijkheid erbij.
fix(a11y): zet het contrast van de app zelf in de repo, en repareer drie plekken (#606)
Some checks failed
CI / Gate (Linux) · Format · Analyze · Coverage (pull_request) Failing after 23s
CI / Docs links (pull_request) Failing after 21s
CI / Web hardening (pull_request) Failing after 22s
CI / Supply-chain (Trivy · advisory) (pull_request) Failing after 22s
CI / Gate (Linux) · Format · Analyze · Coverage (push) Failing after 20s
CI / Docs links (push) Failing after 19s
CI / Web hardening (push) Failing after 23s
CI / Supply-chain (Trivy · advisory) (push) Failing after 30s
CI / Test (macos-latest) (pull_request) Has been cancelled
CI / Test (windows-latest) (pull_request) Has been cancelled
CI / Test (macos-latest) (push) Has been cancelled
CI / Test (windows-latest) (push) Has been cancelled
c11f58d6e7
OciDeck rekent het contrast van jouw dia's na en meldt wat zakt. Dat de
app zelf die lat niet haalde is de makkelijkste "physician, heal thyself"
die een reviewer kan vinden, en de rekensom kost hem vijf minuten.

Eerst het getal, want zonder meting is de rest een mening.
`test/app_theme_contrast_test.dart` meet elk kleurtoken dat de interface
als tékst gebruikt tegen het oppervlak dat de modus werkelijk schildert
(`AppTheme.paper`), in beide modi, met de uitkomst als basislijn. De
ratchet klapt twee kanten op: een nieuw geval erbij faalt, en een geval
dat gerepareerd is maar in de lijst blijft staan faalt óók. Zo kan de
lijst alleen korter worden.

De meting corrigeert het issue op twee punten:

- donker telt **17** tokens onder 4,5:1, niet 21 — het issue telde ook
  vulkleuren mee die de tekstlat niet hoeven te halen;
- **licht is niet in orde.** `severityHigh` (#EA580C) en `severityMedium`
  (#D97706) halen 3,6:1 en 3,3:1 op wit. Het issue mat alleen tegen de
  donkere achtergrond en noemde licht impliciet goed. Een basislijn die
  alleen de helft opschrijft die je toevallig gemeten hebt, is erger dan
  geen basislijn.

Daarna de drie plekken die het issue bij naam noemt: het zegel-indicatie
in de statusbalk, de waarschuwing in de asset-overzicht-editor en de
foutkleur in het kwaliteitspaneel gebruiken nu `dangerFg`/`successFg` in
plaats van `danger700`/`success700`. Die mode-afhankelijke varianten
bestonden al.

Wat er níét in zit, en waarom het geen kwestie van tokens omzetten is:
de vaste tokens zijn bewust vast. Een bevinding moet in een headless
export-isolate identiek renderen aan de preview (PENTEST_MIAUW §11), en
een kleur die met de app-modus meebeweegt breekt dat. Elk van de ~200
gebruiken moet dus gelezen worden als dia-inhoud (laten staan) of als
chrome (mode-afhankelijk maken). Die audit staat nog open; het issue
blijft daarvoor open, en ACCESSIBILITY.md zegt het met zoveel woorden.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
brenno merged commit 6b4f8040f2 into main 2026-07-22 20:25:24 +00:00
Sign in to join this conversation.
No description provided.