Zacznij od natywnego elementu HTML i logicznej kolejności treści, a ARIA dodawaj tylko tam, gdzie brakuje semantyki. Nadaj nazwy elementom sterującym edytora i udostępnij je z klawiatury, nie zamykaj bloku w pułapce fokusu i uniemożliwiaj redaktorowi tworzenie niedozwolonego kontrastu czy hierarchii. Testuj edytor i front end bez myszy oraz z czytnikiem ekranu. Sprawdzaj także powiększenie, długie tłumaczenia i ograniczony ruch. Automatyczny audyt nie zastępuje ręcznej interakcji.
Dostępność bloków Gutenberga dotyczy dwóch interfejsów. Odwiedzający korzysta z HTML na stronie publicznej, a redaktor pracuje z elementami sterującymi w edytorze. Blok może wyglądać poprawnie na stronie, ale podczas wstawiania nie mieć zrozumiałej nazwy, gubić fokus lub wymagać myszy. I odwrotnie: może być wygodny w edytorze, a generować niesemantyczny lub nieobsługiwalny kod wynikowy.
Dostępny blok nie powstanie przez dodanie kilku atrybutów ARIA na koniec prac programistycznych. Potrzebuje semantycznej podstawy, ograniczonych i nazwanych ustawień, przewidywalnej obsługi klawiatury, zarządzania fokusem i testów stanów dynamicznych. Ten poradnik dotyczy komponentu blokowego i redakcyjnych mechanizmów ochronnych, uzupełniając ogólną dostępność strony oraz szersze projektowanie własnych bloków Gutenberga.
Zdefiniuj semantykę przed wariantem wizualnym
Należy określić znaczenie komponentu: nawigacja, lista, ostrzeżenie, karta z linkiem lub sterowalny disclosure. Warto użyć natywnego elementu, który ma już oczekiwane zachowanie. Klikalny div nie zastępuje elementu button, a nagłówek dobrany według wielkości czcionki nie zastępuje logicznego poziomu w dokumencie. CSS zmienia wtedy wygląd bez utraty znaczenia.
Proszę zdecydować, które teksty są treścią, a które dostępnym oznaczeniem. Ikona bez tekstu potrzebuje nazwy kontrolki, obrazek dekoracyjny powinien być ignorowany, a obrazek informacyjny wymaga sensownego tekstu alternatywnego. Blok nie powinien automatycznie tworzyć zduplikowanej nazwy z widocznego tekstu i aria-label jednocześnie.
Zaprojektuj sterowanie edycją za pomocą komponentów WordPress
Używaj obsługiwanych komponentów edytora, które zapewniają oznaczenia, fokus i obsługę klawiatury. Każdy przełącznik (toggle), lista wyboru (select) i pole tekstowe ma widoczną lub programowo dostępną etykietę oraz tekst pomocniczy wyjaśniający skutki. Przycisk z ikoną potrzebuje zrozumiałej nazwy opisującej akcję, a nie kształt ikony.
Kolejność obsługi odzwierciedla logikę zadania. Po wstawieniu, zduplikowaniu, przeniesieniu i usunięciu fokus pozostaje w przewidywalnym miejscu. Nie ograniczaj bloków zagnieżdżonych w sposób, który uniemożliwia wybór rodzica lub opuszczenie komponentu za pomocą klawiatury. Błąd w ustawieniach jest komunikowany tekstem i powiązany z odpowiednią kontrolką.
- Nazwane pola formularza i przyciski z ikonami
- Przewidywalny fokus po zmianie
- Obsługa zagnieżdżenia z klawiatury
- Błąd tekstowy powiązany z ustawieniami
Ograniczenie wariantów, które mogą tworzyć bariery
Redaktor nie powinien wybierać dowolnego koloru tekstu i tła, jeśli dana kombinacja może nie zapewnić wystarczającego kontrastu. Warto zaoferować zatwierdzone tokeny lub pary kolorów, a przy dynamicznym wyborze wyświetlać kontrolę. Podobnie należy ograniczyć nieobsługiwane rozmiary, animacje i hierarchię nagłówków zgodnie z kontekstem, który blok jest w stanie rozpoznać.
Obowiązkowy tekst alternatywny nie jest właściwy dla każdego obrazu; blok powinien umożliwiać oznaczenie celu dekoracyjnego i wyjaśniać różnicę. Nazwa wygenerowana automatycznie z nazwy pliku często nie pomaga. W przypadku linku wymagaj zrozumiałego widocznego tekstu i ostrzegaj przed wieloma identycznymi ogólnymi linkami bez kontekstu.
Wdrażaj dynamiczne zachowanie bez utraty fokusu
Jeśli blok otwiera okno dialogowe, fokus przenosi się do jego wnętrza, pozostaje w nim przez cały czas otwarcia, a po zamknięciu wraca do elementu wyzwalającego. Disclosure aktualizuje aria-expanded i powiązanie z panelem. Karuzela wymaga elementów sterujących, możliwości zatrzymania ruchu i nie może zmieniać treści tak szybko, że użytkownik nie zdąży jej przeczytać.
Komunikaty o stanie należy ogłaszać za pomocą odpowiedniego regionu live, bez przeciążania użytkownika. Ładowanie, sukces i błąd powinny być rozpoznawalne również bez koloru. JavaScript podczas inicjalizacji zachowuje natywną treść lub bezpieczny fallback. Hydratacja nie może zmieniać kolejności tabulacji ani tworzyć zduplikowanych elementów sterujących ukrytych jedynie wizualnie.
Testuj blok w izolacji i na całej stronie
W edytorze należy spróbować wstawić blok przez inserter, wyszukać nazwę, zmienić wszystkie ustawienia, cofnąć zmianę, zduplikować, przenieść i usunąć element wyłącznie za pomocą klawiatury. Należy także przejść przez stany błędów i stany puste przy włączonym czytniku ekranu. Automatyczne reguły wychwycą część problemów, ale nie zweryfikują zrozumiałości ani kolejności interakcji.
Na front-endzie proszę umieścić kilka wystąpień bloku między nagłówkami, formularzami i nawigacją. Warto przetestować powiększenie, wąski viewport, wysoki kontrast, ograniczony ruch i długie tłumaczenie. Kontrolę należy dodać do zestawu testów regresyjnych i dokumentacji dla redaktorów. Dostępność może się zepsuć po zmianie tokena lub wspólnego skryptu, nawet bez modyfikacji samego bloku.
Najczęstsze pytania
Czy wystarczy dodać atrybuty ARIA do bloku Gutenberga?
Nie. Najpierw należy użyć poprawnego natywnego HTML i oczekiwanego zachowania klawiatury. ARIA uzupełnia brakującą semantykę, ale nie naprawi niedziałającego fokusu, kolejności ani klikalnego diva.
Czy trzeba testować także administrację bloku?
Tak. Redaktor może korzystać z klawiatury, powiększenia lub czytnika ekranu. Inserter, inspector controls, zagnieżdżanie i stany błędów muszą być dostępne tak samo jak publiczny wynik.
Czy tekst alternatywny obrazu powinien być zawsze wymagany?
Nie. Obraz informacyjny wymaga sensownego tekstu alternatywnego, dekoracyjny powinien mieć pusty tekst alternatywny i być pomijany. Edytor musi umożliwiać redaktorowi prawidłowe określenie celu obrazu.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
