Zespół Eximee
Dostępność cyfrowa to kluczowy temat – nie tylko ze względu na wymogi WCAG, ale przede wszystkim jako odzwierciedlenie podejścia zorientowanego na klienta. Mimo to wdrożenie standardów dostępności w banku może stanowić poważne wyzwanie. Jak więc to zrobić skutecznie? Przyjrzyjmy się bliżej, jak platforma programistyczna Eximee Low-Code pomaga bankom tworzyć aplikacje zgodne z WCAG.
WCAG (Web Content Accessibility Guidelines) to wytyczne opracowane przez organizacje W3C aby zapewnić osobom niepełnosprawnym pełny dostęp do treści online.
Zgodnie z Europejskim Aktem w sprawie Dostępności (EAA) od 28 czerwca 2025 r. wdrożenie tych wytycznych stanie się obowiązkowe dla sektora finansowego, w tym wielu przedsiębiorstw prywatnych. Innymi słowy, banki muszą zadbać o dostępność swoich stron internetowych i aplikacji — w przeciwnym razie ryzykują skargami klientów i karami finansowymi, które mogą wynieść nawet 10% rocznych obrotów banku.
Należy jednak podkreślić, że dostępność to coś więcej niż tylko wymóg prawny. Oferuje ona również znaczące korzyści biznesowe i wizerunkowe. Zapewniając dostępne usługi cyfrowe, banki mogą budować zaufanie jako instytucje przyjazne klientom i otwierać drzwi milionom potencjalnych użytkowników z niepełnosprawnościami.
Ostatecznym celem jest zapewnienie każdemu klientowi, niezależnie od ograniczeń, niezależnego i bezproblemowego dostępu do usług bankowych. Chociaż istnieją narzędzia wspomagające, takie jak czytniki ekranu i lupy ekranowe, będą one skuteczne tylko wtedy, gdy aplikacja będzie do nich odpowiednio dostosowana. W przeciwnym razie narzędzia te nie będą działać poprawnie, a niektórzy użytkownicy zostaną wykluczeni cyfrowo.
Jednym z podstawowych kryteriów WCAG jest percepcyjność. Aplikacja bankowa powinna być zaprojektowana tak, aby wszystkie elementy interfejsu były czytelne i widoczne dla użytkowników z częściową lub całkowitą dysfunkcją wzroku.
Co to oznacza w praktyce? Między innymi zapewnienie odpowiedniego kontrastu między tekstem a tłem. Zgodnie z WCAG, minimalny współczynnik kontrastu wynosi 4.5:1 dla tekstu standardowego rozmiaruOznacza to również umożliwienie użytkownikom powiększania treści do bardzo dużych rozmiarów bez utraty czytelności. Wytyczne WCAG wymagają, aby użytkownicy mogli skalować zawartość strony do co najmniej 200%, a najnowsze rekomendacje mówią o skalowaniu do 400%.
W Eximee idziemy o krok dalej. Testujemy nasze formularze przy powiększeniu do 500% bez utraty funkcjonalności ani utraty układu. Przy tak dużym powiększeniu nic nie może wychodzić poza ekran. Nawet przyciski takie jak „Dalej” czy „Wstecz” muszą pozostać widoczne i dostępne dla użytkownika.
Z perspektywy tego wymogu kluczowe są również takie elementy, jak kolorystyka i kontrast witryny. Wykorzystaliśmy również kontroler kontrastu kolorów WCAG Narzędzie, które pozwoliło nam szybko zweryfikować, czy kontrast kolorów spełnia wymagane standardy. To proste rozwiązanie, które znacznie ułatwia codzienną kontrolę jakości dostępności.
W jaki sposób Eximee wspiera te wymagania?
Platforma Eximee zapewnia zestaw współdzielonych komponentów UI – takie jak pola tekstowe, przyciski, listy rozwijane – które domyślnie spełniają wymogi WCAG dotyczące kontrastu kolorów i rozmiaru czcionki. Projektując ekran w narzędziu Eximee Designer, pracownik banku może korzystać z predefiniowanych stylów zgodnych z WCAG.
W praktyce zwracamy również uwagę na szczegóły techniczne, takie jak stosowanie jednostek względnych – na przykład rem zamiast stałych pikseli. Dlaczego jest to ważne? Jednostki rem (root em) odnoszą się do rozmiaru czcionki głównego elementu, który domyślnie wynosi 16 pikseli. Pozwala to użytkownikom skalować tekst zgodnie z ich preferencjami, a jednocześnie interfejs pozostaje spójny i czytelny. To drobiazg, ale kluczowy z punktu widzenia WCAG, ponieważ wpływa na dostosowanie treści do indywidualnych potrzeb.
Podświetlanie fokusu w formularzach Eximee
Dodaliśmy także pozornie drobny, ale istotny szczegół: podświetlanie ostrości W polach formularza. Gdy użytkownik nawigujący za pomocą klawiatury przechodzi przez elementy formularza, aktualnie wybrane pole jest wyraźnie zaznaczone (widoczne dla użytkowników z dysfunkcją wzroku). Co ważne, dotyczy to również pól tymczasowo wyłączonych – nawet jeśli nie można ich kliknąć myszą, otrzymują one fokus podczas nawigacji za pomocą klawiatury i są… również podświetlone wizualnie.
W bankowości pewien poziom formalizmu jest nieunikniony, ponieważ język jest pełen terminów prawniczych i oficjalnych sformułowań. Chociaż niektórych z tych sformułowań nie da się uprościć (na przykład umowa kredytowa musi brzmieć jak umowa kredytowa), staramy się używać prostego i zrozumiałego języka, gdziekolwiek to możliweKryterium zrozumiałości WCAG wymaga, aby treści prezentowane użytkownikom były jasne i precyzyjne.
Jasne i proste komunikaty w Eximee
Jest to szczególnie prawdziwe w przypadku komunikaty o błędach oraz wskazówki dotyczące formularzaUżytkownicy powinni rozumieć, co się dzieje i jakie działania należy podjąć, bez konieczności zgadywania, co oznacza komunikat.
Weźmy na przykład komunikaty walidacyjne. Zamiast ogólnego komunikatu, takiego jak „Nieprawidłowa wartość”, lepiej sprecyzować problem, np. „Nieprawidłowy numer PESEL”.
Weryfikator numeru PESEL
Taka informacja zwrotna jest o wiele bardziej pomocna – zarówno dla użytkownika (który wie, co poprawić), jak i dla czytników ekranu, które odczytają ją na głos.
Innym aspektem jest deklaracja języka w kodzie – każda strona powinna mieć odpowiedni atrybut języka w HTML (np. lang="pl" dla języka polskiego), a jeśli fragment tekstu jest w innym języku (np. cytat w języku angielskim), powinien być dodatkowo oznaczony odpowiednim atrybutem lang.
Umożliwia to technologiom wspomagającym (np. syntezatorom mowy) automatyczne przełączanie się na właściwy język czytania. Ponadto treść odczytywana przez czytniki ekranu powinna unikać zbędnych powtórzeń i być jasno sformułowana – tak aby słuchacz bez wątpliwości rozumiał znaczenie komunikatu.
Nasze komponenty formularzy oferują centralnie zarządzane etykiety i komunikaty, jednak wpływ zmian zależy od poziomu konfiguracji. Modyfikacja wprowadzona na poziomie komponentu jest automatycznie stosowana do wszystkich formularzy korzystających z tego komponentu w danym banku. Co więcej, jeśli wiele komponentów korzysta z tego samego klucza translacji, bank może go zmodyfikować w globalnej konfiguracji aplikacji, dzięki czemu aktualizacja będzie obowiązywać we wszystkich odpowiednich komponentach.
Jednocześnie bank może nadpisać określone tłumaczenie lokalnie w Eximee Designer dla wybranego formularza lub aplikacji. W takim przypadku zmiana obowiązuje tylko lokalnie i nie wpływa na inne formularze. Ten dwupoziomowy mechanizm łączy spójność organizacyjną z elastycznością w konkretnych przypadkach użycia.
W rezultacie zachowujemy spójność językową w całej aplikacji – użytkownicy widzą wszędzie te same, jasne i zrozumiałe komunikaty. W praktyce, podczas projektów dla banków, często upraszczaliśmy treść podpowiedzi i komunikatów o błędach. Regularnie dostosowujemy również komunikaty w oparciu o rekomendacje audytów dostępności.
Walidator numerów PESEL ze szczegółowymi kryteriami weryfikacji
Co ważne, w Eximee możemy również dodać opisy czytnika ekranu (atrybuty ARIA), jeśli dana wiadomość wymaga bardziej szczegółowego wyjaśnienia.
Kierujemy się również zasadą, że komunikaty o błędach pojawiają się w kontekście (np. poniżej określonego pola) i są odpowiednio oznaczone, aby czytnik ekranu automatycznie je odczytał w przypadku wystąpienia błędu.
Wszystko to zapewnia użytkownikowi – niezależnie od tego, czy czyta wiadomość wizualnie, czy słucha jej za pomocą czytnika ekranu – wyraźnie rozumie, co poszło nie tak i co należy poprawić.
I to właśnie jest cel jasnej i prostej komunikacji.
Kolejnym filarem dostępności jest zapewnienie, że aplikacje są dostępne dla osób niewidomych lub niedowidzących, które korzystają z czytników ekranu. Popularne czytniki ekranu to NVDA w systemie Windows, VoiceOver na urządzeniach Apple oraz TalkBack na Androidzie. Narzędzia te odczytują zawartość ekranu na głos, ale aby to robić skutecznie, aplikacja musi być odpowiednio przygotowana.
Wszystkie elementy interfejsu powinny mieć odpowiedniki tekstowe i odpowiednie etykiety, umożliwiające czytnikowi ekranu ich jednoznaczną identyfikację i odczytanie. Naszym celem (i wymogiem WCAG) jest umożliwienie użytkownikowi samodzielnego wykonania całego procesu, korzystając wyłącznie z czytnika ekranu – bez konieczności korzystania z pomocy osób trzecich.
W artykule "Testowanie dostępności WCAG”, szczegółowo opisujemy, jak testować dostępność przy użyciu różnych czytników ekranu (NVDA, VoiceOver, TalkBack) – zachęcamy zainteresowanych czytelników do zapoznania się z tym artykułem.
W tym poście skupimy się na tym, jak platforma programistyczna Eximee Low-Code ułatwia tworzenie formularzy przyjaznych dla czytników ekranu. Eximee Designer został stworzony od podstaw, aby zapewnić komponenty zrozumiałe dla czytników ekranu, bez konieczności dodatkowej pracy.
Każdy element formularza standardowego zawiera:
Dodatkowo udoskonaliliśmy sposób powiązania każdego komponentu z kontekstem: przypisaliśmy pole do jego prefiksów/sufiksów, etykiety, opisu/wskazówki oraz komunikatów walidacyjnych. W rezultacie, gdy czytnik ekranu skupi się na polu, odczytuje wszystkie istotne informacje w logicznej kolejności – najpierw etykietę i stan, następnie wskazówkę, a w razie potrzeby komunikat o błędzie. Dzięki temu użytkownik od razu wie, do czego służy kontrolka, jak jej używać i czy wymaga ona korekty.
Na przykład przycisk „Zapisz” zawiera w kodzie informację, że jest przyciskiem, a pole wyboru daty ma etykietę jasno określającą, jakiego rodzaju danych należy się spodziewać. Dzięki temu, gdy pracownik banku tworzy nowy formularz w Eximee, większość prac nad dostępnością jest już wykonana – formularz jest domyślnie zgodny ze standardami dostępności czytników ekranu.
Oczywiście, samo posiadanie dobrych komponentów to jedno – ale poszliśmy dalej, testując, jak nasze formularze faktycznie działają z czytnikami ekranu. Testerzy Eximee i programiści sprawdzali utworzone formularze, korzystając z efektu „czarnej kurtyny” wbudowany w NVDA, umożliwiający nawigację wyłącznie za pomocą czytnika ekranu.
Sprawdziliśmy, czy użytkownik niewidomy jest w stanie samodzielnie przejść przez cały proces – od przeczytania instrukcji, przez wypełnienie wszystkich pól, aż po wysłanie formularza. Podczas testów zidentyfikowaliśmy i usunęliśmy subtelne problemy, które mogły frustrować użytkownika z dysfunkcją wzroku.
Na przykład:
Dzięki dokładnym testom mamy pewność, że nasze formularze są nie tylko zgodne z wymogami technicznymi, ale także nadają się do praktycznego użytku przez osoby, które polegają wyłącznie na technologiach wspomagających.
Zwróciliśmy szczególną uwagę na listy rozwijane oraz pola wyboru Ponieważ bez odpowiedniego oznakowania mogą być trudne w obsłudze dla czytników ekranu. W Eximee zadbaliśmy o to, żeby czytnik ekranu dokładnie przekazywał informacje o stanie kontrolki, liczbie i położeniu opcji oraz wybranych i podświetlonych wartościach.
Na przykład, gdy fokus znajdzie się na polu przed jego rozwinięciem, użytkownik usłyszy pomocne wskazówki, takie jak:
„Pole wyboru miejsca urodzenia” wraz z opisem stanu aktualnego:
„Lista rozwijana, zwinięta, z funkcją autouzupełniania, edytowalna.”
Po rozwinięciu listy czytnik ekranu ogłasza: „Lista, Wybierz…, 1 z 230”, informując użytkownika o liczbie dostępnych opcji i informując go, że może poruszać się po nich za pomocą klawiszy strzałek.
Po ustawieniu fokusu na konkretnym elemencie komunikat może brzmieć: „Andora, niezaznaczone, 6 z 230”, co jasno określa nazwę, status zaznaczenia i pozycję danego elementu.
Listy rozwijane w formularzach
Po dokonaniu wyboru kontrolka powraca do stanu zwiniętego z funkcją autouzupełniania, a czytnik ekranu odczytuje zaktualizowany status: „Lista rozwijana, zwinięta, z autouzupełnianiem, edytowalna, Andora”, potwierdzając wybraną wartość. Dzięki temu cały proces interakcji jest przejrzysty, a nawigacja przewidywalna i przystępna.
Musieliśmy dodać odpowiednie atrybuty ARIA i dopracować strukturę HTML list, w tym poprawną obsługę klawiatury, taką jak logika klawiszy strzałek, zachowanie klawiszy Enter/Escape oraz poprawne przejścia między fokusami. Efekt? Użytkownicy korzystający z funkcji VoiceOver lub NVDA mogą teraz pewnie poruszać się po wszystkich polach wyboru w formularzu i nimi operować, wiedząc dokładnie, co jest wybierane i jak wybrać inną wartość, nie tracąc przy tym skupienia na aplikacji.
Te wysiłki, od projektowania komponentów po szczegółowe testowanie z NVDA, TalkBack i VoiceOver, oznaczają, że formularze Eximee są domyślnie dostępne dla technologii wspomagającychUżytkownik niewidomy może wysłuchać całej umowy kredytowej, wypełnić formularz, zaznaczyć niezbędne zgody i złożyć wniosek samodzielnie.
Dostępność to nie tylko to, co jest widoczne lub słyszalne – to również sposób, w jaki użytkownicy wchodzą w interakcję z aplikacją. Nie każdy użytkownik potrafi precyzyjnie obsługiwać myszkę lub stukać w ekran dotykowy. Dlatego aplikacja bankowa musi być w pełni obsługiwana za pomocą klawiatury i nie powinna wymagać skomplikowanych gestów.
WCAG wyraźnie wymaga, aby wszystkie funkcje były dostępne z klawiatury (zasada operacyjności). Użytkownik powinien móc poruszać się po całym formularzu za pomocą klawiszy Tab / Shift+Tab, Enter, spacji, klawiszy strzałek oraz skrótów klawiaturowych czytnika ekranu. Dotyczy to nawet elementów, które zazwyczaj kojarzymy z interakcją myszą lub dotykiem — takich jak suwaki, kalendarze czy listy rozwijane.
Dodatkowo, jeśli akcja aplikacji jest dostępna za pomocą gestu wielopunktowego (np. uszczypnięcia dwoma palcami w celu powiększenia) lub ruchu urządzenia (np. potrząsnięcia telefonem w celu odświeżenia listy), należy zapewnić alternatywne sposoby wykonania tego samego zadania. Innymi słowy, nie każdy użytkownik może wykonać gest lub potrząsnąć telefonem, dlatego należy zapewnić prostszy odpowiednik, taki jak przycisk powiększania lub opcja wyłączenia akcji opartych na ruchu.
Eximee zapewnia to domyślnie. Nasze gotowe komponenty są zaprojektowane tak, aby formularze utworzone w Eximee były natychmiast dostępne za pomocą klawiatury. Podczas tworzenia nowej aplikacji pracownik banku nie musi implementować poszczególnych kluczy dostępowych — platforma zapewnia pełną obsługę klawiatury od razu po instalacji.
Fokus przemieszcza się po elementach formularza w logicznej kolejności, a złożone elementy sterujące (takie jak listy rozwijane) reagują na standardowe wprowadzanie danych z klawiatury. Jeśli komponent wymaga nietypowej interakcji (np. gestu dwoma palcami lub potrząśnięcia telefonem), Eximee pozwala zaprojektować alternatywną metodę, na przykład dodatkowy przycisk lub akcję, którą można uruchomić jednym kliknięciem.
Co ważne, Eximee Designer unika również typowych problemów związanych ze skrótami klawiszowymi, które nie są stosowane w standardowych szablonach.
Ważne jest również, aby wspomnieć o konieczności zapewnienia użytkownikom wystarczająco dużo czasu na odpowiedźNawet najprostsza czynność, taka jak wpisanie kodu potwierdzającego z wiadomości tekstowej, może być trudna, jeśli użytkownik jest pod presją czasuOsoby starsze i użytkownicy niepełnosprawni mogą potrzebować więcej czasu na odczytanie i wprowadzenie kodu.
Zgodnie z Wytycznymi Dostępności Treści Internetowych (WCAG) użytkownicy muszą mieć zapewnioną odpowiednią ilość czasu lub możliwość wydłużenia limitów czasowych. W Eximee bierzemy to pod uwagę. Nasze standardowe komponenty autoryzacji (np. moduł wprowadzania kodu SMS) są ustawione na domyślny limit pięciu minut na wprowadzenie koduW porozumieniu z bankiem uznaliśmy, że taki przedział czasowy jest bezpieczny i wygodny dla użytkowników.
Ponadto Eximee wyświetla czytelny licznik czasu, który pokazuje czas pozostały do wprowadzenia kodu lub dokonania autoryzacji, dzięki czemu użytkownicy są na bieżąco i unikają niepewności.
Wyobraź sobie sytuację, w której pole adresu e-mail wygląda i zachowuje się inaczej w jednym formularzu bankowym niż w innym formularzu tej samej instytucji. Innym przykładem byłaby sytuacja, gdy użytkownik wchodzi na stronę i uruchamiana jest akcja (np. czytnik ekranu zaczyna odczytywać umowę) bez żadnego udziału użytkownika. Po prostu nie możemy pozwolić na taki chaos.
Chociaż interfejs i jego zawartość może nie być wymieniony jako samodzielny wymóg WCAG, ma jednak silny wpływ na przewidywalność i użyteczność aplikacji, co jest uwzględnione w WCAG. Użytkownicy — zwłaszcza ci z niepełnosprawnościami — polegają na znanych wzorcach. Jeśli nauczyli się korzystać z jednego formularza na naszej stronie internetowej, następny powinien działać w ten sam sposóbDlatego dążymy do pełnej standaryzacji komponentów i doświadczeń we wszystkich aplikacjach zbudowanych w Eximee.
W praktyce oznacza to, że wszystkie żądania i formularze korzystają z tej samej „paletki” komponentów. Eximee Designer oferuje wspólne, wielokrotnego użytku elementy, takie jak pola tekstowe, listy rozwijane, przyciski, sekcje informacyjne i walidatory danych.
Każdy z tych komponentów jest projektowany raz i dostosowywany do wymagań dostępności, a następnie używany spójnie w wielu lokalizacjach. Jeśli wdrożymy poprawkę lub ulepszenie takiego komponentu, zmiana jest automatycznie stosowana do wszystkich formularzy, które jej używają. Gwarantuje to, że dostępność pozostaje spójna w różnych częściach systemu — utrzymujemy jednolity standard. Dotyczy to zarówno wyglądu (np. schematów kolorów błędów, rozmiarów czcionek, rozmieszczenia etykiet), jak i zachowania (np. spójnych skrótów klawiaturowych, jednolitych wymagań dotyczących formatu danych w polach wprowadzania danych).
Co więcej, standaryzacja obejmuje również treść. Wspomniane wcześniej komunikaty walidacyjne są dobrym przykładem – raz zdefiniowana fraza jest używana wszędzie. To samo dotyczy etykiet pól: jeśli pole jest oznaczone etykietą „Numer telefonu komórkowego” zamiast tylko „Telefon” w jednym formularzu, ta sama konwencja jest stosowana w całej aplikacji.
Taka spójność znacznie ułatwia życie użytkownikom, ponieważ wszystko jest przewidywalne — a WCAG wyraźnie zaleca, aby interfejsy zachowywały się w określony, przewidywalny sposób i nie zaskakiwać użytkowników. W Eximee ściśle przestrzegamy tej zasady.
Warto zauważyć, że ściśle współpracujemy z bankami, aby zachować tę spójność. Audyty dostępności często ujawniają obszary wymagające poprawy — na przykład w jednym projekcie dla klientaotrzymaliśmy szczegółową listę rekomendacji WCAG od zewnętrznej firmy audytorskiej.
W innym projekcie współpracowaliśmy, wykorzystując makiety dostarczone przez bank — pomogliśmy im wdrożyć takie funkcje, jak tryb ciemny i wprowadzono zmiany w stylistyce wizualnej, aby zapewnić spójność wizualną i zgodność z wytycznymi WCAG.
Nasz zespół nie tylko wdrożył te zmiany w komponentach współdzielonych, ale także pełnił funkcję doradcyCzasami różne działy banku miały nieco odmienne poglądy lub priorytety dotyczące dostępności — pomogliśmy koordynować te dyskusje Aby zapewnić spójność i zgodność końcowego rezultatu z WCAG, platforma low-code umożliwiła nam szybkie i skalowalne wdrażanie zmian. Oznaczało to znaczną oszczędność czasu dla banku i gwarancję, że żaden moduł nie zostanie pominięty.
Podsumowując tę sekcję: spójność i standaryzacja są kluczem do utrzymania wysokiej dostępności w czasie. Architektura Eximee, oparta na współdzielonych komponentach, pozwala bankom skalować dostępność – dodając nowe procesy i funkcje bez ryzyka „zapomnienia” o dostępności w jakiejkolwiek części systemu.
Każda nowa aplikacja lub formularz stworzony na platformie automatycznie dziedziczy wszystkie wcześniej wdrożone usprawnienia w zakresie dostępności. To tak, jakby dostępność była wpisana w DNA platformy — banki otrzymują ją domyślnie, zamiast musieć ją za każdym razem tworzyć na nowo.
Dostępność cyfrowa w bankowości to złożony i wieloaspektowy temat. Jak widać, nie chodzi tylko o ustawienie odpowiedniego poziomu kontrastu — obejmuje on warstwę wizualną, język używany w komunikacji, obsługę technologii wspomagających, projektowanie nawigacji, a nawet sposób współpracy zespołów podczas tworzenia. Kluczem jest… empatia wobec użytkownika — projektowanie rozwiązań, dla wszystkich. Można z nich korzystać samodzielnie i wygodnie. Wymaga to zmiany sposobu myślenia i dodatkowego wysiłku — ale ten wysiłek naprawdę się opłaca.
Jako dostawca rozwiązań, naszym celem jest odciążenie banków w jak największym stopniu. Platforma programistyczna Eximee Low-Code oferuje wiele funkcji zgodnych z WCAG, dzięki czemu produkty tworzone z jej wykorzystaniem spełniają większość standardów dostępności od samego początku. Wspieramy zespoły bankowe na każdym etapie, od projektowania i wdrażania po ulepszenia poaudytowe. Pomaga to przyspieszyć dostarczanie usług zapewniających dostępność i gwarantuje satysfakcję użytkownika końcowego — klienta banku.
Dostępność nie musi być ciężarem ani ćwiczeniem polegającym na odhaczaniu odpowiednich pól — przy odpowiednich narzędziach i podejściu może stać się naturalną częścią procesu development'u, podobnie jak bezpieczeństwo i jakość.
Chcesz dowiedzieć się więcej? Skontaktuj się z nami i umów się na spotkanie!
