Korzystałem z Internetu przez jeden dzień za pomocą czytnika ekranu

Ten artykuł jest częścią serii, w której staram się korzystać z sieci pod różnymi ograniczeniami, reprezentując daną grupę demograficzną użytkownika. Mam nadzieję podnieść rangę trudności, z jakimi borykają się prawdziwi ludzie, których można uniknąć, jeśli projektujemy i rozwijamy się w sposób zgodny z ich potrzebami. Ostatnim razem przez jeden dzień nawigowałem po Internecie za pomocą samej klawiatury. Tym razem unikam ekranu i korzystam z internetu z czytnikiem ekranu.

Co to jest czytnik ekranu?

Czytnik ekranu to aplikacja, która interpretuje elementy na ekranie (tekst, obrazy, linki itd.) i konwertuje je do formatu, który osoby niedowidzące mogą używać i wchodzić w interakcje. Dwie trzecie użytkowników czytników ekranu wybiera mowę jako dane wyjściowe czytnika ekranu, a jedna trzecia użytkowników czytników ekranu wybiera alfabet Braille'a.

Czytników ekranu można używać z programami, takimi jak edytory tekstu, klienci poczty e-mail i przeglądarki internetowe. Działają poprzez mapowanie zawartości i interfejsu aplikacji do drzewa dostępności, które może być następnie odczytane przez czytnik ekranu. Niektóre czytniki ekranu muszą ręcznie mapować określone programy do drzewa, podczas gdy inne są bardziej ogólne i powinny działać z większością programów.

W systemie Windows najpopularniejszym czytnikiem ekranu jest JAWS, stanowiący prawie połowę całego rynku czytników ekranu. Jest to oprogramowanie komercyjne, którego wydanie domowe kosztuje około tysiąca dolarów. Alternatywą typu open source dla systemu Windows jest NVDA, z którego korzysta prawie jedna trzecia wszystkich użytkowników czytników ekranu na komputerach stacjonarnych.

Istnieją inne alternatywy, w tym Microsoft Narrator , System Access , Window-Eyes i ZoomText (nie pełnoekranowy czytnik, ale program powiększający ekran z możliwością czytania); łączna suma tych wartości odpowiada około 6% użycia czytnika ekranu. W systemie Linux Orca jest domyślnie dołączana do wielu dystrybucji.

Czytnikiem ekranu dołączonym do systemu macOS, iOS i tvOS jest VoiceOver . VoiceOver stanowi 11,7% użytkowników czytników ekranu na komputerach stacjonarnych i 69% użytkowników czytników ekranu na urządzeniach mobilnych. Inne główne czytniki ekranu w przestrzeni mobilnej to Talkback na Androidzie (29,5%) i Voice Assistant na Samsungu (5,2%), który sam jest oparty na Talkback, ale z dodatkowymi gestami.

Mam MacBooka i iPhone'a, więc będę używał VoiceOver i Safari w tym artykule. Safari jest zalecaną przeglądarką do używania z VoiceOver, ponieważ obie są obsługiwane przez Apple i powinny dobrze ze sobą współpracować. Używanie VoiceOver w innej przeglądarce może prowadzić do nieoczekiwanych zachowań.

Jak włączyć i używać czytnika ekranu

Moje instrukcje dotyczą VoiceOver, ale powinny istnieć równoważne polecenia dla wybranego czytnika ekranu.

VoiceOver na pulpicie

Jeśli nigdy wcześniej nie korzystałeś z czytnika ekranu, może to być trudne doświadczenie. Przejście do doświadczenia wyłącznie słuchowego jest poważnym szokiem kulturowym, a brak wiedzy o tym, jak kontrolować atak hałasu, jest denerwujący. Z tego powodu pierwszą rzeczą, której będziesz chciał się nauczyć, jest to, jak ją wyłączyć.

Skrót do wyłączania VoiceOver jest taki sam, jak skrót do jego włączania: ⌘ + F5 ( ⌘ jest również znany jako klawisz Cmd ). Na nowszych komputerach Mac z paskiem dotykowym skrótem jest przytrzymanie klawisza polecenia i trzykrotne naciśnięcie przycisku Touch ID. Czy VoiceOver mówi za szybko? Otwórz Narzędzie VoiceOver, kliknij kartę „Mowa” i odpowiednio dostosuj szybkość.

Kiedy już opanujesz włączanie i wyłączanie, musisz nauczyć się używać „klawisza VoiceOver” (który jest w rzeczywistości dwoma klawiszami wciśniętymi w tym samym czasie): Ctrl i ⌥ (ten ostatni klawisz jest również znany jako „Opcja ” lub klawisz Alt ). Używając klawisza VO w połączeniu z innymi klawiszami, możesz poruszać się po Internecie.

Na przykład możesz użyć VO + A , aby odczytać stronę internetową z bieżącej pozycji; w praktyce oznacza to przytrzymanie Ctrl + ⌥ + A . Zapamiętywanie, co odpowiada VO , jest początkowo mylące, ale notacja VO służy do zwięzłości i spójności. Możliwe jest skonfigurowanie klawisza VO tak, aby był czymś innym, więc sensowne jest posiadanie standardowej notacji, którą każdy może naśladować.

Możesz użyć klawiszy VO i klawiszy strzałek ( VO + → i VO + ← ), aby przejść kolejno przez każdy element DOM. Gdy natkniesz się na łącze, możesz kliknąć go za pomocą klawiszy VO + spacja — użyjesz tych klawiszy również do interakcji z elementami formularza.

Huza! Wiesz już wystarczająco dużo o VoiceOver, aby poruszać się po Internecie.

VoiceOver na urządzeniu mobilnym

Skrót telefonu/tabletu do włączania VoiceOver różni się w zależności od urządzenia, ale zazwyczaj jest to „trzykrotne kliknięcie” przycisku strony głównej (po włączeniu skrótu w ustawieniach).

Możesz czytać wszystko od bieżącej pozycji za pomocą polecenia Two-Finger Swipe Down , a każdy element DOM możesz wybrać po kolei, przesuwając w Swipe Right or Left .

Teraz wiesz tyle samo o iOS VoiceOver, co na komputerze!

Nawigacja według typu zawartości

Zastanów się, jak korzystasz z internetu jako widzący użytkownik. Czy czytasz uważnie każde słowo, po kolei, od góry do dołu? Nie. Ludzie są z założenia leniwi i nauczyli się „skanować” strony w poszukiwaniu interesujących informacji tak szybko, jak to możliwe.

Użytkownicy czytników ekranu mają tę samą potrzebę wydajności, więc większość z nich będzie nawigować po stronie według typu zawartości, np. nagłówków, linków lub kontrolek formularzy. Jednym ze sposobów, aby to zrobić, jest otwarcie menu skrótów za pomocą klawiszy VO + U , przejście do żądanego typu zawartości za pomocą klawiszy strzałek ← i → , a następnie poruszanie się po tych elementach za pomocą klawiszy ↑↓ .

Innym sposobem, aby to zrobić, jest włączenie „Szybkiej nawigacji” (przytrzymując jednocześnie ← i → ). Po włączeniu szybkiej nawigacji możesz wybrać typ zawartości, przytrzymując strzałkę ↑ obok ← lub → . W systemie iOS robisz to za pomocą gestu Two-Finger Rotate .

Po wybraniu typu zawartości możesz przeskakiwać przez poszczególne elementy pokrętła za pomocą klawiszy ↑↓ (lub Swipe Up or Down w systemie iOS). Jeśli wydaje Ci się, że masz dużo do zapamiętania, warto dodać do zakładek tę super poręczną ściągawkę VoiceOver w celach informacyjnych.

Trzecim sposobem poruszania się po typach zawartości jest użycie gestów gładzika. To przybliża wrażenia do korzystania z VoiceOver w systemie iOS na iPadzie/iPhonie, co oznacza konieczność zapamiętania tylko jednego zestawu poleceń czytnika ekranu!

Możesz ćwiczyć nawigację opartą na gestach i wiele innych technik VoiceOver we wbudowanym programie szkoleniowym w systemie OSX. Możesz uzyskać do niego dostęp poprzez Preferencje systemowe → Dostępność → VoiceOver → Otwórz szkolenie VoiceOver.

Po ukończeniu samouczka nie mogłem się doczekać!

Studium przypadku 1: YouTube

Wyszukiwanie w YouTube

Przeszedłem do strony głównej YouTube na pasku narzędzi Safari, na której VoiceOver polecił mi „wkroczyć” do treści internetowych za pomocą Ctrl + ⌥ + Shift + ↓ . Wkrótce przyzwyczaję się do wchodzenia do treści internetowych, ponieważ ten sam mechanizm dotyczy treści osadzonych i niektórych kontrolek formularzy.

Korzystając z Quick Nav, mogłem poruszać się po kontrolkach formularzy, aby łatwo przejść do sekcji wyszukiwania u góry strony.

Szukałem treści wysokiej jakości:

I nawigowałem do przycisku wyszukiwania:

Jednak gdy aktywowałem przycisk VO + Space , nic nie zostało ogłoszone.

Otworzyłem oczy i nastąpiło wyszukiwanie, a strona wypełniła się wynikami, ale nie miałem możliwości poznania tego przez sam dźwięk.

Zdziwiony, odtworzyłem swoje działania z otwartymi narzędziami devtool i obserwowałem kartę sieci.

Zgodnie z podejrzeniami, YouTube wykorzystuje technikę wydajności o nazwie „renderowanie po stronie klienta”, co oznacza, że ​​JavaScript przechwytuje przesyłane formularze i renderuje wyniki wyszukiwania na miejscu, aby uniknąć konieczności ponownego malowania całej strony. Gdyby wyniki wyszukiwania zostały załadowane na nowej stronie jak zwykły link, VoiceOver ogłosiłby nową stronę, abym mógł nawigować.

Istnieją całe artykuły poświęcone dostępności dla aplikacji renderowanych przez klienta; w tym przypadku sugerowałbym, aby YouTube zaimplementował region aria-live , który ogłaszałby, że wyszukiwanie się powiedzie.

Wskazówka 1: Użyj regionów aria-live , aby ogłosić zmiany po stronie klienta w DOM.

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

Teraz, gdy oszukałem i wiedziałem, że są wyniki wyszukiwania, na które warto spojrzeć, zamknąłem oczy i przeszedłem do pierwszego filmu z wynikami, przełączając się w tryb „nagłówków” Quick Nav, a następnie przeglądając wyniki stamtąd.

Odtwarzanie wideo na YouTube

Gdy tylko załadujesz stronę wideo YouTube, wideo zostanie automatycznie odtworzone. To jest coś, co cenię w codziennym użytkowaniu, ale było to bolesne doświadczenie w połączeniu z rozmową VoiceOver. Nie mogłem znaleźć sposobu na wyłączenie autoodtwarzania kolejnych filmów. Wszystko, co mogłem zrobić, to załadować następny film i szybko nacisnąć CTRL , aby zatrzymać komunikaty czytnika ekranu.

Porada 2: Zawsze zapewnij sposób na wyłączenie autoodtwarzania i zapamiętaj wybór użytkownika.

Sam film jest traktowany jako „grupa”, do której musisz wejść, aby wejść w interakcję. Mogłem poruszać się po każdej z opcji w odtwarzaczu wideo, co mnie mile zaskoczyło — wątpię, żeby tak było w czasach Flasha!

Jednak stwierdziłem, że niektóre elementy sterujące w odtwarzaczu nie mają etykiety, więc „Tryb kinowy” był po prostu odczytywany jako „przycisk”.

Porada 3: Zawsze oznaczaj kontrolki formularza.

Podczas gdy użytkownicy czytników ekranu są w większości niewidomi, około 20% jest klasyfikowanych jako osoby słabowidzące, więc mogą zobaczyć część strony. Dlatego użytkownik czytnika ekranu może nadal docenić możliwość aktywacji „Trybu kinowego”.

Te wskazówki nie są wymienione w kolejności ważności, ale gdyby tak było, byłby to mój numer jeden:

Porada 4: Użytkownicy czytników ekranu powinni funkcjonować tak samo jak użytkownicy widzący.

Zaniedbując oznaczenie opcji „tryb kinowy”, wykluczamy użytkowników czytników ekranu z funkcji, z których mogliby korzystać w innym przypadku.

To powiedziawszy, zdarzają się przypadki, w których funkcja nie będzie miała zastosowania do czytnika ekranu — na przykład szczegółowy wykres liniowy SVG, który odczytałby się jako pożeracz liczb bezkontekstowych. W takich przypadkach możemy zastosować specjalny atrybut aria-hidden="true" do elementu, aby został całkowicie zignorowany przez czytniki ekranu. Zwróć uwagę, że nadal musielibyśmy dostarczyć jakiś alternatywny tekst lub tabelę danych poza ekranem jako rozwiązanie awaryjne.

Porada 5: Użyj aria-hidden , aby ukryć treści, które nie są dostępne dla użytkowników czytników ekranu.

Dużo czasu zajęło mi wymyślenie, jak dostosować pozycję odtwarzania, aby móc przewinąć niektóre treści. Po „wkroczeniu” do suwaka ( VO + Shift + ↓ ), przytrzymaj ⌥ + ↑↓ , aby dostosować. Wydaje mi się to nieintuicyjne, ale z drugiej strony to nie pierwszy raz, kiedy Apple podjął kontrowersyjne decyzje dotyczące skrótów klawiaturowych.

Autoodtwarzanie na końcu filmu na YouTube

Pod koniec filmu zostałem automatycznie przekierowany do nowego filmu, co było mylące — nie wydarzyło się żadne ogłoszenie.

Wkrótce nauczyłem się nawigować do elementów sterujących autoodtwarzaniem i je wyłączać:

Nie zapobiega to automatycznemu odtwarzaniu wideo po załadowaniu strony wideo, ale zapobiega automatycznemu przekierowywaniu tej strony wideo do następnego wideo.

Studium przypadku 2: BBC

Ponieważ wiadomości są czymś konsumowanym biernie, a nie przez poszukiwanie czegoś konkretnego, postanowiłem nawigować w BBC News według nagłówków. Warto zauważyć, że nie trzeba do tego celu używać Szybkiej nawigacji: VoiceOver udostępnia polecenia wyszukiwania elementów, które mogą zaoszczędzić czas zaawansowanemu użytkownikowi. W tym przypadku mogłem poruszać się po nagłówkach za pomocą klawiszy VO + ⌘ + H.

Pierwszy nagłówek to informacja o plikach cookie, a drugi nagłówek to <h2> zatytułowany „Linki ułatwień dostępu”. Pod tym drugim nagłówkiem pierwszy link był linkiem „Przejdź do treści”, który umożliwił mi pominięcie wszystkich innych nawigacji.

Linki „Przejdź do treści” są bardzo przydatne, nie tylko dla użytkowników czytników ekranu; zobacz mój poprzedni artykuł „Korzystałem z internetu przez jeden dzień za pomocą samej klawiatury”.

Porada 6: Udostępnij linki „przeskocz do treści” użytkownikom klawiatury i czytnika ekranu.

Nawigacja według nagłówków była dobrym podejściem: każda wiadomość ma swój własny nagłówek, więc mogłem usłyszeć nagłówek przed podjęciem decyzji, czy przeczytać więcej na temat danego artykułu. A ponieważ sam nagłówek był zawinięty w znacznik kotwicy, nie musiałem nawet przełączać trybów nawigacji, gdy chciałem kliknąć; Mógłbym po prostu VO + spacja , aby załadować mój obecny wybór artykułu.

Podczas gdy skrót przechodzenia do treści na stronie głównej ładnie łączy się z kotwicą #skip-to-content-link-target (która następnie odczytuje nagłówek najważniejszych wiadomości), link do pomijania strony artykułu został uszkodzony. Link do innego identyfikatora ( #page ), który zaprowadził mnie do group otaczającej treść artykułu, zamiast odczytywania nagłówka.

W tym momencie naciskam VO + A , aby VoiceOver odczytał mi cały artykuł.

Radził sobie całkiem nieźle, dopóki nie trafił na embed na Twitterze, gdzie zaczął być dość gadatliwy. W pewnym momencie nieprzydatnie odczytał „Link: 1068987739478130688”.

Wydaje się, że jest to spowodowane nieco podejrzanymi znacznikami w części tweeta z osadzonym wideo:

Wygląda na to, że VoiceOver nie odczytuje atrybutu alt zagnieżdżonego obrazu, a wewnątrz zakotwiczenia nie ma żadnego innego tekstu, więc VoiceOver wykonuje najbardziej użyteczną rzecz, jaką potrafi: odczytać część samego adresu URL.

Inne czytniki ekranu mogą działać dobrze z tym znacznikiem — Twój przebieg może się różnić. Ale bezpieczniejszą implementacją byłby znacznik kotwicy z etykietą aria-label lub jakimś wizualnie ukrytym tekstem poza ekranem, który zawierałby tekst alternatywny. Skoro już tu jesteśmy, prawdopodobnie zmieniłbym „Osadzone wideo” na coś bardziej przydatnego, np. „Osadzone wideo: kliknij, aby odtworzyć”).

Nie było problemów z łączem:

Pod główną treścią tweeta znajduje się przycisk „lubię to”, który podwaja się jako licznik „polubień”. Wizualnie ma to sens, ale z perspektywy czytnika ekranu nie ma tu kontekstu. Działanie czytnika ekranu jest złe z dwóch powodów:

1. Nie wiem, co oznacza „1887”.
2. Nie wiem, czy klikając w link, tweet mi się spodoba.

Użytkownicy czytników ekranu powinni mieć więcej kontekstu, np. „1887 użytkowników polubiło ten tweet. Kliknij, aby polubić”. Można to osiągnąć za pomocą przemyślanego tekstu spoza ekranu:

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

Porada 7: Upewnij się, że każdy link ma sens, gdy jest czytany osobno.

Przeczytałem jeszcze kilka artykułów w BBC, w tym artykuł o „długiej formie”.

Czytanie dłuższych artykułów

Spójrz na poniższy zrzut ekranu z innego długiego artykułu BBC — ile różnych obrazów możesz zobaczyć i jakie powinny być ich atrybuty alt ?

Najpierw spójrzmy na pierwszy plan jeziora Havasu na środku obrazu. Poniżej znajduje się podpis: „Jezioro Havasu powstało po ukończeniu tamy Parker w 1938 roku, która powstrzymywała rzekę Kolorado”.

Najlepszym rozwiązaniem jest podanie atrybutu alt , nawet jeśli dostępny jest podpis. Tekst alt powinien opisywać obraz, a podpis powinien zawierać kontekst. W tym przypadku atrybut alt może wyglądać jak „Widok z lotu ptaka na jezioro Havasu w słoneczny dzień”.

Zwróć uwagę, że nie powinniśmy poprzedzać naszego tekstu alt „Obrazem: ”, „Obrazem” lub czymś w tym rodzaju. Czytniki ekranu już zapewniają ten kontekst, ogłaszając słowo „obraz” przed naszym tekstem alt . Również tekst alt powinien być krótki (poniżej 16 słów). Jeśli potrzebny jest dłuższy tekst alt , np. obraz zawiera dużo tekstu, który wymaga skopiowania, zajrzyj do atrybutu longdesc .

Wskazówka nr 8: pisz opisowe, ale skuteczne teksty alt .

Semantycznie przykładowy zrzut ekranu powinien być oznaczony elementami <figure> i <figcaption> :

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

Teraz spójrzmy na obraz tła na tym zrzucie ekranu (ten przedstawiający różne szklanki i sprzęt). Z reguły obrazy tła lub prezentacyjne, takie jak te, powinny mieć pusty atrybut alt ( alt="" ), aby VoiceOver był wyraźnie informowany o braku alternatywnego tekstu i nie próbował go czytać.

Zauważ, że puste alt="" NIE jest tym samym, co brak atrybutu alt , co jest dużym nie-nie. Jeśli brakuje atrybutu alt , czytniki ekranu odczytają zamiast tego nazwy plików obrazów, które często nie są zbyt przydatne!

Wskazówka 9: Nie bój się używać pustych atrybutów alt w treści prezentacyjnej.

Studium przypadku 3: Facebook

Udając się teraz na Facebooka i wcześniej miałem objawy odstawienia, więc poszedłem poszukać więcej Niepraktycznych Jokerów .

Facebook idzie o krok lub dwa dalej niż inne witryny, które do tej pory wypróbowałem, i zamiast linku „Przejdź do treści” mamy nie mniej niż dwa menu rozwijane, które prowadzą odpowiednio do stron lub sekcji stron.

Facebook definiuje również pewną liczbę klawiszy jako klawiszy skrótów, których można używać z dowolnego miejsca na stronie:

Pobawiłem się nimi i działają całkiem dobrze z VoiceOver — kiedy już wiesz, że tam są. Jedynym problemem, jaki widzę, jest to, że są zastrzeżone (nie mogę oczekiwać, że te same skróty będą działać poza Facebookiem), ale fajnie, że Facebook naprawdę się tutaj stara.

Chociaż moje pierwsze wrażenie na temat dostępności Facebooka było dobre, wkrótce zauważyłem drobne osobliwości, które utrudniały nawigację po stronie.

Na przykład bardzo się zdezorientowałem, próbując poruszać się po tej stronie za pomocą nagłówków:

Pierwszy nagłówek na stronie to nagłówek poziomu 3, schowany na pasku bocznym. Bezpośrednio po nim następuje SZEŚĆ nagłówka w głównej kolumnie treści, która odpowiada statusowi udostępnionemu przez Stronę.

Można to zwizualizować za pomocą wtyczki Web Developer dla Chrome/Firefox.

Zgodnie z ogólną zasadą, dobrym pomysłem jest posiadanie kolejnych nagłówków z różnicą nie większą niż 1. Jeśli tego nie zrobisz, to nie jest przełom, ale z pewnością mylące jest przychodzenie do tego z perspektywy czytnika ekranu i martwienie się, że „ Przypadkowo pominąłem kilka ważnych informacji, ponieważ przeskoczyłeś z h1 na h6 .

Wskazówka nr 10: Sprawdź poprawność struktury nagłówków.

Teraz przejdźmy do sedna strony: postów. Facebook polega na utrzymywaniu kontaktu z ludźmi i sprawdzaniu, co zamierzają. Ale żyjemy w świecie, w którym tekst alt jest nieznaną koncepcją dla większości użytkowników, więc jak Facebook tłumaczy te samozadowolone selfie i zdjęcia psów odbiorcom korzystającym z czytników ekranu?

Facebook ma generator automatycznego tekstu alternatywnego, który wykorzystuje technologię rozpoznawania obiektów do analizowania, co (lub kto) znajduje się na zdjęciu i generowania opisu tekstowego. Jak dobrze to działa?

Tekst alt dla tego obrazu to „Obraz może zawierać: niebo, trawę i plener”. Daleko jeszcze do rozpoznania „Katedry w Cambridge o zmierzchu”, ale to zdecydowanie krok we właściwym kierunku.

Byłem pod ogromnym wrażeniem dokładności niektórych opisów. Kolejny obraz, który wypróbowałem, wyszedł jako „Obraz może zawierać: 3 osoby, w tym Johna Smitha, Jane Doe i Chrisa Ashtona, ludzi uśmiechniętych, zbliżenia i w pomieszczeniach” — bardzo opisowy i absolutnie słuszny!

Martwi mnie jednak, że memy i żarty, które stają się wirusowe w mediach społecznościowych, są z natury niedostępne; Facebook traktuje następujące informacje jako „Obraz może zawierać: ptaka i tekst”, co choć prawda jest daleko od prawdziwego obrazu!

Na szczęście użytkownicy mogą napisać własny tekst alt , jeśli chcą.

Studium przypadku 4: Amazon

Coś, co zauważyłem na Facebooku, dzieje się też na Amazonie. Przycisk wyszukiwania pojawia się przed polem wejściowym wyszukiwania w DOM. Dzieje się tak pomimo faktu, że przycisk pojawia się wizualnie po polu wprowadzania.

Twoja witryna prawdopodobnie będzie wyglądać w logicznej kolejności. Co by było, gdyby ktoś losowo przeniósł część Twojej strony internetowej — czy to nadal ma sens?

Prawdopodobnie nie. Oto, co może się stać z korzystaniem z czytnika ekranu, jeśli nie jesteś zdyscyplinowany, jeśli chodzi o synchronizację struktury DOM z projektem wizualnym. Czasami łatwiej jest przenieść zawartość za pomocą CSS, ale zwykle lepiej jest przenieść ją w DOM.

Tip #11: Dopasuj kolejność DOM do kolejności wizualnej.

Zdumiewa mnie, dlaczego te dwie renomowane witryny nie stosują tej wskazówki dotyczącej najlepszych praktyk w swojej nawigacji wyszukiwania. Jednak przycisk i tekst wejściowy nie są tak daleko od siebie, że ich kolejność powoduje duży problem z dostępnością.

Nagłówki na Amazon

Podobnie jak Facebook, Amazon ma dziwną kolejność nagłówków. Szukałem za pomocą nagłówków i byłem najbardziej zdezorientowany, że pierwszy nagłówek na stronie był nagłówkiem poziomu 5 w sekcji „Inni sprzedawcy na Amazon”:

Pomyślałem, że to musi być błąd w czytniku ekranu, więc sięgnąłem do kodu źródłowego Amazona, aby sprawdzić:

H1 strony pojawia się prawie 10 000 wierszy poniżej w kodzie źródłowym.

Jest to kiepskie nie tylko semantycznie i kiepskie pod względem dostępności, ale także kiepskie pod względem SEO. Słabe SEO oznacza mniejszą liczbę konwersji (sprzedaż) — coś, czego spodziewałbym się po Amazonie!

Wskazówka nr 12: Dostępność i SEO to dwie strony tego samego medalu.

Wiele z tego, co robimy, aby poprawić wrażenia z czytnika ekranu, poprawi również SEO. Poprawne semantycznie nagłówki i szczegółowy tekst alt są świetne dla robotów wyszukiwarek, co powinno oznaczać, że Twoja witryna zajmuje wyższą pozycję w wynikach wyszukiwania, co powinno oznaczać, że przyciągniesz szerszą publiczność.

Jeśli kiedykolwiek miałeś problem z przekonaniem swojego menedżera, że ​​tworzenie dostępnych witryn jest ważne, spróbuj spojrzeć z innej perspektywy i zamiast tego wskaż korzyści z SEO.

Różnorodny

Trudno skondensować całodzienne przeglądanie i doświadczenia w jednym artykule. Oto kilka najważniejszych i najgorszych elementów, które wykonały cięcie.

Zauważysz powolne witryny

Czytniki ekranu nie mogą analizować strony i tworzyć drzewa dostępności, dopóki DOM nie zostanie załadowany. Widzący użytkownicy mogą skanować stronę podczas jej ładowania, szybko określając, czy warto poświęcić czas, a jeśli nie, naciśnij przycisk Wstecz. Użytkownicy czytników ekranu nie mają wyboru i muszą poczekać, aż załaduje się 100% strony.

Warto zauważyć, że chociaż tworzenie wydajnej witryny internetowej przynosi korzyści wszystkim, jest ona szczególnie korzystna dla użytkowników czytników ekranu.

Czy zgadzam się na co?

Kontrolki formularzy, takie jak ta z NatWest, mogą w dużym stopniu zależeć od bliskości przestrzennej w celu oznaczenia relacji. W świecie czytników ekranu nie ma bliskości przestrzennej — tylko rodzeństwo i rodzice — i trzeba zgadywać, co oznacza „tak”.

Wiedziałbym, na co się zgadzam, gdyby zastrzeżenie było częścią etykiety:

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

Następujący kod to koszmar

Próbowałem przeczytać artykuł techniczny na temat sztuczek CSS za pomocą mojego czytnika ekranu, ale szczerze mówiąc, okazało się, że to doświadczenie jest całkowicie niemożliwe do naśladowania. To nie wina strony CSS Tricks — myślę, że wyjaśnienie pomysłów technicznych i próbek kodu w sposób w pełni słuchowy jest niezwykle skomplikowane. Ile razy próbowałeś debugować z partnerem i zamiast wyjaśniać dokładną składnię, której potrzebujesz, dajesz mu coś do skopiowania i wklejenia lub sam wypełniasz?

Zobacz, jak łatwo możesz przeczytać ten przykładowy kod z artykułu:

Ale oto wersja czytnika ekranu:

ukośnik ukośnik najpierw pobieramy wysokość rzutni i mnożymy ją przez jeden [pauza] procent, aby uzyskać wartość jednostki vh niech vh równa się wewnętrznej wysokości okna gwiazda [pauza] zero zero jeden ukośnik następnie ustawiamy wartość w [pauza ] vh właściwość niestandardowa do katalogu głównego dokumentu dokument styl elementu dokumentu ustaw właściwość [pause] vh dollar lewy nawias klamrowy vh prawy nawias klamrowy px

Jest to całkowicie nieczytelne w pejzażu dźwiękowym. Zwykle nie stosujemy znaków interpunkcyjnych w komentarzach, a w tym przypadku jedna linia płynnie przechodzi w następną w obszarze czytnika ekranu. tekst camelCase jest odczytywany jako oddzielne słowa, tak jakby zostały zapisane w zdaniu. Kropki takie jak window.innerHeight są ignorowane i traktowane jako „wewnętrzna wysokość okna”. Jedynym odczytanym „kodem” są nawiasy klamrowe na końcu.

Kod jest oznaczony przy użyciu standardowych elementów HTML <pre> i <code> , więc nie wiem, jak można to ulepszyć dla użytkowników czytników ekranu. Każdy, kto wytrwale z kodowaniem, ma mój całkowity podziw.

Poza tym jedyną wadą, jaką mogłem znaleźć, było to, że logo witryny miało link do strony głównej, ale nie zawierał tekstu alt , więc słyszałem tylko „link: ukośnik”. Tylko jako programista WWW wiem, że jeśli masz link z atrybutem href="/" , to prowadzi on cię do strony głównej witryny, więc zorientowałem się, do czego służy link — ale „link: Sztuczki CSS strona główna” byłaby lepsza!

VoiceOver na iOS jest trudniejszy niż OSX

Korzystanie z VoiceOver na moim telefonie było prawdziwym przeżyciem!

Postawiłem sobie wyzwanie nawigowania po aplikacji Twitter i pisania tweeta przy wyłączonym ekranie i przy użyciu klawiatury mobilnej. Było trudniej niż się spodziewałem i popełniłem kilka błędów ortograficznych.

Gdybym był zwykłym użytkownikiem czytnika ekranu, myślę, że musiałbym dołączyć do 41% użytkowników mobilnych czytników ekranu, którzy używają zewnętrznej klawiatury i inwestują w klawiaturę Bluetooth. Clara Van Gerven doszła do tego samego wniosku, używając czytnika ekranu przez czterdzieści dni w 2015 roku.

Fajnie było aktywować tryb zasłony ekranowej za pomocą trzykrotnego dotknięcia trzema palcami. Spowodowało to wyłączenie ekranu, ale pozostawiło telefon odblokowany, dzięki czemu mogłem kontynuować przeglądanie telefonu bez oglądania. Ta funkcja jest niezbędna dla niewidomych użytkowników, którzy w przeciwnym razie mogliby nieświadomie podawać swoje hasła osobie obserwującej ich przez ramię, ale ma również dodatkową zaletę, ponieważ jest świetna do oszczędzania baterii.

Streszczenie

To było ciekawe i wymagające doświadczenie, a także najtrudniejszy do napisania artykuł z serii.

Zaskoczyły mnie małe rzeczy, które są oczywiste, kiedy się zatrzymujesz i myślisz o nich. Na przykład podczas korzystania z czytnika ekranu prawie niemożliwe jest słuchanie muzyki podczas przeglądania Internetu! Utrzymywanie kontekstu strony może być również trudne, zwłaszcza jeśli przerywa Ci telefon lub coś takiego; zanim wrócisz do czytnika ekranu, stracisz swoje miejsce.

Moim największym wnioskiem jest to, że przejście na doświadczenie wyłącznie dźwiękowe jest wielkim szokiem kulturowym. To zupełnie inny sposób poruszania się po sieci, a ponieważ istnieje taki kontrast, trudno jest nawet określić, co składa się na „dobre” lub „złe” wrażenia z czytnika ekranu. Może to być dość przytłaczające i nic dziwnego, że wielu programistów unika ich testowania.

Ale nie powinniśmy unikać robienia tego tylko dlatego, że jest to trudne. Jak powiedział Charlie Owen w swoim przemówieniu, Drogi Deweloperze, sieć nie jest o tobie : to. Jest. Twój. Praca . Whilst it's fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can't just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let's make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I've tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I'd have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.