Trzy dni. Trzy wersje toola. To samo portfolio. F (0/100) do A (100/100) w 8 commitach, 75 minut Claude Code work, 16 unique WCAG findings złapanych i rozwiązanych.
Dzień 1 puścił V0.2 public, nudną warstwę. Statyczny analizator TypeScript plus Playwright z axe-core. Trzy realne findings na portfolio.sdet.it po odsianiu podłogi szumu. Robota CI-grade, deterministyczna, bez AI w pętli.
Dzień 2 puścił V0.3 public, ten sam backbone plus 5 AI specjalistów czytających source. Dwa produktywne runy audytu znalazły 16 unique findings między nimi. Round 3 znalazł zero nowych findings. Konwergencja, nie regresja.
Dzisiaj, Dzień 3, puszcza V0.4 Pro na tym samym projekcie. Te same prompty. To samo portfolio. Te same reguły WCAG 2.2 AA. Co się zmienia: runtime, warstwa auto-fixu, roster specjalistów.
Dzisiaj: co dodaje Pro tier i czemu to dodaje.
Multiplicative token fix, w szczegółach
Wczoraj wspomniałem 4-linijkowy edit, który rozwiązał 6 findings. Warto powiększyć.
Round 2 wczorajszego audytu zwrócił 7 nowych findings. Sześć z nich to issues kontrastu w sześciu różnych plikach: Footer.astro (dwa razy), Topbar.astro (dwa razy), ArticleCard.astro, MatrixToggle.astro. Inne selektory. Inne komponenty. Inne kawałki strony. Ten sam root cause pod spodem.
Diagnoza przyszła od AI specjalisty color-contrast, nie od statycznego analizatora. Statyczny raportuje 6 contrast violations i kończy. AI specjalista czyta CSS source, idzie za var() indirectionem przez pliki, rozpoznaje wzorzec: 6 widocznych symptomów, 2 design tokens, 1 root cause.
Fix:
:root {
/* dark theme default, text on #141414 */
- --color-text-subtle: #737373; /* 3.4:1, AA fail */
- --color-text-muted: #a1a1a1; /* 6.5:1, AA pass but tight */
+ --color-text-subtle: #a3a3a3; /* 6.7:1, AA pass */
+ --color-text-muted: #b3b3b3; /* 8.8:1, AA pass with headroom */
}Sześć plików zawierających symptomy nie zostało otwartych. Footer, Topbar, ArticleCard, MatrixToggle. Nie potrzebowały edycji. Każdy komponent używający --color-text-muted albo --color-text-subtle na ciemnym tle dostał nowe ratio za darmo.
Lekcja architektoniczna jest mała, ale ważna. Design-tokens-first oznacza single source of truth. Sześć komponentów mapuje się do dwóch tokenów mapuje się do jednego fixu. Alternatywa spot-fix to 6 osobnych edycji plików, 6 commitów, sześć szans na drift. Token fix: 1 plik (global.css), 4 linijki, wszystkie 6 findings rozwiązane.
Findability i fixability to różne problemy. Static rule engine znajduje 6 contrast issues. To informacja. AI specjalista znajduje 6 issues i wskazuje 2 design tokens, które je powodują. To akcja.
Tutaj też zaczyna się Pro tier story. AI nie tylko znajduje issues, identyfikuje root cause. V0.5 enterprise rozszerza ten sam pomysł na cross-repo: ten sam issue --color-text-muted w 5 consumer repo w organizacji design-system, atomic patch wszystkich 5. Federation zamiast spot-fixów.
AI semantic understanding razy design-tokens-first architecture daje multiplicative impact. Trafisz w jedno, oszczędzasz czas. Trafisz w oba, dostajesz to.
Pro tier walk-through, V0.4 alpha.3
Pro V0.4 alpha.3 shippuje dzisiaj na tym samym projekcie. Co dodaje ponad public V0.3.
Multi-runtime. Public toolkit zakłada Claude Code in-session. To optymalna ścieżka dla solo devów puszczających audyty podczas code review. Pro dodaje dwa kolejne runtime’y. OpenCode subprocess działa bez sesji Claude Code i jest model-agnostic, więc ten sam pipeline audytu chodzi przeciwko GPT-5, Claude albo dowolnemu modelowi, który OpenCode wspiera. Ollama local runtime nie wysyła nic na zewnątrz: model chodzi na maszynie audytora, source code nie opuszcza laptopa, każdy prompt i response zostaje lokalnie.
Ścieżka Ollama ma znaczenie z jednego powodu: client compliance. Robota audytu dla regulowanych branż (financial services, healthcare, public-sector kontraktorzy) nie może wysyłać client source przez hostowane LLMy. Ollama local runtime to absolutne minimum, żeby w ogóle robić tę robotę. Public toolkit tego nie umie. Pro umie, z założenia.
Pipeline zostaje runtime-agnostic. Ten sam kształt WcagFinding, ten sam dedupe step, ten sam grade A-F. Runtime to swappable backbone, nie feature.
Auto-fix engine. Dwa deterministyczne patchery shippują w alpha.3: ImageAltPatcher dla brakujących atrybutów alt na elementach <img>, HtmlLangPatcher dla brakującego lang na <html>. Oba produkują przewidywalny output i piszą atomic commits per fix. Na portfolio.sdet.it auto-fix engine ogarnia 1 z 22 findings z oryginalnego audytu, czyli 4.5% pokrycia.
Ta liczba to uczciwa wersja story. Auto-fix engine ogarnia mniej więcej 5%, mechaniczne łatki jak brakujący alt albo brakujący html-lang. Pozostałe 95% to decyzje autora i designera. Zawartość aria-label wymaga ludzkiego osądu. Tokeny kolorów wymagają buy-in design-systemu. Restrukturyzacja nagłówków wymaga decyzji edytorskich o content. AI specjaliści to odkrywają. Ludzie to naprawiają. To jest split public/Pro.
Auto-fix oszczędza tę nudną robotę. AI specjaliści oszczędzają tę architektoniczną. Pro to integracja obu.
V0.4 alpha.4 preview, modal i ecommerce
Dwóch specjalistów ląduje w V0.4 alpha.4: modal-specialist i ecommerce-journey. Oboje Pro-only. Oboje niche. Oboje w backlogu następnego sprintu.
Ten kawałek to uczciwy scaffolding sekcji. Sprint alpha.4 leci 06-09.05.2026, więc żaden z agentów nie jest zashippowany w momencie tego write-upu. Traktuj resztę sekcji jako plan, nie inwentarz.
Modal-specialist. Timing focus trapu (kiedy trap się włącza, co łapie). Focus restoration na close (który element dostaje focus, gdy dialog się zamyka, trigger czy body). Obsługa klawisza Escape. Walidacja aria-modal, włącznie z anti-patternem cookie-banner, gdzie aria-modal="true" deklaruje region modalny, podczas gdy strona jest nadal częściowo operowalna dookoła. Drzewo decyzyjne między dialog a alertdialog. Zachowanie scroll-lock na elemencie body, gdy modal się otwiera.
Kontekst legalny nie jest dekoracyjny. Cookie banner z aria-modal="true" to wzorzec EAA, za który strony są pozywane. European Accessibility Act, deadline czerwiec 2025. EU e-commerce jest teraz prawnie wystawione, gdy userzy assistive-tech dostają informację, że strona jest w pełni zablokowana przez region, który tak naprawdę jest częściowo operowalny. Generic agenci ARIA flagują obecność atrybutu. modal-specialist flaguje zły wybór.
Ecommerce-journey. Announcement przy zmianie wariantu przez regiony aria-live, gdy user wybiera rozmiar M potem rozmiar L (price update, availability update, oba odczytane). Payment review step (WCAG 3.3.4 plus 3.3.6, error prevention specyficzny dla transakcji finansowych). Stock indicators tylko-kolorem (zielona kropka bez tekstu, czerwona ramka bez labelki). Politeness toastu z koszyka aria-live, polite vs assertive zależnie od kontekstu. Aktualizacje liczników filtrów ogłaszane po każdym filter toggle.
Modal-specialist to nie “kolejny agent”. To 8 lat e-commerce audytów w jednym promptcie. Możesz to zbudować od zera. Zajmie Ci to lata, które ja spędziłem audytując 50+ e-commerce sites. Albo mnie zatrudnisz.
Split jest ostrzejszy, niż wygląda. Generic keyboard agent flaguje brakujący onKeyDown. Modal-specialist flaguje focus restoration na close do którego konkretnego elementu. Generic forms agent sprawdza labels. ecommerce-journey sprawdza 3.3.4 review-step na payment forms specyficznie. Public toolkit daje Ci 5 specjalistów. Pro dodaje 2, których sam nie napiszesz, jeśli nie audytowałeś e-commerce przez lata.
V0.5 enterprise, jarvis-brain i cross-repo
V0.5 enterprise tier (planowane, post alpha.4): integracja jarvis-brain. Inna klasa problemu.
Story to scope shift, nie feature shift. Solo developer z jednym repo, jednym audytem, jednym fixem mieści się komfortowo w V0.4 Pro. Organizacja design-system z 10 repo konsumującymi shared tokens nie. Multiplicative token fix z wcześniejszej części tego write-upu, ten, który rozwiązał 6 findings na pojedynczym repo, skaluje się inaczej, gdy ten sam issue --color-text-muted istnieje w 5 consumer repo. Pięć spot-fixów, pięć PR, pięć szans na drift. Albo jeden atomic patch skoordynowany przez design system.
jarvis-brain to multi-tenant knowledge vault, który tę koordynację umożliwia. Token federation cross-repo, detekcja DRY violations na warstwie design-systemu, cross-repo deep dedupe (ten sam defekt w semantycznie różnych ścieżkach plików zwija się do jednego findingu, nie pięciu).
Backlog V0.5 łapie też trzy tryby audytu, których obecny single-mode audyt public nie ma. --scope component puszcza audyt w stylu Storybook na jednym komponencie. --scope page puszcza audyt na poziomie route, idąc za importami dwa poziomy w głąb. --scope full puszcza cały projekt, default.
Plus sekcja positive findings w raporcie. Co audyt potwierdził jako działające, nie tylko co jest popsute. Sygnał zaufania dla maintainerów design-systemów, którzy muszą pokazywać postęp, nie tylko zostającą robotę.
Trzy tiery. Trzy problemy. Trzy poziomy cenowe. Wyrównane przez audit scope, nie arbitralne feature gating.
Tier comparison
Wizualna referencja modelu tierów:
graph LR
subgraph Public["Public V0.3 (AGPL-3.0)"]
A1[Static TS]
A2[Dynamic Playwright]
A3[5 AI Specialists]
A4[Lead Orchestrator]
A5[A-F Grading]
A6[/wcag:audit skill]
end
subgraph Pro["Pro V0.4 alpha.3 (Commercial)"]
B1[Everything from Public]
B2[Multi-runtime CC/OpenCode/Ollama]
B3[Auto-fix Engine]
B4[wcag.config.ts]
end
subgraph Pro4["Pro V0.4 alpha.4 (Next sprint)"]
C1[+modal-specialist]
C2[+ecommerce-journey]
end
subgraph Enterprise["Pro V0.5 Enterprise (Planned)"]
D1[Cross-repo via jarvis-brain]
D2[Design System Federation]
D3[Three audit modes]
D4[Deep dedupe semantic]
D5[Positive findings]
end
Public -.imports.-> Pro
Pro --> Pro4
Pro4 --> EnterprisePro importuje z Public. To architektoniczna relacja, nie marketing tagline. Każdy wyższy tier owija niższy. Pięciu specjalistów w Pro to ci pięciu z Public. Pipeline audytu w Enterprise to ten sam, co w Pro. Public to fundament, nie crippled demo.
Czytaj z góry na dół: Public to to, co chodzi w CI na każdym commicie, Pro to to, co chodzi codziennie na utrzymywanym projekcie, Enterprise to to, co chodzi w organizacji przez repo. Inna jednostka audytu w każdym tierze. Wycena wyrównana do tej jednostki, nie do feature gating.
Uczciwy commercial framing
Ostatnie słowo o splicie public/Pro. Chcę być jasny co do tego, za co płacisz.
To nie jest “ukrywamy features za pieniądze”. To jest “płacimy za niche expertise, której nie napiszesz sam, jeśli nie audytowałeś e-commerce przez lata”. Public to edukacja. Pro to ekspertyza.
Trzy rzeczy, które kupujesz licencją Pro. Po pierwsze, niche expertise: modal-specialist i ecommerce-journey kodują wzorce z lat audytu, nie generic ARIA scans. Po drugie, multi-runtime: Ollama lokalnie dla wrażliwych client repo, zero tokenów na zewnątrz, absolutne minimum compliance dla regulowanych branż. Po trzecie, maintenance: reguły ewoluują wraz z WCAG 2.2 stającym się WCAG 3.0, prompty są patchowane przeciwko nowym anti-patternom, toolkit zostaje aktualny bez Twojego śledzenia speca.
Trzy rzeczy, których nie kupujesz. Architektury (sklonuj public toolkit, naucz się z niego, zbuduj od zera). Pięciu baseline specjalistów (są public, AGPL-3.0, free). Magii (audyt nadal wymaga ludzkiej rewizji findings, AI odkrywa, Ty decydujesz).
Możesz odbudować niche specjalistów. Zajmie Ci to lata, które ja spędziłem audytując 50+ e-commerce sites. Albo mnie zatrudnisz.
Public toolkit na GitHub: github.com/darco81/sdet-wcag-toolkit (AGPL-3.0). Pro tier na sdet.it/services. Ale zanim #01 się zamknie, jeszcze jedna rzecz.
Coming w #05: audyt, który znalazł 5 816 findings
Pisząc ten artykuł odpaliłem V0.4 multi-page audit na tym samym portfolio. Ten sam projekt, inny scope. Round 4 router-scan: jedenaście route’ów, dziewięć findings na trzech stronach, których homepage audit nigdy nie tknął. Token-level fix na /projects: edycja jednego ruleset, sześć findings down. Ten sam multiplicative pattern z Dnia 1, skalowany przez cały site.
Potem sitemap audit. Trzydzieści pięć route’ów, pełen published surface włącznie z artykułami i odcinkami. Pięć tysięcy osiemset szesnaście findings.
Cztery CSS-level commity później: siedem. Wszystkie siedem to runtime false positives z toolkit subsystem, który sam napisałem. Zero SERIOUS, zero AA failures. 5 816 → 7. Trzy rzędy wielkości. Cztery commity. Bez JavaScript.
To story #05 - 2-4 czerwca. Multi-page audit pokazuje dependency graph bugów, nie listę URL’i. Single fix, multiplicative cleanup. Różnica między audit tool a Lighthouse extension.
Series wrap, plus co dalej
From the field #01 wrap. Trzy dni, jeden projekt, trzy wersje toola, realne liczby przez całość.
Dzień 1: V0.2 baseline, 3 realne findings złapane przez static plus dynamic. Dzień 2: V0.3 plus AI, 16 unique findings przez runy triangulacji, Round 3 znajdujący zero nowych (proof konwergencji). Dzień 3: F do A w 8 commitach, 75 minut total Claude Code work, plus walk-through Pro tier.
Series continuity tease. Tydzień 2: jarvis-brain, system, który zatrzymuje Claude Code przed paleniem tokenów na Grep i Glob, pre-computing semantic mapy serwowanej przez MCP. Tydzień 3: context-first QA workflow, platforma stojąca za moją codzienną automatyzacją Jira i Tempo. Tydzień 4: performance audit 5-agent pipeline. Tydzień 5: V0.4 multi-runtime build process.
Jeśli budujesz narzędzia accessibility, design systemy albo AI-driven dev workflows, śledź #FromTheField. Realna produkcja, realne liczby, realna engineering humility. Tydzień następny: jarvis-brain.