- Co to jest WCAG i dlaczego banki muszą o nim pamiętać
- Postrzegalność – kontrast i skalowanie interfejsu
- Zrozumiałość – prosty język i czytelne komunikaty
- Dostępność dla czytników ekranu – projektowanie przyjazne NVDA, VoiceOver i innym technologiom
- Funkcjonalność – klawiatura, gesty i czas na reakcję
- Spójność i przewidywalność – jeden standard w całej aplikacji
- Podsumowanie
Dostępność cyfrowa to ważne zagadnienie – nie tylko z powodu wymogów WCAG, ale przede wszystkim jako wyraz podejścia stawiającego klienta w centrum. Mimo to wdrożenie takich standardów w banku bywa sporym wyzwaniem – jak zrobić to skutecznie? Przyjrzyjmy się, jak Eximee Low Code Platform pomaga bankom tworzyć aplikacje zgodne z WCAG.
Co to jest WCAG i dlaczego banki muszą o nim pamiętać
WCAG (Web Content Accessibility Guidelines) to zestaw wytycznych stworzonych przez organizację W3C, których celem jest zapewnienie pełnego dostępu do treści online osobom z różnymi niepełnosprawnościami.
Zgodnie z dyrektywą Europejskiego Aktu o Dostępności (EAA) od 28 czerwca 2025 r. wdrożenie tych wytycznych w sektorze finansowym jest obowiązkowe także w wielu przedsiębiorstwach z sektora prywatnego. Innymi słowy, banki muszą dbać o dostępność swoich serwisów i aplikacji, bo inaczej narażają się na skargi klientów i kary finansowe (mogące sięgać nawet 10% rocznego obrotu banku).
Warto jednak podkreślić, że dostępność to nie tylko obowiązek prawny do „odhaczenia”. To przede wszystkim realne korzyści biznesowe i reputacyjne. Zapewnienie dostępnych usług cyfrowych zwiększa zaufanie do banku jako instytucji przyjaznej klientom oraz otwiera drzwi milionom potencjalnych użytkowników z niepełnosprawnościami.
Ostatecznie chodzi o to, by każdy klient – niezależnie od ograniczeń – mógł samodzielnie skorzystać z usług banku bez barier. Istnieją co prawda narzędzia wspomagające (czytniki ekranu, powiększenia ekranu itp.), ale żeby faktycznie pomagały, aplikacja musi być do nich dostosowana. W przeciwnym razie narzędzia nie będą działały prawidłowo, a część użytkowników zostanie wykluczona cyfrowo.
Postrzegalność – kontrast i skalowanie interfejsu
Jedno z podstawowych kryteriów WCAG to postrzegalność. Aplikacja bankowa musi być zaprojektowana tak, aby każdy element interfejsu był czytelny i widoczny dla użytkownika – również tego z częściowym lub całkowitym ograniczeniem wzroku. Co to oznacza w praktyce? Między innymi zapewnienie odpowiedniego kontrastu tekstu względem tła (wg WCAG minimalny kontrast to 4,5:1 dla tekstu standardowej wielkości) oraz umożliwienie powiększenia treści nawet do bardzo dużych rozmiarów bez utraty czytelności. Wytyczne WCAG wymagają, by użytkownik mógł skalować zawartość strony co najmniej do 200%, a w najnowszych rekomendacjach mówi się nawet o 400%.
W Eximee poszliśmy o krok dalej – testujemy nasze formularze przy powiększeniu aż do 500%, oczywiście bez rozjeżdżania się układu ani utraty funkcjonalności. Nic nie może “uciekać” poza ekran przy tak dużym powiększeniu – nawet przyciski typu “Dalej” czy “Wstecz” muszą pozostawać widoczne i dostępne dla użytkownika.
Z perspektywy tego kryterium istotne są również aspekty takie, jak odpowiedni kontrast i kolorystyka strony internetowej. Podczas tych prac korzystaliśmy również z narzędzia WCAG Color Contrast Checker, które pozwalało szybko weryfikować, czy kontrast kolorów spełnia wymagane normy. To proste rozwiązanie, ale w praktyce bardzo ułatwia codzienną kontrolę jakości dostępności.
Jak Eximee wspiera te wymagania?
Platforma Eximee dostarcza zestaw wspólnych komponentów UI – takich jak pola tekstowe, przyciski, listy rozwijane – które domyślnie spełniają wymogi WCAG w zakresie kontrastu kolorów i rozmiaru czcionek. Projektując ekran w narzędziu Eximee Designer, pracownik banku może korzystać z predefiniowanych stylów zgodnych z WCAG.
W praktyce zwracamy też uwagę na techniczne szczegóły, takie jak stosowanie jednostek względnych – np. rem zamiast sztywno określonych pikseli. Dlaczego to ważne? Jednostki rem (root em) odnoszą się do rozmiaru czcionki elementu głównego <html>, który domyślnie wynosi 16px. Dzięki temu użytkownik może skalować tekst zgodnie ze swoimi preferencjami, a interfejs pozostaje spójny i czytelny. To drobiazg, ale istotny z punktu widzenia WCAG, bo wpływa na możliwość dostosowania treści do indywidualnych potrzeb.
Dodaliśmy również pozornie drobny, lecz istotny detal: podświetlanie fokusu na polach formularza. Gdy użytkownik nawigujący klawiaturą przechodzi Tabem przez kolejne pola, aktualnie wybrane pole jest wyraźnie obramowane (widoczne dla osób niedowidzących). Co ważne, dotyczy to także pól chwilowo niedostępnych (disabled) – nawet jeśli normalnie nie da się w nie kliknąć, to przy nawigacji klawiaturą otrzymują one fokus i również zostają wyróżnione wizualnie.
Zrozumiałość – prosty język i czytelne komunikaty
W bankowości siłą rzeczy musi obowiązywać konkretny język – pełen prawniczych terminów i formalnych określeń. Części z nich nie da się uprościć (umowa kredytowa musi brzmieć jak umowa kredytowa), ale tam, gdzie możemy, staramy się używać prostego, zrozumiałego języka. Kryterium zrozumiałości w WCAG wymaga, by treści prezentowane użytkownikowi były jasne i jednoznaczne.
Dotyczy to szczególnie komunikatów o błędach i podpowiedzi w formularzach. Użytkownik powinien wiedzieć, co się dzieje i co ma zrobić – bez zastanawiania się, co autor wniosku miał na myśli.
Weźmy jako przykład komunikaty walidacyjne. Zamiast ogólnego tekstu typu “Nieprawidłowa wartość” lepiej od razu wskazać, czego dotyczy błąd, np. “Nieprawidłowa wartość numeru PESEL”.
Taki komunikat jest o wiele bardziej pomocny – i dla użytkownika (bo wie, co poprawić), i dla czytnika ekranu, który przeczyta go na głos. Innym aspektem jest język strony z punktu widzenia kodu – każda strona powinna mieć zadeklarowany w HTML właściwy język (lang="pl" dla polskiego), a jeśli wstawiamy fragment tekstu w innym języku (np. cytat po angielsku), też powinniśmy to oznaczyć atrybutem lang.
Dzięki temu technologie asystujące (np. syntezatory mowy) automatycznie przełączą język czytania na odpowiedni. Z kolei treści odczytywane przez czytnik powinny być pozbawione zbędnych powtórzeń i sformułowane jasno – tak, aby osoba słuchająca nie miała wątpliwości, co komunikat oznacza.
Centralne zarządzanie etykietami i komunikatami
Nasze komponenty formularzy mają centralnie zarządzane etykiety i komunikaty, jednak efekt wprowadzanych zmian zależy od poziomu konfiguracji. Gdy modyfikacja powstaje na poziomie komponentu, automatycznie obejmuje wszystkie formularze korzystające z tego komponentu w danym banku. Co więcej, jeśli kilka komponentów używa tego samego klucza tłumaczenia, bank może zmienić je w konfiguracji całej aplikacji, dzięki czemu aktualizacja zadziała we wszystkich tych komponentach.
Jednocześnie bank ma możliwość nadpisania konkretnego tłumaczenia w Eximee Designer w obrębie wybranego formularza lub aplikacji. W takim przypadku zmiana obowiązuje lokalnie i nie wpływa na inne formularze. Taki dwupoziomowy mechanizm łączy spójność na poziomie organizacji z elastycznością w pojedynczych przypadkach.
Dzięki temu zachowujemy spójność językową w całej aplikacji – użytkownik wszędzie widzi te same, zrozumiałe komunikaty. W praktyce podczas projektów dla banków wielokrotnie upraszczaliśmy treść podpowiedzi i błędów. Nierzadko dostosowywaliśmy komunikaty na podstawie zaleceń audytów dostępności.
Co ważne, w Eximee możemy też dodać opisy dla czytników ekranu (atrybuty ARIA), jeśli jakiś komunikat wymaga szerszego objaśnienia. Stosujemy również zasadę, że komunikaty błędów pojawiają się w kontekście (np. pod konkretnym polem) i mają odpowiednie oznaczenia, żeby czytnik ekranu odczytał je automatycznie w momencie wystąpienia błędu.
Wszystko to sprawia, że użytkownik – bez względu na to, czy czyta komunikat wzrokiem, czy odsłuchuje go za pomocą syntezatora mowy – dokładnie rozumie, co poszło nie tak i co należy zrobić. A przecież o to chodzi w prostocie przekazu.
Dostępność dla czytników ekranu – projektowanie przyjazne NVDA, VoiceOver i innym technologiom
Kolejnym filarem dostępności jest zapewnienie, że z aplikacji skorzystają osoby niewidome lub niedowidzące, posługujące się czytnikami ekranu. Popularne czytniki to m.in. NVDA na Windows, VoiceOver na urządzeniach Apple czy TalkBack na Androidzie. Te narzędzia czytają na głos zawartość ekranu, ale żeby robiły to skutecznie, aplikacja musi być odpowiednio przygotowana.
Wszystkie elementy interfejsu powinny mieć tekstowe odpowiedniki i właściwe oznaczenia, tak aby czytnik mógł je jednoznacznie zidentyfikować i odczytać. Naszym celem (i wymogiem WCAG) jest, by klient mógł wykonać całą operację samodzielnie, od początku do końca, korzystając wyłącznie z czytnika – bez potrzeby asysty osoby trzeciej.
W artykule “Testowanie dostępności WCAG”, szczegółowo opisujemy, jak testować dostępność z użyciem różnych czytników ekranu (NVDA, VoiceOver, TalkBack) – zainteresowanych odsyłamy do tego artykułu.
W tym wpisie skupimy się na tym, jak Eximee Low-Code Development Platform ułatwia tworzenie formularzy przyjaznych dla czytników. Otóż Eximee Designer od samego początku dostarcza komponenty zbudowane w taki sposób, by czytniki ekranu “rozumiały” je bez dodatkowych zabiegów. Każdy standardowy element formularza ma zdefiniowaną etykietę tekstową, odpowiednią rolę ARIA i przemyślaną strukturę HTML.
Dodatkowo dopracowaliśmy powiązania każdego komponentu z jego kontekstem: łączymy pole z prefiksami/sufiksami, etykietą, opisem/podpowiedzią oraz komunikatami walidacyjnymi. Dzięki temu, gdy fokus trafia w dane pole, czytnik ekranu odczytuje komplet informacji w logicznej kolejności (najpierw etykieta i stan, potem wskazówki, a w razie potrzeby także błąd), więc użytkownik od razu wie, co to za kontrolka, jak z niej skorzystać i czy wymaga poprawy.
Na przykład przycisk zapisu ma w kodzie informację, że jest przyciskiem, a pole wyboru daty ma etykietę mówiącą wprost o tym, jakie parametry należy w niej wpisać. Dzięki temu, gdy pracownik banku tworzy nowy formularz w Eximee, większość pracy związanej z zapewnieniem dostępności jest już wykonana za niego – formularz domyślnie spełnia standardy dostępności dla czytników.
Efekt “czarnej kurtyny” – testy w praktyce
Oczywiście, sam fakt istnienia dobrych komponentów to jedno, ale my poszliśmy dalej, testując faktyczne działanie naszych formularzy z czytnikami. Testerzy i deweloperzy Eximee sprawdzili stworzone formularze z wykorzystaniem efektu “czarnej kurtyny” wbudowanego w NVDA, nawigując wyłącznie przy pomocy czytnika.
Sprawdziliśmy w ten sposób, czy osoba niewidoma będzie mogła przejść przez cały proces samodzielnie – od odczytania instrukcji, przez wypełnienie wszystkich pól, po wysłanie wniosku. W trakcie takich testów wychwyciliśmy i poprawiliśmy subtelne błędy, które mogłyby frustrować niewidomego użytkownika.
Dodaliśmy brakujące etykiety ARIA tam, gdzie czytnik ogłaszał tylko “przycisk bez nazwy”. Wprowadziliśmy zasadę, że wszystkie obrazki dodawane w treści formularza (np. logo banku czy infografiki) muszą mieć tekst alternatywny – platforma wymusza podanie opisu przy wstawianiu obrazka, dzięki czemu czytnik zawsze odczyta, co na nim jest (chyba że oznaczymy obrazek jako czysto dekoracyjny).
Listy rozwijane – jak zapewnić użytkownikowi możliwość wyboru?
Szczególną uwagę poświęciliśmy listom rozwijanym i wszelkiego rodzaju polom wyboru. To elementy, które bywają problematyczne dla czytników, jeśli nie zadba się o ich odpowiednie oznaczenie. W Eximee dopilnowaliśmy, aby czytnik poprawnie informował użytkownika o otwarciu listy, liczbie opcji, nawigacji po nich i wyborze konkretnej wartości.
Szczególną uwagę poświęciliśmy listom rozwijanym i polom wyboru, bo bez właściwego oznaczenia bywają trudne dla czytników ekranu. W Eximee zadbaliśmy o to, by czytnik precyzyjnie komunikował stan kontrolki, liczbę i pozycję opcji oraz informował o zaznaczeniu i wybranej wartości. Przykładowo, gdy fokus trafia na pole przed rozwinięciem, użytkownik słyszy informację pomocniczą, np. "Pole wyboru miejsca urodzenia" oraz opis dostępnych statusów, np.: "Lista rozwijana, zwinięte, z autouzupełnianiem, edytowalne”.
Po rozwinięciu listy czytnik anonsuje: „lista, Wybierz…, 1 z 230”, dzięki czemu wiadomo, ile pozycji jest dostępnych i że można po nich przechodzić strzałkami. Gdy fokus znajdzie się na konkretnej opcji, komunikat brzmi np.: „Andora, niezaznaczony, 6 z 230”, co jasno wskazuje nazwę pozycji, jej status i miejsce na liście.
Po dokonaniu wyboru kontrolka wraca do stanu zwiniętego z autouzupełnianiem i czytnik czyta informację pomocniczą oraz pozycję zaznaczoną na danej liście, np.: Lista rozwijana, zwinięte, z autouzupełnianiem, edytowalne, Andora”, potwierdzając wybraną wartość. Dzięki temu cały przebieg interakcji jest czytelny, a nawigacja – przewidywalna i dostępna.
Po naszej stronie wymagało to uzupełnienia atrybutów ARIA oraz dopracowania struktury HTML list – w tym obsługi klawiatury (logika strzałek, Enter/Escape, poprawne przechodzenie fokusu). Efekt? Osoba korzystająca z VoiceOver czy NVDA może swobodnie obsłużyć wszystkie wybory w formularzu – ma pewność, co zostało zaznaczone i jak wybrać inną wartość, a aplikacja nie gubi fokusu.
Wszystkie te działania – od projektowania komponentów po drobiazgowe testy z użyciem NVDA, TalkBack i VoiceOver – sprawiły, że formularze Eximee są domyślnie czytelne dla technologii asystujących. Niewidomy użytkownik może usłyszeć cały tekst umowy kredytowej, wypełnić wniosek, zaznaczyć wymagane zgody i wysłać formularz bez żadnej pomocy z zewnątrz.
Funkcjonalność – klawiatura, gesty i czas na reakcję
Dostępność to nie tylko kwestia tego, co widać lub słychać, ale także jak można wchodzić w interakcję z aplikacją. Nie każdy użytkownik jest w stanie posługiwać się myszką czy precyzyjnie klikać na ekranie dotykowym. Dlatego aplikacja bankowa musi być całkowicie obsługiwalna za pomocą klawiatury oraz powinna unikać wymuszania skomplikowanych gestów.
WCAG wprost wymaga, by wszystkie funkcje były dostępne z poziomu klawiatury (zasada operability). Użytkownik powinien móc przejść przez cały formularz, używając klawiszy Tab/Shift+Tab, Enter, Spacji, strzałek oraz skrótów klawiaturowych oferowanych przez czytniki ekranu. Dotyczy to także elementów, które normalnie kojarzymy z interakcją myszką czy dotykiem – np. suwaków, kalendarzy czy wspomnianych list rozwijanych.
Ponadto jeśli jakaś czynność w aplikacji jest dostępna poprzez gest wielopunktowy (np. rozsuwanie dwoma palcami, żeby powiększyć obrazek) albo poprzez ruch urządzenia (np. potrząśnięcie telefonem, aby odświeżyć listę), to powinny istnieć alternatywne metody wykonania tej czynności. Innymi słowy, nie można zakładać, że każdy użytkownik wykona skomplikowany gest czy machnie telefonem – trzeba zapewnić prostszy ekwiwalent (jak przycisk powiększenia czy opcjonalne wyłączenie reakcji na ruch).
Eximee zapewnia to domyślnie. Nasze gotowe komponenty zostały tak zaprojektowane, żeby formularze złożone w Eximee były od razu nawigowalne klawiaturą. Tworząc nowy wniosek, pracownik banku nie musi osobno implementować obsługi poszczególnych klawiszy – platforma zapewnia to out of the box.
Focus kolejno przechodzi przez kolejne elementy formularza w logicznej kolejności, a złożone kontrolki (np. wybór z listy) reagują na standardowe klawisze. Jeśli jakiś komponent wymagałby nietypowej interakcji (jak wspomniany gest dwoma palcami czy potrząśnięcie urządzeniem), to Eximee umożliwia zaprojektowanie alternatywy – np. dodatkowego przycisku lub akcji, którą można przeprowadzić za pomocą jednego kliknięcia.
Co ważne, Eximee Designer unika też pułapek z jednym skrótem klawiszowym – w standardowych szablonach nie stosujemy tego typu skrótów.
Odpowiedni czas na reakcję
Warto wspomnieć także o zapewnieniu użytkownikowi odpowiedniego czasu na reakcję. Nawet najprostsza czynność, jak przepisanie kodu z SMS-a do potwierdzenia operacji, może okazać się trudna, jeśli użytkownik ma za mało czasu. Osoby starsze lub użytkownicy z niepełnosprawnościami mogą potrzebować nieco więcej czasu na odczytanie i wpisanie kodu.
Zgodnie z WCAG należy zapewnić wystarczający zapas czasu lub możliwość przedłużenia limitu. W Eximee mamy to na uwadze. Standardowe komponenty autoryzacji (np. moduł wpisywania kodu SMS) mają domyślnie ustawiony limit 5 minut na wprowadzenie kodu. Taki przedział czasowy uznaliśmy (w porozumieniu z bankiem) za bezpieczny i komfortowy dla użytkownika.
Dodatkowo Eximee umożliwia wyświetlanie czytelnego licznika, który informuje o pozostałym czasie na wpisanie kodu/dokończenie autoryzacji, dzięki czemu użytkownik wie, ile czasu mu zostało i nie działa w niepewności.
Spójność i przewidywalność – jeden standard w całej aplikacji
Wyobraźmy sobie, że w jednym wniosku bankowym pole z adresem email wygląda i działa zupełnie inaczej niż w innym wniosku tej samej instytucji. Inny przykład: od razu po wejściu przez użytkownika na daną stronę rozpocznie się działanie (np. odczytanie tekstu umowy przez czytnik), którego użytkownik w żaden sposób nie zainicjował. Nie możemy sobie pozwolić na taki chaos.
Spójność interfejsu to kryterium, które co prawda nie jest formalnie wypisanym, osobnym punktem WCAG, ale mocno wpływa na przewidywalność i użyteczność aplikacji (co już w WCAG się pojawia). Użytkownicy – zwłaszcza ci z niepełnosprawnościami – polegają na pewnych schematach. Jeśli nauczyli się obsługi jednego formularza w naszym banku, to kolejny formularz powinien działać podobnie. Dlatego dążymy do pełnej standaryzacji komponentów i doświadczeń w obrębie wszystkich aplikacji tworzonych na Eximee.
W praktyce oznacza to, że wszystkie wnioski i formularze budujemy z tej samej “paletki” komponentów. Eximee Designer udostępnia wspólne, wielokrotnie używalne elementy: pola tekstowe, listy rozwijane, przyciski, sekcje informacyjne, walidatory danych itp.
Każdy z tych komponentów jest raz zaprojektowany i dostosowany do wymogów dostępności, a potem używany konsekwentnie w wielu miejscach. Jeśli wprowadzimy poprawkę lub usprawnienie takiego komponentu, zmiana automatycznie trafia do wszystkich formularzy, które go wykorzystują. Dzięki temu mamy pewność, że dostępność jest spójna w różnych częściach systemu – trzymamy jednolity standard. Dotyczy to zarówno wyglądu (np. kolorystyka błędów, wielkość czcionek, rozmieszczenie etykiet), jak i działania (np. te same skróty klawiaturowe, jednakowe wymagania co do formatów danych w polach).
Co więcej, standaryzacja obejmuje też treści. Wspomniane wcześniej komunikaty walidacyjne to dobry przykład – raz ustalona fraza obowiązuje wszędzie. Podobnie etykiety pól: jeśli pole na numer telefonu w jednym wniosku nazywa się "Numer telefonu komórkowego" zamiast "Telefon", to w całej aplikacji stosujemy tę samą konwencję.
Taka konsekwencja ogromnie ułatwia życie użytkownikom, bo wszystko jest przewidywalne – WCAG zaleca właśnie, by interfejs działał w sposób przewidywalny i nie zaskakiwał niczym niespodziewanym. Tej zasady trzymamy się również w Eximee.
Współpraca z bankami – informacje z pierwszej ręki
Warto wspomnieć, że ściśle współpracujemy z bankami przy utrzymaniu tej spójności. Często audyty dostępności wykrywają obszary do poprawy – przykładowo, w jednym z projektów dla jednego z naszych klientów otrzymaliśmy od zewnętrznej firmy audytorskiej listę zaleceń dostosowania aplikacji do WCAG.
W jednym z projektów współpracowaliśmy na bazie makiet dostarczonych przez bank – przygotowywaliśmy dla nich m.in. tryb dark mode i poprawki w szatach graficznych, tak aby całość pozostała spójna i zgodna ze standardami.
Nasz zespół nie tylko je zaimplementował we współdzielonych komponentach, ale też pełnił rolę doradców. Bywało, że różne departamenty banku miały nieco inne spojrzenia czy priorytety odnośnie dostępności – pomagaliśmy koordynować ustalenia, tak by efekt końcowy był spójny i zgodny z WCAG. Dzięki platformie low-code mogliśmy wprowadzać zmiany szybko i hurtowo. To ogromna oszczędność czasu dla banku i gwarancja, że żaden moduł nie zostanie pominięty.
Podsumowując ten wątek: spójność i standaryzacja to klucz do utrzymania dostępności na wysokim poziomie w dłuższej perspektywie. Eximee, dzięki architekturze opartej o wspólne komponenty, umożliwia bankom skalowanie dostępności – dodawanie nowych procesów i funkcji bez ryzyka, że “zapomnimy” o dostępności w którymś miejscu.
Każdy nowy wniosek zbudowany na platformie automatycznie dziedziczy wszystkie dostępnościowe usprawnienia wypracowane wcześniej. To tak, jakby dostępność była wbudowana w DNA platformy – bank dostaje ją w pakiecie, zamiast za każdym razem projektować wszystko od zera.
Podsumowanie
Dostępność cyfrowa w bankowości to temat złożony i wielowymiarowy. Jak widać, nie sprowadza się on tylko do ustawienia kontrastu na właściwym poziomie – obejmuje zarówno warstwę wizualną, język komunikacji z użytkownikiem, wsparcie dla technologii asystujących, sposób nawigacji, jak i organizację pracy nad projektem. Kluczem jest empatia wobec użytkownika – projektowanie rozwiązań tak, aby każdy mógł z nich skorzystać samodzielnie i komfortowo. Wymaga to pewnej zmiany myślenia i dodatkowego wysiłku, ale ten wysiłek zdecydowanie się opłaca.
Jako dostawca rozwiązań staramy się maksymalnie odciążyć banki w tym zadaniu. Platforma Eximee Low-Code dostarcza “out of the box” wiele rozwiązań zgodnych z WCAG, dzięki czemu produkty tworzone z jej użyciem już na starcie spełniają większość kryteriów dostępności. Wspieramy też zespoły bankowe na każdym etapie – od projektowania aż po pomoc we wdrażaniu poprawek poaudytowych. Wszystko po to, by przyspieszyć uruchamianie dostępnych usług i mieć pewność, że końcowy użytkownik (klient banku) będzie zadowolony.
Dostępność nie musi być kulą u nogi ani przykrym obowiązkiem – z odpowiednimi narzędziami i podejściem może stać się naturalną częścią procesu tworzenia oprogramowania, tak jak bezpieczeństwo czy jakość.
Chcesz dowiedzieć się więcej? Skontaktuj się z nami i umów spotkanie!
