core-bundle icon indicating copy to clipboard operation
core-bundle copied to clipboard

Published 20 hours ago • verified publisher icon contao

Landmarks für das Contao-Backend

Open NinaG opened this issue 7 years ago • 12 comments

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

Hier die Vorschläge für einige grundlegende Landmarks im Contao-Backend, damit es für sehbehinderte und blinde Nutzer via Screenreader besser erfassbar wird:

  • [x] <ul id="tmenu" role="navigation" aria-label="Service-Navigation">
  • [x] <nav id="tl_navigation" role="navigation" aria-label="Navigation">
  • [x] <div id="main" role="main" aria-label="Hauptbereich">

Über die genauen Benennungen könnten wir sicher noch sprechen. :)

NinaG avatar Apr 19 '17 07:04 NinaG

Noch ein Nachtrag: Wenn wir die Sache mit den Landmarks ordentlich machen, können wir uns imho in der left-Spalte den unsichtbaren Sprunglink sparen.

NinaG avatar Apr 20 '17 08:04 NinaG

Wie in Ticket #769 beschrieben, benötigen Nutzer von assistiven Technologien wie z.B. Screenreader, eine einfache Möglichkeit um im Hauptbereich die Leiste mit den Filtern, Suchen etc. zu überspringen, wenn sie direkt zum eigentlichen Inhalt gelangen wollen.

Wie im anderen Ticket erwähnt, habe ich dazu mit diversen anderen Barrierefreiheit-Experten (u.a. Eric Eggert, Marco Zehe etc.) gesprochen und diskutiert, was die besten Wege wären um das zu erreichen.

Das ist das Ergebnis:

  • Der gesamte Hauptbereich erhält wie eingangs beschrieben die Rolle "main" und wird via aria-labelledby mit der H1 verknüpft.
  • Die gesamte Leiste mit Suche / Filter etc. erhält die Rolle "search" und ein aussagekräftiges aria-label zur Beschriftung
  • Der eigentliche Inhalt wird als Section mit ID + aussagekräftigem aria-label versehen

Am Beispiel der Artikelübersicht im Contao-Backend:

<div id="main" role="main" aria-labelledby="main_headline">
  <h1 id="main_headline">Hauptüberschrift je nach Bereich</h1>
  <a href="#tl_content" class="invisible focusable">Zum Hauptinhalt</a>

  <form action="..." class="tl_form" method="post" role="search" aria-label="Filter- und Suchfunktionen">
  …
  </form>
  <section id="tl_content" aria-label="Hauptinhalt">
    <div id="tl_buttons">
    …
    </div>
    <div id="tl_listing" class="tl_listing_container tree_view">
    …
    </div>
  </section>
</div>

Ich habe für den Sprunglink die Klassenkombination "invisible focusable" genutzt, die u.a Sprunglinks visuell unsichtbar macht, aber fokusierbar, sobald mit der Tastatur navigiert wird (siehe: https://www.w3.org/WAI/tutorials/fundamentals/hiding/). Wir setzen in Contao schon die Klasse invisible ein (identisch mit der Klasse visuallyhidden aus dem Beispiel), müssten dafür aber noch ergänzend die Klasse focusable im CSS hinzufügen.

https://www.w3.org/TR/wai-aria/roles#search https://www.w3.org/TR/wai-aria/roles#section

NinaG avatar Apr 26 '17 08:04 NinaG

Erledigt sich dieses Ticket durch #868 und #869?

leofeyer avatar Jul 17 '17 13:07 leofeyer

Nein, das erledigt sich nicht. Hier werden die primären Bereiche gekennzeichnet, in den anderen Tickets dazu ergänzend die Nav.

NinaG avatar Jul 19 '17 13:07 NinaG

Sehe ich es richtig, dass wir dann die #skipNavigation-Links entfernen können?

@ausi @aschempp /cc

leofeyer avatar Sep 11 '17 19:09 leofeyer

Ich denke Skip-Links sind nach wie vor wichtig für die Barrierefreiheit, sieh z. B. https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html.

Allerdings könnte es sinnvoll sein ganz am Anfang der Seite einen „zum Inhalt springen“-Link zu haben anstatt vor jeder Navigation einen Navigations-Skip-Link. Ich denke das wäre die empfohlene Herangehensweise der WCAG.

ausi avatar Sep 12 '17 06:09 ausi

Wenn wir die Inhalte ordentlich semantisch auszeichnen, Landmarks richtig einsetzen, mit Überschriften arbeiten etc., würde ich Skiplinks nur noch sehr punktuell einsetzen. Die klassischen Skiplinks am Seitenanfang machen weiterhin Sinn. Ständige Skiplinks bei jeder einzelnen Navigation sind imho nicht mehr nötig, wenn der Rest korrekt gemacht ist.

NinaG avatar Sep 12 '17 07:09 NinaG

Nur bei langen Navigationen ist ein Skiplink immer noch angeraten. Von daher wäre so ein Skiplink für die Hauptnavigation im Linken Bereich immer noch angeraten finde ich. Bei allen anderen Stellen könnte man sich das dann sparen (Wobei die jetzt auch nicht schaden, wenn die eh einmal da sind).

MacKP avatar Nov 22 '17 15:11 MacKP

Hier mal ein Zwischenstand:

  • Service-Navigation Ist implementiert, allerdings bräuchten wir ein besseres Label.

  • Hauptnavigation Das ist in der 4.5.0-beta2 bereits drin.

  • Hauptbereich Ist implementiert.

  • Rolle "search" Das soll man bei <form> nicht verwenden und außerdem sollte es nur für die tatsächliche Suche und nicht für Filter etc. verwendet werden?

  • Inhalt als Section mit ID Das ist aktuell das größte Problem, denn um den Sprunglink direkt nach der <h1> haben zu können, muss ich ihn direkt im Template be_main.html5 einfügen. Allerdings kann <?= $this-main ?> alles mögliche sein und muss das Zielelement des Sprunglinks nicht zwangsläufig enthalten. In vielen Fällen würde der Sprunglink dann ins Leere führen, was schlechter ist als gar keinen Sprunglink zu haben, oder?

leofeyer avatar Nov 28 '17 08:11 leofeyer

Ich habe den unproblematischen Teil in bd46cafca7c2fe826aa9323b1db8ca2e73c8bac9 implementiert.

leofeyer avatar Nov 28 '17 10:11 leofeyer

Kommt da noch ein Feedback zu den offenen Fragen (siehe meinen Kommentar vom 28. November 2017)?

leofeyer avatar Mar 19 '18 16:03 leofeyer

Oh, sorry... ich schaffe gerade leider nur drüber schauen. Soweit ich die Implementierung lesen kann sieht das schon mal gut aus. Eventuell hat @NinaG etwas mehr Zeit sich das auch richtig im Backend anzuschauen?

MacKP avatar Mar 19 '18 19:03 MacKP