Uwaga na fałszywe maile

Szanowni Państwo, informujemy, że z dniem 06.09.2023 r. spółka Entera s.c. zakończyła działalność. Wszystkie zobowiązania spółki zostały w wypełnione, a sprawy bieżące zamknięte. Wszystkim naszym kontrahentom i współpracownikom dziękujemy za lata wspólnych wyzwań. Dostępność niniejszej strony internetowej będzie utrzymywana przez najbliższe 24 miesiące, wyłącznie w celach informacyjnych.

Dziękujemy
Entera s.c.

System Przedszkolny dla podwarszawskiej gminy Piaseczno w telewizji

Nasze oprogramowanie – konkretnie System Przedszkolny dla podwarszawskiej gminy Piaseczno został „gwiazdą” telewizji. Oczywiście żartujemy i sami siebie odsyłamy celem zjedzenia Snickersa, aby nie „gwiazdorzyć” 🙂

Żarty na bok – nasz system okazał się na tyle interesujący i innowacyjny, że stał się kanwą jednej z wiadomości programu TVP „Kurier Mazowiecki”. O audycji wspominamy nie dlatego, aby się pochwalić, ale dlatego, że jest to okazja, aby zobaczyć taki zamknięty, dedykowany system informatyczny w akcji. Normalnie, tego typu dedykowane oprogramowanie nie jest publicznie dostępne. Sam system obsługuje obecnie 11 przedszkoli. Jest zintegrowany z kartą miejską (odczyt NFC). Oferuje ewidencję czasu obecności, rozliczenia finansowe, ogłoszenia, powiadomienia e-mail i SMS. Od strony administracyjnej jest wyposażony w aplikacje dla systemów Windows, Android i oczywiście część serwerowo-webową, a od strony frontendu – użytkownika końcowego – w pełni mobilny i responsywny. Cały program „Kurier Mazowiecki” możecie obejrzeć pod poniższym linkiem. Informacja na temat Systemu Przedszkolnego rozpoczyna się od 5 min 22 sekundy programu.

Jak to jest z tym audytem WCAG 2.1

Przepisy o dostosowywaniu aplikacji i stron internetowych do potrzeb osób niepełnosprawnych funkcjonują w obiegu prawnym od dekady, a mimo to wciąż budzą wiele wątpliwości. Może już nie w sferze tego kto musi je stosować – ta świadomość stała się dość powszechna. Najprościej rzecz ujmując – wszystkie przejawy działalności informacyjnej opłacane z publicznych pieniędzy muszą być dostępne dla wszystkich obywateli, dzięki pieniądzom których powstają. Skoro osoby niepełnosprawne płacą podatki, to strony internetowe i aplikacje oferowane przez podmioty publiczne lub opracowywane przy użyciu publicznych pieniędzy muszą być dostępne także dla nich.

Wątpliwości wciąż dotyczą tego jak sprawdzić, czy strona WWW lub aplikacja mobilna rzeczywiście jest dla osób niepełnosprawnych dostępna. Większość zainteresowanych wie, że trzeba przeprowadzić audyt zgodności strony WWW lub aplikacji mobilnej ze specyfikacją WCAG 2.1 i na tym wiedza się kończy. Jak? Kto może taki audyt przeprowadzić? Jak powinien on wyglądać? – to już kwestie które, na które większość osób odpowiedzialnych nie zna odpowiedzi.

„Zasługę” należy tu przypisać zagmatwanym przepisom dotyczącym tej kwestii – są ogromnie skomplikowane pod względem struktury. Wymogi dotyczące prowadzenia audytu WCAG 2.1 istnieją w systemie prawnym i są konkretnie określone, ale dotarcie do nich to długa i skomplikowana ścieżka, gdyż polska „Ustawa o dostępności cyfrowej stron WWW i aplikacji mobilnych podmiotów publicznych” z 2019 r odwołuje się do decyzji wykonawczych Komisji Europejskiej, które z kolei odwołują się do dyrektyw Parlamentu Europejskiego, które z kolei odwołują się do kolejnych decyzji wykonawczych KE i do Normy Europejskiej EN 301 549 V1.1.2 (2015-04).

Jednym z pytań najczęściej budzących wątpliwości jest – czy istnieje lista jednostek uprawnionych do prowadzenia audytu WCAG 2.1? Nie istnieje. Nie ma żadnego oficjalnego rejestru. Przepisy są oparte o zasadę zaufania lub udowodnienia, że jednostka podejmująca się audytu WCAG 2.1 posiada odpowiednią wiedzę, doświadczenie i środki umożliwiające przeprowadzenie takiego audytu. Decyzje wykonawcze Komisji Europejskiej obwarowują warunki prowadzenia audytu WCAG 2.1 następująco:

Audyt WCAG 2.1 jest to:

  • Badanie techniczne strony WWW lub aplikacji mobilnej przeprowadzone przez dwóch specjalistów – programistów z minimum pięcioletnim stażem lub doświadczeniem zawodowym. Przy czym to doświadczenie może być potwierdzone wykształceniem kierunkowym i minimum pięcioletnim stażem pracy lub też innym dowodem takim jak np. dowody na przeprowadzenie co najmniej 5 audytów WCAG 2.1 w ciągu ostatnich 3 lat.
  • Badanie faktycznego odbioru strony WWW lub aplikacji mobilnej przez użytkowników z różnych grup niepełnosprawności – tzw. badanie testerskie. Uczestniczą w nim minimum 4 osoby reprezentujące grupy niepełnosprawności: niewidomi/słabowidzący, niesłyszący, osoby z dysfunkcjami motorycznymi, osoby z problemami kognitywnymi. Zaleceniem jest koordynacja tego zespołu przez osobę z doświadczeniem w rehabilitacji niepełnosprawnych. Przy czym decyzje wykonawcze Komisji Europejskiej nie precyzują sposobu weryfikacji niepełnosprawności tych osób zostawiając to krajom członkowskim ze względu na różne systemy kwalifikacji niepełnosprawności w poszczególnych krajach, a polskie przepisy wynikające z owych decyzji wykonawczych temat omijają – przyjmuje się, że są to po prostu osoby z orzeczeniami o niepełnosprawności danego typu.

W audyt WCAG 2.1 musi być zatem zaangażowanych minimum 6 osób. Audyt i dostosowanie strony WWW lub aplikacji mobilnej do wymogów WCAG 2.1 musi być przeprowadzony w następujących etapach:

  • Audyt właściwy, dwuetapowy, przeprowadzony według opisanych wyżej założeń,
  • Nanoszenie poprawek na stronie WWW lub w aplikacji mobilnej zgodnie z wynikami audytu,
  • Audyt ponowny, dwuetapowy, według powyższych założeń potwierdzający zgodność ze specyfikacją WCAG 2.1.
PHP w nowej wersji, czyli dlaczego moja strona nie działa?

PHP jest językiem programowania, który kryje się za 95 proc. stron internetowych i systemów współcześnie dostępnych w Internecie. Do pewnego momentu był „przezroczysty” dla użytkowników. Powstawały kolejne wersje, były aktualizowane „gdzieś tam” w czeluściach konta hostingowego, a ponieważ nowsze wersje zawsze były wstecznie kompatybilne zatem mało kto zauważał fakt aktualizacji jakiegoś enigmatycznego języka skryptowego w tle, skoro jego WordPress, Joomla, czy inny Drupal działają jak działały. Luki bezpieczeństwa, kiepska wydajność, coraz większe problemy z zabezpieczeniem serwerów przez słabe zabezpieczenia języka co najwyżej spędzały sen z powiek administratorom serwerów. Tak było do wersji 5.6 tego języka. Zespół odpowiedzialny za PHP zauważył, że zmiany są niezbędne, gdyż coraz więcej firm hostingowych i administratorów serwerów wprost odradza klientom używanie PHP. Postawiono na radykalne rozwiązania. Radykalne rozwiązania w IT często oznaczają porzucenie balastu przeszłości, a to zazwyczaj oznacza brak kompatybilności wstecznej. Tak też stało się z PHP – z powodu dużych zmian w jądrze tego języka pominięto całkowicie numerację 6 i od razu przeskoczono do wersji 7. Wprowadzono też zasadę, że każda kolejna wersja będzie wspierana tylko do pewnego momentu – w praktyce jest to ok. 2 lat – a potem stanie się wersją przestarzałą i niewspieraną. Zespół odpowiedzialny za PHP doszedł także do wniosku, iż utrzymywanie „na siłę” wstecznej kompatybilności w nieustannie zmieniającym się środowisku Internetu, gdzie nowe zagrożenia pojawiają się z dnia na dzień, nie ma żadnego uzasadnienia, w związku z czym nowe wersje niekoniecznie muszą być wstecznie kompatybilne o ile  jest to uzasadnione zwiększonym bezpieczeństwem i stabilnością. Większość właścicieli stron internetowych przeżyła nieprzyjemne zaskoczenie, gdy ich normalnie dotychczas działająca strona WWW nagle zaczęła generować dziwne błędy lub całkowicie przestała funkcjonować po którejś z kolejnych aktualizacji systemu hostingu. Powodem okazywała się zmiana wersji języka PHP z 5.6 na 7.1, a potem na 7.2 itd. aż do aktualnie kończącej wsparcie wersji 7.4. Jak wspomniano, nowe wersje PHP nie zawsze są wstecznie kompatybilne – wprawdzie w obrębie jednej gałęzi te niekompatybilności nie są znaczące, a dostosowanie kodu strony do nowej wersji PHP jest stosunkowo łatwe, niemniej jednak istnieją. Powstaje zatem konieczność stałej opieki nad stroną WWW – czy to samodzielnej, czy zleconej.

Obecnie aktualną wersją języka PHP jest wersja 8.0. Najczęściej stosowana jeszcze wersja 7.4 kończy wsparcie w grudniu 2022. Ponownie – PHP 8.0 nie jest w pełni kompatybilny wstecznie. Znacząca ilość stron i systemów udostępnionych poprzez WWW będzie wymagała prac dostosowujących – każdy właściciel takiego systemu ma do wprowadzania pozycję do kalendarza na rok 2023.

Kosztów uniknąć się nie da – albo trzeba ponieść je na dostosowanie strony lub systemu jeśli nie są kompatybilne z nową wersją PHP, albo zapłacić dostawcy usług hostingowych za możliwość dalszego używania starszej wersji języka PHP. Dostawcy usług hostingowych znaleźli bowiem w nowym modelu aktualizacji języka PHP sposób na dodatkowy zarobek. Jeśli klient nie chce lub nie ma możliwości dostosowania do nowej wersji języka PHP swojej strony WWW czy też systemu utrzymywanego na serwerach danej firmy hostingowej może opłacić „usługę udostępniania starszej wersji PHP”. Rozważania nad etyką biznesową takiego postępowania zostawmy na kiedy indziej. Fakt faktem, że aktualizacja języka programowania stojącego za istotnym elementem biznesowym lub wizerunkowym jakim jest strona WWW lub system dostępny w Internecie, do nowszej, lepiej zabezpieczonej wersji tego oprogramowania jest zawsze rozsądnym posunięciem w realiach obecnego IT.

iOS 16 i watchOS 9 – tuning pod maską

W najnowszych iteracjach systemów operacyjnych dla urządzeń mobilnych Apple – iOS 16, i watchOS 9 – z punktu widzenia użytkownika nie zmienia się wiele. Ot, kolejne wersje systemów dla iPhone i Apple Watch bez większych innowacji. Dla właścicieli aplikacji kierowanych na te systemy Apple zmiany są widoczne i choć na razie nie są one szczególnie obciążające i czysto opcjonalne, to jednak są zapowiedzią większych restrykcji, których zapewne doczekamy się w kolejnych wersjach systemów – już niewątpliwie jako obowiązkowych do implementacji.

Chodzi naturalnie o dalsze zacieśnianie polityki prywatności do usług lokalizacyjnych, co ma niebagatelne znaczenie dla właścicieli aplikacji, których funkcjonalność opiera się o te usługi, takich jak np. systemy monitoringu.

Jak wiadomo, aby iOS lub watchOS przesyłały dane lokalizacyjne w tle, użytkownik musi wyrazić na to zgodę. Podczas pierwszego pytania o zgodę na lokalizację, iOS od wersji 16 w ogóle nie pokazuje użytkownikowi opcji „Pozwalaj zawsze” – jest tylko „Jeden raz” i „Gdy używam aplikacji”. Pole „Pozwalaj zawsze” pojawia się podczas drugiego pytania. W poprzednich wersjach iOS to drugie, uszczegółowione pytanie pojawiało się automatycznie po pierwszym wywołaniu funkcji lokalizacji w tle. Teraz mamy istotną zmianę – to iOS lub watchOS decydują samodzielnie kiedy je pokazać – decyzję podejmuje Neural Engine (koprocesor sztucznej inteligencji). Możliwa stała się zatem sytuacja, że Neural Engine pokaże to pytanie dopiero po jakimś czasie, a dopóki użytkownik nie zaakceptuje uprawnienia, dane lokalizacyjne w tle nie będą zsyłane – należy to uwzględnić w projekcie aplikacji.

Jest to jednak stosunkowo niewielka zmiana z punktu widzenia frontu aplikacji. Znacznie ciekawsze rzeczy dzieją się „pod maską” – Xcode (program deweloperski służący do projektowania aplikacji dla systemów Apple) pokazuje ostrzeżenia, nawet jeśli sprawdzenie czy usługi lokalizacyjne są dostępne w systemie odbywa się bez wcześniejszego przyznania uprawnień przez użytkownika. Mowa nie o skorzystaniu z lokalizacji, wyznaczeniu pozycji itd. – wystarczy samo sprawdzenie czy w systemie jest dostępna możliwość pobrania lokalizacji, bez faktycznego korzystania z niej, aby Xcode ostrzegał o nieuprawnionym dostępie. A to może oznaczać tylko jedno – w przyszłych wersjach systemów iOS i watchOS samo sprawdzenie, czy można korzystać z usług lokalizacyjnych będzie jeszcze bardziej ograniczone i możliwe do wykonania po uprzednim zapytaniu użytkownika o zgodę. Obecnie jest to tylko przypuszczenie, jednak jeśli miałoby się spełnić, wszystkie systemy i aplikacje opierające swoją funkcjonalność na wyznaczaniu pozycji urządzeń z iOS lub watchOS będą wymagały przeprojektowania na tyle znaczącego, że już obecnie watro te zmiany zacząć rozważać przynajmniej na poziomie koncepcyjnym.

Uprawnienia użytkownika w Androidzie 10 i nowszych

Projektując kolejne wersje systemu Android, Google dodaje kolejne uprawnienia i zmiany w tym systemie operacyjnym związane z prywatnością i ochroną danych użytkownika. Od wersji 11 w podsystemie uprawnień użytkownika dzieje się jednak prawdziwa rewolucja, wpływająca na wszystkie aktywnie wpierane aplikacje dostępne w Google Play.

Zmiany są częste – wprowadzane z każdą kolejną wersją systemu – i komunikowane w sposób charakterystyczny dla Google, czyli niejasno. Dlaczego moja aplikacja na Androida nagle przestała działać? – to chyba najczęściej w ciągu ostatnich dwóch lat stawiane nam pytanie przez właścicieli różnych aplikacji dostępnych w Google Play. Odpowiedź jest prawie zawsze taka sama – jeśli aplikacja korzysta z usług lokalizacyjnych, zapisuje dane na dysku użytkownika, ma wbudowane funkcje związane z bluetooth – to, to co działało do Androida 10, od Androida 11 działać nie będzie o ile aplikacja nie zapyta użytkownika o zgodę na używanie tych funkcjonalności i jeśli użytkownik się na ich używanie nie zgodzi.

W najnowszym wydaniu systemu Android – wersji 13 – pojawiły się kolejne uprawnienia wpływające na funkcjonalność aplikacji – wzorem iOS, Android pyta teraz użytkownika o pozwolenie na pokazywanie powiadomień. Jeśli użytkownik się nie zgodzi, aplikacja powiadomień wyświetlać nie będzie, a co za tym idzie zostaną wyłączone wszystkie funkcje zależne od pokazywania powiadomień, takie jak np. usługi lokalizacyjne w tle.

Warto mieć świadomość, że wprawdzie właścicieli aplikacji opartych o wspomniane funkcjonalności, takich jak np. systemy monitoringu, zmiany te mogą irytować, gdyż aplikacje praktycznie co roku wymagają znaczących aktualizacji pociągających za sobą koszty, to jednak z punktu widzenia użytkownika są to zmiany jak najbardziej słuszne i wprowadzone o wiele za późno.

Oficjalnym powodem wprowadzania zmian w systemie Android jest dbałość o prywatność użytkowników. W rzeczywistości tak daleko idące zmiany ograniczające Google możliwość śledzenia użytkowników są dla tej korporacji wyjątkowo niewygodne, gdyż uderzają bezpośrednio w model biznesowy producenta systemu operacyjnego (reklama i profilowanie danych), jednak firma została do nich zmuszona gigantyczną karą finansową wynoszącą ok. 4,5 miliarda euro za naruszanie prywatności użytkowników.

Aby nieco uporządkować system uprawnień w Androidzie i mieć świadomość czego należy się spodziewać krótki przewodnik po kolejnych wersjach uprawnień użytkownika w kolejnych wersjach Androida:

Android 9

Usługi bluetooth, lokalizacja za zgodą użytkownika, zapis danych na dysku będą działały tak jak wcześniej. Jeśli aplikacja korzysta ze stałego śledzenia pozycji użytkownika w tle, od Androida 9 obowiązkowe jest wyświetlanie stałego powiadomienia w bloku  tzw. cichych powiadomień na belce systemowej, że aplikacja cały czas działa w tle i zbiera dane o lokalizacji. Powiadomienie musi być stale obecne pomimo, że użytkownik wydał zgodę na takie działanie – ma przypominać użytkownikowi o wyrażonej zgodzie i fakcie, że w każdej chwili może ją cofnąć.

Android 10

Pierwsza poważna zmiana dla aplikacji, które swoją główną funkcjonalność budują na znajomości stałego położenia użytkownika. Wyznaczanie pozycji użytkownika działa tylko po wyrażeniu przez użytkownika zgody i tylko, gdy aplikacja jest uruchomiona. Wprowadzono nowe uprawnienie lokalizacyjne „Lokalizacja w tle”. Pytanie o to uprawnienie jest zawarte bezpośrednio w oknie z pytaniem o lokalizację pod nazwą „Zawsze zezwalaj” – stałe wyznaczanie pozycji użytkownika jest możliwe tylko jeśli użytkownik zaakceptuje to uprawnienie.

Android 11 i 12

Ta wersja systemu Android z punktu widzenia właścicieli aplikacji jest najbardziej kłopotliwa – nie obejdzie się bez dostosowania kodu i aktualizacji aplikacji. Android 11 całkowicie zmienia sposób obsługi uprawnienia „Lokalizacja w tle” – nie jest ono już pokazywane w dymku z pytaniem o lokalizację, a należy odesłać użytkownika do ustawień systemu, aby mógł wybrać odpowiednią opcję ręcznie. Jednak można to zrobić dopiero po tym, gdy użytkownik przyzna jakiekolwiek inne uprawnienie do lokalizacji – uzyskiwanie uprawnień lokalizacyjnych odbywa się zatem dwuetapowo.

Ta wersja systemu Android zmienia również uprawnienia do zapisu danych oraz używania funkcji bluetooth, aparatu i mikrofonu. Aplikacje mają całkowicie cofniętą możliwość zapisu danych w różnych folderach systemowych – zapis danych może się odbywać wyłącznie w dedykowanym folderze aplikacji. Aby uzyskać możliwość zapisu i odczytu danych z folderów plików multimedialnych – szczególnie istotne dla aplikacji korzystających z funkcji fotograficznych i funkcji mikrofonu – wprowadzono dodatkowe, szczególne uprawnienia podlegające silnym restrykcjom ze strony systemu operacyjnego.

Część uprawnień związanych z lokalizacją, aparatem, mikrofonem i bluetooth została przeniesiona do tzw. uprawnień specjalnych newralgicznych – korzystać z nich mogą tylko aplikacje, których funkcjonalności uzasadniają korzystanie z tych uprawnień, a ich publikacja w Google Play jest poprzedzona uzyskaniem dodatkowej zgody od Google na publikację w procesie rozszerzonej recenzji.

Android 13

W Androidzie 13 wprowadzono nowe uprawnienie „Pokazuj powiadomienia”. Same uprawnienia do lokalizacji działają tak, jak w Androidzie 11 i 12. Należy jednak zwrócić uwagę, że aby włączyć lokalizację w tle, już od Androida 9 trzeba pokazywać stałe powiadomienie w tzw. bloku „ciche” na belce systemu, informujące użytkownika, że aplikacja działa i zbiera dane o lokalizacji. Zatem w Androidzie 13, aby włączyć lokalizację w tle, użytkownik najpierw musi wyrazić zgodę na pokazywanie powiadomień, a dopiero następnie wyrazić zgodę na lokalizację w procesie dwuetapowego uzyskiwania pozwolenia.

WearOS 3 – czas na zmiany

Nowa wersja systemu Android dla zegarków nosi nazwę WearOS 3 i jest przez Google reklamowana jako rewolucja na rynku smartwatchy. Na razie nie ma zbyt wielu modeli zegarków opartych o tą wersję systemu – obecnie jest to najnowszy Galaxy Watch od Samsunga oraz Pixel Watch od Google, jednak z czasem będzie się to w naturalny sposób zmieniać.

Przy okazji wprowadzania nowej wersji zegarkowego systemu na rynek, Google wywołało potężne zamieszanie twierdząc, że aplikacje napisane dla poprzedniej wersji systemu WearOS 2 nie będą kompatybilne z WearOS 3. W rzeczywistości tak nie jest – znakomita większość oprogramowania napisanego dla WearOS 2 działa bezproblemowo na WearOS 3. Trudno spodziewać się, żeby było inaczej skoro WearOS 3 to w istocie Android 11, a WearOS 2 to po prostu Android 9. Czym innym jednak są wymagania Google w przypadku aplikacji dla WearOS wydawanych w sklepie Google Play – tutaj rzeczywiście nastąpiły znaczące zmiany.

Wszelkie niekompatybilności programowe mogą wynikać jedynie z faktu, że nowsze wydanie WearOS jest oparte o wersję 11 Androida, zatem wszelkie mechanizmy znane z „dużej” wersji systemu są obecne i tutaj – w szczególności dotyczy to podsystemu uprawnień użytkownika do lokalizacji, zapisu danych na dysku, korzystania z aparatu, mikrofonu i bluetooth. Aplikacje korzystające z tych uprawnień podlegają takim samym ograniczeniom, jak aplikacje na telefonach i wymagają dostosowania.

W Google Play nastąpiła jedna istotna zmiana – aby wydać aplikację na zegarek w sklepie, musi ona być kompatybilna z WearOS 3, a konkretniej z wytycznymi Google dotyczącymi jakości określonymi dla tego systemu. Największą zmianą jest całkowita rezygnacja z poziomej obsługi kart na rzecz podejścia bardziej „telefonicznego” – ekrany aplikacji mają być przewijane pionowo. Dotychczas charakterystyczny dla WearOS layout poziomy oparty na gestach przesuwania w prawo i lewo jest według nowych wytycznych niemile widziany. To niekiedy implikuje konieczność wprowadzenia bardzo głębokich zmian w aplikacji.

O ile implementacja nowego systemu uprawnień z Androida 11 nie stanowi większej zmiany dla użytkownika – zegarek po prostu w odpowiednim momencie zadaje dodatkowe pytanie, czy użytkownik wyraża zgodę na daną czynność – o tyle często całkowita zmiana interfejsu użytkownika aplikacji wpływa na interakcję z aplikacją i doświadczenie z tego płynące. Pomijając koszy, które taka zmiana za sobą pociąga dla właścicieli aplikacji na WearOS, ma to szczególne znaczenie w przypadku aplikacji, które wykorzystywane są na co dzień i do których sposobu obsługi użytkownicy są przyzwyczajeni – całkowita zmiana sposobu używania aplikacji może spowodować jej porzucenie przez użytkownika. Dlatego planując rozwój swojej aplikacji na WearOS należy obecnie szczególną wagę przyłożyć do UX, zwłaszcza jeśli aplikacja była zaprojektowana zgodnie z dotychczasowym „flow” systemu wearOS.

Synteza mowy, a WCAG 2.1 – czy to ma sens?

Czy na stronie zgodnej z WCAG 2.1 należy zapewnić czytnik tekstu w formie możliwości odczytywania treści przez lektora lub syntezator mowy? Zgodnie z manierą panującą obecnie w Internecie konkluzja powinna znaleźć się na początku testu, aby nie trzeba było go czytać, zatem do konkluzji: odpowiedź brzmi – nie. WCAG 2.1 nie stawia takiego wymagania, gdyż zwyczajnie nie ma takiej potrzeby.

Jest to jedno z najczęściej mylonych pojęć, gdy przychodzi do rozważań nad dostosowaniem strony WWW do potrzeb osób niepełnosprawnych zgodnie ze specyfikacją WCAG 2.1 – zapewnienie możliwości odczytu tekstu, alternatyw tekstowych, deskrypcji multimediów nie oznacza zapewnienia mechanizmu odczytującego te teksty. Innymi słowy – zapewnienie możliwości odczytu tekstu na głos, nie oznacza zapewnienia jego odczytywania na głos. Osoby niepełnosprawne są wyposażone w dedykowane technologie asystujące mające wbudowane mechanizmy odczytujące treść strony głosem lektora – administrator strony zgodnej z WCAG 2.1 ma jedynie zapewnić, aby te mechanizmy mogły działać bez przeszkód.

WCAG 2.1 na żadnym poziomie zgodności, nawet najwyższym AAA, nie wymaga obecności na stronie internetowej mechanizmu odczytywania tekstu na głos. Zapewnić należy, że informacje – normalnie pisane zwykłym tekstem oraz inne treści na stronie – będą możliwe do odczytania na głos przez czytniki używane przez osoby niewidome. Stąd konieczność opisywania obrazków, grafik  i zdjęć tekstami alternatywnymi, zapewniania napisów do filmów, zamieszczania deskrypcji nagrań audio itd. Jeśli na stronie jest zamieszczony tekst w formie możliwej do odczytania (w praktyce po prostu w postaci kodu HTML), czytnik osoby niepełnosprawnej sobie z nim doskonale poradzi. Warto natomiast niewątpliwie zadbać o to, aby tekst był pisany z poszanowaniem zasad interpunkcji języka określonego jako język danej strony. Stosowanie kropek, przecinków i znaków interpunkcyjnych charakterystycznych dla danego języka sprawia, że tekst syntezowany przez czytnik osoby niewidomej brzmi bardziej naturalnie. Oprogramowanie to podczas interpretacji tekstu stara się bowiem naśladować czytającego na głos człowieka – znaki interpunkcyjne stosowane w tekście, zgodnie z zasadami interpunkcji, powodują, że „lektor” robi naturalnie brzmiące pauzy w zdaniu i pomiędzy zdaniami, a tak odczytywany tekst jest łatwy do zrozumienia. Brak znaków interpunkcyjnych sprawia, iż odczytywany tekst „zlewa się” w niezrozumiały potok słów, pozbawiony przerw pomiędzy zdaniami i w zdaniach wielokrotnie złożonych, co bardzo utrudnia jego odbiór.

Strony WWW sołectw - WCAG 2.1 jest wymagane

Strony WWW sołectw nie są jeszcze codziennością. Być może dlatego, że wbrew pozorom, są to systemy bardziej rozbudowane pod względem programistycznym od portali miast, czy gmin. Objętościowo są mniejsze, lecz technicznie bardziej skomplikowane. Wynika to z ich charakteru – innego, niż informacyjne strony samorządów wyższego szczebla.

W jednostce samorządu obejmującej jedną miejscowość, czasem ledwie kilka ulic, taka platforma służy nie tylko przekazywaniu informacji, ale przede wszystkim integrowaniu lokalnej społeczności. Stąd potrzeba implementacji większej ilości funkcji – głęboka integracja z portalami społecznościowymi do poziomu poszczególnych komentarzy i dyskusji, systemy ankiet, czy głosowań umożliwiające codzienne podejmowanie wspólnych decyzji, podsystemy katalogowe i wymiany informacji – to są realne, codziennie wykorzystywane funkcje takich stron, które nie są potrzebne w wypadku platform obejmujących zasięgiem większy teren. 

Jak każda strona jednostki publicznej, tak i strona samorządu szczebla sołeckiego musi być w pełni dostępna dla osób niepełnosprawnych i spełniać wymagania specyfikacji WCAG 2.1. Fakt, że Facebook, czy Instagram tych wymagań nie spełniają (nie muszą – to są portale prowadzone przez komercyjne korporacje) nie stanowi usprawiedliwienia w przypadku jednostki publicznej.

Jeżeli treści z portali komercyjnych, które nie są dostosowane do wymagań specyfikacji WCAG 2.1, mają być prezentowane w obrębie strony sołectwa muszą przejść dostosowanie. Najwygodniej, realizowane automatycznie przez oprogramowanie strony, chociaż oczywiście nic nie stoi na przeszkodzie, aby nakładem czasu dostosowywać te materiały ręcznie.

Pomocnik WCAG 2.1 - Windows Edition

Wprawdzie na podstawie „Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z dnia 4 kwietnia 2019 r., w polskim obiegu prawnym wciąż jako obowiązująca funkcjonuje wersja specyfikacji WCAG 2.1, to jednak warto wiedzieć, że w bliższej lub dalszej przyszłości ten stan rzeczy się zmieni, a wymagania dotyczące dostosowywania stron WWW i aplikacji mobilnych do potrzeb osób niepełnosprawnych wzrosną – W3C opublikowała bowiem nową wersję specyfikacji WCAG – WCAG 2.2.

Rewolucyjnych zmian nie ma – o najważniejszych można przeczytać tutaj – jednak warto wiedzieć, że w wyniku przesunięć między poszczególnymi działami WCAG, do osiągnięcia poziomu zgodności AA wymaganego „Ustawą o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” dojdzie 8 kolejnych kryteriów sukcesu – obecnie jest ich 50, będzie 58.

Aby ułatwić Wam zadanie przygotowania swoich stron WWW zaktualizowaliśmy naszą pomocniczą aplikację Pomocnik WCAG 2.1 do standardu WCAG 2.2 – nazwy i opisów w aplikacji na razie nie zmieniamy, jako, że wciąż oficjalnie obowiązującym w Polsce standardem jest WCAG 2.1, jednak sam silnik sprawdzający strony WWW w aplikacji został zaktualizowany do zgodności z wersją WCAG 2.2.

Dla przypomnienia – aplikacja Pomocnik WCAG 2.1 to praktyczne narzędzie ułatwiające prowadzenie i kontrolę audytu stron WWW, aplikacji wyprowadzających kod wynikowy zgodny z technologią HTML publikowanych w przestrzeni WWW i systemów teleinformatycznych wyprowadzających kod wynikowy zgodny z technologią HTML dostępnych w Internecie, pod kątem dostępności dla osób niepełnosprawnych zgodnie z wytycznymi zawartymi w instrukcji WCAG 2.1. Aplikacja zapewnia ponad 180 zautomatyzowanych testów i analiz pod kątem zgodności strony WWW ze specyfikacją WCAG 2.1. Pobierzecie ją bezpłatnie ze sklepu Microsoft Store.

Aplikacja jest przeznaczona do analizy stron WWW i aplikacji internetowych opublikowanych w języku polskim (PL).

Z racji swojego charakteru, aplikacja Pomocnik WCAG 2.1 jest kierowana przede wszystkim do webmasterów i osób odpowiedzialnych w jednostkach administracyjnych i publicznych za wdrożenie „Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z dnia 4 kwietnia 2019 r., w szczególności w zakresie dostosowania stron WWW, aplikacji i systemów informatycznych do specyfikacji WCAG 2.1.

Należy przy tym pamiętać, co zawsze podkreślaliśmy i będziemy podkreślać, że wskazania jakiejkolwiek aplikacji, również naszej Pomocnik WCAG 2.1 w żadnym wypadku nie mogą być traktowane jako ekwiwalent przeprowadzenia audytu dostępności strony WWW, czy aplikacji mobilnej lub internetowej, wymaganego „Ustawą o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych”. Wskazania aplikacji należy traktować jedynie orientacyjnie, jako pomoc przy planowaniu obszarów audytu, mając jednocześnie na uwadze, że audyt dostępności strony WWW lub aplikacji mobilnej obowiązkowo wymaga współpracy z osobami niepełnoprawnymi podczas jego przeprowadzania.