Obietnica: decyzja i grupa
Dla kogo: twórcy stron w Webflow, Framer lub Wix, product designerzy i właściciele małych serwisów, którzy chcą w 5–15 minut sprawdzić, czy witryna da się przejść wyłącznie klawiaturą. Werdykt na starcie: jeśli strona nie działa z Tab/Shift+Tab + Enter/Esc, to ma realny problem z użytecznością i dostępnością.
Szybkie pytania (2–4) — natychmiastowy kierunek
Czy wszystkie akcje są dostępne z klawiatury? Tak → OK; Nie → priorytet naprawy. (WCAG: funkcjonalność z klawiatury to kryterium 2.1.1). ([webaim.org)
Czy widać, który element ma focus? Tak → OK; Nie → dodaj styl focus. (Webflow i inne buildery podkreślają potrzebę widocznego focusa). ([webflow.com)
Czy da się wyjść z modala/overlay klawiaturą (np. Esc)? Tak → OK; Nie → to keyboard trap — pilnie naprawić. ([webaim.org)
Czym jest test klawiaturą (krótko)
Test klawiaturą to próba interakcji z całym interfejsem używając wyłącznie klawiszy: Tab/Shift+Tab (przechodzenie), Enter/Space (akceptacja), Esc (zamknięcie), strzałki (tam gdzie wymagane). W praktyce: usiądź przy bezmyszowej nawigacji i wykonaj typowe zadania (przejdź do menu, wypełnij formularz, zamknij popup). Dla odwołania do standardów zobacz WebAIM WCAG checklist. ([webaim.org)
Jak zacząć — 5–15 minutowy plan
Kroki (konkret)
Otwórz stronę w przeglądarce w trybie normalnym (nie w edytorze).
Naciśnij Tab i policz, czy focus przechodzi w logicznej kolejności: logo → menu → najważniejsze linki → treść. Jeśli focus skacze losowo, masz problem z porządkiem DOM/ tabindex.
Spróbuj wykonać trzy zadania: otworzyć menu, wypełnić pole formularza, zamknąć modal klawiszem Esc. Zwróć uwagę na brak możliwości opuszczenia elementu (keyboard trap).
Zobacz, czy każdy element ma wyraźny wizualny focus (kontrast/wielkość obrysu). Jeśli nie — zanotuj selektory do poprawy w edytorze.
W praktyce pierwsze wnioski masz po 5 minutach; pełne przejście kilku stron to 10–15 minut.
Co sprawdzić w edytorze (Webflow / Framer / Wix)
Fakt → Skutek → Werdykt
Webflow: edytor i dokumentacja mówią, żeby "style focus" pozostawić i dostosować widoczność focusa; natomiast niektóre komponenty wymagają dodatkowych ustawień, aby były w pełni keyboard-friendly. Skutek: brak widocznego focusa utrudnia orientację. Werdykt: jeśli używasz Webflow, najpierw ustaw widoczny focus w panelu stylów. ([help.webflow.com)
Framer: panel Accessibility pozwala dodawać aria-label i zarządzać tabindex; jednak prefabrykaty i warstwy mogą zmieniać porządek focusu (tabindex + layer order). Skutek: łatwo niechcący dodać niepotrzebne punkty focusu. Werdykt: w Framer sprawdź Accessibility panel dla kluczowych komponentów i dostosuj tabindexy. Jeśli nie jesteś pewny, otwórz dokumentację Framer dotyczącą aria-labels/tabindex. ([framer.com)
Wix: Wix deklaruje „Full Keyboard Functionality” i automatyczne porządkowanie DOM, ale treść dodana przez użytkownika (np. niestandardowe widżety) może wymagać ręcznej korekty. Skutek: podstawowe komponenty zwykle działają, ale customy — niekoniecznie. Werdykt: przetestuj live-site; jeśli używasz aplikek/widżetów, sprawdź je osobno. ([wix.com)
Porównanie: szybka tabela i mini-werdykt
| Platforma | Co daje out-of-the-box | Mini-werdykt |
|---|---|---|
| Webflow | Elementy oznaczone jako „Accessible”, trzeba zadbać o focus styles. ([help.webflow.com) | Dobre dla projektów, gdzie kontrolujesz HTML/CSS. |
| Framer | Accessibility panel: aria-label, tabindex; warstwy wpływają na porządek. ([framer.com) | Dobry jeśli rozumiesz layer/tabindex — inaczej wymaga testów. |
| Wix | Automatyczne DOM order, smart focus ring; dodatki mogą wprowadzać problemy. ([wix.com) | Szybki start; dobry dla content-first, mniej dla custom interactions. |
Typowe błędy i jak je rozpoznać (Fakt → Skutek → Naprawa)
Elementy nie-fokusowalne (np. klikalny div) → użytkownik nie może przejść do akcji → zamień na button/a lub dodaj tabindex + rola.
Brak widocznego focusa → użytkownik nie wie, gdzie jest → dodaj widoczny outline/box-shadow kontrastujący z tłem.
Keyboard trap w modalach → użytkownik zostaje uwięziony → zadbaj o zamknięcie Esc i cykliczne ograniczenie focusu w obrębie modala. (WCAG: No Keyboard Trap). ([webaim.org)
Co robić, jeśli coś jest niepewne
Jeśli zachowanie platformy wygląda inaczej niż dokumentacja (np. update edytora zmienił handling tabindex), sprawdź oficjalny help/guide danej platformy: Webflow Help, Framer Help, Wix Accessibility. W treści linkuję do poradnika WCAG/WebAIM jako głównego checklistu do weryfikacji. Jeśli masz podejrzenie błędu technicznego — powtórz test w trybie incognito i na live-publikacji; jeśli dalej występuje — zgłoś ticket do supportu platformy (linki w dokumentacji platformy). ([webflow.com)
Plusy / typowe skargi — synteza
Plusy:
Szybkie wykrywanie problemów bez narzędzi deweloperskich — wystarczy klawiatura.
Wiele komponentów w builderach jest przygotowanych do keyboard navigation.
Typowe skargi:
Nieintuicyjna kolejność tabowania (tab order).
Brak lub słaby focus visual.
Widgety zewnętrzne, które dodają niepotrzebne punkty focus.
Synteza: większość problemów naprawisz bez kodu, ale elementy zewnętrzne i niestandardowe interakcje mogą wymagać edycji w edytorze albo drobnego kodu.
Puenta — jednoznaczna rekomendacja
Idealne dla: jeśli priorytetem jest szybkie wdrożenie i podstawowa dostępność, Wix da szybki start; jeśli chcesz pełnej kontroli i jesteś gotów poprawiać styl focus/porządek DOM — Webflow jest lepszy; jeśli projekt wymaga złożonej interakcji i kontroli tabindex/ARIA — Framer daje narzędzia, ale wymaga testów. Jeśli test klawiaturą nie przechodzi — traktuj to jako priorytet UX, nie kosmetykę.
Źródła: sprawdź dokumentację Webflow, Framer i Wix oraz checklistę WCAG/WebAIM (WebAIM WCAG checklist). ([help.webflow.com)
