Strona: https://deniz-estate.com/ru/
Problemy:
Hreflang:
Dla każdej wersji językowej strony konieczne jest dodanie w tagu <Head> aktualnych:
<link rel="alternate" hreflang="ru" href="https://deniz-estate.com/ru/” />
<link rel="alternate" hreflang="uk" href="https://deniz-estate.comua/" />
<link rel="alternate" hreflang="pl" href="https://deniz-estate.com/pl/" />
<link rel="alternate" hreflang="en" href="https://deniz-estate.com/en/" />
Moduł obsługi obrazów WebP:
Należy, aby moduł automatycznie konwertował obrazki do formatu WebP
Co należy zrobić dodatkowo:
Sprawdzić, czy WebP jest faktycznie wysyłane do przeglądarek
Włączyć i sprawdzić Lazy Load
Jeśli używany jest plugin (np. WP Rocket, natywne lazy load, Gum), upewnić się, że:
Sprawdzić rozmiary i responsywność
Wszystkie obrazki muszą mieć ustawione width i height
Naprawić srcset i sizes, aby przeglądarka ładowała odpowiedni rozmiar
Sprawdzić cache'owanie
Sprawdzić Lighthouse
Przeprowadzić test strony za pomocą Google Lighthouse (w DevTools)
Upewnić się, że nie ma ostrzeżeń dotyczących obrazów (rozmiar, format, lazy load itp.)
Rezultat:
Obrazki ładują się szybko, nie „psują” układu
Brak duplikatów lub zbędnego obciążenia
WebP działa
Wyniki Lighthouse dotyczące obrazów bez błędów
Zapewnić, aby wszystkie przyciski na stronie:
były poprawnie oznaczone (<button> lub <a>)
działały z klawiatury
były dostępne dla czytników ekranu
zgodnie z wytycznymi WCAG 2.1 i Lighthouse
1. Semantyka
Używać tylko natywnych tagów:
<button> — do działań (wysyłanie, zamykanie, otwieranie itp.)
<a href="..."> — do przejść na strony
Zabrania się używania <div> lub <span> jako przycisków (chyba że dodano role="button" + tabindex + obsługa Enter/Space — ale lepiej zamienić na <button>)
2. Typ przycisku
Dla przycisków w formularzach:
Wyraźnie wskazać type="submit" lub type="button"
(domyślnie <button> = submit, co może powodować niepożądane zachowanie)
3. Dostępność z klawiatury
Przyciski powinny być aktywowane klawiszami:
4. atrybuty aria i opis
Wszystkie przyciski muszą mieć:
lub widoczny tekst (<button>Pobierz</button>)
lub aria-label="Pobierz" — jeśli przycisk zawiera tylko ikonę
Zapewnić dostępność wszystkich elementów formularza
Cel: Zwiększyć dostępność formularzy dla użytkowników z szczególnymi potrzebami i spełnić standardy WCAG.
Sprawdzić i poprawić zachowanie pola wyboru kraju (wprowadzanie telefonu)
Co zrobić:
Element .iti__selected-flag nie powinien być samodzielnie fokusem, jeśli nie pełni funkcji zarządzania wprowadzaniem.
Usunąć tabindex="0" i role="combobox" z elementów, które nie są aktywnymi elementami sterującymi.
Upewnić się, że przejście klawiaturą (Tab) odbywa się wyłącznie po potrzebnych elementach interaktywnych (wprowadzanie, select, przycisk).
Sprawdzić obecność i poprawne oznaczenie przycisku wysyłania formularza
Co zrobić:
Ulepszyć atrybuty ARIA
Co zrobić:
Zostawić aria-label lub aria-labelledby, jeśli nie ma label, ale najlepiej używać <label> jako głównego środka.
Jeśli są walidacje pól, dodać aria-describedby="id-komunikatu" i aria-invalid="true" przy błędach.
Testowanie skupienia i nawigacji
Sprawdzić ręcznie:
Klawisz Tab powinien kolejno przechodzić przez:
pole „Imię”;
pole „Email”;
pole telefonu;
przycisk wysyłki.
Klawisz Enter/Space powinien aktywować wysyłkę i elementy klikalne.
Nie powinno być „skoków” lub fokusu na elementach dekoracyjnych.
Zmniejszyć opóźnienie przy podłączaniu do zewnętrznych usług
Zidentyfikować wszystkie zewnętrzne skrypty, które są ładowane (np. analityka, czcionki, widgety).
Dla nieistotnych skryptów zaimplementować opóźnione ładowanie (lazy loading).
W miarę możliwości używać async lub defer przy podłączaniu zewnętrznych JS-ów.
Optymalizować kolejność podłączania zewnętrznych usług, aby nie blokowały krytycznego renderowania strony.
Zapewnić odpowiedni kontrast między kolorem tła a tekstem
Używać narzędzi do sprawdzania kontrastu (np. WebAIM Contrast Checker).
Sprawdzić, czy kontrast między tekstem a tłem spełnia minimalne wymagania WCAG:
Poziom AA: nie mniej niż 4.5:1 dla zwykłego tekstu, 3:1 dla dużego.
Poziom AAA (zalecany): 7:1 dla zwykłego tekstu.
Zapewnić poprawną semantyczną strukturę <li>
Cel: Zachować poprawną strukturę HTML i poprawić percepcję treści przez technologie wspomagające.
Co należy zrobić:
Wszystkie tagi <li> muszą być używane tylko wewnątrz list <ul>, <ol> lub <menu>.
Wykluczyć przypadki:
<li> poza nadrzędną listą;
<div><li>...</li></div> bez zagnieżdżenia w <ul> lub <ol>.
W razie potrzeby zamienić niepoprawne <li> na <div>, <p> lub inne semantycznie odpowiednie tagi.
Upewnić się, że struktura list jest logiczna i poprawnie zagnieżdżona (zagnieżdżone listy poprawnie wyświetlają się i są poprawnie sformatowane).
Usunąć niepoprawne przypisanie ról ARIA
Cel: Zapewnić poprawną pracę z technologiami wspomagającymi (czytniki, VoiceOver itp.).
Co należy zrobić:
Wykluczyć przypadki:
Przypisanie role="button" do <button> — jest powielaniem;
role="link" do <a> z href — jest zbędne;
Używanie przestarzałych ról lub nieistniejących wartości.
Używać tylko dozwolonych wartości z oficjalnej specyfikacji WAI-ARIA.
Sprawdzić, czy wszystkie role ARIA są logiczne w kontekście, np.:
role="navigation" — dla bloku z menu;
role="dialog" — dla okien modalnych;
role="alert" — dla powiadomień o błędach i ostrzeżeniach.
Poprawnie wypełnić atrybut href w linkach
Cel: Zapewnić poprawną nawigację i zachowanie linków na stronie.
Co należy zrobić:
Wszystkie tagi <a> muszą mieć wypełniony atrybut href. Unikać:
href="";
href="#" — tylko jeśli używane z JavaScript, i wtedy z preventDefault() (np. w popupach).
Dla zasobów zewnętrznych — pełne linki z protokołem https:// i zamknięte rel="nofollow noopener noreferrer"
Jeśli link otwiera się w nowej karcie (target="_blank"), koniecznie dodać:
Dodatkowo:
Po wdrożeniu wszystkich punktów konieczne jest przeprowadzenie audytu:
- Lighthouse (w Chrome DevTools, zakładka "Audyt" lub "Sprawdzanie");
- axe DevTools — do głębokiej analizy dostępności.
Wyniki testów warto zapisać w formie zrzutów ekranu przed i po zmianach.
