Co to jest testowanie dostępności? (Przykłady)

Co to jest testowanie dostępności?

Testowanie dostępności to rodzaj testów oprogramowania przeprowadzanych w celu potwierdzenia, że ​​aplikacja jest użyteczna dla osób z niepełnosprawnościami, w tym użytkowników z niepełnosprawnościami wzroku, słuchu, motorycznymi, poznawczymi i związanymi z wiekiem. Jest to podzbiór test użyteczności i sprawdza, czy produkt współpracuje z technologiami wspomagającymi, z których użytkownicy korzystają na co dzień.

Technologie wspomagające pomagają osobom niepełnosprawnym obsługiwać oprogramowanie. Typowe przykłady to:

• Oprogramowanie do rozpoznawania mowy – Zamienia wypowiadane słowa na tekst, który służy jako dane wejściowe dla komputera.
• Oprogramowanie czytnika ekranu – Odczytuje tekst i elementy interfejsu wyświetlane na ekranie.
• Oprogramowanie do powiększania ekranu – Powiększa część monitora, aby ułatwić czytanie użytkownikom ze słabym wzrokiem.
• Specjalistyczne klawiatury – Zaprojektowany dla użytkowników mających trudności z kontrolą motoryczną, aby ułatwićping łatwiejsze.
• Przełącznik i oko-tracurządzenia królewskie – Umożliwia użytkownikom z poważnymi niepełnosprawnościami ruchowymi nawigację i wybieranie elementów interfejsu.

Dlaczego testowanie dostępności?

Powód 1:Dostosowanie do rynku użytkowników niepełnosprawnych.

Według Światowej Organizacji Zdrowia na świecie żyje około 1.3 miliarda ludzi (co szósta osoba), którzy cierpią na znaczną niepełnosprawność.

• 1 na 10 osób ma ciężką niepełnosprawność.
• 1 na 2 osoby po 65 roku życia ma ograniczone zdolności poznawcze.

Niepełnosprawności obejmują ślepotę, głuchotę, upośledzenie motoryczne, zaburzenia poznawcze i inne długotrwałe problemy zdrowotne. Produkt stworzony z myślą o dostępności może dotrzeć do tak dużego rynku, a większości defektów w zakresie dostępności można zapobiec, włączając testowanie dostępności do normalnego cyklu testowania oprogramowania.

Powód 2:Przestrzegaj przepisów dotyczących dostępności.

Rządy na całym świecie uchwaliły przepisy, które wymagają, aby produkty IT były dostępne dla osób niepełnosprawnych. Do najważniejszych przykładów należą:

• Stany Zjednoczone: Ustawa o osobach niepełnosprawnych (ADA, 1990) i sekcja 508 ustawy o rehabilitacji.
• Zjednoczone Królestwo: Ustawa o równości z 2010 r. (która zastąpiła Ustawę o dyskryminacji osób niepełnosprawnych z 1995 r.).
• Unia Europejska: Europejski akt w sprawie dostępności, który wszedł w życie w odniesieniu do wielu produktów i usług w czerwcu 2025 r., oraz norma EN 301 549.
• Australia: Ustawa o dyskryminacji osób niepełnosprawnych z 1992 r.
• Irlandia: Ustawa o osobach niepełnosprawnych z 2005 r.
• Kanada: Ustawa o dostępnej Kanadzie z 2019 r.

Testowanie dostępności jest niezbędne, aby zagwarantować zgodność z przepisami na każdym rynku, na którym sprzedawany jest Twój produkt.

Powód 3:Unikaj potencjalnych pozwów.

Duże firmy były wielokrotnie pozywane z powodu braku dostępności ich produktów cyfrowych. Oto kilka głośnych przypadków:

• Krajowa Federacja Niewidomych (NFB) przeciwko. Target (2006, rozliczenie 2008).
• Ugoda NFB v. AOL (1999).
• Robles kontra Domino's Pizza (2019), gdzie Stany Zjednoczone SupremSąd podtrzymał orzeczenie, że ustawa ADA ma zastosowanie do stron internetowych i aplikacji mobilnych.
• Gil v. Winn-Dixie (2017) – pierwszy wyrok w procesie w USA nakazujący naprawienie niedostępnej strony internetowej.

Liczba pozwów dotyczących dostępności stron internetowych w Stanach Zjednoczonych rośnie z roku na rok – od 2022 roku corocznie wnosi się ponad 4,000 spraw dotyczących cyfrowych treści w ramach tytułu III ustawy ADA. Tworzenie dostępnych produktów od samego początku pozwala uniknąć tych kosztów i chroni markę.

Jakie osoby niepełnosprawne wspierać?

Aplikacja musi wspierać osoby niepełnosprawne, takie jak:

Rodzaj niepełnosprawności	Inwalidztwo Descriptjon
Niepełnosprawność wzroku	Całkowita ślepota, daltonizm lub słaby wzrok. Wrażliwość na efekty wizualne: stroboskopowe i migotanie.
Kalectwo fizyczne	Niemożność korzystania z myszy lub klawiatury jedną ręką. Osłabienie sprawności ruchowej, w tym ograniczenie ruchów dłoni lub spowolnienie mięśni.
Niepełnosprawność poznawcza	Trudności w uczeniu się, słaba pamięć lub trudności w rozumieniu złożonych scenariuszy.
Niepełnosprawność czytania i pisania	Trudności z czytaniem, np. dysleksja.
Niepełnosprawność słuchu	Problemy ze słuchem, w tym głuchota i upośledzenie słuchu. Niezdolność do słyszenia dźwięku lub do wyraźnego słyszenia go.

Standardy i wytyczne dotyczące dostępności

Programy testowania dostępności opierają się na niewielkim zestawie powszechnie przyjętych standardów. Zrozumienie, który standard ma zastosowanie na danym rynku, to pierwszy krok przed opracowaniem jakiegokolwiek planu testów.

• WCAG 2.2 – Opublikowane przez W3C w październiku 2023 roku Wytyczne dotyczące dostępności treści internetowych 2.2 stanowią aktualny globalny punkt odniesienia. Definiują one trzy poziomy zgodności: A (podstawowy), AA (minimalny poziom prawny w większości krajów) i AAA (najwyższy).
• WCAG 3.0 – Wersja robocza W3C wprowadzająca model punktacji oparty na rezultatach. Jest ona wciąż w fazie rozwoju i nie zastąpiła WCAG 2.2.
• Sekcja 508 – amerykańskie przepisy dotyczące zamówień publicznych, które wymagają, aby technologie elektroniczne i informatyczne kupowane przez agencje federalne spełniały kryteria WCAG 2.0 poziomu AA.
• 301 549 – europejska zharmonizowana norma dotycząca dostępności ICT, stosowana w celu wykazania zgodności z Europejską ustawą w sprawie dostępności.
• Tytuł III ustawy ADA – Amerykańskie prawo dotyczące praw obywatelskich ma zastosowanie do stron internetowych i aplikacji mobilnych obiektów użyteczności publicznej; sądy powszechnie stosują jako punkt odniesienia normy WCAG 2.1 lub 2.2 AA.

Większość zespołów traktuje WCAG 2.2 Poziom AA jako ich cel roboczy, ponieważ stanowi on zarówno wspólną podstawę prawną, jak i praktyczny cel inżynieryjny.

Jak przeprowadzić testy dostępności?

Testowanie dostępności można przeprowadzić na dwa sposoby:

1. Instrukcja obsługi
2. zautomatyzowane

Testowanie dostępności może być trudne dla testerów, którzy nie znają problemów z niepełnosprawnościami. Dobrą praktyką jest angażowanie użytkowników z niepełnosprawnościami lub specjalistów ds. dostępności, którzy potrafią opisać rzeczywiste wyzwania. Poniższe techniki obejmują główne kategorie niepełnosprawności.

1) Niepełnosprawność wzroku

Wyobraź sobie, że w ogóle nie widzisz i musisz skorzystać ze strony internetowej XYZ. Jedyną praktyczną opcją jest czytnik ekranu. Czytnik ekranu to oprogramowanie, które odczytuje treść strony internetowej, w tym tekst, linki, przyciski opcji, obrazy i wideo, tak aby użytkownik niewidomy mógł odczytać interfejs. Popularne czytniki ekranu to m.in. SZCZĘKI, NVDA, Apple VoiceOver i Android rozmowa zwrotna.

Po uruchomieniu JAWS i otwarciu przeglądarki, JAWS odczytuje tytuł strony. Jeśli przesuniesz fokus na pasek adresu, JAWS powie „Pasek adresu”, a następnie odczyta każdy wpisany znak. Na przykład:ping google.com generuje komunikat podobny do poniższego:

Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m.
When the page finishes loading, JAWS announces "Google.com home page".
When focus reaches the search field, JAWS announces "Google search, edit".

Czytnik ekranu odczytuje tekst słowo po słowie w polach tekstowych, ogłasza linki jako „link”, a przyciski jako „przycisk”, aby niewidomy użytkownik mógł zidentyfikować każdy element sterujący. Jeśli strona internetowa jest źle zbudowana, czytnik ekranu może błędnie identyfikować elementy; na przykład link w formacie zwykłego tekstu może zostać odczytany jako treść, ukrywając użytkownikowi kluczową czynność. Kosztem dla firmy jest realna utrata przychodów.

2) Daltonizm

Daltonizm oznacza, że ​​użytkownik nie jest w stanie prawidłowo postrzegać niektórych kolorów. Najczęstszą postacią jest daltonizm czerwono-zielony. Jeśli strona internetowa w dużym stopniu opiera się na kolorze czerwonym w przekazie treści, użytkownik z daltonizmem może nie zrozumieć przekazu.

Zespoły projektowe nigdy nie powinny używać wyłącznie koloru do przekazywania informacji. Czerwony przycisk błędu jest bardziej dostępny, gdy jest dodatkowo oznaczony, oznaczony ikoną i opatrzony tekstem opisowym. Czerń i biel pozostają najbezpieczniejszą uniwersalną paletą barw, a narzędzia takie jak wtyczka Stark czy symulatory daltonizmu w przeglądarkach pomagają wcześnie wykryć problemy.

3) Słaby wzrok

Użytkownicy ze słabym wzrokiem lub innymi schorzeniami siatkówki potrzebują dodatkowego wsparcia, aby móc korzystać z witryny:

1. Unikaj bardzo małego tekstu. WCAG zaleca domyślny rozmiar tekstu, który wygodnie skaluje się bez powiększania.
2. Upewnij się, że układ tekstu jest płynnie reflowowany po powiększeniu do 200 procent (kryterium sukcesu WCAG 2.2). Wiersze nie powinny być ucięte, a treść nie powinna na siebie nachodzić.
3. Należy zachować minimalny współczynnik kontrastu 4.5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu.

4) Niepełnosprawności motoryczne i inne

Głównym wymogiem dostępności jest to, aby cała witryna działała bez użycia myszy. Każdy link, przycisk, przycisk opcji, pole wyboru, wyskakujące okienko, rozwijane menu i kontrolka powinny być dostępne i obsługiwane wyłącznie za pomocą klawiatury.

Na przykładUżytkownik z ograniczoną ruchomością dłoni może nie być w stanie korzystać z myszy. Jeśli pola wyboru lub linki nie są dostępne za pomocą klawisza Tab, użytkownik nie ma dostępu do tych funkcji.

Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.

Fokus musi być zawsze widoczny. Po naciśnięciu klawisza Tab, podświetlony element sterujący powinien być wyraźnie widoczny. Widoczny fokus pomaga użytkownikom z wadami wzroku lub daltonizmem śledzić przepływ treści na stronie i sprawia, że ​​nawigacja jest przewidywalna dla wszystkich.

Użytkownicy z wadami słuchu Zazwyczaj można zobaczyć zawartość wizualną witryny, ale audio i wideo stwarzają problemy. Każdy film musi zawierać napisy, a każdy plik audio transkrypcję lub tekst opisowy. Na przykład film instruktażowy dotyczący rezerwacji biletu lotniczego powinien być dostarczany z dokładnymi napisami, aby użytkownik niesłyszący mógł go śledzić.

Przykładowe przypadki testowe do testowania dostępności

Poniższa lista kontrolna służy do zatwierdzenia testów dostępności dla typowej aplikacji webowej. Użyj jej jako punktu wyjścia i rozszerz ją o kryteria sukcesu WCAG 2.2 istotne dla Twojego produktu.

1. Czy dla każdej operacji myszy i każdego okna dialogowego dostępne są odpowiedniki klawiaturowe?
2. Czy dokumentacja użytkownika zawiera wyjaśnienia, jak korzystać z aplikacji przy użyciu technologii wspomagających?
3. Czy kolejność zakładek jest logiczna i umożliwia naturalną nawigację?
4. Czy dostępne są klawisze skrótu do menu głównych?
5. Czy aplikacja obsługuje wszystkie docelowe systemy operacyjne i czytniki ekranu?
6. Czy czas reakcji każdego ekranu lub strony jest jasno podany, aby użytkownicy wiedzieli, ile czasu mają czekać?
7. Czy wszystkie etykiety są poprawnie napisane i programowo powiązane z kontrolkami?
8. Czy wybór kolorów jest elastyczny i czy można go przetestować w symulatorach osób cierpiących na daltonizm?
9. Czy obrazy, ikony i emotikony są używane w sposób zrozumiały dla użytkowników końcowych?
10. Czy aplikacja oferuje alerty dźwiękowe, gdy są one przydatne?
11. Czy użytkownik może dostosować lub wyciszyć sterowanie dźwiękiem i obrazem?
12. Czy użytkownik może zastąpić domyślne czcionki używane w druku i tekście wyświetlanym na ekranie?
13. Czy użytkownik może regulować lub wyłączać migające, obracające się lub ruchome wyświetlacze?
14. Upewnij się, że kolor nigdy nie jest używany jako jedyny środek przekazywania informacji.
15. Czy podświetlenie jest nadal widoczne po odwróceniu kolorów systemowych? Sprawdź, zmieniając współczynniki kontrastu.
16. Czy transkrypcje audio i wideo oraz napisy są dostępne dla użytkowników, którzy nie słyszą?
17. Czy użytkownicy niepełnosprawni są szkoleni, aby pomóc im zapoznać się z aplikacją?
18. Czy wszystkie interaktywne elementy sterujące można obsługiwać i zamykać za pomocą samej klawiatury?

Jak AI zmienia testowanie dostępności

Sztuczna inteligencja to reshaping Testowanie dostępności na trzy praktyczne sposoby. Po pierwsze, skanery uczenia maszynowego odczytują teraz wyrenderowany DOM wraz z modelami widzenia komputerowego, aby wykrywać problemy pomijane przez narzędzia oparte na regułach, takie jak nieodpowiedni tekst alternatywny lub kombinacje kolorów, które nie działają w rzeczywistych układach. Po drugie, generatywna AI sugeruje czytelne dla człowieka poprawki, w tym lepszy tekst alternatywny, bardziej przejrzyste komunikaty o błędach i atrybuty ARIA dla niestandardowych komponentów. Po trzecie, AI priorytetyzuje wnioski według wpływu na użytkownika, dzięki czemu zespoły mogą przeznaczyć budżet na problemy, które mają największe znaczenie. Narzędzia takie jak Deque axe AI, Evinced, UserWay i Siteimprove zawierają teraz funkcje sztucznej inteligencji. Sztuczna inteligencja nie zastępuje ręcznego testowania czytników ekranu ani badań użytkowników z udziałem osób z niepełnosprawnościami, ale znacznie zmniejsza nakład pracy związany z ręczną selekcją i pomaga przesunąć kwestię dostępności w stronę cyklu rozwoju.

Mity o testowaniu dostępności

Poniżej przedstawiamy popularne mity na temat testów dostępności oraz fakty:

Mit: Stworzenie dostępnej witryny internetowej jest kosztowne.

Fakt: Nie jest. Uwzględnienie dostępności na etapie projektowania, wraz z podstawowymi testami, pozwala zaoszczędzić pieniądze w porównaniu z modernizacją i redukuje kosztowne przeróbki.

Mit: Zmiana niedostępnej witryny internetowej w dostępną jest zbyt czasochłonna i kosztowna.

Fakt: Nie musisz wdrażać wszystkich poprawek naraz. Zacznij od zmian, które mają największy wpływ na użytkowników z niepełnosprawnościami, a resztę wdrożysz w kolejnych wersjach.

Mit: Dostępność jest zwyczajna i nudna.

Fakt: Strony mogą być nadal bogate wizualnie itractywny, spełniając jednocześnie wytyczne WCAG 2.2. W3C wyraźnie odradza wersje wyłącznie tekstowe na rzecz jednolitego, dostępnego dla wszystkich interfejsu.

Mit: Dostępność dotyczy wyłącznie użytkowników niewidomych i niepełnosprawnych.

Fakt: Przestrzeganie wytycznych dotyczących dostępności poprawia ogólną użyteczność i przynosi korzyści wszystkim użytkownikom, w tym tym korzystającym z urządzeń mobilnych, przebywającym w jasnym świetle słonecznym lub w hałaśliwym otoczeniu.

FAQ