Verschachteltes fokussierbares Element
Stehlen Sie nicht den Fokus von einem anklickbaren Elternelement, indem Sie ein Kindelement fokussierbar machen
Was wir überprüfen
Fokussierbare Elemente sollten nicht innerhalb von anklickbaren Elternelementen verschachtelt sein. Wenn ein nicht-interaktives Kindelement fokussierbar ist, konzentriert sich die unterstützende Technologie darauf anstelle des anklickbaren Elternteils – das bedeutet, dass die interaktive Rolle des Elements nie angekündigt wird.
Diese Regel überprüft alle steuerbaren Elemente der Barrierefreiheit, die nicht selbst interaktiv sind. Wenn ein solches Steuerelement innerhalb eines anklickbaren Elternteils enthalten ist, ist es von Natur aus interaktiv, wird jedoch keine Rolle ankündigen. Das Element wird als Barrierefreiheitsverstoß markiert.
Fehlerhaftes Beispiel ❌
Die Karte ist anklickbar, aber das Profilbild darin ist separat fokussierbar.
TalkBack kündigt nicht die Rolle der Karte oder den Hinweis „Doppeltippen, um zu aktivieren“ an, sondern fokussiert und kündigt das innere Element an.
Benutzer wissen nicht, dass die Karte interaktiv ist, und das fokussierte Element ist nicht anklickbar.
Bestandenes Beispiel ✅
Das innere Element ist nicht mehr separat fokussierbar.
TalkBack konzentriert sich auf die Karte selbst und kündigt deren Inhalt, Rolle und „Doppeltippen, um zu aktivieren“ an.
Benutzer verstehen, dass die Karte interaktiv ist und sie aktivieren können.
Auf einen Blick
- Diese Regel hat einen kritischen Einfluss auf Benutzer von TalkBack und Voice Access
- Wenn ein Kindelement den Fokus von einem anklickbaren Elternteil stiehlt, geht die interaktive Rolle verloren
- TalkBack wird „Doppeltippen, um zu aktivieren“ nicht ankündigen, wenn das fokussierte Element nicht selbst anklickbar ist
- Die Lösung besteht immer darin, die Fokusfähigkeit des verschachtelten Elements zu entfernen und nicht, ihm eine Rolle hinzuzufügen
- Containeransichten, die keine Aktion haben, sollten nicht anklickbar gelassen werden – dies vermeidet Fehlalarme
Auswirkungen auf Benutzer
Wenn unterstützende Technologie keine Rolle ankündigt, wissen blinde oder sehbehinderte Benutzer, die sich auf TalkBack verlassen, nicht, dass sie eine Aktion auslösen können. Zum Beispiel konzentriert sich TalkBack auf ein inneres Element und kündigt nur dessen Text an (z. B. „Thema“). Es wird nicht angekündigt, dass es sich um eine Schaltfläche handelt oder dass der Benutzer zum Aktivieren doppeltippen soll. Benutzer sind ohne den Kontext, den sie benötigen, um mit dem Bildschirm zu interagieren.
Problem mit verschachteltem fokussierbarem Element bestätigen
- TalkBack einschalten
- Fokus auf das Element und jedes seiner Nachkommen setzen
- Eines der folgenden Dinge wird passieren:
- Nicht zugänglich: TalkBack liest den Text, aber kündigt keine Rolle oder Interaktionsmöglichkeit an
- Zugänglich: TalkBack liest alle Texte und kündigt auch eine Rolle und/oder die Interaktionsmöglichkeit mit dem Element an
Probleme beheben
Entfernen Sie die Fokusfähigkeit von verschachtelten Elementen, damit das anklickbare Elternteil den Fokus erhalten und seine Rolle ankündigen kann. Fügen Sie keinen nicht-interaktiven Nachkommen einer anklickbaren Ansicht fokussierbare Eigenschaften hinzu.
Um einen Fehlalarm zu vermeiden, stellen Sie sicher, dass Containerelemente, die bei Berührung nichts tun, nicht anklickbar bleiben. Unsere Tools können nicht feststellen, ob ein anklickbares Element eine zugehörige programmierte Aktion hat, daher müssen wir annehmen, dass es dies tut, um potenziell unzugängliches Verhalten zu kennzeichnen.
Untersuchen Sie umliegende Containerelemente, wie z. B. Frame-Layouts, Kartenansichten oder Schubladen, um sicherzustellen, dass jedes Element ohne zugehörige Aktion nicht als anklickbar eingestellt ist.
XML
Im untenstehenden Beispiel ist die MaterialCardView anklickbar, aber wenn eines der Kinder - LinearLayout oder TextView - eine focusable="true" hat, wird TalkBack darauf statt auf die Karte fokussieren. Im Standardzustand ist die focusable-Eigenschaft sowohl von LinearLayout als auch von TextView falsch. Stellen Sie sicher, dass sie nicht auf wahr gesetzt ist, damit die Karte den Fokus erhalten und ihre interaktive Rolle ankündigen kann.
<com.google.android.material.card.MaterialCardView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:clickable="true">
<LinearLayout
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_margin="10dp">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/contact_name"/>
</LinearLayout>
</com.google.android.material.card.MaterialCardView>Komponieren
In diesem Beispiel ist die Card anklickbar, aber wenn eines der Kinder - Row oder Text - ein .focusable()-Attribut hat, wird TalkBack darauf statt auf die Karte fokussieren. Stellen Sie sicher, dass Row oder Text kein .focusable()-Attribut haben, damit die Card den Fokus erhalten, ihren Textinhalt ankündigen und ihre interaktive Rolle vermitteln kann (z. B. „Doppeltippen, um zu aktivieren“).
Card(
modifier = Modifier
.clickable {
openContact(context)
}
) {
Row(
modifier = Modifier
.padding(10.dp),
horizontalArrangement = Arrangement.spacedBy(10.dp, Alignment.CenterHorizontally)
) {
Text("Sarah Anderson")
}
}.NET MAUI
Im Beispiel unten hat die Kontaktkarte Grid eine TapGestureRecognizer, um den Kontakt zu öffnen. Wenn ein Kindelement innerhalb der Grid unabhängig fokussierbar ist, wird TalkBack darauf statt auf die Karte fokussieren. Stellen Sie sicher, dass kein Kindelement AutomationProperties.IsInAccessibleTree="true" explizit gesetzt hat, damit die Grid den Fokus behält und „Doppeltippen, um zu aktivieren“ ankündigen kann.
<Grid
HorizontalOptions="FillAndExpand"
RowDefinitions="Auto,Auto"
RowSpacing="10"
VerticalOptions="FillAndExpand">
<Grid.GestureRecognizers>
<TapGestureRecognizer Command="{Binding OpenContactCommand}"/>
</Grid.GestureRecognizers>
<Label
Grid.Row="1"
FontAttributes="Bold"
FontSize="16"
HorizontalOptions="CenterAndExpand"
VerticalOptions="FillAndExpand">
<Label.FormattedText>
<FormattedString>
<Span Text="Sarah Anderson"/>
</FormattedString>
</Label.FormattedText>
</Label>
</Grid>React Native
In diesem Beispiel ist die Kontaktkarte eine TouchableOpacity mit Zugänglichkeitseigenschaften, die direkt darauf gesetzt sind. Die Eigenschaften accessible={true} und accessibilityRole="button" stellen sicher, dass TalkBack die Karte als interaktives Element ankündigt. Alle Kinderansichten darin sollten nicht accessible={true} unabhängig setzen, was dazu führen würde, dass sie den Fokus von der Karte stehlen.
<TouchableOpacity
accessible={true}
accessibilityRole="button"
style={styles.contactCard}
onPress={() => openContact("sarah-anderson")}
>
<Text>Sarah Anderson</Text>
<Text>sarah@example.com</Text>
</TouchableOpacity>Flutter
In diesem Beispiel ist die Kontaktkarte eine Card mit einem InkWell, der den Tap verarbeitet. Wenn ein Kind-Widget innerhalb der Card seinen eigenen Semantics-Wrapper mit button: true oder onTap gesetzt hat, wird TalkBack darauf statt auf die Karte fokussieren. Halten Sie den Tap-Handler auf der InkWell und stellen Sie sicher, dass kein nachfolgendes Widget unabhängig den Fokus beansprucht.
Card(
child: InkWell(
onTap: () => openContact(context, "sarah-anderson"),
child: const Padding(
padding: EdgeInsets.all(16.0),
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text("Sarah Anderson"),
Text("sarah@example.com"),
],
),
),
),
)Kann ich diese Regel ignorieren?
Verschachteltes fokussierbares Element hat eine Kritische Auswirkung für Benutzer, und wir empfehlen dringend, dieses Problem zu beheben. Wenn der Fokus auf ein nicht-interaktives Element innerhalb eines anklickbaren Elternteils fällt, haben TalkBack-Benutzer keine Möglichkeit zu erkennen, dass das Element aktiviert werden kann. Diese Regel zu ignorieren bedeutet, dass diese Benutzer effektiv nicht mit dem betroffenen Element interagieren können. Erfahren Sie mehr über Regeln ignorieren.
Ressourcen
Deque University Kursseiten
Hinweis: Der vollständige Zugriff auf die Ressourcen der Deque University erfordert ein Abonnement.
Weitere Ressourcen
- Richtlinien für barrierefreie Webinhalte (WCAG) 2.1, W3C-Empfehlung
- WCAG 2.1 Verständlichkeitsdokumente