• Nie Znaleziono Wyników

Błędy znalezione podczas walidacji kodu HTML są najliczniej występującymi nieprawidłowościami we wszystkich badanych wdrożeniach. Utilitia wyróżnia wśród nich m.in. problem z powtarzalnością identyfikatorów HTML; dodatkowo w przypadku systemów EDS i Summon pojawiają się błędnie użyte nagłówki. Utilitia wskazuje również we wszystkich trzech systemach na błędy w CSS-ie35. Kwestie te w świetle WCAG 2.0 stanowią problemy na poziomie podstawowym (A).

W ramach przeprowadzonego badania dostępności założono poprawność automatycznej analizy w tym zakresie, nie weryfikując wyników poprzez sprawdzenie kodu interfejsów. Należy jednak mieć świadomość, że zapisy uznawane w HTML-u i CSS-ie za błędne mogą być efektem dążenia do optymalizacji wyświetlania strony w starszych wersjach przeglądarek internetowych.

Punktem, w którym Utilitia również wskazała nieprawidłowości we wdrożeniach wszystkich trzech systemów, jest dostępność linków. Niedogodnością dla osoby niewidomej może być brak możliwości określenia celu odnośnika po samej jego treści (poziom AAA) – np. link opisany „Pełny tekst PDF” nie informuje, do pełnego tekstu jakiego dokumentu zostanie przeniesiony użytkownik.

Mimo że możliwość rozpoznania miejsca docelowego linku przyporządkowano do najwyższego poziomu (AAA), brak tej możliwości stanowi utrudnienie z punktu widzenia osób niewidomych i niedowidzących, których poruszanie się po systemie opiera się na nawigowaniu sekwencyjnym36, przenoszeniu fokusu między kolejnymi odsyłaczami (których etykiety mogą być odczytywane na głos przez programy typu screen reader).

Dla takiego użytkownika utrudnione jest odróżnienie odnośników i zidentyfikowanie właściwego linku, szczególnie kiedy ta sama etykieta jest wykorzystana w różnych kontekstach.

35 CSS (ang. Cascading Style Sheets), czyli kaskadowe arkusze stylów zawierają reguły wyświetlania dokumentów elektronicznych w przeglądarce internetowej (m.in. krój i rozmiar fontu, kolory, odstępy między wierszami) (Meyer, 2004, p. 3–4).

36 Nawigowanie sekwencyjne wg WCAG 2.0 to nawigowanie po stronie poprzez przenoszenie fokusu między kolejnymi elementami przy pomocy klawiatury (Caldwell et al., 2013). Kiedy fokus znajduje się na wybranym odnośniku, użytkownik może łatwo go aktywować i przenieść się do miejsca docelowego, do którego prowadzi link.

2.Dostępność systemów discovery

W tej sytuacji niezwykle istotna jest kolejność, w jakiej fokusowane są poszczególne hiperłącza na stronie – w systemach EDS i Primo jest ona prawidłowa, co częściowo niweluje problemy spowodowane powtarzającymi się etykietami. Testy eksperckie pozwoliły natomiast zidentyfikować problem z kolejnością fokusów w badanym wdrożeniu Summona – poważnym utrudnieniem dla użytkowników niewidomych może być fakt, że na liście wyników wyszukiwania fokus pojawia się najpierw na opcji podglądu szczegółów rekordu oraz funkcji zapamiętania rekordu w systemie na czas trwania sesji, a dopiero w dalszej kolejności na tytule dokumentu. Oznacza to, że użytkownik otrzymuje dostęp do funkcji, zanim dowie się, jakiego dokumentu one dotyczą.

Twórcy WCAG 2.0 zwracają uwagę na umożliwienie określenia celu linku po treści odnośnika w połączeniu z kontekstem, w jakim się znajduje (nagłówek, sąsiedni akapit itp.).

Postulat sugerujący powinność wykonania strony tak, aby to umożliwić, przyporządkowano do poziomu A. Utilitia wskazała błędy w zakresie dostępności linków także na tym poziomie w przypadku wszystkich systemów, jednak zdaniem autorki systemy discovery spełniają to kryterium skuteczności.

Chociaż w przypadku większości elementów fokus jest dobrze widoczny, w każdym z badanych wdrożeń można znaleźć sytuacje, w których wymóg (na poziomie AA) ten nie jest spełniony. W EDS-ie fokus nie zawsze jest widoczny w górnym menu, w którym umieszczono funkcję zmiany języka czy link do logowania w serwisie EBSCOhost, w Primo nie jest widoczny na przycisku inicjującym wyszukiwanie, a w Summonie nie widać go, kiedy znajduje się na ikonach towarzyszących wynikom wyszukiwania.

Żadne z poddanych badaniu dostępności wdrożeń nie posiada ścieżek powrotu (zwanych powszechnie okruszkami), które wskazują miejsce strony, na której znajduje się użytkownik, w strukturze większej, hierarchicznie zorganizowanej całości. Stosowanie ścieżek powrotu jako elementu nawigacji znajduje zastosowanie w przypadku stron o układzie hierarchicznym. Nie jest to jednak cecha systemów discovery, podobnie jak innych systemów wyszukiwawczych, dlatego nawigacja w postaci ścieżek powrotu nie znalazła w tym przypadku zastosowania i jej brak nie powinien być zdaniem autorki uznany za nieprawidłowość.

Wszystkie systemy realizują postulat dotyczący stosowania tekstu alternatywnego w przypadku komponentów nietekstowych – w przypadku systemów discovery są to treści graficzne (poziom A). Tekst alternatywny stanowi informację o treści przedstawionej w sposób inny niż przy pomocy tekstu i jest przeznaczony dla osób niewidomych

2.Dostępność systemów discovery

i niedowidzących, dla których utrudniona jest percepcja takiego komunikatu. Problematyczny jest jednak brak tłumaczenia tych alternatywnych tekstów na język interfejsu. W przypadku Primo wszystkie znalezione teksty alternatywne występowały w języku angielskim, w Summonie to samo dotyczyło większości przypadków. Najlepiej sytuacja wygląda w EDS-ie, chociaż i w jego przypadku zdarzają się nieprzetłumaczone frazy.

Możliwość powiększenia zawartości do 200% (poziom AA), a nawet więcej, jest dostępna we wszystkich trzech wdrożeniach. Odnotowano jednak znaczne utrudnienia w korzystaniu z tej funkcji w Summonie Biblioteki Uniwersyteckiej we Wrocławiu. Funkcja nie działa płynnie, opóźnienie jej realizacji przekracza nawet 20 s., przez co staje się ona nieprzydatna, a wręcz korzystanie z niej utrudnia pracę w systemie.

W przypadku wszystkich badanych wdrożeń po powiększeniu treści strony do 200%

zawartość nie dostosowuje się do szerokości strony – w celu zobaczenia całej treści konieczne jest skorzystanie z poziomego przewijania. Niespełniony postulat przyporządkowano do poziomu AAA, jego realizacja nie jest więc niezbędna. Byłaby jednak udogodnieniem nie tylko dla osób mających problemy ze wzrokiem, lecz także dla korzystających ze sprzętu charakteryzującego się niską rozdzielczością. Co ciekawe, w przypadku Primo, po zwężeniu okna przeglądarki na możliwie najmniejszą szerokość, interfejs ponownie staje się dostosowany do szerokości.

Zastosowanie odpowiedniego kontrastu w WCAG 2.0 zdefiniowano na poziomie AA oraz AAA; minimalnymi wymaganymi wartościami kontrastu są odpowiednio 4,5:1 i 7:1.

Żadne z badanych wdrożeń nie spełnia tego kryterium sukcesu nawet na niższym z poziomów. Zdecydowana większość stron we wszystkich wdrożeniach charakteryzowała się odpowiednią różnicą kolorów w większości zawartości, jednak w każdym z systemów znaleziono elementy, których odczytanie ze względu na niewystarczająco wysoki kontrast może być kłopotliwe dla osób mających problemy ze wzrokiem. W EDS-ie zbyt mały kontrast miały przykładowo wartości znajdujące się na rozwijanej liście służącej do zdefiniowania warunku sortowania (jasnoniebieskie napisy na białym tle), a w Primo i Summonie zbyt mała różnica kolorów występuje m.in. na przycisku inicjującym wyszukiwanie (w obu przypadkach jest to jasny napis na pomarańczowym tle).

Kolory, a więc i kontrast, stanowią cechę indywidualną wdrożenia. Teoretycznie zatem nieprawidłowości znalezione w tym zakresie nie muszą się odnosić do innych wdrożeń badanych systemów. Jednak interfejsy EDS-a i Summona zastosowane w badanych wdrożeniach są widokami standardowymi, stosowanymi także przez inne biblioteki. Primo

2.Dostępność systemów discovery

Biblioteki UWM w Olsztynie, mimo że odbiega najdalej od standardowego wyglądu, posiada elementy domyślnego widoku, wśród których jest niespełniający wymogu odpowiedniego kontrastu przycisk „Szukaj”. Można na tej podstawie przypuszczać, że inne wdrożenia EDS-a, Primo i Summona również mogą posiadać elementy z niewystarczającym kontrastem.

Producenci systemów podczas projektowania powinni uwzględnić możliwość wpływania przez użytkowników na limity czasu – w przypadku badanych wyszukiwarek w odniesieniu do tego zapisu problemem może być ograniczony czas bezczynności w systemie, po upływie którego sesja zostaje przerwana. Standard WCAG 2.0 uznaje za spełnione kryterium związane z możliwością dostosowania czasu na poziomie A w sytuacji, kiedy użytkownik ma przynajmniej jedną z następujących możliwości:

• wyłączenie limitu czasu;

• dostosowanie limitu czasu do własnych potrzeb;

• przedłużenie limitu czasu ad hoc (użytkownik otrzymuje komunikat o dobiegającym końca limicie czasowym, który może w prosty sposób przedłużyć, np. wciskając spację).

Żaden z systemów nie oferuje ani jednej z powyższych opcji w odniesieniu do czasu trwania sesji i dopuszczalnego czasu bezczynności. Utrata wyników wyszukiwania, zapamiętanych rekordów (w przypadku EDS-a i Summona w każdych okolicznościach, a w Primo w przypadku braku zalogowania) w wyniku zbyt długiego czasu bezczynności spowodowanego np. równoległym poszukiwaniem treści w katalogach innych bibliotek, może być sytuacją kłopotliwą dla wszystkich, nie tylko dla osób uznawanych za wykluczone.

Konsekwencją problemów z czasem trwania sesji jest konieczność ponownego zalogowania się po jej zakończeniu (dotyczy to wdrożeń, w których logowanie jest konieczne lub możliwe, a więc w tym przypadku badanych wdrożeń systemu EDS i Primo). Fakt, że po ponownej autoryzacji użytkownik nie rozpoczyna pracy w miejscu, w którym znajdował się w momencie automatycznego wylogowania z systemu, ale musi rozpocząć proces poszukiwania zasobów od początku, również może być frustrujący dla wszystkich użytkowników. Utrata danych po wylogowaniu i brak odzyskania ich w momencie ponownego uwierzytelnienia oznacza problem z realizacją punktu 2.2.5. Został on przyporządkowany do poziomu AAA, niemniej opisana sytuacja może okazać się wysoce frustrująca, a utracone dane (np. wyniki wyszukiwania będące efektem długotrwałych modyfikacji zapytania) mogą nie być możliwe do odtworzenia w stu procentach.

2.Dostępność systemów discovery

W systemie EDS wdrożonym w BUW-ie Utilitia wskazała na istnienie zbyt szybko mrugających elementów. Program sugeruje, że wytyczna związana z niwelowaniem ryzyka wystąpienia u użytkownika ataku padaczki nie jest spełniona nawet na poziomie A na stronie z wynikami wyszukiwania. Autorka nie potwierdza jednak tej oceny – podczas testów eksperckich mających zweryfikować wyniki uzyskane przy pomocy automatycznej analizy nie znaleziono żadnych ruchomych elementów, które mogłyby stanowić zagrożenie dla epileptyków. Wskazanie systemu Utilitia uznano za błędne, a wdrożenie systemu EDS za spełniające postulat związany z migotaniem elementów strony.

EDS jako jedyny posiada opcję pomocy kontekstowej, nie odpowiada ona jednak w pełni na potrzeby polskiego rynku. Jest to narzędzie bardzo przydatne w przypadku, kiedy użytkownik chce dowiedzieć się do czego służy konkretna funkcja lub jakie ma możliwości działania w miejscu systemu, w którym się znajduje. W przypadku systemu EDS brakuje jednak polskiej wersji językowej plików pomocy, przez co są one dostępne tylko dla grupy użytkowników posługujących się językiem angielskim.

Jedynie w przypadku Primo przeanalizowano realizację punktu, który odnosi się do przechowywania i modyfikacji danych (w żadnym z pozostałych systemów nie było możliwości wprowadzania i modyfikowania danych związanych z kontaktem z użytkownikiem, transakcjami finansowymi itp.), punkt ten przyporządkowano do poziomu AA. Testy wykazały, że wprowadzanie danych jest odwracalne, dane są sprawdzane pod kątem błędów (przykładowo sprawdzana jest składnia adresu e-mail), brakuje jedynie mechanizmu potwierdzania danych przed wysłaniem formularza. Postulat ten mógłby być realizowany poprzez wyświetlenie okna, które należy zatwierdzić w celu ostatecznego wysłania formularza z danymi. Mimo tego braku badane wdrożenie Primo spełnia opisane kryterium sukcesu, ponieważ za wystarczającą uznaje się realizację jednego z wymienionych podpunktów.

Mimo że żaden z systemów nie pozwala na dostosowanie czasu trwania sesji, w tym na przedłużenie jej doraźnie, Primo najlepiej neutralizuje skutki tego braku.

W przypadku kiedy użytkownik korzysta z systemu po uprzednim uwierzytelnieniu, dane zapisane w czasie korzystania z systemu, np. rekordy dodane do e-półki, zostają zapamiętane i są dostępne po ponownym zalogowaniu (realizacja postulatu na poziomie AAA).

Analogiczne dane mogą zostać zapamiętane w EDS-ie, jednak nie wystarcza do tego zalogowanie na konto biblioteczne (za pośrednictwem systemu HAN) – konieczna jest dodatkowa rejestracja i zalogowanie do konta w serwisie EBSCOhost. Oznacza

2.Dostępność systemów discovery

to, że aby zapamiętać rekordy w systemie, użytkownik musi się zalogować jednocześnie do dwóch kont. W przypadku Summona nie ma możliwości logowania, wskutek czego rekordy mogą zostać zapamiętane jedynie na czas bieżącej sesji, a po jej zakończeniu nie ma możliwości ich odzyskania.

Jedynie we wdrożeniu Summona badanie przy pomocy systemu Utilitia wykazało braki w etykietach w polach formularza na wszystkich stronach, które udało się poddać badaniu (poziom A). Podobnie jest w przypadku innego postulatu, również przyporządkowanego do poziomu A, dotyczącego nagłówków. Ekran zawierający formularz wyszukiwania nie posiada nagłówka, co może utrudnić użytkownikowi identyfikację funkcji ekranu.

Inne niespełnione w Summonie kryterium na poziomie AA wiąże się z dwoma opisanymi powyżej. Traktuje ono o konieczności stosowania etykiet pól formularzy i nagłówków jednoznacznych, odzwierciedlających treść i jej strukturę. Brak realizacji wyżej opisanych punktów na poziomie A uniemożliwia realizację również tego postulatu.

Dodatkowym problemem jest zachowanie Summona, podczas gdy okno z zapisanymi rekordami jest wyświetlone na ekranie, a użytkownik kontynuuje przenoszenie fokusa.

Po zaznaczeniu wszystkich elementów w oknie prezentującym zapamiętane rekordy, Summon kontynuuje przenoszenie fokusa na stronę w tle (np. z wynikami wyszukiwania). Nie pozwala jednak skorzystać ze wszystkich funkcji na tej stronie dostępnych, nie reagując na część poleceń wywołanych wciśnięciem klawisza „enter” – nie jest możliwe ograniczenie wyników przy pomocy faset. Taka sytuacja może stanowić problem przede wszystkim dla osób niewidomych, jednak kłopotliwa może być również dla wszystkich pozostałych.

2.4.Dostępność systemów discovery w kontekście polskich