W celu świadczenia usług na najwyższym poziomie stosujemy pliki cookies. Korzystanie z naszej witryny oznacza, że będą one zamieszczane w Państwa urządzeniu. W każdym momencie można dokonać zmiany ustawień Państwa przeglądarki. Zobacz politykę cookies.
Powrót

Jak zamówić dostępny serwis internetowy?

Pojawia się już sporo pytań o to, w jaki sposób zamówić dostępny serwis internetowy?

W polskim prawie, od 30 maja 2012 roku, obowiązują przepisy nakładające na instytucje administracji publicznej, obowiązek dostosowania istniejących serwisów internetowych do potrzeb osób niepełnosprawnych. Ostateczny termin dostosowania — najpóźniej do maja 2015 roku.

Decydując się na uruchomienie nowego serwisu internetowego lub nowej wersji istniejącego serwisu, jego właściciel jest zobowiązany zapewnić dostępność od razu na etapie uruchomienia. Kiedy serwis powstanie, obowiązkiem właściciela jest dbać i kontrolować dostępność — serwis internetowy zmienia się i aktualizuje, niekiedy nawet z dnia na dzień.

W umowie z wykonawcą serwisu — firmą zewnętrzną lub osobą fizyczną, z którą zawieramy umowę cywilnoprawną, trzeba zawrzeć odpowiednie zapisy, które zabezpieczą zamawiającego. Będą gwarantem dostarczenia nam dostępnego serwisu, a ewentualne bariery dostępności wykonawca będzie musiał poprawić we własnym zakresie w ramach niedotrzymania warunków umowy. Innym problemem jest rzeczywiste wyegzekwowanie dostępnego produktu od wykonawcy.
 

Obowiązujące ustawodawstwo

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: 

Materiały

http://www.dziennikustaw.gov.pl/du/2019/848/1?fbclid=IwAR2xBB8T2cWUASKSd3n2GmgiknCAT72Qg4Ga-4R3R7BnOKVtjc7u9uuKBcE

Co wpisać w umowę z podwykonawcą?

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 

Audyt zgodności WCAG 

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.0 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.0 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.

Edytor treści

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 nr 4 Rozporządzenia.

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.” 
 

Jak wybrać wykonawcę?

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.”.  

Dostępny czy droższy?

Spotykamy się często ze stwierdzeniem, że dostępne serwisy zgodne z wytycznymi, o których mowa w rozporządzeniu wspominanym poniżej, będą kosztować więcej od serwisów niedostępnych. Instytucje publiczne chcące zamówić nowy serwis, zgodny z wytycznymi WCAG 2.0, 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.

Weryfikacja zgodności dostarczonego przedmiotu zamówienia z zapisami SIWZ i obowiązującym prawem

Pozostaje pytanie, w jaki sposób sprawdzić, czy dostarczony przez wykonawcę produkt spełnia zasady dostępności, o których mowa w wytycznych Ministerstwa Pracy i Polityki Społecznej oraz załączniku nr 4 do Rozporządzenia?

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.

WYMAGANIA TECHNICZNE/ FUNKCJONALNE

Proponowane funkcjonalności zgodne z WCAG 2.0 na poziomie AA zgodnie z zał. 4 do Rozporządzenia o KRI. 
Tworzenie WWW ułatwi zastosowanie m.in. poniższych zasad:

  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 lub napisy, 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).
Informacje o publikacji dokumentu
Ostatnia modyfikacja:
22.05.2019 11:53 administrator gov.pl
Pierwsza publikacja:
22.05.2019 11:53 administrator gov.pl