UX i dostępność dla developera
Dostępność jest częścią jakości interfejsu, nie dodatkiem po zakończeniu projektu. Semantyczny HTML, obsługa klawiatury, widoczny focus, poprawne formularze i zrozumiałe komunikaty pomagają zarówno technologiom asystującym, jak i zwykłym użytkownikom.
Aktualnym zalecanym punktem odniesienia W3C jest WCAG 2.2.
Powiązane tematy: Nowoczesny HTML i CSS, Browser DevTools oraz Web Performance.
1. UX dla developera
UX to nie tylko wygląd.
Dobre rozwiązanie: - jest zrozumiałe, - przewidywalne, - daje feedback, - pomaga naprawić błąd, - nie wymaga zgadywania.
2. Hierarchia
Użytkownik powinien od razu wiedzieć: - gdzie jest, - co może zrobić, - co jest najważniejsze.
3. Formularze
Każde pole powinno mieć label:
<label for="email">E-mail</label>
<input id="email" name="email" type="email">
Placeholder nie zastępuje label.
4. Błędy
Słabo:
Error 422
Lepiej:
Adres e-mail ma nieprawidłowy format.
Jeszcze lepiej: - wskaż konkretne pole, - zachowaj poprawnie wprowadzone dane, - powiedz jak naprawić problem.
5. Loading state
Jeżeli operacja trwa: - pokaż stan, - zablokuj podwójne wysłanie, - daj informację o zakończeniu.
6. Empty state
Zamiast pustej tabeli:
Nie masz jeszcze projektów.
Utwórz pierwszy projekt.
7. Keyboard navigation
Aplikacja powinna być używalna bez myszy.
Sprawdź: - Tab, - Shift+Tab, - Enter, - Space, - Escape.
8. Focus
Nie usuwaj outline bez zapewnienia zamiennika.
:focus-visible {
outline: 2px solid currentColor;
outline-offset: 2px;
}
9. Semantyczny HTML
Używaj:
header
nav
main
section
article
button
form
label
footer
zamiast budować wszystko z div.
10. Button vs link
Link: - prowadzi gdzieś.
Button: - wykonuje akcję.
Nie rób klikalnego div, jeśli potrzebujesz przycisku.
11. Alt text
Informacyjny obraz:
<img src="chart.png" alt="Wzrost sprzedaży o 18% rok do roku">
Dekoracyjny:
<img src="decoration.svg" alt="">
12. Kontrast
Tekst musi być czytelny.
Nie projektuj tylko „na oko”. Warto używać narzędzi sprawdzających kontrast.
13. Kolor
Nie przekazuj informacji wyłącznie kolorem.
Źle:
zielone = OK
czerwone = błąd
Lepiej: - kolor, - ikona, - tekst.
14. Responsive design
Projektuj dla: - telefonu, - tabletu, - desktopu.
Nie tylko skaluj wszystko proporcjonalnie.
15. Touch targets
Elementy dotykowe powinny być wystarczająco duże i mieć odstęp.
16. Motion
Animacja powinna: - pomagać, - nie przeszkadzać.
Respektuj:
@media (prefers-reduced-motion: reduce) {
/* ogranicz animacje */
}
17. ARIA
Zasada:
najpierw semantyczny HTML, potem ARIA
Nie dodawaj ARIA, jeśli natywny element już ma odpowiednią semantykę.
18. aria-label
Przykład dla przycisku z samą ikoną:
<button aria-label="Zamknij">
×
</button>
19. Screen reader
Sprawdź: - kolejność nagłówków, - nazwy przycisków, - label formularzy, - komunikaty błędów.
20. WCAG 2.2 - praktycznie
Nie musisz znać całego standardu na pamięć.
Developer powinien przede wszystkim pilnować: - semantyki, - klawiatury, - focus, - kontrastu, - label, - alt, - komunikatów błędów, - responsywności.
21. UX procesu
Dobry proces: 1. użytkownik wie, co zrobić, 2. system pokazuje postęp, 3. sukces jest potwierdzony, 4. błąd można naprawić.
22. Potwierdzenie operacji destrukcyjnej
Przy usuwaniu ważnych danych: - jednoznaczny komunikat, - nazwa obiektu, - jasny przycisk.
Nie pytaj o potwierdzenie każdej drobnostki.
23. Progressive disclosure
Nie pokazuj 30 opcji od razu.
Najczęstsze funkcje: - widoczne, - zaawansowane: ukryte głębiej.
24. Developer checklist
- semantyczny HTML,
- obsługa klawiatury,
- widoczny focus,
- label formularzy,
- czytelne błędy,
- loading state,
- empty state,
- responsive,
- poprawne button/link,
- sensowny alt,
- brak informacji tylko kolorem.
25. Co trzeba umieć
- ocenić formularz,
- znaleźć problemy dostępności,
- tworzyć semantyczny HTML,
- projektować stany loading/error/empty,
- rozumieć podstawowe wymagania WCAG.
Oficjalne źródła
- WCAG 2.2: https://www.w3.org/TR/WCAG22/
- WAI Accessibility Fundamentals: https://www.w3.org/WAI/fundamentals/
- WAI ARIA Authoring Practices: https://www.w3.org/WAI/ARIA/apg/