Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Please document correct usage of accessibilityRole "link"

Offen
  • Stimmt etwas nicht?
#3,215 6 Kommentare 4 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Dokumentation
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
react-native
Bereich
accessibility, documentation

Rechercherichtung

Beginne mit der im Issue verlinkten Dokumentation zu accessibilityRole und vergleiche anschließend die darin zitierten Hinweise zu React Navigation, react-native-accessibility-engine und iOS. Kläre das beabsichtigte Plattformverhalten mit den Projektbetreuern, bevor du die Rollenbeschreibung änderst; abgeschlossen ist die Aufgabe, wenn die Dokumentation eine eindeutige Nutzungsregel enthält.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Never gets stale

Description

Here's the current documentation for accessibilityRole="link":

link Used when the element should be treated as a link.

This... could be more helpful. It's arguably a tautology: it says the link role should be used in those cases where the link role should be used.

There are many examples (some given below) of inconsistent and sometimes contradictory ways this has been interpreted.

What is the problem?

This is a problem because people fill in their own common-sense opinion on how link roles should be used (possibly influenced by non-equivalent experience of links on websites).

For example, I've encountered three different interpretations on how the link role should be used, all from seemingly authoritative sources:

  1. Navigation between screens: The widely used react-navigation project has utilities like useLinkProps that apply accessiblityRole="link" to any element that navigates between screens - every element using these utilities that would do internal routing in a web context will get the "link" role in Android and iOS.
  2. All interactive inline text: The react-native-accessibility-engine project has a test "link-role-required" that requires any Text element with an onPress handler to have the role "link", regardless of what the press does. This appears to be interpreting "link" by presentation (interactive inline text) rather than the nature of the action.
  3. Opening URLs in device browser: App accessibility consultants I've worked with in the past have advised that "link" should be used specifically for interactive elements that cause the app open and focus a web browser, and that "button" should be used for in-app navigation (regardless of element type). Here's an example of an accessibility consultancy giving this advice in the context of iOS:

Links open a URL in an external browser. This the important distinction between buttons. Only apply the trait of link when the users interaction with the control will take them out of your application and into Safari.

How can we address it?

There is one right answer as to how React Native's link accessibilityRole is intended to be used, based on the appropriate iOS and Android guidance for the underlying properties and traits that React Native applies internally to the native Android and iOS elements it controls.

The React Native accessibility docs should state it clearly. For example (assuming this one is correct):

link Interactive elements that load a web page in a device browser, switching focus away from this app

Why is it important?

There's clearly already diverging interpretations of how this role should be used, and it's a very commonly used role, so there is almost certainly already a lot of inconsistency on when elements are described as a "Link" in React Native apps in production.

Who needs this?

Ideally all React Native developers should be applying this accessibilityRole consistently and correctly.

When should this happen (use version numbers if needed)?

As soon as there's a clear consensus on what the correct usage is.

Vorherrschende Sprache
MDX
Sterne
2.2k
Forks
6.4k
Ø Merge
13 Std. 55 Min.
Gemergte PRs (30 T.)
25

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus react/react-native-website

Alle Issues in react/react-native-website

Ähnliche Issues

Weitere Issues zu Accessibility

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.