Nie wahaj się proponować zmian. Możesz komentować, uzupełniać, redagować każdy fragment dokumentu.
Poradnik: Cykl życia technologii informacyjno-komunikacyjnej
Rozdział 1. Faza koncepcji i definiowania wymagań
To moment, kiedy pojawia się pomysł - zanim jeszcze powstanie dokument, strona czy aplikacja. To kluczowy etap, bo decyzje podjęte tutaj wpływają na cały projekt. Jeśli dostępność cyfrowa zostanie pominięta na starcie, jej zapewnienie na późniejszych etapach może być trudniejsze i droższe.
1.1 Wymagania prawne
Na etapie planowania każdego nowego produktu cyfrowego organizacja powinna przeprowadzić wstępną analizę prawną. Jej celem jest ustalenie, które regulacje prawne z zakresu dostępności dotyczą danego projektu.
Część ustaw i dyrektyw dotyczących dostępności cyfrowej obowiązuje wszystkie podmioty publiczne. W zależności od charakteru projektu mogą pojawić się dodatkowe wymogi, np. związane z edukacją, ochroną zdrowia, sądownictwem, usługami transgranicznymi czy danymi wrażliwymi.
Dlatego każda instytucja powinna zadać sobie pytanie:
„Jakie akty prawne i standardy obowiązują nas w odniesieniu do produktu cyfrowego, który planujemy?"
Uwzględnienie analizy prawnej już na etapie koncepcji pozwala zaplanować
adekwatne i trwałe rozwiązania oraz uniknąć ryzyka niezgodności z
przepisami.
Zgodnie z ustawą o dostępności cyfrowej i wytycznymi WCAG:
-
WCAG 2.1 AA to obecnie wymagany standard dostępności - obowiązuje wszystkie strony, dokumenty i aplikacje objęte ustawą. Warto jednak sięgnąć po WCAG 2.2, bo dodaje nowe, praktyczne zasady, które jeszcze lepiej odpowiadają na potrzeby użytkowników - na przykład osób korzystających z urządzeń mobilnych albo mających problemy z koncentracją. Stosowanie WCAG 2.2 już teraz pozwala tworzyć bardziej przyjazne i nowoczesne rozwiązania cyfrowe, a także przygotowuje nas na przyszłe zmiany przepisów.
-
W opisie zamówienia wymagaj, aby produkt końcowy - strona internetowa, aplikacja czy dokument - był zgodny z wymaganiami dostępności, np. według standardu WCAG. Dzięki temu wykonawca/ dostawca od początku wie, że dostępność jest jednym z kluczowych obszarów jakości i musi być traktowana z odpowiednią uwagą. Można też zażądać od wykonawcy przedstawienia przykładów wcześniejszych projektów spełniających te standardy, a także zaplanować testy dostępności cyfrowej jako element odbioru prac.
-
Gdy nie da się zapewnić pełnej dostępności cyfrowej, trzeba zapewnić alternatywny dostęp. Oznacza to, że użytkownik musi mieć możliwość dotarcia do tych samych informacji lub usług inną drogą - na przykład przez rozmowę telefoniczną, kontakt e-mailowy albo udostępnienie uproszczonej wersji treści. Ważne, aby ta alternatywa była łatwa do znalezienia i szybka w użyciu. W przypadku materiałów wideo z transmisji na żywo, trzeba je uzupełnić o napisy lub tłumaczenie na Polski Język Migowy, tak by nikt nie został wykluczony z dostępu do treści.
-
Jeśli jakiś element strony, dokumentu lub aplikacji nie jest dostępny, należy to wyjaśnić i udokumentować. Najczęściej przyczyną są wysokie koszty lub ograniczenia techniczne, ale samo stwierdzenie nie wystarczy. Trzeba przygotować konkretne uzasadnienie, w którym wyjaśni się, dlaczego nie dało się spełnić wymagań dostępności oraz jakie działania alternatywne zostały zaplanowane. Taki opis musi być publicznie dostępny, np. w deklaracji dostępności. Dodatkowo każda instytucja objęta ustawą ma obowiązek prowadzenia rocznego sprawozdania, w którym uwzględnia m.in. liczbę zgłoszeń dotyczących braku dostępności oraz sposób, w jaki na nie zareagowano.
-
Stosujemy normę PN ETSI EN 301 549, ponieważ jest to oficjalny europejski standard opisujący wymagania techniczne dla produktów i usług cyfrowych, które mają być dostępne dla wszystkich, w tym dla osób z niepełnosprawnościami. Norma ta jest ściśle powiązana z Dyrektywą o dostępności stron internetowych i aplikacji mobilnych sektora publicznego (UE 2016/2102), która zobowiązuje instytucje publiczne w całej Unii Europejskiej do zapewnienia dostępności swoich serwisów cyfrowych. Norma ta zawiera konkretne wytyczne dotyczące stron internetowych, dokumentów elektronicznych, aplikacji mobilnych, a także sprzętu i oprogramowania. Dobrze jest się z nią zapoznać już na etapie planowania, by uniknąć błędów projektowych i ułatwić spełnienie przepisów prawa.
1.2 Dobre praktyki w planowaniu
Już na początku trzeba:
-
Zidentyfikować możliwie szerokie spektrum potrzeb użytkowników, wynikających z różnorodnych sposobów korzystania z technologii - niezależnie od wieku, poziomu kompetencji cyfrowych, używanych urządzeń czy technologii wspomagających. Celem nie jest wyodrębnianie konkretnych grup, lecz projektowanie produktów cyfrowych w sposób dostępny dla wszystkich użytkowników, zgodnie z zasadą dostępności uniwersalnej i wymaganiami WCAG. Dostępność cyfrowa nie jest opcją, lecz podstawową cechą dobrej jakości usług
- jej uwzględnianie od początku projektowania pozwala realnie odpowiedzieć na potrzeby wszystkich użytkowników.
-
Sprawdzić, jakie mamy przepisy i wewnętrzne procedury, które mogą mieć wpływ na dostępność - zarówno te wynikające z przepisów prawa (np. ustawa o dostępności cyfrowej, Kodeks pracy, prawo zamówień publicznych), jak i regulacje wewnętrzne organizacji. Warto też sprawdzić, czy istnieją instrukcje tworzenia treści, zasady prowadzenia serwisów internetowych lub standardy projektowe, które mogą wspierać albo utrudniać realizację zasad dostępności. Dzięki temu można zidentyfikować luki i uzupełnić je na możliwie wczesnym etapie, zanim projekt wejdzie w fazę realizacji.
-
Ocenić, jak wygląda dostępność w naszej organizacji - warto przyjrzeć się temu, czy pracownicy wiedzą, czym jest dostępność cyfrowa i czy przeszli odpowiednie szkolenia. Dobrze też sprawdzić, czy mamy narzędzia do tworzenia dostępnych treści - np. edytory dokumentów ze wsparciem dla WCAG, czytniki ekranu do testowania lub szablony dostępnych stron. Warto zapytać samych pracowników, z jakimi barierami się spotykają i jakie wsparcie byłoby dla nich pomocne.
-
Zaplanować budżet na wszystkie działania związane z dostępnością cyfrową - w tym szkolenia dla zespołu, testy użyteczności i dostępności (zarówno automatyczne, jak i z udziałem użytkowników), a także późniejsze poprawki i wdrożenie rekomendacji. Warto też uwzględnić koszty licencji narzędzi wspierających dostępność, tłumaczeń na PJM czy opracowania alternatywnych wersji treści.
-
Wybrać technologie i wykonawców, którzy mają doświadczenie z dostępnością - warto postawić na takie narzędzia i rozwiązania, które wspierają tworzenie treści zgodnych z WCAG (np. edytory z wbudowaną walidacją dostępności, systemy CMS z możliwością edycji tekstu alternatywnego, kontrastów czy struktur nagłówków). Równie istotny jest wybór wykonawców - należy sprawdzić ich doświadczenie, zapytać o wcześniejsze projekty, poprosić o referencje oraz zapisywać wymagania dostępności w umowie, w tym również warunek wykonania testów przed końcowym odbiorem.
-
Dodać dostępność do dokumentów przetargowych - należy jasno wpisać w dokumentację przetargową wymagania dotyczące dostępności cyfrowej, np. obowiązek spełniania kryteriów sukcesu standardu WCAG 2.1 poziomu AA lub WCAG 2.2, poziomu AA, uwzględnienie normy PN ETSI EN 301 549 oraz przeprowadzenie testów dostępności przed odbiorem. Warto dodać, że brak spełnienia wymagań dostępności może być podstawą do odrzucenia wykonania lub naliczenia kar umownych. Takie zapisy zwiększają szanse, że wykonawca potraktuje dostępność poważnie i od początku uwzględni ją w procesie projektowania i realizacji. W opisie przedmiotu zamówienia warto wyodrębnić sekcję wymagań z obszaru dostępności cyfrowej i zgrupować w niej wszystkie stawiane warunki.
1.3 Na co zwrócić uwagę w zależności od produktu
Różne typy produktów cyfrowych mają swoje specyficzne wymagania w zakresie dostępności. Już na etapie koncepcji warto zidentyfikować, jaki typ produktu planujemy - czy będzie to dokument, strona internetowa, czy aplikacja mobilna - i odpowiednio dostosować listę pytań oraz kryteriów dostępności. Poniżej przedstawiamy zestawienie najważniejszych zagadnień dla każdego z tych trzech typów.
Dokumenty
- Jakie typy dokumentów będą tworzone? Czy będą to pliki PDF, DOCX, arkusze kalkulacyjne, prezentacje?
- Czy mamy dostępne i stosujemy szablony zgodne z zasadami WCAG i standardem EN?
- Czy pracownicy używają stylów nagłówków, list i tabel zamiast ręcznego formatowania, co ułatwia nawigację osobom korzystającym z czytników ekranu?
- Czy zapewniamy opisy alternatywne dla grafik i zdjęć w dokumentach?
- Jak wygląda proces sprawdzania dostępności dokumentów przed ich publikacją - czy używamy narzędzi takich jak wbudowane testery dostępności w pakiecie Office lub Adobe Acrobat Pro?
Strony internetowe
- Czy tworzymy nową stronę czy modernizujemy istniejącą - i jaki zakres zmian planujemy? Czy planowane zmiany są istotne, co może mieć wpływ na konieczność aktualizacji deklaracji dostępności.
- Jakiego systemu zarządzania treścią (CMS) używamy - czy pozwala on na edycję kodu, dodawanie opisów alternatywnych, ustalanie kontrastu i struktury nagłówków?
- Czy dostępność jest ujęta w procesie projektowania UX i UI?
- Czy planujemy testy z użytkownikami, w tym z osobami z niepełnosprawnościami?
- Jakie zasady nawigacji obowiązują na stronie - czy możliwa jest obsługa wyłącznie klawiaturą?
- Czy formularze, przyciski i linki mają jednoznaczne etykiety i odpowiedni kontrast?
- Czy treści są pisane językiem prostym i zrozumiałym?
Aplikacje mobilne
- Czy aplikacja będzie działać tylko na telefonach z systemem Android lub iOS (tzw. aplikacja natywna), czy też będzie działać przez przeglądarkę internetową, jak strona (tzw. aplikacja webowa lub PWA)? A może będzie to rozwiązanie mieszane, tzw. hybrydowe?
- Czy testujemy aplikację na różnych urządzeniach , wersjach systemów operacyjnych oraz najbardziej popularnych przeglądarkach i ich aktualnych wersjach?
- Czy interfejs aplikacji jest dostępny dla użytkowników korzystających z VoiceOver, TalkBack i innych narzędzi wspomagających?
- Czy zadbaliśmy o odpowiednią wielkość elementów interaktywnych i odstępy między nimi?
- Czy aplikacja umożliwia zmianę rozmiaru tekstu i kontrastu? Względnie
- czy rozmiar tekstu i kontrast będą zapewnione domyślnie (by design) na właściwym poziomie?
- Czy użytkownik znajdzie informację o dostępności aplikacji w opisie w App Store i Google Play?
- Czy przeprowadzono testy z udziałem użytkowników z niepełnosprawnościami lub uwzględniono ich potrzeby w fazie projektowania?
Takie podejście pomaga już od początku zaplanować konkretne działania i uniknąć błędów, które później są kosztowne do naprawienia. To również dobra baza do stworzenia listy kontrolnej i oceny zgodności z wymaganiami prawnymi.
1.4 Lista kontrolna - faza koncepcji i definiowania wymagań
| Nr | Kryterium kontrolne | Tak | Nie | Uwagi |
|---|---|---|---|---|
| 1 | Czy przeprowadzono wstępną analizę obowiązujących przepisów prawa, w tym ustaw o dostępności oraz ewentualnych regulacji branżowych lub wewnętrznych, mających zastosowanie do planowanego produktu cyfrowego? | |||
| 2 | Czy zidentyfikowano wszystkie potencjalne grupy użytkowników? | |||
| 3 | Czy przeprowadzono analizę ryzyka dostępności? | |||
| 4 | Czy zaplanowano budżet na działania związane z dostępnością? | |||
| 5 | Czy w dokumentacji projektowej uwzględniono wymagania WCAG i EN 301 549? | |||
| 6 | Czy określono osoby odpowiedzialne za dostępność? | |||
| 7 | Czy zaplanowano działania naprawcze i alternatywne sposoby dostępu (w tym 14 dni na multimedia)? | |||
| 8 | Czy ustalono standardy i narzędzia do tworzenia dostępnych dokumentów? | |||
| 9 | Czy określono technologię i platformy zapewniające dostępność stron i aplikacji? | |||
| 10 | Czy zaplanowano procedury testowania i walidacji dostępności? |