Aktualizacje API Dostępności

Nieoficjalne Tłumaczenie Beta

Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt. Znalazłeś błąd? Zgłoś problem →

Motywacja

Wraz z postępem technologicznym i rosnącym znaczeniem aplikacji mobilnych w codziennym życiu, rośnie także potrzeba tworzenia dostępnych aplikacji.

Ograniczone API Dostępności React Native zawsze było dużym problemem dla developerów, dlatego wprowadziliśmy kilka aktualizacji, aby ułatwić tworzenie inkluzywnych aplikacji mobilnych.

Problemy z istniejącym API

Problem pierwszy: Dwie zupełnie różne, a jednak podobne właściwości - accessibilityComponentType (Android) i accessibilityTraits (iOS)

accessibilityComponentType i accessibilityTraits to dwie właściwości służące do informowania TalkBack na Androidzie i VoiceOver na iOS, z jakim elementem interfejsu użytkownik ma do czynienia. Największe problemy z tymi właściwościami to:

1. To dwie różne właściwości o różnych metodach użycia, ale tym samym celu. W poprzednim API były to osobne właściwości (po jednej na platformę), co było nie tylko niewygodne, ale też mylące dla wielu developerów. accessibilityTraits na iOS pozwala na 17 różnych wartości, podczas gdy accessibilityComponentType na Androidzie tylko na 4. Co więcej, wartości w większości się nie pokrywały. Nawet typy danych wejściowych różnią się: accessibilityTraits akceptuje tablicę cech lub pojedynczą cechę, podczas gdy accessibilityComponentType tylko pojedynczą wartość.

2. Bardzo ograniczona funkcjonalność na Androidzie. Przy starej właściwości TalkBack rozpoznawał tylko elementy: "button", "radiobutton_checked" i "radiobutton_unchecked".

Problem drugi: Brak podpowiedzi dostępności

Podpowiedzi dostępności pomagają użytkownikom TalkBack i VoiceOver zrozumieć, co się stanie po wykonaniu akcji na elemencie dostępności, gdy nie jest to oczywiste na podstawie samej etykiety. Te podpowiedzi można włączać i wyłączać w panelu ustawień. Poprzednio API React Native w ogóle nie obsługiwało podpowiedzi dostępności.

Problem trzeci: Ignorowanie odwróconych kolorów

Niektórzy użytkownicy z wadami wzroku używają odwróconych kolorów w telefonach, aby uzyskać większy kontrast ekranu. Apple udostępniło API dla iOS, które pozwala developerom ignorować określone widoki. Dzięki temu obrazy i filmy nie są zniekształcane, gdy użytkownik ma włączone odwrócone kolory. To API nie jest obecnie obsługiwane przez React Native.

Projekt nowego API

Rozwiązanie pierwsze: Połączenie accessibilityComponentType (Android) i accessibilityTraits (iOS)

Aby rozwiązać problem rozbieżności między accessibilityComponentType a accessibilityTraits, postanowiliśmy połączyć je w jedną właściwość. To rozwiązanie miało sens, ponieważ technicznie pełnią tę samą funkcję, a ich połączenie zwalnia developerów z konieczności martwienia się o specyfikę platformy przy budowaniu funkcji dostępności.

Tło

W iOS UIAccessibilityTraits to właściwość, którą można ustawić na dowolnym obiekcie NSObject. Każda z 17 cech przekazanych przez właściwość JavaScript do natywnych jest mapowana na element UIAccessibilityTraits w Objective-C. Cechy są reprezentowane przez wartości typu long int, a każda ustawiona cecha jest łączona operatorem OR.

W Androidzie jednak AccessibilityComponentType to koncept wymyślony przez React Native, który nie ma bezpośredniego odpowiednika we właściwościach Androida. Dostępność jest obsługiwana przez delegata dostępności. Każdy widok ma domyślnego delegata. Aby dostosować dowolne akcje dostępności, należy utworzyć nowego delegata, nadpisać konkretne metody, które chcemy dostosować, a następnie ustawić delegata dostępności dla obsługiwanego widoku. Gdy developer ustawiał AccessibilityComponentType, natywny kod tworzył nowego delegata na podstawie przekazanego komponentu i przypisywał go do widoku.

Wprowadzone zmiany

Dla naszej nowej właściwości chcieliśmy stworzyć superset obu istniejących właściwości. Zdecydowaliśmy się wzorować nową właściwość głównie na istniejącej accessibilityTraits, ponieważ accessibilityTraits ma znacznie więcej wartości. Funkcjonalność dla Androida zostanie zapewniona poprzez modyfikację Delegata Dostępności.

Istnieje 17 wartości UIAccessibilityTraits, które można ustawić dla accessibilityTraits w iOS. Jednak nie uwzględniliśmy wszystkich jako możliwych wartości dla nowej właściwości. Dzieje się tak, ponieważ efekt ustawienia niektórych z tych cech jest mało znany, a wiele wartości praktycznie nigdy nie jest używanych.

Wartości UIAccessibilityTraits generalnie pełniły jedną z dwóch funkcji: opisywały rolę elementu interfejsu lub jego stan. W większości obserwowanych przypadków używano jednej wartości reprezentującej rolę w połączeniu z "state selected", "state disabled" lub obydwoma. Dlatego zdecydowaliśmy się stworzyć dwie nowe właściwości dostępności: accessibilityRole i accessibilityState.

accessibilityRole

Nowa właściwość accessibilityRole służy do informowania TalkBacka lub Voiceovera o roli elementu interfejsu. Może przyjmować jedną z następujących wartości:

• none

• button

• link

• search

• image

• keyboardkey

• text

• adjustable

• header

• summary

• imagebutton

Ta właściwość pozwala na przekazanie tylko jednej wartości, ponieważ elementy interfejsu generalnie nie pełnią logicznie więcej niż jednej z tych ról. Wyjątkiem jest połączenie obrazu i przycisku, dlatego dodaliśmy rolę imagebutton będącą kombinacją obu.

accessibilityStates

Nowa właściwość accessibilityStates służy do informowania TalkBacka lub Voiceovera o stanie elementu interfejsu. Przyjmuje tablicę zawierającą jedną lub obie z następujących wartości:

• selected

• disabled

Rozwiązanie drugie: Dodawanie podpowiedzi dostępności

W tym celu dodaliśmy nową właściwość accessibilityHint. Jej ustawienie umożliwi TalkBackowi lub Voiceoverowi odczytanie podpowiedzi użytkownikom.

accessibilityHint

Ta właściwość przyjmuje podpowiedź dostępności w formie ciągu znaków (String) do odczytania.

W iOS ustawienie tej właściwości konfiguruje natywną właściwość AccessibilityHint widoku. Podpowiedź będzie odczytywana przez Voiceover, jeśli podpowiedzi dostępności są włączone w ustawieniach iPhone'a.

W Androidzie ustawienie tej właściwości dołącza wartość podpowiedzi na końcu etykiety dostępności. Zaleta tego rozwiązania polega na naśladowaniu zachowania podpowiedzi w iOS, ale wadą jest to, że w Androidzie nie można wyłączyć tych podpowiedzi w ustawieniach tak jak w iOS.

Podjęliśmy tę decyzję dla Androida, ponieważ podpowiedzi dostępności zwykle odpowiadają konkretnej akcji (np. kliknięciu) i chcieliśmy zachować spójne zachowanie między platformami.

Rozwiązanie problemu trzeciego

accessibilityIgnoresInvertColors

Udostępniliśmy w JavaScript interfejs API Apple AccessibilityIgnoresInvertColors. Teraz gdy masz widok, którego kolory nie powinny być inwertowane (np. obraz), możesz ustawić tę właściwość na true, a kolory nie zostaną odwrócone.

Nowe zastosowanie

Te nowe właściwości będą dostępne w wydaniu React Native 0.57.

Jak przeprowadzić aktualizację

Jeśli obecnie używasz accessibilityComponentType i accessibilityTraits, oto kroki, które możesz podjąć, aby przejść na nowe właściwości.

1. Używanie jscodeshift

Najprostsze przypadki użycia można zastąpić, uruchamiając skrypt jscodeshift.

Ten skrypt zastępuje następujące przypadki:

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

Zastąpiono przez

accessibilityRole= “trait”

Ten skrypt usuwa również wystąpienia AccessibilityComponentType (zakładając, że wszędzie tam, gdzie ustawiono AccessibilityComponentType, ustawiono również AccessibilityTraits).

2. Używanie ręcznego codemodu

W przypadkach, w których używano AccessibilityTraits bez odpowiedniej wartości dla AccessibilityRole, oraz w przypadkach, gdy do AccessibilityTraits przekazywano wiele cech, konieczne było wykonanie ręcznego codemodu.

Ogólnie rzecz biorąc,

accessibilityTraits= {[“button”, “selected”]}

byłyby ręcznie zastąpione przez

accessibilityRole=“button”
accessibilityStates={[“selected”]}

Te właściwości są już używane w bazie kodu Facebooka. Codemod dla Facebooka był zaskakująco prosty. Skrypt jscodeshift naprawił około połowy naszych przypadków, a druga połowa została naprawiona ręcznie. Cały proces trwał mniej niż kilka godzin.

Mamy nadzieję, że zaktualizowane API okaże się przydatne! I prosimy, kontynuujcie tworzenie dostępnych aplikacji! #inclusion