,

WCAG 2.1 zamiast WCAG 2.0

WCAG 2.1 zamiast WCAG 2.0
WCAG 2.1 zamiast WCAG 2.0
2.4 (47.92%) 53 głos[ów]

Nareszcie – tym krótkim słowem moglibyśmy podsumować wejście w życie „Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z 4 kwietnia 2019 r. Ustawa ta zmienia archaiczne założenia „Rozporządzenia Rady Ministrów z 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności”, wymagającego dostosowania stron www do nieaktualnego od czerwca 2018 roku standardu WCAG 2.0 i wprowadza współczesny standard WCAG 2.1 – ARIA. Co to oznacza dla idei dostępności stron www dla osób niepełnosprawnych i sprawdzania tejże dostępności w postaci audytu strony www?

Zasadniczo niewiele, jednak w szczegółach bardzo dużo. Ramy samego audytu nie ulegają zmianie – nadal sprawdzana jest dostępność stron www do poziomu AA specyfikacji WCAG i nadal wymagane jest aby odbywało się to przy aktywnym współudziale osób niepełnosprawnych. Jednak specyfikacja WCAG 2.1 dostosowuje jednocześnie swoje wymagania do wymagań współczesnego rynku informatycznego, dzięki czemu nie narzuca już twórcom stron www i systemów teleinformatycznych przestarzałych rozwiązań. Sama ustawa porządkuje też kwestie certyfikacji dostosowania i deklaracji dostępności strony www, które to kwestie były całkowicie nieuregulowane w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. Mianowicie podmiot prowadzący audyt WCAG 2.1, zgodnie z wytycznymi specyfikacji WAI-ARIA, na koniec badania wystawia badanemu systemowi deklarację zgodności na usystematyzowanym formularzu stanowiącym załącznik do Ustawy – brak tego dokumentu był niezwykle odczuwalny w RRM z 12 kwietnia 2012 roku.

Nowa ustawa zasadniczo poprawia też sytuację deweloperów budujących strony www, którzy chcą (lub muszą, jeśli są to strony przeznaczone dla podmiotów administracji publicznej) dostosować swoje produkty do potrzeb osób niepełnosprawnych. Kierując się bowiem Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności należało m.in. zrezygnować z pełnego wykorzystania Java Scriptu. Strony niedziałające z wyłączonym Java Scriptem, według wytycznych WCAG 2.0 całkowicie bowiem nie spełniają zasady 4 – Kompatybilność. Aby zrozumieć dlaczego tak jest należy uzmysłowić sobie, że założenie dotyczące Java Scriptu przyjęte w wersji 2.0 specyfikacji WCAG pochodzi sprzed blisko dekady. W międzyczasie, w systemach informatycznych oraz samej specyfikacji WCAG dokonał się znaczący postęp. Sama specyfikacja WCAG, w czerwcu 2018 r., została opublikowana w wersji 2.1 uznającej i dostosowującej wytyczne do zmieniających się technologii informatycznych oraz nieustannie rozwijanych technologii asystujących wykorzystywanych przez osoby niepełnosprawne. WCAG 2.1 zmienia m.in. zasadę 4 – Kompatybilność. Zniesiony w niej został m.in. wymóg poprawnej obsługi systemu informatycznego z wyłączonym Java Scriptem, jako że od co najmniej 5 lat na rynku nie ma urządzenia bądź technologii asystującej nie obsługującej poprawnie Java Scriptu, który sam w sobie został włączony do podstawowej semantyki języka HTML, który to z kolei w ciągu ostatnich lat standaryzowano w wersji 5 (specyfikacja WCAG 2.0 odnosi się jeszcze do semantyki HTML 4).

WCAG 2.1 jest częścią WAI ARIA – (Web Accessibility Initiative – Accessible Rich Internet Applications) – specyfikacji technicznej opublikowanej przez W3C, zawierającej zestaw rekomendacji dotyczących poprawy dostępności złożonych aplikacji internetowych. WCAG 2.0, do którego odnosi się RRM z dnia 12 kwietnia 2012 r., nie uwzględnia standardu ARIA, jako, że w momencie publikacji tej wersji WCAG nie był on jeszcze dostępny (został wprowadzony 5 lat później), a kolejna wersja – WCAG 2.1 – stała się formalnie częścią ARIA – stanowiąc jej drugi rozdział.

W związku z wprowadzeniem ARIA dalsze odrębne rozwijanie specyfikacji WCAG stoi pod znakiem zapytania, jako, że WCAG odnosi się w swym założeniu tylko do stron internetowych opartych o język HTML i jest obecnie tylko jednym z rozdziałów ARIA, natomiast ARIA samo w sobie rozszerza pojęcie strony internetowej do „złożonej aplikacji internetowej”. Zatem badanie systemu, który w pełni wdraża i wykorzystuje ARIA dalece wykracza poza ramy oceny jego dostępności przy pomocy specyfikacji WCAG 2.0. Specyfikacja ARIA stanowi bowiem zestaw atrybutów, za pomocą których można nadać semantyczne znaczenie niesemantycznym elementom HTML, bądź też zmienić semantyczne znaczenie elementów, które zostały “przerobione” przy użyciu Java Scriptu na komponenty służące do innych celów, niż jest to opisane w dokumentacji HTML. Dzięki atrybutom ARIA możliwe jest uzupełnienie drzewka dostępności przeglądarki internetowej o dodatkowe informacje na temat właściwości tych elementów, a co za tym idzie przekazanie tych informacji technologiom asystującym. Efekty działania atrybutów ARIA są niewidoczne dla osób niekorzystających np. z czytników ekranu – strona internetowa, która nie używa ARIA będzie wyglądać dokładnie tak samo, jak używająca atrybutów ARIA. Zmieni się za to jej funkcjonalność i użyteczność z punktu widzenia osób korzystających z czytników ekranu. System oparty o ARIA jest zatem w pełni dostępny dla użytkowników niepełnosprawnych i to w stopniu znacząco wyższym, niż przewiduje to specyfikacja WCAG 2.0, choć formalnie może być całkowicie niezgodny z WCAG 2.0, która to specyfikacja nie przewidziała wychodzenia poza język HTML. I to jest właśnie najważniejsza zmiana wprowadzona nową ustawą.

,

Gdzie do lekarza

Aplikacja Terminy leczenia NFZ
Gdzie do lekarza
5 (100%) 16 głos[ów]

Dziś mamy dla was coś szczególnie przydatnego – bezpłatna aplikacja Terminy leczenia NFZ, dostępna dla telefonów z iOS i Androidem, pozwala sprawdzić najbliższy wolny termin leczenia w ramach pakietu świadczeń gwarantowanych Narodowego Funduszu Zdrowia. Aplikacja korzysta bezpośrednio z bazy kolejkowej NFZ udostępnianej poprzez API opracowane ze wsparciem UE i oferuje przeszukiwanie pełnego spektrum tej obszernej bazy dla terenu całej Polski – wyszukuje wolne miejsca i sprawdza terminy zarówno do lekarzy specjalistów, na zabiegi, badania diagnostyczne, jak i wolne miejsca w oddziałach szpitalnych.

Wyszukiwanie terminów to nie wszystko – można też bezpośrednio skontaktować się z wybranym szpitalem lub przychodnią oraz sprawdzić, czy dana placówka oferuje parking, windę, udogodnienia dla osób niepełnosprawnych itp.

 

,

Android Q – kompatybilność zachowana

Android Q - kompatybilność zachowana
Android Q – kompatybilność zachowana
4.92 (98.46%) 13 głos[ów]

No i jest – pierwsza wersja deweloperska Androida Q, która w telefonach użytkowników zacznie pojawiać się w przyszłym roku. Obejrzeliśmy, sprawdziliśmy i spieszymy z informacjami co nowego. W kwestii kompatybilności Waszych aplikacji wyprodukowanych dla Androida 5.0 Lollipop i nowszych nie musicie się niczym martwić – nie znaleźliśmy żadnych problemów z kompatybilnością i nic nie wskazuje na to, aby w kolejnych wersjach deweloperskich, aż do wydania ostatecznego miały się takowe problemy pojawić. W gruncie rzeczy Android Q nie wnosi wiele w stosunku do obecnej wersji Androida P – Pie. Jest to raczej zestaw usprawnień interfejsu użytkownika, jak cokolwiek co mogłoby wpłynąć na funkcjonalność, czy kompatybilność istniejących aplikacji. Z najważniejszych zmian:

  • Android Q pozwala zmieniać motywy systemu – kolory akcentowe, czcionki, kształty ikon. Dodaje też motyw ciemny, który może wymuszać ciemny motyw dla zewnętrznych aplikacji o ile te takowy posiadają. Warto zatem w kolejnych aktualizacjach własnych aplikacji zadbać o dodanie do nich night mode.
  • Przewidywany czas pracy na aktualnym naładowaniu akumulatora jest pokazywany na pasku szybkich ustawień.
  • Można dzielić się szczegółami o sieci Wi-Fi za pomocą kodu QR.
  • Android Q wprowadza natywny tryb pulpitu po podłączeniu zewnętrznego monitora.
  • Dodano funkcję nagrywania ekranu.

Nieco ciekawsze, aczkolwiek też nie rewolucyjne, zmiany dodano „pod maską” i mają one znaczenie jeśli planujecie rozwijanie swojej aplikacji lub produkcję nowej. Są to funkcje dostępne dla programistów, zatem ich użycie można uwzględniać podczas projektowania aplikacji:

  • Dostępne są dodatkowe informacje z aparatów – głębia obrazu i poszczególnych obiektów na ujęciu.
  • Wsparcie dla składanych smartfonów.
  • Dodatkowe ustawienia dla urządzeń IoT (Internet of Things – internet rzeczy).
,

Apple i NFC

iPhone, iPad i NFC
Apple i NFC
5 (100%) 15 głos[ów]

Aplikacje typu Karta Miejska stają się coraz powszechniejsze wraz z postępującą cyfryzacją życia codziennego. Jedną z najnowszych jest aplikacja Miasta i Gminy Piaseczno (od premiery minął zaledwie miesiąc). Produkcja tej aplikacji okazała się o tyle interesująca, że przyniosła nam przygodę ze sprzętem Apple – przygodę, podczas której frustrację, że Apple (które jako firma będąca producentem systemu iOS ma do tego pełne prawo) czegoś ponownie programistom zabrania, udało się przekuć w funkcję wzbogacającą usability apki i poprawiającą komfort jej obsługi dla użytkownika końcowego.

Ale po kolei – założenie było takie, że aplikacja ma korzystać z dedykowanego API i umożliwiać odczyt wyemitowanych już przez Gminę Piaseczno i będących w rękach mieszkańców kart za pomocą NFC. Karty wyprodukowano w jednym z bezpiecznych, szyfrowanych standardów, których… iOS nie obsługuje. Ściśle rzecz ujmując obsługuje, jednak tylko pierwszy, w pełni otwarty i nieszyfrowany sektor pamięci kart zawierający tzw. tag publiczny. W założeniach Apple, NFC ma bowiem służyć do obsługi płatności Apple Pay i ewentualnie do odczytywania publicznie dostępnych informacyjnych tagów NFC w miejscach takich jak muzea, czy galerie handlowe. Odczyt szyfrowanych sektorów kart pod iOS za pomocą NFC jest zatem niemożliwy, a tymczasem potrzebny do poprawnej obsługi numer karty jest bezpiecznie zaszyfrowany właśnie w tych sektorach…

Dla kreatywnego programisty nie ma jednak sytuacji bez wyjścia. Na każdej karcie nadrukowany jest kod kreskowy pozwalający ją zidentyfikować, a iPhone i iPad są wyposażone w aparat fotograficzny. Zatem NFC w przypadku systemu iOS można zastąpić skanerem kodów kreskowych. I tak, funkcjonalnie na ograniczeniu narzucanym przez Apple w iOS zyskali użytkownicy wersji na system Android, którzy mogą odczytywać swoje karty i za pomocą NFC i za pomocą skanowania kodu kreskowego.