Ist es möglich, Javascript zu verwenden, um zu erkennen, ob ein Screenreader auf dem Computer eines Benutzers ausgeführt wird?

Lesezeit: 6 Minuten

Benutzer-Avatar
schuklendu

Ich möchte erkennen, ob ein Screenreader auf dem Computer eines Benutzers ausgeführt wird, um zu vermeiden, dass Ton mit dem Audio-Tag in HTML kollidiert. Wenn ja, machen Sie bitte Angaben dazu, wie dies geschehen könnte.

  • +1. Ich habe keine Erfahrung damit, aber sicherlich einen Bildschirmleser, der das unterstützt <audio> Tag einen Weg gefunden hätte, um kollidierende Geräusche zu vermeiden? es wäre sicherlich eine Kernfunktionalität für sie?

    – Spudley

    10. Oktober 2011 um 11:43 Uhr


  • Es ist generell nicht möglich zu erkennen, ob ein Screenreader läuft. (Auch wenn eine Barrierefreiheitstechnologie ausgeführt wird, handelt es sich möglicherweise nicht um einen audiobasierten Bildschirmleser: Es könnte sich um einen Braille-basierten Bildschirmleser oder eine Befehls-und-Steuerung-Sprachsteuerungs-App handeln, die einige der gleichen Techniken wie ein Bildschirmleser verwendet tut.) Was würden Sie anders machen wollen, wenn Sie feststellen könnten, dass ein Screenreader läuft?

    – Brendan McK

    10. Oktober 2011 um 12:18 Uhr

Benutzer-Avatar
Brendan McK

Sie sollten wahrscheinlich nichts Besonderes tun, selbst wenn Sie feststellen könnten, dass ein Screenreader ausgeführt wird. Selbst wenn Sie es für eine Gruppe von Screenreader-Benutzern richtig machen, können Sie es für eine andere Gruppe falsch machen. Es ist am besten, sich in erster Linie darauf zu konzentrieren, gutes, sauberes HTML5 zu schreiben.

Beachten Sie, dass nicht alle Screenreader-Benutzer Text-to-Speech verwenden; Viele verwenden die Braille-Ausgabe. Darüber hinaus verwenden andere Arten von Barrierefreiheitstools – wie z. B. Content-Highlighter und Spracheingabe-Apps – dieselben Techniken und APIs (z. B. DOM, MSAA) wie Screenreader, sodass jede Technik, die „einen Screenreader erkennt“, diese wahrscheinlich auch erkennt – so Sie können nicht davon ausgehen, dass der Benutzer vollständig blind ist und nur Sprache verwendet.

Nach derzeitigem Stand ist das Audio-Tag derzeit nicht allgemein zugänglich, verschiedene Browser haben unterschiedliche Ebenen der Barrierefreiheitsunterstützung – siehe HTML5-Barrierefreiheit und scrollen Sie nach unten zu Audio, um weitere Informationen zum aktuellen Support zu erhalten. Ich habe einige Seiten gesehen, die HTML5-basierte Steuerelemente plus Javascript nach dem Audio-Tag hinzufügen, damit sie ihre eigene Benutzeroberfläche bereitstellen können, um sicherzustellen, dass Tastatur- oder Screenreader-Benutzer das Audio nach Bedarf abspielen/stoppen können. (Irgendwann, wenn Browser aufholen, sollte dies nicht erforderlich sein.)

Was die allgemeine Barrierefreiheit betrifft, so sind die WCAG 2.0 (Richtlinien für die Barrierefreiheit von Webinhalten) empfiehlt, dass jedes Audio, das länger als 3 Sekunden automatisch abgespielt wird, über eine zugängliche Möglichkeit zum Anhalten oder Stoppen des Audios verfügen sollte. (Ich würde sogar noch weiter gehen und davon abraten, automatisches Audio zu verwenden – wenn Sie Tabbed Browsing verwenden, ist es oft unmöglich festzustellen, von welchem ​​Tab das Audio kommt.)

  • Downvoter – möchten Sie erklären, warum die Ablehnung? Gibt es etwas, das mit dieser Antwort verbessert werden könnte?

    – Brendan McK

    5. Dezember 2016 um 21:53 Uhr

  • Ich bin kein Downvoter, aber ein Beispiel, das mir einfällt, ist, wenn Sie ein Framework schreiben, das eine grundlegende Kontrolle bietet, wie z. B. eine Datumseingabe mit einem angehängten Picker. Für mobile Plattformen oder Bildschirmleseprogramme möchten Sie möglicherweise die Eingabe verwenden[type=date]. Es ist hacky, aber nicht schwer, Handy zu erkennen; Screenreader würden von der Frage abgedeckt.

    – Adam Leggett

    24. Oktober 2018 um 21:54 Uhr

  • Ich bin auch nicht der Downvoter – in meinem Fall habe ich ein perfekt funktionierendes natives Select-Dropdown, das so gut funktioniert, wie es mit Screenreadern zu erwarten ist. Aber wenn ich es mit einem Plugin wie selectric “erweitere”, ist es für Screenreader plötzlich nutzlos. Wenn ich wüsste, dass ein Screenreader im Spiel ist, würde ich nie in den Selectric einsteigen und alle wären glücklicher.

    – Changokun

    14. März 2019 um 21:12 Uhr

  • Ich kann nicht ablehnen, aber in meinem Fall möchte ich zwei verschiedene Tabellen mit vielen Daten haben, eine für Screenreader mit normalen

    -Tags und

    und so weiter und eine weitere

    -Tabelle, um es schön in der zu machen ansprechende Ansicht. Wie Garrett Dimon sagte: „Datentabellen eignen sich nicht so gut für responsives Design.

    – Kurt Lagerbier

    18. Mai 2021 um 17:34 Uhr

    Benutzer-Avatar
    hexalys

    Obwohl dies wahrscheinlich nicht ganz zuverlässig ist, kann der Fortschritt eines Screenreaders über Javascript mithilfe des Focus-Ereignisses erkannt werden, während der Benutzer den Inhalt überfliegt.

    Ein versteckter „Navigationslink überspringen“ (http://webaim.org/techniques/skipnav/) sollte es fokussiert sein, wäre eine Möglichkeit zu erkennen, ob jemand einen Screenreader verwendet.

    Auch wenn der Audioteil der Frage nicht angesprochen wird, wollte ich nur diese Teillösung bereitstellen, da ich nach Möglichkeiten suchte, Bildschirmlesegeräte selbst zu erkennen.

    • Was ist mit Leuten, die mit der Tastatur navigieren? sind nicht mit einem Screenreader?

      – Steveax

      18. April 2013 um 8:49 Uhr

    • @stevax, meines Wissens impliziert das Navigieren mit der Tastatur neben den beschriebenen üblichen IE-Macken ein Fokusereignis, unabhängig davon, ob Sie einen Bildschirmleser verwenden oder nicht. Das unterstützte VoiceOver von Safari zum Beispiel wendet den Fokus an, während es Inhalte mit der Tastatur überfliegt. Und ein Tabindex kann verwendet werden, um den Fokus auf ein bestimmtes Element in der Reihenfolge zu erzwingen, wenn der Benutzer durch die Seite blättert.

      – hexalys

      19. April 2013 um 0:11 Uhr


    • Vielleicht habe ich mich in meinem Kommentar nicht klar ausgedrückt. Der Punkt, den ich machen wollte, ist, dass es nicht möglich wäre, zwischen Screenreader-Benutzern und Leuten zu unterscheiden, die aus anderen Gründen (möglicherweise in einem Zusammenhang) mit der Tastatur navigieren, die keinen Screenreader verwenden, und die versuchen, auf den Bildschirm zu zielen Reader-Benutzer auf diese Weise würde wahrscheinlich zu einer großen Menge Schaden führen.

      – Steveax

      19. April 2013 um 2:29 Uhr

    • Ich verstehe was du meinst. “Anzeige: keine;” Für Screenreader unsichtbar zu sein, ist ebenfalls eine Hürde. Ein denkbarer Weg, dies zu tun, wäre jedoch, ein mittleres Element innerhalb von 3 aufeinanderfolgenden als aria-hidden=”true” oder aria-disabled=”true” zu markieren. Wenn Element 1 und 3 den Fokus erhalten, würde dies darauf hinweisen, dass eine Hilfstechnologie verwendet wird (weil eine übersprungen wurde), anders als eine einfache Tastaturnavigation. Da ich keine Tastaturnavigationswerkzeuge oder Plugins vorsehe, die WAI-ARIA-bezogene Zustände oder Eigenschaften anwenden.

      – hexalys

      19. April 2013 um 6:32 Uhr


    • Einige (wahrscheinlich veraltete) Beispielcodes, die die Unterschiede in Javascript-Ereignissen (zwischen Bildschirmlesern, Tastaturbenutzern und Mausbenutzern) erkennen, finden Sie hier dylanb.github.io/screenreaderdetection

      – Robokatze

      1. September 2016 um 0:02 Uhr

    Benutzer-Avatar
    Steve Faulkner

    Sie können Screenreader nicht mit Javascript erkennen, Sie können Screenreader nicht mit irgendeiner clientseitigen Technologie erkennen. Sie können Software erkennen, die ausgeführt wird MSAA Client mit Flash. Weitere Einzelheiten darüber, wie es funktioniert und warum es nicht nützlich ist und nicht verwendet werden sollte, um Screenreader zu erkennen, finden Sie hier: Vorsicht für Entwickler: Verwendung von Flash zur Erkennung von Screenreadern

    1142540cookie-checkIst es möglich, Javascript zu verwenden, um zu erkennen, ob ein Screenreader auf dem Computer eines Benutzers ausgeführt wird?

    This website is using cookies to improve the user-friendliness. You agree by using the website further.

    Privacy policy