Baza wiedzy

Serwis internetowy musi być w pełni zgodny z obowiązującym prawem.

Wszystkie strony internetowe administracji publicznej powinny spełniać zapisy Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych Dz.U. z 2019 roku poz 848 dostępna jest pod adresem: 

Mając na uwadze powyższe, podmioty publiczne obligatoryjnie muszą wymagać od wykonawców, aby produkt końcowy, czyli serwis był zgodny z obowiązującym prawem. W tym celu proponujemy zawrzeć w umowie na przykład następujący zapis:

„Przedmiot zamówienia musi być zgodny ze wszystkimi wytycznymi WCAG 2.1 zawartymi w załączniku do Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych Dz.U. z 2019 roku poz 848 

Wykonawca oświadcza, że posiada niezbędną wiedzę i doświadczenie w zakresie standardów sieciowych i wytycznych dotyczących dostępności serwisów internetowych dla osób niepełnosprawnych, o których mowa w załączniku do Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych Dz.U. z 2019 roku poz 848 

Wszelkie poprawki serwisu wynikające z jego niedostępności i niezgodności z załącznikiem do Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych Dz.U. z 2019 roku poz 848 wykonawca zobowiązuje się wdrożyć bezzwłocznie na swój koszt w terminie 14 dni od daty wskazania błędów dostępności przez Zamawiającego.

Zamawiający zobowiązuje się zgłosić Wykonawcy w formie pisemnej wykryte wady i błędy niezgodności z wytycznymi zawartymi w załączniku do Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych Dz.U. z 2019 roku poz 848 

Przedmiotem zamówienia jest usługa przeprowadzenia specjalistycznych badań i testów dostępności cyfrowej (audytu) portalu xxxx pod kątem zgodności z rekomendacjami WCAG 2.1 zawartymi w załączniku do Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych Dz.U. z 2019 roku poz 848

Szczegółowe zalecenia w zakresie dostępności dla osób niepełnosprawnych określone przez standard Web Content Accessibility Guidelines 2.1 (WCAG) można znaleźć w języku angielskim, w Internecie pod adresem https://www.w3.org/TR/WCAG21/. 

Audyt podstawowy (pierwszy) zostanie zrealizowany w trzystopniowej procedurze gwarantującej pełne zbadanie dostępności i zgodności z zaleceniami WCAG 2.1 na poziomie ("A", "AA"). 

Pierwszym etapem audytu będzie badanie automatyczne z użyciem narzędzia do automatycznego wykrycia błędów dostępności. Wynik tego badania, z którego uproszczony raport Wykonawca przedstawi Zamawiającemu, będzie podstawą do przedstawienia przez Wykonawcę Zamawiającemu selekcji podstron serwisu, na których zostanie zrealizowany kolejny etap audytu. Wykonawca zaproponuje Zamawiającemu do zatwierdzenia narzędzie do automatycznego badania dostępności. 

Drugim etapem audytu będzie badanie serwisu przez doświadczonego audytora technicznego. Wskazane podstrony serwisu zostaną skontrolowane pod kątem dostępności cyfrowej przez audytora znającego zarówno techniki budowy stron internetowych jak i zalecenia WCAG 2.0. Wykonawca wykaże, że osoba przeprowadzająca badanie ma wystarczające doświadczenie w badaniu dostępności serwisów internetowych wskazując co najmniej pięć badań dostępności serwisów internetowych, które ta osoba przeprowadziła w ciągu ostatnich 3 lat. Przed przystąpieniem do badań wykonawca przedstawi Zamawiającemu do zatwierdzenia sposób (metodykę), jaką zastosuje podczas badania dostępności cyfrowej. Wszystkie badania dostępności cyfrowej będą wykonywane, tam gdzie jest to niezbędne, również za pomocą najczęściej używanych czytników ekranu, programów powiększających i urządzeń mobilnych. Wykonawca uzgodni z Zamawiającym zakres urządzeń i oprogramowania które zostanie użyte w badaniach dostępności.

Raport z audytu eksperckiego będzie zawierał, w każdym przypadku stwierdzenia błędu w dostępności cyfrowej, wyczerpujące rekomendacje techniczne wskazujące sposób, w jaki należy postępować by usunąć wskazany błąd.

Trzecim etapem audytu będzie badanie testerskie, czyli sprawdzenie wybranych elementów stron serwisu przez użytkowników z różnymi rodzajami niepełnosprawności zgodnie ze wskazaniami audytora technicznego realizującego drugi etap badania. Wykonawca przygotuje scenariusze badań testerskich, które przedstawi Zamawiającemu do zatwierdzenia, 

W badaniach testerskich wezmą udział testerzy: 

• Niewidomi,
• Niesłyszący, 
• Słabowidzący.

Efektem badania testerskiego będzie raport z badania testerskiego, w którym zostaną przedstawione wszystkie uwagi testerów opatrzone odpowiednim komentarzem audytora technicznego realizującego drugi etap badania wraz z niezbędnymi rekomendacjami technicznymi wskazującymi sposób, w jaki należy postępować by usunąć wskazane błędy.
Badanie zgodności serwisu z zaleceniami WCAG 2.1 ma obejmować całą zawartość wyselekcjonowanych podstron portalu xxxx obejmującą wszelkie elementy, włącznie z zawartymi na tych podstronach dokumentami.

Po przedstawieniu przez Wykonawcę i przyjęciu przez Zamawiającego raportu z audytu eksperckiego oraz raportu z badań testerskich, Zamawiający wprowadzi, w porozumieniu z Wykonawcą, niezbędne zmiany i poprawki wynikające z rekomendacji zawartych w raportach z audytu i badań testerskich. 

Po wprowadzeniu koniecznych poprawek Wykonawca przeprowadzi ponowne badanie eksperckie dostępności cyfrowej ) portalu xxxx mające w celu sprawdzenia poprawności wprowadzonych poprawek. Ponowne badanie dostępności obejmie wyselekcjonowane do pierwszego badania podstrony, jak również, jeśli okaże się to niezbędne, inne podstrony, których liczba nie przekroczy 50% liczby stron zbadanych w badaniu podstawowym.  

Dodatkowo Wykonawca po przeprowadzeniu ponownego badania przedstawi zamawiającemu tabelę odpowiadającą swoją strukturą załącznikowi do Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych Dz.U. z 2019 roku poz 848 w której wskaże kryteria sukcesu które są spełnione, które nie są spełnione, a które nie dotyczą badanego serwisu. W przypadku niespełnienia wymagań poszczególnych kryteriów sukcesu, dla każdego z nich zostanie umieszczone w tabeli wyjaśnienie i odpowiedni opis.

Dostępny serwis internetowy to nie tylko szablony stron stworzone przez projektanta oraz funkcje zaprogramowane przez zespół programistów. Bardzo ważna jest zawartość serwisu. Pracownicy urzędu, którzy aktualizują serwis, muszą mieć do swojej dyspozycji narzędzie umożliwiające wprowadzanie treści zgodnej z wytycznymi z załącznika do ustawy.

Większość systemów zarządzania treścią (CMS — ang. Content Management System) wykorzystywanych do budowy serwisów internetowych jest wyposażona w edytor treści dla redaktorów. Edytor zazwyczaj posiada pełne wsparcie dla elementów semantycznych HTML (ang. HyperText Markup Language — hipertekstowy język znaczników).

Należy pamiętać, że bardzo często, wyłącznie od Wykonawcy zależy jaki CMS zostanie wykorzystany do budowy serwisu. Aby zapobiec potencjalnym problemom z dostępnością treści proponujemy zawrzeć dodatkowo w umowie z wykonawcą następujący zapis:

„Wykonawca wraz z serwisem dostarczy Zamawiającemu zintegrowany z serwisem edytor treści zgodny z zaleceniami ATAG 2.0 (ang. Authoring Tool Accessibility Guidelines). Zaproponowane rozwiązanie musi wspierać między innymi tworzenie semantycznych elementów HTML, takich jak: nagłówki, listy wypunktowane, tytuły podstron. Edytor ponadto powinien zawierać następujące funkcjonalności: wyrównywanie bloków tekstu do danej strony, dodawanie opisów alternatywnych do elementów graficznych oraz tytułów do linków, a także umożliwiać zmianę definicji języka dla całych podstron lub pojedynczych wyrazów czy zwrotów.” 

Aby mieć pewność, że przedmiot zamówienia zostanie wykonany poprawnie wykonawca powinien wykazać się doświadczeniem w przygotowywaniu dostępnych serwisów i przedłożyć stosowne oświadczenie. Zapis w SWIZ mógłby brzmieć następująco:

„Wykonawca w raz z ofertą dostarczy oświadczenie, że posiada niezbędną wiedzę z zakresu dostępności dla osób niepełnosprawnych serwisów internetowych zgodnej z załącznikiem do ustawy.”.  

Spotykamy się często ze stwierdzeniem, że dostępne serwisy zgodne z wytycznymi, o których mowa w ustawie będą kosztować więcej od serwisów niedostępnych. Instytucje publiczne chcące zamówić nowy serwis, zgodny z wytycznymi WCAG 2.1, otrzymują niekiedy od wykonawców sygnały, że serwis taki będzie dużo droższy. Ceny, o jakich słyszeliśmy, a których wolimy tu nie powtarzać są wręcz „powalające”. Nasuwa się pytanie, czy jest to próba sprzedania drożej swojego produktu licząc na niewiedzę klienta, że dostępny serwis musi więcej kosztować? Może jednak wśród deweloperów, też panuje przekonanie, że strony dostępne są trudniejsze do zrobienia i wymagają posiadania skomplikowanej wiedzy?

Należy jednak bardzo wyraźnie powiedzieć, że strony dostępne nie powinny a wręcz nie muszą być droższe. Tworzenie stron internetowych zgodnie z obowiązującymi standardami sieciowymi jest rękojmią, że większość błędów dostępności na stronie się po prostu nie pojawi.

Pozostaje pytanie, w jaki sposób sprawdzić, czy dostarczony przez wykonawcę produkt spełnia zasady dostępności, o których mowa w ustawie.

Jeśli chcą Państwo się zabezpieczyć warto pomyśleć o audycie realizowanym przez eksperta zewnętrznego i przewidzieć środki finansowe na ten cel lub wymagać od wykonawcy dostarczenia poświadczenia dostępności serwisu.

Proponowane funkcjonalności zgodne z WCAG 2.1 na poziomie AA:

1. Wszystkie elementy graficzne muszą mieć adekwatny do pełniącej funkcji opis alternatywny lub możliwość ustawienia takiego tekstu przez redaktora. 
2. Jeśli serwis umożliwia dodawanie treści audio i wideo - odtwarzacze muszą być dostępne dla osób niepełnosprawnych. Należy sprawdzić ich dostępność również pod kątem osób korzystających wyłącznie z klawiatury oraz niewidomych użytkowników czytników ekranu. 
3. Jeśli w serwisie osadzone zostały materiały audio-wideo, powinny zawierać transkrypcje, napisy, lub audiodeskrypcję o ile zawartość tego wymaga.
4. Wszystkie strony powinny mieć możliwość stosowania nagłówków w prawidłowej hierarchii. 
5. Serwis nie może być zbudowany na bazie tabel, traktowanych jako element konstrukcji układu serwisu. 
6. Mechanizmy nawigacyjne jak np. grupy odnośników powinny być przedstawione za pomocą list.
7. Kolejność nawigacji oraz czytania, określona za pomocą kolejności w kodzie HTML musi być logiczna i intuicyjna.
8. Architektura informacji powinna być logiczna, przejrzysta, spójna i przewidywalna. 
9. Elementy nawigacyjne oraz komunikaty nie mogą polegać tylko na charakterystykach zmysłowych jak np.: kształt, lokalizacja wizualna, miejsce lub dźwięk.
10. Odnośniki zamieszczone w treściach artykułów muszą odróżniać się od pozostałego tekstu nie tylko kolorem, ale i dodatkowym wyróżnieniem np. podkreśleniem.
11. Po wczytaniu strony www dźwięk nie może być automatycznie odtwarzany.
12. Kontrast treści w stosunku do tła musi wynosić co najmniej 4,5:1. Jeśli nie jest to możliwe, np. ze względu na utrzymanie identyfikacji wizualnej instytucji lub firmy serwis powinien posiadać wersję kontrastową posiadającą taką samą zawartość i funkcjonalność jak wersja graficzna, przy czym: 
    1. Przycisk przełączenia na wersję kontrastową powinien być dobrze widoczny i spełniać minimalne wymagania kontrastu.
    2. W wersji kontrastowej powinien być dobrze widoczny przycisk powrotu do pierwotnej kolorystyki. Nie należy zapominać o użytkownikach korzystających z trybów dużego kontrastu dostępnych np. w systemie operacyjnym MS Windows. Wówczas również wszystkie informacje, elementy nawigacyjne i formularze muszą być widoczne.
13. Typografia tekstów i kontrasty muszą być zaprojektowane pod kątem czytelności. 
14. Po powiększeniu w przeglądarce rozmiaru czcionki do 200% nie może nastąpić utrata zawartości lub funkcjonalności serwisu. Jeśli powiększenie czcionki następuje poprzez zaimplementowany na stronie mechanizm, wówczas:
    1. Przycisk powiększenia powinien zmieniać nie tylko tekst artykułu, ale również wielkość tekstu nawigacji i innych bloków treści strony.
    2. Wybrany rozmiar czcionki powinien zostać zapamiętany w obrębie wszystkich podstron przynajmniej na czas trwania sesji użytkownika.
    3. Przyciski powiększenia powinny być widoczne.
    4. Przyciski powiększenia powinny być dostępne z poziomu klawiatury.
15. Treści nie mogą być przedstawione za pomocą grafiki, jeśli ta sama prezentacja wizualna może być zaprezentowana jedynie przy użyciu tekstu. Wyjątkiem jest tekst, który jest częścią logo lub nazwy własnej produktu.
16. Nawigacja w serwisie powinna być również możliwa używając tylko klawiatury (bez użycia myszki).  
17. Fokus powinien być widoczny, a najlepiej wzmocniony i spełniać minimalne wymagania kontrastu.
18. Wszystkie informacje, które będą automatycznie przesuwane i widoczne dłużej niż 5 sekund lub automatycznie się aktualizują, muszą posiadać mechanizm, który pozwoli na ich zatrzymanie lub ukrycie.
19. Nie mogą być prezentowane treści zwiększające ryzyko napadu padaczki, czyli takie, które migają więcej niż 3 razy na sekundę i zawierają dużo czerwieni.
20. Pierwszym elementem w kodzie HTML powinno być menu służące do przeskoczenia, bez przeładownia strony, do istotnych treści serwisu za pomocą kotwic („skip links”).
21. Wszystkie strony serwisu muszą mieć unikalne tytuły. 
22. Odnośniki będące częścią nawigacji jak np. rozwinięcia artykułów („więcej”, „czytaj więcej”) muszą być uzupełnione tak, aby były zrozumiałe i jednoznacznie informowały użytkownika, dokąd go zaprowadzą lub jaką akcję wykona. 
23. Poza standardową nawigacją muszą być jeszcze inne sposoby odnalezienia informacji jak np. mapa strony i wyszukiwarka.
24. Musi być zdefiniowany główny język dokumentu adekwatny do wersji językowej. Mechanizm edycji treści musi mieć możliwość definiowania języka dla poszczególnych treści zamieszczonych na podstronach (atrybut „lang”).
25. Nie mogą być stosowane mechanizmy, które powodują przy zmianie ustawień jakiegokolwiek komponentu interfejsu użytkownika, automatyczną zmianę kontekstu.
26. Serwis powinien zawierać mechanizm pozwalający na ostrzeganie o otwieraniu się wybranych stron w nowym oknie. Tego rodzaju rozwiązanie np. w postaci uzupełnienia w samym odnośniku można wdrożyć w algorytmie serwisu. 
27. Dynamiczne zmiany treści jak np. komunikaty w okienkach dialogowych, ostrzeżenia, itp. (odbywające się bez przeładowania strony) powinny być opatrzone odpowiednimi atrybutami ARIA.
28. Wszystkie pola formularzy muszą być opatrzone etykietami. Muszą jednoznacznie informować o błędach lub sukcesie po ich wypełnieniu. W przypadku wystąpienia błędów system powinien sugerować jego rozwiązanie.
29. Jako zabezpieczenie formularzy nie może być zastosowane rozwiązanie CAPTCHA, bazujące tylko na charakterystykach zmysłowych jak wzrok czy słuch. Dozwolone są inne metody jak np. proste zadanie matematyczne. 
30. Całkowita zgodność ze standardami HTML całego serwisu (zarówno szablonów, jak i kodu generowanego z edytora treści, w którym pracuje redaktor).