MAPA - PROCES TWORZENIA DOSTĘPNEGO SERWISU INTERNETOWEGO ZGODNEGO Z WCAG 2.0 NA POZIOMIE AA*

~ 05-05-2015
  1. ZDOBĄDŹ WIEDZĘ
    • Czym jest „dostępny serwis www”?
    • Jak poszczególne grupy osób niepełnosprawnych(ON) poruszają się po Internecie?
  2. MYŚL KATEGORIAMI DOSTĘPNOŚCI
    • Stwórz stanowisko koordynatora (lidera) ds. dostępności w swojej instytucji.
    • Zapewnij szkolenia w zakresie standardów dostępności dla pracowników odpowiedzialnych za zarządzanie informacjami i usługami cyfrowymi w serwisach internetowych, za które odpowiadasz.
  3. UWZGLĘDNIJ ZASADY DOSTĘPNOŚCI NA ETAPIE PLANOWANIA SERWISU
  4. OPRACUJ DOKUMENTACJĘ
    •             Sporządź dokumentację ofertową (SIWZ, zapytanie ofertowe) uwzględniając w niej zapisy wymagające od wykonawcy odpowiedniego wdrożenia strony internetowej lub jej modernizacji w zgodzie ze standardami dostępności.
    • Opracuj zamówienia i umowy na: wykonanie serwisu, audyt strony www i przeprowadzenie szkoleń.
  5. NARZĘDZIA
  6. WSPÓŁPRACUJ Z EKSPERTAMI
    •             Zatrudnij doradcę -> Kto jest ekspertem?
    •             Uczestnicz w konferencjach i innych wydarzeniach popularyzujących problematykę dostępności serwisów internetowych.
  7. WYBIERZ DOŚWIADCZONEGO WYKONAWCĘ

            Weryfikuj kompetencje i doświadczenie wykonawcy -> Jak wybrać wykonawcę?

  1. WSPÓŁPRACUJ Z WYKONAWCĄ

            Organizuj spotkania i warsztaty podczas realizacji projektu.

  1. PRZEPROWADŹ AUDYT STRONY WWW

            Weryfikuj kompetencje i doświadczenie audytora -> Jak wybrać audytora?

  1. REDAGUJ DOSTĘPNE TREŚCI, DOKUMENTY, MULTIMEDIA

            Zapewnij szkolenie dla twórców www i dla redaktorów -> Zakres szkolenia.

  1. PAMIĘTAJ, ŻE DOSTĘPNOŚĆ TO PROCES

* Paragraf 19 Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych z dnia 12 kwietnia 2012 roku. Poziom wymagań dla poszczególnych  funkcjonalności serwisu internetowego określono w załączniku nr 4 do rozporządzenia.

1.        ZDOBĄDŹ WIEDZĘ

Aby zrozumieć, jak ważna jest dostępność stron internetowych i jakie przynosi korzyści – zarówno użytkownikom, jak i osobom zarządzającym serwisami, trzeba dowiedzieć się, na czym ona polega, jakie są jej zasady, standardy i sposoby wdrażania i stosowania w codziennej praktyce. Który serwis jest dostępny, a który nie? Co zrobić, by zapewnić jego dostępność? Jak osoby z niepełnosprawnością korzystają z Internetu? Jak porusza się po stronach osoba niewidoma, jak niedowidząca, z jakich rozwiązań korzystają osoby z zaawansowaną niepełnosprawnością motoryczną? Dlaczego tak ważne jest, aby zapewnić odpowiednią zrozumiałość treści dla osób niesłyszących?

Stan wiedzy na temat dostępności informacji cyfrowej można skutecznie podnieść, nie ponosząc kosztów, poprzez studiowanie literatury tematu, śledzenie stron internetowych i wiadomości na portalach społecznościowych, a przede wszystkim uczestnictwo w szkoleniach, seminariach i konferencjach oraz korzystanie ze szkoleń e-learningowych.

W zakładce „Publikacje” portalu Polskiej Akademii Dostępności została zebrana większość wydanych w Polsce publikacji na powyższy temat (Pełna Bibliografia wkrótce).

 

 

2.        MYŚL KATEGORIAMI DOSTĘPNOŚCI

Nie każdy programista zna zasady programowania dostępnego, mało który informatyk wie, jakie są standardy dostępności i jak je stosować. Wiedzy na ten temat nie mają też zatrudnieni w urzędach specjaliści ds. funduszy unijnych.

Dla prawidłowego i zgodnego z wymogami polskiego prawa zarządzania informacją i usługami cyfrowymi warto na stałe pozyskać specjalistę z zakresu dostępności i zatrudnić jako koordynatora. Dostępność informacji cyfrowej to nie tylko dostępna strona, ale także dostępne dokumenty (np. pdf, doc) czy dostępne rozwiązania technologiczne (np. automaty kolejkowe).

Koordynator ds. dostępności przyda się również podczas realizacji projektów z funduszy unijnych. W nowej perspektywie finansowej (2014-2020) temat dostępności jest bardzo mocno zaznaczony. Produkty wszystkich projektów z funduszy UE muszą być w pełni dostępne dla osób z niepełnosprawnością.

Linki do studiów i warsztatów:

Linki do konferencji:

Zaproszenia:

Materiały z konferencji archiwalnych:

•          E-dostępność sektora publicznego w Polsce 2013

 

3.        UWZGLĘDNIJ ZASADY DOSTĘPNOŚCI NA ETAPIE PLANOWANIA SERWISU

Planując utworzenie lub modernizację serwisu internetowego, trzeba od razu uwzględnić jego dostępność. Pozwoli to na ujęcie dostępności w dokumentacji projektowej. Ma to także bezpośrednie przełożenie na koszt realizacji – dostosowanie już funkcjonującego serwisu do standardów dostępności jest wielokrotnie droższe od utworzenia serwisu zgodnego ze standardami dostępności.

Standardy dostępności wpływają na odpowiedni kontrast www, czcionki i interlinie. Jeżeli grafik pracujący nad serwisem będzie o tym wiedział od początku, znacznie poprawi to jakość jego pracy.

4.        OPRACUJ DOKUMENTACJĘ

4.1      TYTUŁ ZAMÓWIENIA. /SIWZ, UMOWA/

Zamówienie na budowę lub modyfikację strony dostosowanej do potrzeb osób zagrożonych wykluczeniem cyfrowym. To szeroka grupa, która obejmuje nie tylko osoby z niepełnosprawnościami, ale także np. ludzi starszych lub korzystających z urządzeń mobilnych, czy wręcz przeciwnie: z przestarzałego oprogramowania lub limitowanego Internetu.

Każde zapytanie ofertowe – czy w ramach Prawa Zamówień Publicznych czy też zapytania ofertowego, konkursu ofert lub przetargu dotyczącego stworzenia bądź modernizacji serwisu internetowego, musi zawierać zapisy wskazujące na konkretne wymagania dotyczące standardów dostępności. Dokument ten – np. Specyfikacja Istotnych Warunków Zamówienia – musi zawierać zapisy w trzech obszarach: prawnym, technicznym i merytorycznym.

W obszarze merytorycznym KONIECZNE jest takie ujęcie wymogów, jakie będzie musiał spełnić wykonawca. Wyeliminuje to oferentów przypadkowych, bez wymaganych kompetencji bądź nieuczciwych.

4.2      PODSTAWY PRAWNE. /SIWZ, UMOWA/

Zaznacz, że strona musi być zgodna ze standardami i wytycznymi.

Kluczowy będzie zapis o zgodności zamawianego serwisu przynajmniej z wytycznymi WCAG 2.0. zawartymi w załączniku nr 4 do Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 16 maja 2012 poz. 526). To absolutne minimum wymagane prawem.

Rozporządzenie nie reguluje tłumaczeń migowych i udogodnień w transmisji online. W praktyce część instytucji (np. Sejm i Senat) wdraża tłumaczenia migowe i napisy na żywo w transmisji online powołując się na art 3 ustawy o dostępie do informacji publicznej z dnia 6 września 2001 roku (Dz.U. 2001 nr 112 poz. 1198). Samorządy, które zamieszczają na swoich stronach www informacje w języku migowym jako podstawę prawną podają ustawę o języku migowym i innych środkach wspierania komunikacji z dnia 19 sierpnia 2011 roku (Dz.U. 2011 nr 209 poz. 1243), w której dostępne strony internetowe wymienione są jako alternatywna forma komunikacji.

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

  1. Typografia tekstów i kontrasty muszą być zaprojektowane pod kątem czytelności.
  2. 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.
  1. 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.
  2. Nawigacja w serwisie powinna być również możliwa używając tylko klawiatury (bez użycia myszki).
  3. Fokus powinien być widoczny, a najlepiej wzmocniony i spełniać minimalne wymagania kontrastu.
  4. 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.
  5. 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.
  6. 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”).
  7. Wszystkie strony serwisu muszą mieć unikalne tytuły.
  8. 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.
  9. Poza standardową nawigacją muszą być jeszcze inne sposoby odnalezienia informacji jak np. mapa strony i wyszukiwarka.
  10. 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”).
  11. Nie mogą być stosowane mechanizmy, które powodują przy zmianie ustawień jakiegokolwiek komponentu interfejsu użytkownika, automatyczną zmianę kontekstu.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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).

Funkcjonalności WCAG 2.0 na poziomie AAA (zgodne z ustawą o języku migowym)

Dodatkowo wybrane treści w serwisie zostaną opatrzone filmem wideo z tłumaczeniem migowym zgodnie z wytycznymi WCAG 2.0 poziom AAA w zakresie tłumaczeń migowych w związku z ustawą z dnia 19 sierpnia 2011 r. o języku migowym i innych środkach wspierania komunikacji (Dz.U. nr 209 poz. 1243).

Praktyczne zalecenia w zakresie realizacji tłumaczeń:

Więcej w polskim tłumaczeniu WCAG 2.0 http://www.fdc.org.pl/wcag2/index.html

5.        NARZĘDZIA

Aby aktualizacja dostępnego serwisu była dla redaktora możliwa, musi on posiadać dostosowany do tego edytor, będący częścią systemu zarządzania treścią (Content Management System – CMS). Jako, że wybór CMS zależy wyłącznie od wykonawcy, by zapobiec późniejszym problemom lub utrudnieniom, zapotrzebowanie w tym zakresie warto zaznaczyć w dokumentacji.

Warto rozważyć zobowiązanie wykonawcy, że wraz z serwisem dostarczy zintegrowany z systemem CMS edytor treści, który będzie zgodny z zaleceniami ATAG 2.0 (ang. Authoring Tool Accessibility Guidelines) z części B, która wymaga wsparcia od narzędzia tworzenie dostępnych treści. Zaproponowane rozwiązanie musi wspierać między innymi tworzenie semantycznych elementów HTML takich jak: nagłówki, akapity, listy wypunktowane oraz numerowane, cytaty, tabele, skróty, odnośniki, 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 pojedynczych wyrazów i zwrotów. Przykładem takiego edytora treści jest TinyMCE, który został wykorzystany m.in. w Polskiej Akademii Dostępności.

Dodatkowo, jeśli CMS ma być przystosowany do obsługi przez osoby z niepełnosprawnościami sensorycznymi, należy zadbać o jego dostępność zgodnie z WCAG 2.0. AA

6.        WSPÓŁPRACUJ Z EKSPERTAMI

DORADCA

Warto skorzystać z rady specjalisty. Zatrudnienie eksperta jest w ogólnym bilansie mniej kosztowne niż dokonywanie poprawek i dostosowań w nieskończoność. Jak wynika z badań, budowa serwisu wyposażonego w rozwiązania zgodne ze standardami dostępności praktycznie nie podnosi kosztu realizacji, dostosowanie już istniejącego do tych standardów może wynieść nawet 25 % kosztów jego utworzenia.

Ekspert pomoże zrozumieć załącznik 4 do rozporządzenia, rozpozna potrzeby, doradzi jak przygotować dokumentację projektową i jak sporządzić umowę z wykonawcą. Pomoże zweryfikować dostarczone w ofertach dane dotyczące wykonanych realizacji, doświadczenie, referencje oraz zaproponowaną przez oferenta metodologię badawczą. Będzie dostępny na każdym etapie realizacji projektu oraz podczas wdrożenia zaleceń poaudytowych.

Doradca pracuje dla Ciebie, nie dla wykonawcy, współpracując z nim będziesz miał pewność, że produkt finalny będzie spełniał wszelkie standardy.

Kto jest ekspertem w zakresie dostępności?

Osoba, która:

7.        WYBIERZ DOŚWIADCZONEGO WYKONAWCĘ

WYBÓR WYKONAWCY

Upewnij się, że wykonawca właściwie rozumie znaczenie dostępności serwisu, a końcowy produkt będzie spełniał wymagania postawione przez prawo. Wraz z ofertą poproś o listę referencyjną wykonanych projektów. Ich analiza pokaże, czy firma rozumie, o co chodzi.

W umowie zapisz:

8.        PRZEPROWADŹ ZEWNĘTRZNY AUDYT WWW

AUDYT 

To badanie pozwala ustalić, w jakim stopniu serwis spełnia standardy dostępności i na ile jest funkcjonalny dla użytkowników.

Kiedy przeprowadza się audyt?

Przed zleceniem przebudowy serwisu zadaniem audytu jest ustalenie elementów wymagających dostosowania.

 

W tej sytuacji dokument powinien być załącznikiem do specyfikacji zlecenia. Z kolei w przypadku budowy nowego serwisu, audyt powinien zostać wykonany po zakończeniu prac, przed podpisaniem protokołu zdawczo-odbiorczego.

Wdrożenie zaleceń poaudytowych powinno stanowić warunek odbioru serwisu. Aby audyt był wiarygodny, powinna przeprowadzać go inna firma niż wykonująca zlecenie.

Czym jest audyt?

Audyt dostępności stron internetowych powinien uwzględniać przeprowadzenie analizy automatycznej, badania eksperckiego oraz badania z udziałem osób niepełnosprawnych. Wykazanie niezgodności ze standardem oraz przedstawienie sposobów naprawy odnalezionych błędów.

Jak wybrać audytora?

Wybierając audytora, podobnie jak przy wyborze wykonawcy www, należy zapoznać się z jego doświadczeniem, rekomendacjami oraz przeanalizować zrealizowane projekty. Doświadczenie powinno być udokumentowane.

Minimalnym wymogiem jest przeprowadzenie w przeciągu 5 lat poprzedzających realizację zlecanego audytu co najmniej 50 audytów dostępności z raportem o błędach i propozycjami ich rozwiązania (weryfikowalna lista adresów www). Potwierdzeniem jakości przeprowadzonych audytów jest 10 rekomendacji lub protokołów odbioru dotyczących przeprowadzonych audytów.

Konieczne jest także załączenie noty metodologicznej stanowiącej załącznik do oferty. W nocie powinna być opisana metoda organizacji i przebieg audytu stron www:  1. sposób prowadzenia analizy eksperckiej (metody, techniki, narzędzia), 2. sposób prowadzenia testów user experience (uczestnicy testów, przygotowanie zadań, wymagania sprzętowe, miejsce przeprowadzenia badania, narzędzia do wykonania zadań). Wynikiem audytu jest raport końcowy, zawierający wyniki badań wraz z rekomendacjami konkretnych rozwiązań. Standardem jest także przeprowadzenie reaudytu po wdrożeniu uwag – wymóg ten powinien zostać zapisany w umowie na przeprowadzenie audytu www.

Przykład metodologii badania dostępności stron www opracowanej przez Fundację Widzialni i Uniwersytet Śląski http://widzialni.org/pobierz,metodologia-badania-dostepnosci-stron-www,11

 

 

9.        WSPÓŁPRACUJ Z WYKONAWCĄ

Zaplanuj wspólne warsztaty. Zorganizuj warsztat poaudytowy z udziałem wykonawców i audytorów, podczas którego omówione i wyjaśnione zostaną niezgodności ze standardem. Ułatwi on wykonawcy zrozumienie raportu, umożliwi odpowiedzi na pytania.

Po zakończeniu projektu przydatny będzie też zorganizowany przez wykonawcę warsztat dla redaktorów z obsługi dostarczonego wraz z www systemu CMS.

10.      REDAGUJ DOSTĘPNE TREŚCI, DOKUMENTY, MULTIMEDIA

Pamiętaj, że tworzone przez Ciebie treści powinny być dostępne dla każdego odbiorcy, muszą spełniać standardy dostępności. Twórz je w taki sposób, żeby były obsługiwane przez oprogramowanie asystujące – programy czytające, powiększające. Dbaj o zrozumiałość treści. Wspieraj się wiedzą fachową – korzystaj z publikacji na temat dostępności, szkoleń – w tym zdalnych – lub pomocy specjalistów. Pamiętaj, że tworzone dokumenty – w tym te do pobrania ze strony – muszą być tworzone w dostępnej postaci – zgodnie z załącznikiem 4 Rozporządzenia KRI.

Częsta niestety praktyka zamieszczania skanów dokumentów jest niedopuszczalna – skan, czyli zdjęcie dokumentu w formacie graficznym (np. jpg), jest dla osób korzystających z oprogramowania czytającego całkowicie niedostępny. Publikuj dostępne pdf.

Materiały multimedialne zamieszczane w obszarze serwisu muszą być opatrzone w rozwiązania wspomagające dostępność – materiały wideo w napisy dla słabosłyszących i niesłyszących oraz audiodeskrypcję dla osób niewidomych (WCAG 2.0 AA) oraz jeśli chcemy, aby były zrozumiałe dla osób głuchych od urodzenia tłumaczenia migowe w PJM (WCAG 2.0 AAA).

11.      PAMIĘTAJ, ŻE DOSTĘPNOŚĆ TO PROCES

REDAKCJA

Nawet najlepiej przygotowany dostępny serwis może stać się niedostępny w dzień po jego premierze w sieci. Codzienna aktualizacja strony www wymaga rzetelności i bezwzględnego przestrzegania zasad przy tworzeniu m.in. tekstów, załączników oraz opisów zdjęć i linków.

Redaktor serwisu tak samo jak jego twórca musi rozumieć, w jaki sposób osoby z różnymi dysfunkcjami korzystają z Internetu. W tym celu warto, by zapoznał się z literaturą oraz przeszedł szkolenie, które może przeprowadzić wykonawca lub niezależne podmioty.

Przeprowadzenie szkolenia może generować dodatkowe koszty, dlatego należy to uwzględnić już na początku projektu.

Podczas szkolenia redaktorzy dowiadują się, przy użyciu jakich narzędzi i technologii użytkownicy narażeni na wykluczenie cyfrowe korzystają z Internetu, co oznacza dostępność www dla osób z niepełnosprawnością: fizyczną, sensoryczną (niewidomych, słabowidzących, głuchych, słabosłyszących, głuchoniewidomych), intelektualną a także dla osób starszych, czy też korzystających z urządzeń mobilnych lub starszego oprogramowania. Omawiane są główne zasady WCAG 2.0. Redaktorzy w praktyce uczą się opracowywać dostępne treści i multimedia.

Podczas szkoleń poruszane są m.in. takie zagadnienia: formatowanie, nagłówki i listy, odnośniki, odpowiedniki tekstowe dla elementów graficznych, formularze, kontrast, dokumenty do pobrania (DOC, PDF). Szkolenie odbywa się w oparciu o demo prostego systemu zarządzania treścią – CMS, w którym zaimplementowane są najpopularniejsze edytory tekstowe bądź w oparciu o CMS klienta.

 

Patroni Honorowi

Społeczni Partnerzy Merytoryczni

Kontakt

Masz jakieś pytania ?

Fundacja IT Leader Club Polska
Biuro:
Concept Tower, ul. Grzybowska 87
00-844 Warszawa

+48 506 955 942

biuro@akademiait.edu.pl

NIP: 527-266-68-79
KRS: 0000396492