Co czwarta strona www na Wodpressie

WordPress wyrósł na lidera CMS typu open source i lidera systemów CMS w ogóle. Jak wynika z zakończonej niedawno analizy W3Techs, WordPress odpowiada obecnie za aż 25 procent wszystkich stron dostępnych w sieci. Z tego CMS korzysta aktualnie 58,7% stron www korzystających z systemów zarządzania treścią, co odpowiada 25 procentom wszystkich stron dostępnych w Internecie. Drugim najpopularniejszym CMS-em używanym przez wydawców stron jest Joomla, mająca obecnie 9% udziałów. Popularność WordPressa rośnie z roku na rok. W 2011 roku oparte o niego było 13,21% stron www, a rok później już 15,8%.

Wynik ten to absolutna deklasacja rywali. Wyraźnie widać, że z trzech równorzędnych jeszcze kilka lat temu platform CMS, czyli WordPressa, Joomla i Drupala, na placu boju został w praktyce tylko ten pierwszy. O ile Joomla jeszcze jakoś sobie radzi, o tyle ewidentne pogubienie się zespołu deweloperskiego Drupala (wydawanie stabilnej wersji 8 trwało ponad dwa lata!) prawdopodobnie zepchnie ten CMS na margines silników zarządzania stronami www. Pytanie tylko, czy taki układ sił służy użytkownikom? Zaletą WordPressa niewątpliwie są łatwość obsługi i tysiące wtyczek pozwalających zbudować i rozbudowywać praktycznie dowolny serwis www – i w tym należy upatrywać rosnącej popularności tego CMS – wadą, raczej niewielki poziom bezpieczeństwa w podstawowej instalacji. Używając WordPressa zawsze warto pamiętać o zadbaniu o bezpieczeństwo opartej na nim strony www we własnym zakresie.

Aplikacje mobilne na Android Wear i Apple Watch

Urządzenia naręczne oparte o platformy Android Wear i Watch OS, czyli po prostu zegarki z Androidem i Apple Watch stają się coraz popularniejsze. Abstrahując od dyskusji o przydatności tych gadżetów, faktem jest, że w ciągu ostatniego roku ich sprzedaż przekroczyła poziom 10 milionów. Stają się zatem kolejną platformą potencjalnego dotarcia do odbiorcy z informacją o usługach, czy produktach. Urządzenia te zaczynają także znajdować swoje miejsce w kulturze informacji – i tu ich roli nie sposób już nie docenić: powiadomienia o zbliżającym się terminie zabiegu, opóźnieniu lotu, wyniki badań przesyłane do firmowej aplikacji – przykłady zastosowań można mnożyć. Odpowiadając zatem na pytanie postawione w tytule: jeśli twoja organizacja/firma oferuje aplikację na telefony komórkowe (czy to dla klientów, czy też wewnętrzną dla pracowników) warto rozważyć uzupełnienie jej o aplikację dla urządzenia naręcznego. Jest to kolejny sposób na budowanie bliskich relacji z klientami, czy w zespole – nieco żartem można powiedzieć, że w tym wypadku już nie w kieszeni, a wręcz „przy skórze”. Nie ma najmniejszych wątpliwości, że elektronika „do ubierania” ma przed sobą świetlaną przyszłość. Kilkanaście lat temu telefon w kieszeni mający możliwości przenośnego komputera też wydawał się dość fantastycznym pomysłem… Dziś mało kto nie używa telefonu komórkowego.

Kompendium WCAG 2.0: Wytyczna 3.3 Pomoc przy wprowadzaniu danych

Postaraj się pomóc użytkownikom nie robić błędów, a w razie wystąpienia błędu pomóż go skorygować

tak brzmi wytyczna 3.3 specyfikacji WCAG 2.0 i należy ją rozumieć dosłownie.

3.3.1 Jasna identyfikacja błędów
Informacja po wystąpieniu błędu musi być jasna, skuteczna i intuicyjna oraz dostępna dla wszystkich użytkowników.
Trzeba pozwalać użytkownikowi jednoznacznie określić błąd oraz udostępnić możliwość jego skorygowania. Prostym przykładem jest formularz z wymaganym polem „Wpisz swoje imię”. Jeśli użytkownik nie wypełni tego pola i usiłuje wysłać formularz strona wyświetla jasny, tekstowy komunikat „Proszę wpisz swoje imię!”.

3.3.2 Etykiety i instrukcje
W każdym miejscu strony www, w którym wymagane jest wprowadzenie przez użytkownika informacji należy zapewnić jasne etykiety, instrukcje wypełnienia formularza, przykłady itp. pomoc.

3.3.3 Podpowiadaj rozwiązania błędów
Stosuj czytelne, jasne i prezentowane w sposób dostępny podpowiedzi w wypadku wystąpienia błędu podczas wprowadzania danych do formularza przez użytkownika. Sugestie nie mogą zmieniać celu treści oraz stanowić zagrożenia bezpieczeństwa (np. system nie może wyświetlać w podpowiedzi hasła użytkownika).

3.3.4 Zapobieganie błędom podczas wypełniania formularzy niosących konsekwencje prawne
Należy zapewnić dostępne mechanizmy umożliwiające przywrócenie danych oraz ich weryfikację.
Jeśli na stronie www użytkownik może:
– zawierać zobowiązania prawne lub transakcje finansowe,
– modyfikować i usuwać przechowywane dane,
– wypełniać testy
trzeba zapewnić dostępne mechanizmy umożliwiające przywrócenie danych oraz ich weryfikację.

3.3.5 Pomoc
W każdym miejscu strony www, gdzie użytkownik może wprowadzać, zmieniać lub usuwać informacje trzeba zapewnić pełną, jasną i rzeczową informację o tym, jak należy to zrobić. Może to być forma opisu, prezentacji, wirtualnego asystenta i wszelkie inne formy pomocy zaimplementowane w sposób zapewniający dostępność.

3.3.6 Bezwzględne zapobieganie błędom
Ten punkt jest tożsamy z wytyczną 3.3.4 z rozszerzeniem, że mechanizmy pozwalające na przywrócenie poprzednich danych i ich weryfikację muszą być zaimplementowane bezwzględnie dla wszystkich formularzy wysyłających dane ze strony www.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Kompendium WCAG 2.0: Wytyczna 3.2 Przewidywalność

Buduj strony www, tak aby otwierały się i działały w sposób, który da się przewidzieć

tak brzmi zalecenie wytycznej 3.2 specyfikacji WCAG 2.0

3.2.1 Zaznaczanie elementu
Na stronie www nie powinna zaistnieć żadna zmiana kontekstu wprowadzająca w błąd lub dezorientująca użytkownika, jeśli jakikolwiek element tej strony otrzymał zaznaczenie (angielskie: focus). Nie powinno dochodzić do automatycznego przeładowywania strony, wysyłania formularzy etc. Wszystkie zmiany muszą być świadomym działaniem ze strony użytkownika.

3.2.2 Wprowadzanie danych
Nie wolno powodować automatycznej zmiany kontekstu treści podczas zmiany ustawień jakiegokolwiek elementu interfejsu przez użytkownika. Jeśli taki mechanizm jest niezbędny, należy bezwzględnie ostrzec użytkownika o takiej zmianie i to jeszcze zanim zacznie korzystać z elementu powodującego zmianę.

3.2.3 Jednolita nawigacja
Wszystkie elementy nawigacji powtarzające się na podstronach strony www, czy systemu informatycznego powinny pojawiać się w tym samym porządku za każdym razem, gdy są prezentowane. Dozwolone jest umieszczanie dodatkowych informacji pomiędzy powtarzającymi się elementami nawigacji, czy ich pomijanie w uzasadnionych sytuacjach, jednak pod warunkiem zachowania ustalonego porządku pozostałych.

3.2.4 jednolita identyfikacja
Elementy o tożsamej funkcjonalności na różnych podstronach strony www powinny być tak samo rozpoznawane. Np. formularze powinny być zawsze o tym samym wyglądzie. Takie działanie ułatwia odbiór strony użytkownikom z problemami kognitywnymi.

3.2.5 Zmiana na żądanie
Wszystkie zmiany treści i kontekstu strony www (np. pojawienie się wyskakujących okien, przekierowania, elementy wprowadzania danych) są wywoływane i prezentowane tylko na świadome życzenie użytkownika – bez wyjątku w całym serwisie.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Collaser - edytor zdjęć dla iOS i Androida

Jeśli lubicie pobawić się zdjęciami i chcecie obudzić w sobie nutę kreatywności projektując zabawne kolaże zapoznajcie się z naszą nową aplikacją demonstracyjną. Collaser to zaawansowany edytor kolaży z możliwością edycji zdjęć robionych smartfonem, czy tabletem. Można także edytować zdjęcia wczytane z biblioteki urządzenia. W aplikacji znajdziecie ponad 150 różnych elementów do tworzenia kolaży i ciekawe narzędzia do edycji zdjęć. Wynikami swojej zabawy można podzielić się ze znajomymi na wszystkich portalach społecznościowych, a jeśli będziecie chcieli funkcje geolokalizacji określą za Was miejsce zrobienia zdjęcia. Aplikacja dostępna jest bezpłatnie dla systemów iOS (iPhone, iPad) oraz Android.

 

Certyfikaty WCAG 2.0

Nawiązując do dużej ilości zadawanych nam pytań postaramy się wyjaśnić kwestę tzw. certyfikatów zgodności stron internetowych z WCAG 2.0, co ma związek z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, nakazującym instytucjom użyteczności publicznej oraz organom administracji państwowej i samorządowej dostosowanie stron www i systemów teleinformatycznych do standardu WCAG 2.0.

Już na wstępie należy podkreślić, że Polskie instytucje państwowe nie prowadzą certyfikacji zgodności stron z WCAG 2.0. Wynika to z natury samej specyfikacji WCAG 2.0, która jest tworzona i rozwijana na bieżąco przez jedną z agend ONZ. Rząd musiałaby powołać stosowny urząd kontrolny, a instytucja ta musiałaby zostać akredytowana przy W3C i ONZ. Nie istnieje zatem certyfikat zgodności z WCAG 2.0 w rozumieniu dokumentu poświadczanego przez instytucję państwową. Deklarację zgodności wystawia jednostka przeprowadzająca audyt poświadczając tym samym poziom zgodności i przyjmując na siebie za taką deklarację odpowiedzialność.

Również w przypadku prowadzonego przez nas audytu WCAG 2.0 wystawiana jest pisemna deklaracja zgodności strony z WCAG 2.0 i Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności. Strony www, które uzyskują wymagany poziom zgodności mogą ponadto posługiwać się logotypem W3C informującym o zgodności z danym poziomem WCAG 2.0. Wzory logotypów wyglądają następująco:

Logotypy zgodności z WCAG 2.0

Logotypy zgodności z WCAG 2.0

Warto także przypomnieć, że rozporządzenie nakłada obowiązek dostosowania stron www według wybranych 36 pozycji specyfikacji WCAG 2.0, pogrupowanych w 12 wymagań, według 4 zasad, w 10 punktach do poziomu AA (drugi, z trzech możliwych), w pozostałych do poziomu A. Nie jest wymagany zatem pełny audyt WCAG 2.0 i dostosowywanie stron do poziomu AAA. Ta kwestia budzi wiele wątpliwości – strony www według wspomnianego rozporządzenia muszą zostać dostosowane do poziomu AA WCAG 2.0.

Należy także pamiętać, że wspomniane rozporządzenie określa ponadto minimalne wymagania, które musi spełnić sam audyt WCAG 2.0. Wymagania te wynikają bezpośrednio ze specyfikacji WCAG 2.0 i ich niespełnienie może skutkować zakwestionowaniem audytu WCAG 2.0 przez instytucje kontrolne. Minimalnych wymagań nigdy nie spełni audyt WCAG 2.0 przeprowadzony przez jedną osobę. W audycie WCAG 2.0 bierze udział minimum 6-oosobowy zespół specjalistów – złożony nie tylko z programistów oceniających techniczną budowę kodu strony internetowej i zastosowane rozwiązania z zakresu user experience lecz również samych zainteresowanych: osób niepełnosprawnych z różnymi dysfunkcjami, do których kierowane jest rozporządzenie. Audyt powinien zostać również skontrolowany i zatwierdzony przez specjalistę ds. rehabilitacji osób niepełnosprawnych. Audyt WCAG 2.0 prowadzony bez udziału osób niepełnosprawnych nie spełnia wymagań Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, które to rozporządzenie w dużej mierze opiera się na specyfikacji WCAG 2.0. Sama specyfikacja bowiem, w swoich założeniach, przewiduje oprócz kontroli technicznych aspektów działania, dostępności i dostosowania strony internetowej, kontrolę jej faktycznego odbioru przez osoby niepełnosprawne.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

System Android, a strategia marketingowa

Planując własną aplikację dla systemu Android coraz więcej firm ma problem z konkretnym wyznaczeniem ścieżki osiągnięcia celów sprzedażowych, bądź marketingowych jakie aplikacja ma przynieść i samego cyklu życia oprogramowania. Powodem takiego stanu rzeczy jest naturalnie coraz większa fragmentacja tego mobilnego systemu operacyjnego. Fragmentacja to ilość wersji tego samego systemu mających znaczący udział w rynku urządzeń konsumenckich w jednym czasie. Android pod tym względem jest absolutnym liderem – obecnie w codziennym użyciu jest sześć głównych wersji tego systemu, dodatkowo modyfikowanego przez różnych producentów na potrzeby swoich urządzeń. Pomijając różnice w funkcjach i kompatybilności rozmaitych rozwiązań, najczęściej pada pytanie – do której wersji Androida aplikacja powinna być kompatybilna? Na chwilę obecną najwłaściwsze wydaje się dostosowywanie aplikacji do Androida 4 (czyli Androida 4.0, 4.1, 4.2, 4.3 i 4.4), gdyż ta wersja systemu zajmuje największą część rynku. Jeśli jednak aplikacja ma pracować na wizerunek firmy przez około dwa lata, a taki jest przeciętny czas życia aplikacji produktowej/wizerunkowej, warto już obecnie rozważać wsparcie dla Androida 5 Lollipop.

Najnowszy Android 5.0 i 5.1, kilka miesięcy po premierze, ma udziały w rynku na poziomie 1.6%. Niemniej jednak jego znaczenie będzie wzrastać wraz z kolejnymi urządzeniami prezentowanymi przez poszczególnych producentów. Jako problem często jest jednak postrzegany diametralnie zmieniony design najnowszej wersji tego systemu. W Androidzie 5 Google wprowadził bowiem nowy, płaski wygląd interfejsu użytkownika zwany Material Design. Aplikacje z Androida 4 w najnowszej odsłonie wyglądają jakby nie pasowały do całości. Część firm wybiera zatem rozwiązanie pośrednie, publikując dwie wersje aplikacji z odmiennym designem interfejsu – dla starszego i nowszego Androida. Takie działanie naturalnie zapewnia użytkownikom różnych wersji systemu Google maksymalnie pozytywne doświadczenia, jednak jest droższe we wdrożeniu i aktualizacjach. Planując nową aplikację, gdy w rachubę wchodzi optymalizacja kosztów, warto rozważyć zatem wydanie wersji aplikacji dostosowanej designem do Androida 5 również dla wcześniejszych wersji tego systemu – użytkownikom starszych wersji systemu zaprezentuje się ona jako aplikacja o niestandardowym, niemniej jednak eleganckim, interfejsie, a jednocześnie, w ciągu najbliższych kilkunastu miesięcy, gdy Android 5 będzie stopniowo zastępował starsze wersje, aplikacja nie zdewaluuje się pod względem wizerunkowym.

Kompendium WCAG 2.0: Wytyczna 3.1 Czytelność

Treść strony www oraz obsługa interfejsu użytkownika musi być zrozumiała

tak w dosłownym przekładzie brzmi zasada 3 specyfikacji WCAG 2.0.

Wytyczna 3.1 Czytelność
Po prostu: twórz treści czytelne i łatwe do zrozumienia

3.1.1 Język strony
Język strony powinien być jasno określony za pomocą atrybutu lang lub xml:lang w znacznikach HTML. Pozwala to poprawnie wybrać interpretowany język przez urządzenia wspomagające, używane przez osoby niepełnosprawne. W praktyce chodzi głównie o syntetyzery mowy czytające strony www osobom niewidomym.

3.1.2 Język elementów
Język elementów strony powinien być jasno określony za pomocą atrybutu lang lub xml:lang w znacznikach HTML. Podobnie, jak w punkcie 3.1.1 – pozwala m.in. poprawnie określić język dla syntetyzerów mowy.

3.1.3 Nietypowe słowa
Jeśli w treści strony www użyte są skróty, należy zapewnić opisy ich znaczeń w pełnej formie.

3.1.4 Skróty
Słowa nietypowe, nieznane powszechnie, dwuznaczne, albo używane w specyficzny sposób powinny być wytłumaczone. Np. w podręcznym słowniczku dostępnym obok tekstu.

3.1.5 Poziom umiejętności czytania
Teksty, instrukcje i informacje zawierające nazwy własne, których zrozumienie wymaga wiedzy i wykształcenia wyższego, niż poziom gimnazjalny, należy uzupełniać o streszczenia, ilustracje, wykresy itp.

3.1.6 Jak to wymówić?
Jeśli do zrozumienia słowa użytego w treści strony www niezbędna jest znajomość wymowy, zaraz po użytym słowie należy zapewnić możliwość poznania wymowy tego słowa lub zamieścić odnośnik do stosownego słownika.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Kompendium WCAG 2.0: Wytyczna 2.4 Nawigacja

Ostatni już w tym roku wpis z cyklu Kompendium WCAG 2.0 – dotychczas omówiliśmy około 50% specyfikacji, tak więc zainteresowanych tematem WCAG 2.0 zapraszamy do śledzenia naszego bloga także w roku 2015. Na koniec roku 2014 Wytyczna 2.4 Nawigacja.

Przekład z WCAG 2.0 Guideline:

Udostępnij na stronie www narzędzia pomagające użytkownikom w nawigacji, dotarciu do treści i określaniu, w którym miejscu strony się aktualnie znajdują.

2.4.1 Dostęp bezpośredni
Zapewnij w nagłówku strony www – nie chodzi o sekcję head w samym kodzie, a o nagłówek strony z punktu widzenia użytkownika – menu służące do przechodzenia do istotnych treści serwisu za pomocą kotwic, bez konieczności przeładownia strony. Pomimo, _że każdy program czytający posiada skróty klawiaturowe, dzięki którym użytkownik może poruszać się po dowolnych elementach serwisu – nagłówkach, polach formularzy, akapitach, odnośnikach itd. w ten sposób ułatwisz osobom niewidomym nawigację przez możliwość pominięcia powtarzających się na kolejnych podstronach stałych elementów np. menu narzędziowe serwisu.

2.4.2 Tytuł strony
Każda podstrona strony www czy systemu informatycznego powinna być zatytułowana w sposób jednoznaczny. Tytuł strony to bowiem pierwszy tekst odczytywany przez czytniki ekranowe.

2.4.3 Kolejność zaznaczenia
Kolejność nawigacji po odnośnikach, elementach formularzy, itp. elementach musi mieć spójną i logiczną strukturę, tak, aby zapewnić mozliwie naturalne poruszanie się pomiędzy np. polami formularza. Przykład: Pole 1 – wpisz swoje imię, 2 – wpisz swoje nazwisko.

2.4.4 Cel odnośnika i jego kontekst
Określaj jednoznacznie cel wszystkich elementów aktywnych na stronie www. Linki, przyciski formularza, czy obszary aktywne map odnośników powinny być opisane konkretnie wraz z jasnym wskazaniem celu, do którego prowadzą.

2.4.5 wiele dróg
Do każdego elementu strony www można dotrzeć przynajmniej na dwa z wymienionych sposobów:

  • spis treści,
  • wyszukiwarka,
  • mapa strony,
  • lista podstron pokrewnych,
  • lista wszystkich podstron.

2.4.6 Nagłówki i etykiety
Nagłówki i etykiety muszą być opisane w sposób logiczny, sensowny i jednoznaczny, dzięki czemu użytkownikom łatwiej jest odnaleźć konkretną treść i zorientować się w strukturze strony. Nie wolno stosować podwójnych nagłówków i etykiet, zwłaszcza w elementach aktywnych, takich jak np. pola formularza.

2.4.7 Wyraźne akcentowanie zaznaczeń
Obsługując stronę www za pomocą klawiatury, użytkownik musi wiedzieć, który aktywny element strony ma wybrany. Podczas poruszania się po stronie klawiszem Tab musi być wyraźnie widoczne, który element został zaznaczony. Minimum jest niewyłączanie za pomocą atrybutu outline:none; tzw. autofokusu dostępnego w każdej przeglądarce internetowej.

2.4.8 Lokalizacja
Użytkownik zawsze musi wiedzieć, w którym miejscu strony www lub systemu informatycznego właśnie się znajduje. Należy zatem zapewnić odnośniki powrotne do stron nadrzędnych, które użytkownik przejrzał przed dotarciem do aktualnej strony. Najczęściej stosuje się ścieżkę linków, z angielskiego zwaną breadcrumbs.

2.4.9 Cel linku bez kontekstu
Zasada tożsama z wytyczną 2.4.4, jednak bardziej restrykcyjna: Określaj jednoznacznie cel wszystkich elementów aktywnych na stronie www. Linki, przyciski formularza, czy obszary aktywne map odnośników powinny być opisane konkretnie wraz z jasnym wskazaniem celu, do którego prowadzą. Nie mogą istnieć żadne odnośniki i elementy aktywne z tym samym tekstem kierujące w różne miejsca. Dobrym przykładem jest tutaj często spotykany odnośnik „Czytaj więcej” – na tym poziomie WCAG 2.0 należy go całkowicie wyeliminować.

2.4.10 Nagłówki sekcji
Punkt tożsamy z wytyczną 1.3.1, mówiącą o stosowaniu nagłówków w strukturze ogólnej strony www. Aby zapewnić poziom zgodności AAA nagłówki należy stosować w każdej sekcji każdego dokumentu podzielonego na sekcje. Np. jeśli artykuł jest podzielony na akapity, nagłówkiem należy opatrzyć część tytułową artykułu i każdy jego akapit.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Kompatybilność aplikacji iOS na rok 2015

Rozwój rynku IT niesie różne niespodzianki, a czasami prowadzi do niecodziennych sytuacji. Dotychczas jednym z większych problemów do rozstrzygnięcia podczas projektowania aplikacji mobilnych był wybór wersji systemu Android na jakich aplikacja ma działać, gdyż rynek urządzeń z Androidem jest mocno pofragmentowany. Z urządzeniami opartymi o system iOS firmy Apple takiego problemu nie było – zazwyczaj najnowsza wersja systemu iPhone’ów i iPadów była tą obowiązującą. Tak działo się do mijającej właśnie jesieni, kiedy to Apple wydało najnowszy iOS 8. Abstrahując od analizy przyczyn dlaczego tak się stało, system spotkał się z chłodnym przyjęciem wśród użytkowników – po dwóch miesiącach od wydania, iOS 8 zainstalowany jest na zaledwie na 64% wszystkich aktywnych urządzeń produkcji Apple (dane oficjalne podane w grudniu przez Apple na podstawie ruchu urządzeń w sklepie App Store). W przypadku urządzeń z IOS jest to sytuacja bez precedensu – dotychczasowe aktualizacje tego systemu osiągały współczynnik instalacji rzędu 90% po 4 tygodniach od premiery. Taka sytuacja rodzi problem wśród osób, czy firm planujących wydanie aplikacji mobilnej dla iOS na rok 2015. Na pewno powinna być kompatybilna z iOS 8, bowiem procent udziału tego systemu w rynku będzie rósł, gdyż nowe iPhone’y i iPady sprzedawane są z tą wersją systemu. Pierwszy raz jednak trzeba wziąć pod uwagę, także w przypadku nowych aplikacji, kompatybilność wsteczną z iOS 7 – system ten obecnie ma wciąż 36% udziałów, co przekłada się na miliony użytkowników, którzy dotychczas nie przeszli na nowy system, zatem z dużym prawdopodobieństwem można założyć, że nie zamierzają tego zrobić – a ma to znaczenie w przypadku aplikacji, która z założenia powinna dotrzeć do jak największej grupy odbiorców.

Oczywiście powyższa uwaga ta nie dotyczy aplikacji korporacyjnych nieprzeznaczonych do rozpowszechniania publicznego w App Store – takie aplikacje są ściśle dostosowywane do wymagań działu IT danej firmy, a przeznaczone zazwyczaj do użytku wewnętrznego na określonej liczbie urządzeń ze zdefiniowaną „z góry” wersją systemu operacyjnego.