Przyciski iOS w UIKit, SwiftUI oraz React Native
- Przejdź do artykułów z tagiem accessibility
- Przejdź do artykułów z tagiem akademiaWCAG
- Przejdź do artykułów z tagiem iOS
- Przejdź do artykułów z tagiem mobile
- Przejdź do artykułów z tagiem react
Treść artykułu
Przyciski stanowią istotną część każdej aplikacji mobilnej. Tym bardziej więc warto sprawić, żeby czytniki ekranu i inne technologie asystujące zrobiły z nich użytek.
Jak działają?
Co do zasady każdy przycisk jest dodawany do listy elementów dostępnych dla użytkownika korzystającego z takich technologii asystujących jak czytniki ekranu (np. VoiceOver), sterowanie głosowe czy sterowanie przełącznikami.
Czytnik ekranu dla przycisku odczytuje 3 parametry:
- Tytuł przycisku.
- Rolę, czyli w tym przypadku słowo „Przycisk”.
- Podpowiedź, czyli krótki opis tego, co aktywowanie danego przycisku zmienia.
Natywne komponenty we frameworkach Apple jak UIButton dla UIKit czy Button w SwiftUI zawsze ogłoszą tytuł i rolę przycisku. Jednak przyjrzyjmy się chwilkę, by zrozumieć, w jaki sposób dostosować działanie przycisków do ich roli w strukturze naszej aplikacji. Kontekst ma przecież fundamentalne znaczenie, głównie dla niewidomych użytkowników. Ich jedynym źródłem informacji na temat interfejsu naszej aplikacji jest przecież tylko to, co zakomunikuje im czytnik ekranu.
Tytuł przycisku
Dla VoiceOver lub sterowania głosowego właściwe stworzenie przydatnego tytułu może mieć kluczowe znaczenie. Dlatego zazwyczaj rekomenduje się wprowadzanie krótkich fraz, najlepiej zaczynających się od czasownika, np. „Zarejestruj się”, „Zaloguj”, „Odtwarzaj”, „Zatrzymaj”, „Aplikuj” itp.
Zauważcie, że każdy tytuł Zaczęłam wielką literą, co ułatwia zadanie czytnikom ekranu. To wspiera też wydawanie poleceń głosowych. Na końcu tytułu nie umieściłam też kropki, ponieważ ona utrudnia czytnikowi ekranu zadanie.
Przyciski w aplikacjach często mają także obrazek zamiast tytułu. Warto wówczas nadać obrazkowi tytuł alternatywny, bo czasami system może wykorzystać nazwę pliku obrazka, by wygenerować go samodzielnie. Może też, w nowszych modelach telefonów, rozpoznać obrazek błędnie, co także wiele utrudni.
Warto też pamiętać, by tytułem przycisku nie była na przykład pojedyńcza spacja, obok której jest obrazek. W takich sytuacjach może się niekiedy okazać, że atrybut accessibilityLabel, który przydzieliliśmy, nie zostanie wykorzystany. Stanie się tak dlatego, że w kontrolkach takich jak UIButton tytuł będzie zawsze preferowany.
Jeśli zdarzy się, że mamy powtarzający się tytuł dla wielu podobnych elementów, warto nadać mu więcej kontekstu. Na przykład jeśli na liście jest wiele produktów, do tytułu można dodać: „Dodaj [nazwa produktu] do koszyka” (np. „Dodaj Kredki kolorowe 12 sztuk do koszyka”).
Rola przycisku
W ten element nie mamy szansy ingerować. Jest ona zawsze taka sama i ogłaszana jako „przycisk”. Pamiętajmy jedynie, by nie dodawać tego słowa (lub odpowiedników) do tytułu przycisku lub jego opisu alternatywnego. Gdybyśmy to zrobili, system odczyta ją dwukrotnie, co wprowadzi jedynie zamieszanie.
Podpowiedź
Ten element wspiera użytkowników w zrozumieniu przeznaczenia danego przycisku w kontekście. I na przykład dla przycisku „Odtwarzaj” w aplikacji wideo może brzmieć „Odtwarza wybrany film. Naciśnij ponownie, aby włączyć pauzę”.
Warto pamiętać, że niektórzy użytkownicy co do zasady mają podpowiedzi wyłączone i że jest to materiał opcjonalny. Stąd nie należy umieszczać w podpowiedzi informacji krytycznych dla działania aplikacji. Przypominam o tym głównie w kontekście przycisków destruktywnych. Utrata danych może być bolesna dla użytkownika, dlatego dobrą praktyką jest dodatkowy alert potwierdzający jego intencje.
O czym jeszcze warto pamiętać?
Kiedy użytkownik naciśnie przycisk, VoiceOver poinformuje go o tym generując odpowiedni dźwięk. Jeśli chcesz tego uniknąć to:
Dla UIKit:
let button = UIButton() button.setImage(UIImage(contentsOfFile: „my_example_image.png”), for: .normal) button.accessibilityLabel = „More details” button.accessibilityHint = „Plays media. Press again to pause” button.accessibilityTraits = .playsSound // jeśli aktywacja przycisku ma wywołać dźwięk charakterystyczny dla aplikacji // lub button.accessibilityTraits = .startsMediaSession // jeśli przycisk służy rozpoczęciu odtwarzania muzyki lub wideo // lub button.accessibilityTraits = .causesPageTurn // jeśli przycisk przewraca strony, na przykład ebooka (wymaga dodatkowej implementacji accessibility.scroll dla kontenera)
Dla SwiftUI:
Button(action: {startPlayback()}, label: {Text(„Play”)}) .accessibilityAddTraits([.startsMediaSession, // zaczyna odtwarzanie audio lub wideo .playsSound, // gdy reagujesz na naciśnięcie przycisku własnym dźwiękiem .causesPageTurn // gdy przewracasz stronę tym przyciskiem, również wymaga dodatkowych implementacji scrollowania dla kontenera ])
Alternatywy dla typowych przycisków
Czasami zdarza się, że sama grafika lub fragment tekstu może stanowić element klikalny. Wówczas warto pamiętać o dodaniu mu odpowiedniej roli oraz implementacji niezbędnych metod, by klient dostępności (czytnik ekranu lub inny) był w stanie wykonać zadanie. Oto przykłady:
UIKit:
let myImage = UIImage(contentsOfFile: „example_image.png”) image.accessibilityLabel = „Show details” image.accessibilityHint = „Press to show album details” image.accessibilityTraits = .button
SwiftUI:
import SwiftUI
struct MyTappableImage: View {
var body: some View {
Image(„my_example_image.png”)
.resizable()
.accessibilityLabel(Text(„Provide useful text here”))
.accessibilityHint(„Provide some optional info if necessary”)
.onTapGesture({
// perform some action
})
.accessibilityAddTrait([.isButton])
}
}
I jeszcze dla fanów React Native:
import React from ‘react’; import { View, Image, TouchableOpacity, Text } from ‘react-native’; const AccessibleImageButton = () => { const handleButtonPress = () => { // Handle button press here }; return ( <TouchableOpacity onPress={handleButtonPress} accessible={true} accessibilityLabel=“Describe the Button’s Purpose” accessibilityHint=“Provides more detailed context if necessary.” accessibilityRole=“button” > <Image source={require(‘./path_to_your_image.png’)} // replace with your image path style={{width: 50, height: 50}} // adjust as needed /> </TouchableOpacity> ); } export default AccessibleImageButton;
Wydawałoby się, że stworzenie przycisku w aplikacji to sprawa wręcz trywialna. W większości przypadków rzeczywiście nie będzie wymagała głębokiego zastanowienia. Jednak projektując z myślą o dostępności, warto przetestować każdy element. Wizualnie atrakcyjne przyciski mogą okazać się nieprzydatne dla użytkowników korzystających z czytnika ekranu lub osób słabowidzących, które na przykład powiększają czcionki, aby było im wygodniej odczytać treść.
Warto jeszcze wspomnieć, że z funkcji dostępności korzystają różne osoby, w tym te obsługujące telefony lub tablety za pomocą przełączników lub sterowania głosowego. One zobaczą przycisk. Ale co z tego, skoro nie czyniąc go elementem dostępnym, nie damy im do niego dotrzeć? Tym bardziej warto jest więc wziąć pod uwagę potrzeby i oczekiwania różnych użytkowników.
Barbara Filipowska
Audytor dostępności
Polecane artykuły
-
17.11.2023Dostępność cyfrowa
WCAG 2.1. – kryterium 2.3.3 – Animacja po interakcji (poziom AAA)
Dzisiaj omówimy sobie kryterium 2.3.3 – Animacja po interakcji (poziom AAA) WCAG 2.1. Być może na pierwszy rzut oka skojarzy…
-
29.06.2023Dostępność cyfrowa
Okiem niewidomego: Zakupy online z dostawą do paczkomatu
Ostatnio sporo razy zdarzyło mi się zamawiać produkty w sklepach internetowych. O samym przygotowaniu stron sklepowych wspominałem już we wcześniejszych…
-
07.06.2024Akademia WCAG
WCAG 2.1 – Kryterium 3.2.3 – Spójna nawigacja (Poziom AA)
W kolejnym poście Akademii WCAG skupiamy się na kryterium WCAG 3.2.3 Spójna nawigacja (poziom AA). Co określa WCAG 3.2.3 spójna…