Dla starszych usług cyfrowych przewidziano okres przejściowy do 28 czerwca 2030 r., jednak już dziś banki powinny podejmować działania wdrożeniowe, aby uniknąć ryzyka sankcji i zapewnić pełną dostępność. Odpowiedzią na krok pierwszy jest profesjonalny audyt WCAG dla banku.
Co podlega audytowi w banku
- Serwisy WWW bankowości elektronicznej – logowanie, rejestracja, procesy KYC, formularze, tabele transakcji, wnioski kredytowe i płatności online.
- Aplikacje mobilne (iOS/Android) – obsługa czytników ekranu (VoiceOver, TalkBack), nawigacja klawiaturą, dostępność gestów, kompatybilność z ustawieniami systemowymi.
- Dokumenty cyfrowe – PDF, HTML i inne dokumenty publikowane dla klientów, takie jak umowy czy taryfy opłat.
- Urządzenia i kanały towarzyszące – bankomaty, wpłatomaty, terminale płatnicze, infolinie i systemy IVR.
Podstawy zgodności: EAA/PAD, EN 301 549 i WCAG
EAA i PAD – co wymagają od banków
EAA to unijna dyrektywa ujednolicająca standardy dostępności usług i produktów w całej UE. Polski Akt o Dostępności wdraża ją w naszym kraju, rozszerzając obowiązki dostępności także na banki i inne podmioty sektora prywatnego.
Najważniejsze zasady:
- wszystkie nowe produkty i usługi wprowadzone po 28 czerwca 2025 r. muszą być zgodne z wymaganiami,
- istniejące systemy mają czas na dostosowanie do 28 czerwca 2030 r.,
- nadzór nad dostępnością usług bankowości detalicznej sprawuje w Polsce Rzecznik Finansowy.
EN 301 549 i WCAG – jak działają razem
- EN 301 549 to standard techniczny, który obejmuje strony WWW, aplikacje mobilne, dokumenty cyfrowe, oprogramowanie oraz urządzenia.
- WCAG 2.2 stanowi trzon wymagań dla treści cyfrowych, rozszerzając wcześniejsze standardy (WCAG 2.1) m.in. o kryteria dotyczące logowania, formularzy, gestów dotykowych i wskaźników fokus.
Jak przeprowadzić audyt WCAG dla banku – 6 kroków
1. Mapowanie procesów kluczowych
Zidentyfikuj kluczowe procesy klienta: logowanie, rejestracja, reset hasła, wnioski kredytowe, przelewy, płatności online, autoryzacja dwuskładnikowa, korzystanie z infolinii.
2. Testy zgodności czyli audyt WCAG dla banku
- WWW: pełna walidacja WCAG 2.2 (poziomy A i AA).
- Mobile: testy z czytnikami ekranu, nawigacja alternatywna, zgodność z systemowymi ustawieniami dostępności.
- Dokumenty: sprawdzenie poprawności struktury PDF/HTML, tagowanie, kolejność odczytu.
- Dodatkowo: audyt CAPTCHA, biometrii, czasów sesji i powiadomień.
3. Testy użyteczności z udziałem osób z niepełnosprawnościami
Przeprowadź moderowane testy z użytkownikami, aby sprawdzić realne bariery w logowaniu, wykonywaniu przelewów czy składaniu wniosków.
4. Analiza zgodności end-to-end
Oceń dostępność całego ekosystemu: od aplikacji WWW i mobilnych po infolinię, komunikaty SMS i e-mail, a także urządzenia samoobsługowe.
5. Plan napraw i dowody zgodności
Opracuj priorytety napraw błędów, określ terminy i przygotuj dokumentację (raporty, matryce zgodności, zrzuty ekranu, wyniki testów).
6. Monitoring i przeglądy
Wprowadź automatyczne testy w procesach CI/CD, stwórz zestaw testów regresyjnych oraz planuj kwartalne przeglądy deklaracji dostępności.
Najczęstsze problemy w bankowości
Logowanie i autoryzacja
Problemy: puzzle, testy pamięciowe, brak alternatywy dla biometrii.
Rozwiązania: logowanie zgodne z zasadą Accessible Authentication, OTP dostępne z czytnikiem ekranu, wyraźny fokus.
Formularze i wnioski kredytowe
Problemy: brak etykiet, walidacja tylko kolorem, konieczność powtarzania danych.
Rozwiązania: spójne komunikaty błędów, wsparcie autouzupełniania, unikanie powtarzania pól.
Nawigacja i interakcje
Problemy: niewidoczny fokus, małe cele dotykowe, blokowanie focusu w modalach.
Rozwiązania: wyraźne wskaźniki fokus, minimalny rozmiar elementów 24×24 px, poprawne linki nawigacyjne.
Aplikacje mobilne
Problemy: brak opisów ikon, niesemantyczne listy, błędy w deeplinkach.
Rozwiązania: etykiety dostępności, testy VoiceOver i TalkBack, poprawna kolejność odczytu.
Dokumenty cyfrowe
Problemy: brak tagowania PDF, skany bez OCR.
Rozwiązania: dokumenty zgodne z PDF/UA lub dostępne alternatywy HTML.
Urządzenia samoobsługowe
Problemy: brak wsparcia głosowego, niedostępne elementy dotykowe.
Rozwiązania: wdrożenie voice guidance, ergonomiczne rozmieszczenie elementów, wsparcie dla osób niewidomych i słabowidzących.
Jak przygotować się do kontroli
- Stwórz matrycę zgodności (ekrany/procesy ↔ WCAG 2.2 i EN 301 549).
- Przygotuj raporty audytowe i retestowe.
- Ustal procedury zgłaszania problemów i SLA na ich obsługę.
- Opublikuj aktualną i rzetelną deklarację dostępności.
- Zabezpiecz dowody testów (zrzuty ekranu, nagrania, raporty).
- Wprowadź zapisy o dostępności w umowach z dostawcami oprogramowania.
Najczęstsze pytania zarządów banków
Czy wystarczy zgodność z WCAG?
Nie, ponieważ EN 301 549 zawiera dodatkowe wymagania, które muszą być spełnione obok WCAG.
WCAG 2.1 czy 2.2?
Standard prawny w EN 301 549 opiera się na WCAG 2.1, ale najlepszą praktyką i przyszłościowym podejściem jest już wdrażanie kryteriów WCAG 2.2.
Kto będzie kontrolował banki?
W Polsce za nadzór nad bankowością detaliczną w obszarze dostępności odpowiada Rzecznik Finansowy.
Checklista audyt WCAG dla banku
- Zmapowanie kluczowych procesów w WWW i mobile
- Audyt zgodności z WCAG 2.2 i EN 301 549
- Testy z czytnikami ekranu i klawiaturą
- Weryfikacja logowania i autoryzacji (2FA)
- Sprawdzenie dokumentów PDF/HTML
- Audyt urządzeń samoobsługowych
- Plan napraw i dowody zgodności
- Aktualna deklaracja dostępności
- Standardowy audyt dostępności cyfrowej serwisu w standardzie WCAG 2.2