Dostępne pola tekstowe w iOS w UIKit, SwiftUI oraz React Native

Praktycznie w każdej aplikacji znajdziemy różnego typu pola tekstowe, do których użytkownik wpisuje dane. Logowanie, wyszukiwanie, podawanie kwoty przelewu, wpisywanie wiadomości na czacie – przykłady można by mnożyć. Gorzej, jak użytkownik korzystający z funkcji dostępności nie jest w stanie takich pól samodzielnie uzupełnić. Jak zatem dostosować pola tekstowe do potrzeb osoby korzystającej z czytnika ekranu, sterowania głosowego i innych pokrewnych funkcjonalności? Rozważmy kilka kwestii.

Proces wpisywania

Użytkownik korzystający z czytnika ekranu, gdy natrafi na pole tekstowe, usłyszy na jego temat następujące informacje:

Etykieta – nazwa pola, np. „Kwota przelewu”.
Rola – pole tekstowe, bezpieczne pole tekstowe, pole wyszukiwania.
Status – ogłaszany tylko dla pól tekstowych w trakcie edycji lub wygaszonych.
Wartość – zawartość wpisaną przez siebie dla zwykłych pól tekstowych lub pól wyszukiwania, a dla bezpiecznego pola tekstowego jedynie liczbę wpisanych znaków
Podpowiedź – opcjonalną wskazówkę na temat oczekiwanych informacji, np. „Wpisz szukaną frazę”.

Dwukrotne stuknięcie pozwala aktywować pole, a w przypadku komponentów natywnych daje dodatkowe możliwości:

Gdy użytkownik ponownie stuknie dwukrotnie, może przesunąć punkt wstawiania (kursor) na początek lub koniec tekstu.
Ma możliwość skorzystania z pokrętła. Tam może na przykład wybrać, czy po zawartości pola chce się przemieszczać po znakach lub wyrazach. Potem wystarczy, że przesunie palcem w lewo lub w prawo, aby przesunąć punkt wstawiania.
Na pokrętle może mieć także dostęp do podstawowych czynności edycji, jak kopiuj/wklej.

Gdy niewidomy użytkownik wprowadza tekst, system podaje mu dodatkowe informacje. Przemieszczanie palcem po klawiaturze sprawia, że system odczytuje dany znak, a w przypadku liter także informację, czy to wielka litera oraz, po pewnym czasie, imię przypisane do danego znaku (jeśli istnieje), np. „Wielkie m – Maria”.

Aby wybrać dany znak, użytkownik także ma kilka opcji, zależnych od preferowanego trybu wpisywania:

Stuka dwukrotnie gdziekolwiek na ekranie po usłyszeniu określonego znaku.
Przytrzymując palec na danym znaku, potwierdza wybór stukając drugim palcem w inny punkt ekranu.
Przesuwa palcem po klawiaturze, a gdy usłyszy wybrany znak, podnosi palec.

Gdy używamy natywnej klawiatury iOS, system ponownie wypowie dany znak. Wyjątkiem będzie tutaj bezpieczne pole tekstowe, gdzie system wygeneruje dźwięk potwierdzający wprowadzenie znaku. Tak samo rzecz się ma z usuwaniem – system wypowie go, często też zmieniając wysokość tonu.

Jak wspierać dostępność pól tekstowych

Jest kilka obszarów, o które warto zadbać w tym kontekście. Postaram się przybliżyć poniżej te najważniejsze.

Etykiety i podpowiedzi

Niezależnie od używanej technologii można sprawić, by poprawnie opisywać pola. To znaczy, by widoczna obok niego etykieta brzmiała tak samo, jak ta przydzielona do samego pola. Można też rozważyć, czy ukryć widoczną etykietę przed czytnikiem ekranu, aby

zmniejszyć liczbę gestów koniecznych dla przemieszczenia się do danego elementu.

Dla UIKit można na przykład zrobić tak:

```swift
let label = UILabel()
label.text = "Username"
label.isAccessibilityElement = false // hides visible label from accessibility clients
let textfield = UITextField()
textfield.accessibilityLabel = "Username"
textfield.accessibilityHint = "Enter your username"
// now positioning code you can write yourself with ease
```

Takie rozwiązanie wspiera dostępność nie tylko dla osób korzystających z czytnika ekranu, ale także używających przełączników do sterowania telefonem. Warto też nadmienić, że często spotykaną praktyką jest połączenie accessibilityFrame obu elementów, aby ramka widoczna wokół pola tekstowego rozszerzała się także na towarzyszącą mu, widoczną etykietę. W ten sposób osoby słabowidzące, dla których czytnik ekranu także bywa wsparciem, albo niewidomi eksplorujący ekran po prostu przesuwając po nim palcem w dowolny sposób, mają większą szansę natrafienia na żądany element.

React Native także pozwala na ukrycie przed klientem dostępności widocznych etykiet:

```javascript
import React, { Component } from 'react';
import { View, Text, TextInput } from 'react-native';

class MyTextInput extends Component {
  render() {
    return (
      <View style={{ flexDirection: 'row', alignItems: 'center' }}>
        {/* Hidden label */}
        <Text
          style={{
            width: 0,
            height: 0,
            opacity: 0,
            overflow: 'hidden',
            position: 'absolute',
          }}
          importantForAccessibility="no-hide-descendants" // Hide label from accessibility
        >
          Username
        </Text>

        {/* Visible label (for visual users) */}
        <Text style={{ marginRight: 8 }}>Username:</Text>

        {/* Text input with accessibility properties */}
        <TextInput
          placeholder="Enter your username"
          accessibilityLabel="Username"
          accessibilityHint = "Enter your username"
          style={{
            flex: 1, // Allow the text input to expand and take available space
            borderWidth: 1,
            borderColor: 'gray',
            borderRadius: 4,
            paddingHorizontal: 8,
            paddingVertical: 4,
          }}
        />
      </View>
    );
  }
}

export default MyTextInput;
```

SwiftUI wymaga znacznie mniej kodu, żeby osiągnąć spodziewany efekt. A ponieważ można wybrać spośród wielu dostępnych opcji implementując pole tekstowe, można na przykład przygotować takie rozwiązanie:

```swift
import SwiftUI

struct ContentView: View {
    @State private var input = ""
    var body: some View {
        VStack {
            TextField(text: $input, label: {
                Text("Username")
                .accessibilityHidden(true) // hides the visible label
            })
            .accessibilityLabel(Text("Username") // adds accessibility label with the same text)
            .accessibilityHint(Text("Enter your username"))
        }
    }
}
```

Oczywiście jak dla każdego użytkownika, także dla osób korzystających z funkcji dostępności, istotne jest możliwość szybkiego schowania klawiatury oraz to, by pole tekstowe nie było przez nią przykryte. Ale o tej kwestii napisano już bardzo wiele.

Wymagane dane i anonsowanie błędów

Co do zasady iOS nie posiada dla pól tekstowych specjalnych właściwości, by dało się w prosty sposób zaznaczyć, czy pole jest wymagane. Dlatego zazwyczaj na widocznej obok niego etykiecie umieszcza się gwiazdkę. Czytnikowi ekranu natomiast można to zasygnalizować dodając do treści etykiety dodatkowe informacje, np. „Użytkownik (wymagane)”.

Podobnie rzecz się ma z ogłoszeniem błędu. Warto dodać informację o istnieniu pomyłki oraz wymaganej wartości do accessibilityLabel. Opcjonalnie można rozszerzyć podpowiedź o przydatne sugestie. Niektórzy użytkownicy mogą mieć wyłączone podpowiedzi, nie jest to więc zalecaną praktyką.

Przypominam także, że używanie placeholdera nie może w żadnym sensie zastąpić accessibilityLabel, ponieważ jego treść znika po wprowadzeniu przez użytkownika już pierwszego znaku. Dla osób z problemami kognitywnymi albo przy zwykłym chwilowym rozproszeniu uwagi, nie wspiera to użytkownika w poprawnym wprowadzeniu danych.

Focus

Kolejną istotną kwestią jest poprawne kierowanie fokusu. Jest to ważne w takich scenariuszach jak:

Zakończenie edycji, kiedy focus powinien wrócić do pola tekstowego.
Poprawianie błędów. Gdy walidujemy pole dopiero po wprowadzeniu wszystkich danych i naciśnięciu przycisku wysyłającego, wówczas warto po zakomunikowaniu, że znaleziono błędy, przenieść użytkownika na pierwsze niepoprawnie wypełnione pole.

Przenosząc focus unikajmy jednak gwałtownego lub za bardzo opóźnionego przesunięcia, bo może to wprowadzić zamieszanie. A to jest dokładnie to, czego nie chcemy robić. Na szczęście iOS może nas powiadomić o wielu zmianach związanych z działaniem klientów dostępności, więc daje się stworzyć przyjazne, eleganckie rozwiązanie. System wysyła na przykład powiadomienia, że czytnik ekranu zakończył ogłaszanie tego, co mu zleciliśmy.

Dyktowanie

Z przyczyn oczywistych (dane liczbowe, identyfikatory itp.) nie wszędzie można dać użytkownikom możliwość korzystania akurat z tej funkcjonalności. Mimo wszystko warto ją rozważyć wszędzie tam, gdzie miałoby to logiczne uzasadnienie. Wielu użytkownikom możliwość podyktowania całości lub części treści zwyczajnie upraszcza życie.

Podsumowując

Pola tekstowe wymagają zazwyczaj sporo uwagi, bo często możemy przewidzieć nieskończoną liczbę dziwnych pomysłów użytkowników. Mimo wszystko warto jednak poświęcić nieco czasu, aby z przyjemnością korzystały z nich także osoby używające czytników ekranu, sterowania głosowego czy innych funkcji dostępności. Zwłaszcza że odbiorców korzystających z podobnych rozwiązań jest coraz więcej.

Udostępnij artykuł