Leaflet: Verbesserungen der Barrierefreiheit

Ich möchte Ihr Problem hier nicht übernehmen, @stevevance , aber ich habe Ihren Tweet darüber früher gesehen und wollte einspringen und über die Barrierefreiheit im Allgemeinen sprechen. Dies könnte (sollte?) Sein eigenes Problem sein, aber ich dachte, ich würde hier anfangen, weil der von Ihnen bereitgestellte Kontext ein großartiger Einstieg ist.

Ich arbeite an der digitalen Kartierung für den National Park Service, und alle unsere Produkte müssen Abschnitt 508 und WCAG entsprechen. Wir haben kürzlich ein Barrierefreiheits-Audit eines Drittanbieters durchgeführt, um unsere Webkarten zu testen. Da unsere Mapping-Bibliothek (NPMap.js) auf Leaflet basiert, gelten einige der Ergebnisse und Empfehlungen des Audits direkt für Leaflet selbst. Ich wollte schon seit einiger Zeit ein Thema dazu eröffnen, aber andere Dinge standen mir im Weg. Danke für den Schubs!

Ich habe viele der Empfehlungen des Audits aufgegriffen und in umsetzbare Punkte umgewandelt. Sie können das offene Problem auf der Seite von NPMap.js hier sehen: https://github.com/nationalparkservice/npmap.js/issues/168.

Wir (das NPMap-Team) würden gerne mit der Implementierung einiger dieser Korrekturen in Leaflet beginnen, wenn diese Arbeit unterstützt wird. Insbesondere möchten wir an diesen Korrekturen arbeiten:

1. Verwenden Sie für Steuerelemente Schaltflächen und keine Links
2. Verwenden Sie alt Text anstelle von title Attributen für Steuerelemente
3. Setzen Sie tabIndex des HTML-Elements mit der Klasse leaflet-container auf 0
4. Verwenden Sie Ankerelemente anstelle von Divs für Markierungen und zeigen Sie das Attribut href auf die ID des Divs des Popups (ich denke, dieses ist möglicherweise ziemlich schwierig).
5. Setzen Sie den Fokus auf ein Header-Element im Popup, wenn Popup angezeigt wird, und setzen Sie tabindex auf -1, bevor das Element fokussiert wird

Die obige Liste ist eine Teilmenge der Fixes, die wir in NPMap.js implementieren möchten. Ich halte diese Elemente jedoch für sinnvoll, um sie in Leaflet zu implementieren. Ich glaube, der dritte Punkt würde beim VoiceOver-Problem helfen.

Es gibt ein größeres Problem, für das ich wirklich keine Lösung habe: Alle Vektoren, nicht nur Marker, müssen tabellierbar sein. So wie die Dinge derzeit sind, sind nur Marker tabellierbar. Dies bedeutet, dass VoiceOver und andere Eingabehilfen für andere Vektoren nicht funktionieren. Derzeit weiß ich nicht genug über Barrierefreiheit und SVG, VML und Canvas, um eine fundierte Empfehlung abzugeben, aber ich bin bereit, etwas Zeit in die Recherche zu investieren.

@stevevance + @nateirwin -

Schauen Sie sich auch dieses StackOverflow- Problem an. Es kann für Sie genauso hilfreich sein wie für meine Anwendung:
http://stackoverflow.com/questions/26745454/how-to-make-leaflet-tile-layers-accessible

@geospatialem : Das sieht gut aus. Vielleicht möchten Sie das zur Liste hinzufügen ...

Vielen Dank für das äußerst wertvolle Feedback! Es liegt in meinem besten Interesse, die Broschüre in Bezug auf die Barrierefreiheit zu verbessern, daher sind PRs immer willkommen. Ich werde eine detailliertere Antwort geben, wollte aber nur schnell bestimmte Änderungen von @nateirwin kommentieren :

Verwenden Sie für Steuerelemente Schaltflächen und keine Links

Einverstanden!

Verwenden Sie Alt-Text anstelle von Titelattributen für Steuerelemente

Die HTML-Spezifikationen besagen, dass das Attribut alt nur für Bilder und Eingaben gilt. Wollten Sie etwas anderes als "Kontrollen" sagen?

Setzen Sie tabIndex des HTML-Elements mit der Leaflet-Container-Klasse auf 0

Bereits das Standardverhalten.

Verwenden Sie Ankerelemente anstelle von divs für Markierungen und zeigen Sie das href-Attribut auf die ID des div des Popups (ich denke, dieses ist möglicherweise ziemlich schwierig).

Ja, kann ein bisschen schwierig sein. Gibt es Alternativen? Vielleicht können Sie auch den gesamten Popup-Inhaltscontainer fokussierbar machen und den Fokus auf das Klicken auf Markierungen setzen - würde das funktionieren?

Setzen Sie den Fokus auf ein Header-Element im Popup, wenn Popup angezeigt wird, und setzen Sie den Tabindex auf -1, bevor das Element fokussiert wird

Können Sie beschreiben, wie dies in der Praxis funktioniert?

Danke, @mourner. So adressieren Sie Ihre Kommentare:

Die HTML-Spezifikationen besagen, dass das alt-Attribut nur für Bilder und Eingaben gilt. Wollten Sie etwas anderes als "Kontrollen" sagen?

Entschuldigung, ich hätte klarer sein sollen. Wir verwenden Bilder in den meisten unserer Steuerelemente (wie einige der Steuerelemente von Leaflet und viele Leaflet-Plugins), und die Anleitung, die wir erhalten haben, besagt, dass wir Vordergrundbilder (keine Hintergrundbilder) mit dem darauf angegebenen Attribut alt sollten. In dem Bericht wurde Folgendes über title Attribute angegeben:

Titelattribute werden nicht von allen Hilfstechnologien zuverlässig ausgelesen. Einige Bildschirmleseprogramme lesen standardmäßig keine Titelattribute, sodass diese Benutzer die Kartensteuerelemente nicht voneinander unterscheiden können. Titelattribute können auch für Benutzer mit Sehbehinderung problematisch sein - sie sind mit Bildschirmvergrößerung nicht lesbar und können andere Oberflächenelemente verdecken.

Aufgrund dieser Anleitung schalten wir alle Steuerelemente auf Vordergrundbilder mit den angegebenen alt -Attributen um und verwenden für die meisten Elemente keine title -Attribute mehr.

Bereits das Standardverhalten.

Ah, ok. Ich dachte, die tabindex sei auf 1 gesetzt.

Ja, kann ein bisschen schwierig sein. Gibt es Alternativen? Vielleicht können Sie auch den gesamten Popup-Inhaltscontainer fokussierbar machen und den Fokus auf das Klicken auf Markierungen setzen - würde das funktionieren?

Ich glaube, die Absicht, Ankerelemente mit href Attributen ( href="#popup-div") besteht darin, dass jemand, der einen Bildschirmleser verwendet, auf das Element "klicken" und die unterstützende Technologie den Inhalt des Popups vorlesen lassen kann Das Problem dabei ist, dass davon ausgegangen wird, dass jeder Marker ein Popup-Div hat, das beim Initialisieren der Ebene gerendert wird. Korrigieren Sie mich, wenn ich falsch liege, aber ich glaube, dass Popups im Allgemeinen spontan erstellt werden, wenn ein Marker angeklickt oder aktiviert wird mit einer Tastatur und dann zerstört, so dass nicht viele unnötige DOM-Elemente herumliegen.

Eine andere mögliche Lösung besteht darin, jedem Marker-Div ein verstecktes Div hinzuzufügen, das Informationen über den Marker enthält. Möglicherweise die gleichen Informationen, die im Popup angezeigt werden, oder eine prägnantere Version dieser Informationen. Ein Bildschirmleser kann dann leicht auf diese Informationen zugreifen, wenn er von Marker zu Marker springt.

Beide Lösungen setzen voraus, dass die zum Erstellen eines Popups erforderlichen Informationen auf dem Client verfügbar sind. Ich weiß, dass wir häufig Informationen für Popups über AJAX-Aufrufe abrufen, und diese Änderungen werden diesen Anwendungsfall offensichtlich nicht ansprechen.

Alles in allem denke ich, dass das, was Sie skizzieren, eine gute Verbesserung gegenüber dem aktuellen Verhalten darstellt. Ich würde sagen, es ist ein guter Kompromiss. Es verbessert die Zugänglichkeit und bewahrt gleichzeitig die Einfachheit und Flexibilität des aktuellen Ansatzes.

Können Sie beschreiben, wie dies in der Praxis funktioniert?

In der Praxis würden Sie so etwas tun, wenn ein Marker mit einer Tastatur angeklickt oder aktiviert wird:

<h3>Oregon Caves National Monument</h3>
$(‘.leaflet-popup-content h3’).attr(‘tabindex’, -1).focus();

Wenn Sie tabindex auf -1 setzen und die Tastatur verwendet wird, um vom h3 -Element wegzuschalten, ist es nicht möglich, dorthin zurückzukehren. Wenn Sie den Fokus auf dieses Element setzen, liest ein Bildschirmleser sofort den Titel des Popups und bietet so einen wichtigen Kontext für nachfolgende Inhalte.

Um ehrlich zu sein, ist mir nicht 100% klar, warum die tabindex der h3 auf -1 geändert werden müssen, aber ich kann eine Klarstellung dazu bekommen.

Eine andere Sache, die verbessert werden kann, ist die enge Verbindung des Popups. Wir können die Zugänglichkeit leicht verbessern, indem wir der "x" -Spanne ein aria-hidden="true" -Attribut hinzufügen. Dann könnten wir eine versteckte Spanne mit dichtem Text hinzufügen:

<a class="leaflet-popup-close-button" href="#marker-id">

  <span aria-hidden="true">x</span>

  <span class="visuallyhidden">close popup</span>

</a>

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);

  height: 1px;
  width: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  position: absolute;
}

Freut mich, dieses Problem zu sehen! Vielen Dank, dass Sie auf @stevevance und @nateirwin aufmerksam gemacht haben

Die Korrektur für die Kachelbilder, die oben auf dem Stapelüberlauf veröffentlicht wurden, scheint aus Benutzersicht immer noch problematisch zu sein, aber bitte korrigieren Sie mich, wenn ich falsch liege. Ich bin hier kein Experte.

Ist es nützlich, Kachelbilder für Bildschirmleser "sichtbar" zu machen? Ich habe das Gefühl, dass ein blinder oder sehbehinderter Benutzer von den zugrunde liegenden Basiskacheln keinen nützlichen Kontext erhält, insbesondere wenn es etwa ein Dutzend Kacheln mit alt = "Kartenbildkachel" gibt.

Wäre es das bevorzugte Verhalten, diese vollständig vor Bildschirmlesern zu verbergen oder es einfach zu machen, diese mit einem Sprunglink zu überspringen? Oder ist das einfach genug, um alle Bilder, die bereits mit der vorhandenen Bildschirmlesetechnologie vorhanden sind, zu überbrücken?

Oh, sorry @stevevance, ich denke, genau das schlagen Sie oben vor. : +1:

@ Jasonlally Hey Jason!

Also habe ich die Kommentare von @mourner und @nateirwin gelesen und

Das größte Problem, auf das der blinde Benutzer stieß, mit dem ich zusammengearbeitet habe, war, dass jedes Mal, wenn sie auf die Karte auf ihrem iPad tippte, das iPad den Dateinamen der Bildkachel las. Das wäre das erste, was ich reparieren möchte. Hat jemand einen Vorschlag, wie man dem iPad sagt, dass das Element nicht "tippbar" ist?

Wenn Sie das iPad dazu bringen, die Bildkacheln zu ignorieren, hilft es dann, den Ratschlägen hier zu folgen?
http://www.w3.org/WAI/tutorials/images/decorative/

Etwas wie:

<img src="tile.png" role="presentation" alt="">

Man könnte argumentieren, dass Kartenkacheln mehr als dekorativ sind und Informationen liefern, aber in diesem primären Anwendungsfall wird der Kontext tatsächlich durch die Ebeneninformationen bereitgestellt. Es scheint, dass unterstützende Technologien Bilder mit alt = "" ignorieren und neuere Technologien das Arien-Tag role = "Presentation" berücksichtigen.

Hat noch jemand Gedanken dazu? Es scheint, als würde eine einfache Änderung der Broschüre darin bestehen, dass Kacheln dies als Standard ausgeben.

@nateirwin nicht sicher, wie einfach es ist, die Faltblattsteuerelemente so zu ändern, dass Schaltflächen anstelle von Links verwendet werden, aber was ist, wenn die aktuellen Links role="button" ?

@jasonlally Es scheint, dass die Broschüre standardmäßig kein alt -Tag auf den Bildern enthält. Ist ein fehlendes alt -Tag dasselbe wie alt="" ?

Es gibt ein größeres Problem, für das ich wirklich keine Lösung habe: Alle Vektoren, nicht nur Marker, müssen tabellierbar sein. So wie die Dinge derzeit sind, sind nur Marker tabellierbar. Dies bedeutet, dass VoiceOver und andere Eingabehilfen für andere Vektoren nicht funktionieren. Derzeit weiß ich nicht genug über Barrierefreiheit und SVG, VML und Canvas, um eine fundierte Empfehlung abzugeben, aber ich bin bereit, etwas Zeit in die Recherche zu investieren.

Eine Problemumgehung, mit der ich experimentiert habe, besteht darin, jedes SVG-Pfad-Tag mit einem leeren <a> -Tag zu versehen, auf das über Registerkarten zugegriffen werden kann. Dann habe ich ein bisschen CSS-Code hinzugefügt, um die Pfade zu formatieren, wenn sie den Fokus haben:
a:focus>path.leaflet-clickable {stroke-width:5px;}
Wenn ich zu dem Link gehe, der jeden Pfad umgibt, ändert sich der Pfad, sodass ich visuell erkennen kann, welcher Pfad mit einer Registerkarte versehen ist.
und jetzt arbeite ich daran, das Klickereignis aus dem den Pfad umgebenden Ereignis zu erfassen

@nateirwin & @stevevance Wenn Sie nach einem Patch für die Steuerelemente der Broschüre suchen (während die größeren Probleme Aufmerksamkeit erregen), wird L.EasyButton so aktualisiert, dass button s mit img Tags verwendet werden .

Hier sind Zoom-Steuerelemente , die basierend auf den obigen Angaben für den Bildschirmleser geeignet sein sollten.

Hoffe es hilft in der Zwischenzeit!

Nachdem ich diese Ausgabe gelesen habe (als Antwort auf eine interne Esri-Diskussion über Barrierefreiheit), denke ich, dass einige Dinge getan werden könnten:

• Verwenden Sie role=presentation und alt="" auf Kartenkacheln, damit Bildschirmleser ihre URLs nicht lesen.
• Benutzer role=button und aria-label="Zoom In/Out" auf den Zoomtasten. aria-label möglicherweise von mehr Bildschirmlesern als title gelesen.

Ist ein fehlendes alt-Tag dasselbe wie alt = ""?
@stevevance in https://github.com/Leaflet/Leaflet/issues/3210#issuecomment -96029220

Definitiv nicht. In meinen eigenen Tests lesen die meisten Bildschirmleser die Bild-URL, wenn ein alt -Attribut fehlt. Weitere Informationen finden Sie unter https://www.w3.org/TR/WCAG20-TECHS/H67 und unter https://github.com/Esri/esri-leaflet/blob/10fced2121c5cbc506c8b6e7ee95cc891076eabe/src/Layers/TiledMapLayer. L81 -L85 für die Implementierung in Esri Leaflet.

Möglicherweise können Sie auch den gesamten Popup-Inhaltscontainer fokussieren und den Fokus auf Markierungsklick umschalten
@mourner in https://github.com/Leaflet/Leaflet/issues/3210#issuecomment -73291846

Ich mag diese Idee wirklich sehr. Wenn ein Benutzer ein Popup fokussiert, sollten wir den Fokus an den Popup-Container senden. Ich könnte versuchen, dies zuerst in die Esri-Broschüre aufzunehmen und zu prüfen, ob ich irgendetwas, das nützlich sein könnte, stromaufwärts zur Broschüre bringen kann. Dies müsste auch SVGs zugänglich machen, aber ich denke, hier gibt es etwas.

Verwenden Sie role=presentation und alt="" auf Kartenkacheln, damit Bildschirmleser ihre URLs nicht lesen.

Ja. Bitte machen Sie dies Wirklichkeit.

Hallo, bei meinen eigenen Tests des NVDA-Bildschirmlesegeräts habe ich festgestellt, dass Popups nicht einfach zu öffnen sind. Wenn im "Navigations" -Modus von NVDA eine Markierung mit der TAB-Taste fokussiert wird, sagt der Bildschirmleser den Alternativtext des img-Tags, falls vorhanden. Wenn Sie jedoch die EINGABETASTE drücken oder SPACE, wird das Popup nicht geöffnet.

Wenn Sie nur role="button" zum img-Tag der Marker hinzufügen, funktioniert dies.

_initIcon: function () { ... if (icon !== this._icon) { ... icon.setAttribute('role', 'button') }... } funktioniert großartig. Gibt es einen Grund, dies nicht zu tun?

Danach: Fokussieren Sie den Popup-Inhalt möglicherweise automatisch auf popupOpen -> die Stimme kann ihn lesen -> geben Sie dem Marker den Fokus zurück, wenn das Popup geschlossen ist -> der Benutzer kann zum nächsten Marker wechseln.

Dies ist sehr nützlich, wenn Popups komplexe Informationen, Links oder Schaltflächen enthalten und nicht nur im Alt-Tag von Symbolen zusammengefasst werden können.

BEARBEITET
Diese Demo 2015 ist sehr aufschlussreich: http://melmo.github.io/accessibility/berlin.js/code/dist/leaflet.html

• Sie verwenden role = 'präsentation' für Kacheln (die sich jetzt im Faltblattkern befinden).
• Sie fokussieren das Popup beim Öffnen und beim Schließen wieder auf die Markierung
• Sie verwenden role = 'application' auf map div

Die Rolle = 'Anwendung' verhindert grundsätzlich, dass die assistive Technologie (JAWS / NVDA) JS übernimmt.
Bei meinen Tests (Chrome und Firefox, Broschüre im Vollbildmodus) wird verhindert, dass der Bildschirmleser beim Laden der Seite ALLE Alt-Tags von Symbolen liest. Danach kann der Benutzer mit der Tabulatortaste von einem Marker zum anderen wechseln und die Marker mit der EINGABETASTE öffnen. Wie bei der üblichen Navigation auf der Tastatur ohne Bildschirmleser.

Die Rolle = 'Anwendung' kann gefährlich sein, da sie die Tastenkombinationen für Lesegeräte deaktiviert, an die ein Benutzer gewöhnt sein könnte, aber sie scheint perfekt zur Broschüre zu passen.
Der Artikel sagt, es bricht Dinge in Firefox. Es ist aber ok für mich.

HINWEIS: Das Hinzufügen von role = 'button' zu img-Tags ist immer noch eine gute Idee:
Wenn Sie zwischen Markierungen tippen, hört der Benutzer: "Dies ist mein Alternativtext - TASTE" und nicht "Dies ist mein Alternativtext - GRAFIK". Er weiß also, dass er mit der Eingabetaste darauf "klicken" kann. groß!

Sie fokussieren das Popup beim Öffnen und beim Schließen wieder auf die Markierung

Dies scheint Tastaturbenutzern hilfreich zu sein. Wäre dies eine gute Idee, um die Broschüre selbst zu ergänzen?

Eine Alternative besteht darin, das Popup direkt nach der Markierung in den HTML-Code einzufügen. Dies könnte die Notwendigkeit beseitigen, focus aufzurufen, und würde es ermöglichen, aus dem Popup zum nächsten Marker zu wechseln.

https://github.com/Leaflet/Leaflet/issues/3210#issuecomment -73323789

Eine andere Sache, die verbessert werden kann, ist die enge Verbindung des Popups. Wir können die Zugänglichkeit leicht verbessern, indem wir der "x" -Spanne ein aria-hidden = "true" -Attribut hinzufügen. Dann könnten wir eine versteckte Spanne mit dichtem Text hinzufügen:

<a class="leaflet-popup-close-button" href="#marker-id">

 <span aria-hidden="true">x</span>

 <span class="visuallyhidden">close popup</span>

</a>

Eine Bewertung der Barrierefreiheit, an der ich beteiligt war, berichtete über dieses spezielle Problem.

Ich denke, die "visuell versteckte" Texterklärung für den Popup-Link zum Schließen sollte auch in andere Sprachen übersetzbar sein.

Sie fokussieren das Popup beim Öffnen und beim Schließen wieder auf die Markierung

Dies scheint Tastaturbenutzern hilfreich zu sein. Wäre dies eine gute Idee, um die Broschüre selbst zu ergänzen?

Eine Alternative besteht darin, das Popup direkt nach der Markierung in den HTML-Code einzufügen. Dies könnte die Notwendigkeit beseitigen, focus aufzurufen, und würde es ermöglichen, aus dem Popup zum nächsten Marker zu wechseln.

Hierfür gibt es bereits ein Problem unter https://github.com/Leaflet/Leaflet/issues/2199

# 3210 (Kommentar)

Eine andere Sache, die verbessert werden kann, ist die enge Verbindung des Popups. Wir können die Zugänglichkeit leicht verbessern, indem wir der "x" -Spanne ein aria-hidden = "true" -Attribut hinzufügen. Dann könnten wir eine versteckte Spanne mit dichtem Text hinzufügen:

<a class="leaflet-popup-close-button" href="#marker-id">
> 
 <span aria-hidden="true">x</span>
> 
 <span class="visuallyhidden">close popup</span>
> 
</a>

Eine Bewertung der Barrierefreiheit, an der ich beteiligt war, berichtete über dieses spezielle Problem.

Ich denke, die "visuell versteckte" Texterklärung für den Popup-Link zum Schließen sollte auch in andere Sprachen übersetzbar sein.

@ahukkanen - https://github.com/Leaflet/Leaflet/pull/7079 (speziell https://github.com/Leaflet/Leaflet/pull/7079/commits/45f04d3bc7a357ea6fe8b90e90ac09364a37d92c) verbessert das Schließen des Textes für das Schließen.

In Bezug auf Übersetzungen: Internationalisierung ist nicht in den Faltblattkern integriert, sondern als Plugin verfügbar - https://github.com/yohanboniface/Leaflet.i18n

@mourner , @IvanSanchez und andere wichtige Mitwirkende, würden Sie in Betracht ziehen, ein Label "Barrierefreiheit" für Probleme in diesem Repo hinzuzufügen? Wenn Sie der Meinung sind, dass dies nicht sehr hilfreich ist, um Probleme im Auge zu behalten, bitte ich Sie dennoch, dies zu berücksichtigen, da dies meiner Meinung nach die Community dazu ermutigt, über Barrierefreiheit nachzudenken.

@ Malvoz
Erledigt

Danke @ johnd0e , das ist großartig. Die folgenden offenen Fragen beziehen sich auf die Barrierefreiheit und können dieselbe Bezeichnung haben:

1. https://github.com/Leaflet/Leaflet/issues/7211
2. https://github.com/Leaflet/Leaflet/issues/7193
3. https://github.com/Leaflet/Leaflet/issues/7192
4. https://github.com/Leaflet/Leaflet/issues/6821
5. https://github.com/Leaflet/Leaflet/issues/6742
6. https://github.com/Leaflet/Leaflet/issues/3472
7. https://github.com/Leaflet/Leaflet/issues/2199