Accessibility/Barrierefreiheit. Landmarks und roles. 2 Verständnisfragen.

  • 1.) Ich habe in einer Seite ein Modul außerhalb anderer Landmarks mit einem Toggler-Button, der eine Liste von klickbaren, internen Seitenlinks öffnet. So in der Art:

    Code
    1. <div class="umgebender-container">
    2. <button class="...">
    3. Ich öffne den Collapse-Bereich mit der Seiten-Links-Liste
    4. </button>
    5. <div class="collapse-bereich">
    6. Anker-Link-Liste
    7. </div>
    8. </div>

    Das ist alles soweit korrekt ausgezeichnet mit A11Y-Kram, zumindest so, dass ich in AXE keine Reklamationen sehe.


    Außer "All page content must be contained by landmarks".


    Frage für mich ist jetzt, ob ein role="navigation" für den umgebenden Container korrekt ist (weil das für mein Spoiler-JLayout das einfachste wäre). Ich bin einfach unsicher des Toggle-Buttons wegen, der dann innerhalb wäre.


    Die 2. Vielleicht-Option wäre ein <nav> statt <div>. Aber letztlich stellt sich mir da die selbe Frage.


    2.)

    Ich habe im oberen Teil des HTML einen Button, der ein Modal-PopUp öffnet. Das jeweilige Modal-HTML befindet sich am Ende der Seite vor dem schließenden BODY.

    Dem Modal-Bereich habe ich jetzt aus Verlegenheit ein role="dialog" gegeben. Vielleicht ja richtig. Zumindest habe ich vorerst nichts besseres gefunden.

    Das Modal enthält sowohl Teilen-Knöpfe als auch ein Suchfeld, also "diversen Inhalt".


    Jetzt muss ich noch was landmark-mäßiges finden für den abgetrennten <button>-Bereich oben, der ja auch als aria-label (aria-labelledby) für das Modal fungiert. Kann ich also nicht plump für Screen-Reader verstecken, die vermutlich(?) nur das Modal-HTML benötigen.


    Blick ich also nicht mehr durch...

  • Leider nicht. Buttons im Modal, also innerhalb des aufgegangenen PopUps sind alle soweit OK.


    Aber ich weiß bei 1) nicht, ob man dem äußersten DIV

    <div class="umgebender-container">

    , der sowohl den Button zum Öffnen des Modals enthält als auch das Modal-HTML selbst

    ein role="navigation" bekommen kann oder nur der

    <div class="collapse-bereich">

    Ob das eine oder andere eher zu Konfusion führen kann oder komplett egal, so lange der Button und Modal erzählen, dass sie zusammengehören. Der eine klappt die Navigation auf. Der andere ist die Navigation.



    Ich blick da eh überhaupt nicht mehr durch. Eigentlich ist der Modal-Inhalt ja sowieso als HTML in der Seite vorhanden, halt nur erst mal versteckt für sehende Besucher. Aber einem Screen Reader sollte das ja eigentlich wurst sein. oder muss man da auch erst den Button "klicken", damit der versteckte Inhalt vorgelesen wird? Aber das ist dann schon wieder eine neue Frage.

  • Diese Meldung "All page content must be contained by landmarks" kannst du ignorieren, wenn sie sich auf die gesamte Seite bezieht (das <html ).

    Ich habe noch nie eine Seite gefunden, bei der AXE diese Meldung nicht ausgibt.


    Teste die Seite mal mit https://wave.webaim.org/ ob es da auch angemosert wird.


    Meines Wissens ist es so: <nav liegt direkt um die Menüpunkte herum, ohne den öffneneden Button,
    Der Button liegt ausserhalb und sagt mittels aria-attribute dass er das modal kontrolliert.

    Er gibt mittels aria-expandend="true" or "false" an, ob das modal sichtbar ist oder nicht. Je nachdem liest der Screenreader es vor oder auch nicht.


    Wenn du bei diesen Themen 5 Leute fragst, bekommst du 10 Antworten und eine Zillion von Links. Ich habe mir den kostenfreien Screenreader NVDA installiert und schaue was der sagt. Was ich fürchterlich nervig finde, aber manchmal muss es eben sein wenn kein blinder Tester da ist.

  • Frage für mich ist jetzt, ob ein role="navigation" für den umgebenden Container korrekt ist (weil das für mein Spoiler-JLayout das einfachste wäre). Ich bin einfach unsicher des Toggle-Buttons wegen, der dann innerhalb wäre.

    Frage 1.) beantworte ich mir jetzt erst mal mit Ja, aber nur deswegen, weil ich das öfters auf anderen Seiten so sehe. Da weiß man zwar dann nicht gewiss, weil es ja offensichtlich viele Missverständnisse in dem Bereich gibt, aber erst mal OK.


    Und bzgl. Teilfrage in 2.) vergrößerst sich meine Wirrnis weiter.

    Jetzt muss ich noch was landmark-mäßiges finden für den abgetrennten <button>-Bereich oben, der ja auch als aria-label (aria-labelledby) für das Modal fungiert. Kann ich also nicht plump für Screen-Reader verstecken, die vermutlich(?) nur das Modal-HTML benötigen.

    Im Cassiopaia finde ich nämlich für einen Menü-Toggler-Button:

    PHP
    1. <button class="..." type="button" aria-hidden="true" data-toggle="collapse" data-target="#navbar" aria-controls="navbar" aria-expanded="false" aria-label="<?php echo Text::_('TPL_CASSIOPEIA_TOGGLE'); ?>">

    Also einerseits ein "Versteck mich für Screenreader"

    Code
    1. aria-hidden="true"

    Auf der anderen Seite zahlreiche "aria-" Auszeichnungen für Screenreader. Was nun, "hidden" oder doch nicht? ;-)

  • Das Cassiopeia habe ich noch nie angeschaut, kann also nicht sagen wie das da ist.

    So aus dem Stand halte ich das aria-hidden="true" in deinem Zitat für falsch. Der Button muss da und für screenreader sichtbar sein. Wenn ein icon zur Dekoration auf dem Button drauf ist, dann kannst du das per aria-hidden="true" verstecken.

  • PR done :-)


    bestätige (nach check der index.php):

    PHP
    1. <button class="navbar-toggler navbar-toggler-right" type="button" data-toggle="collapse" data-target="#navbar" aria-controls="navbar" aria-expanded="false" aria-label="<?php echo Text::_('TPL_CASSIOPEIA_TOGGLE'); ?>">
    2. <span class="fa fa-bars" aria-hidden="true"></span>

    OT: ach, das Cassiodingens brachte mir schon zusätzliche graue Haare. Mittlerweile 2 in den Sand gesteckt. Obiger PR auf einer (neuen) 4.0.0-beta1-dev

    Liebe Grüße

    Christine

  • Zitat

    Sorry, wenn ich hier zum Alleinunterhalter werde bei der Lösungsfindung und ständig weitere Fragen nachreiche ;-) Mag ich ja ansonsten gar nicht:

    Ich bin froh wenn jemand sich dafür interessiert - meistenst bin ich da Alleinunterhalter.


    Guter PR :)


    Für mich stellt sich das so dar dass es bei dem Thema a11y einige (viele) einleuchtende und umittelbar nachvollziehbare Regeln und Konstrukte gibt.

    Aber gerade bei landmarks und roles sind sind sich nicht mal größten Gurus immer einig. Ein ähnliches Kapitel sind title-Attribute. Wann muss, wann darf nicht, wann ist es egal, darüber wurde im Backend Template lang und breit diskutiert, bis eine Lösung gefunden war, mit der dann alle leben konnten.

    Das backend Template "atum" ist jetzt eine recht gute Basis - es ist screenreader getestet und von a11 Gurus beäugt. Daran kann man sich gut orientieren. Auch wenn es andere Lösungsmöglichkeiten gibt, natürlich..

  • Teste die Seite mal mit https://wave.webaim.org/ ob es da auch angemosert wird.

    Nein. Das Ergebnis sieht für einen Anfänger-Versuch eh ganz akzeptabel aus, auch, wenn mein ehemals Orange jetzt ein hässliches Braun ist, der Kontratse wegen ;-)


    webaim widerspricht an anderer Stelle eigentlich meiner GitHub-PR-Logik. Es gibt einen toTop-Button mit aria-hidden, der keinen Inhalt hat, da er mit CSS befüllt wird. Der wird mir als Fehler angezeigt, weil leer. Bekommt er dann ein aria-label, ist er OK. Soll mir recht sein ;-)