Komplizierte Navigation *grumpf*
einsiedler
- css
- javascript
Hallo liebe Forumer, ich benötige nocheinmal eure Unterstützung: Wie ihr hier seht komme und komme ich einfach mit meiner Navigation nicht weiter. Ich habe alles auf Papier durchgespielt aber mein Hirn hat sich inzwischen so verknotet das es nicht mehr will. Sicherlich gibt es eine (sehr) einfache Lösung (warscheinlich das!). Deshalb benötige ich eure Hilfe!
Ersteinmal die Basics, hier mein html:
<div class="contentspan">
<a class="anzume" href="#main-nav">zum Hauptmenü</a>
<nav id="main-nav">
<ul class="tree" role="tree" aria-labelledby="main-nav">
<li role="treeitem">
<button aria-hidden="true" aria-expanded="true" class="treeitemmain"><span class="visually-hidden">HauptNavigation</span></button>
<ul class="group" role="group">
<li role="treeitem">
<a class="a-link" href="http://www.example.com/aktuell.html">Aktuelles</a>
<button aria-hidden="true" aria-expanded="true" class="treeitem"><span class="visually-hidden">SubNavigation Item 1</span></button>
<div class="nav-group" role="group">
<a class="a-sublink" href="http://www.example.com" role="treeitem">aktuelle Ausstellungen</a>
</div>
</li>
<li role="treeitem">
<a class="a-link" href="http://www.example.com/arbeiten.html">Arbeiten</a>
<button aria-hidden="true" aria-expanded="true" class="treeitem"><span class="visually-hidden">SubNavigation Item 2</span></button>
<div class="nav-group" role="group">
<a class="a-sublink" href="http://www.example.com" role="treeitem">Drifters, 2012</a>
<a class="a-sublink" href="http://www.example.com" role="treeitem">Waldfrieden, 2006</a>
</div>
</li>
<li role="treeitem">
<a class="a-link" href="http://www.example.com/cv.html">Curriculum Vitae</a>
<button aria-hidden="true" aria-expanded="true" class="treeitem"><span class="visually-hidden">SubNavigation Item 3</span></button>
<div class="nav-group" role="group">
<a class="a-sublink" href="http://www.example.com" role="treeitem">Lebenslauf</a>
<a class="a-sublink" href="http://www.example.com" role="treeitem">Studium & Stipendien</a>
</div>
</li>
</ul>
</li>
</ul>
</nav>
</div>
Nun das CSS und ich gehe hier vom Standpunkt aus, das alle scripte deaktiviert sind:
[aria-hidden="true"] {display: none!important;}
.hidden {display: none!important;}
ul.group {hier: alles nötige das das sichtbar ist}
div.nav-group {hier: alles nötige das das sichtbar ist}
Bottons:
button.treeitemmain > aria-hidden="true" {display: none;}
button.treeitem > aria-hidden="true" {display: none;}
Bedeutet einfach nur: Wenn java-script aus, dann werden alle Menüpunkte (also ul.group & div.nav-group) angezeigt + die Bottons (Sandwich + von den Untermenüs) verschwinden, da sie ja nicht gebraucht werden.
So weit so geschmeidig:
weiter gehts:
Nächster Fall: java-script an & großer Bildschirm
Der Botton (Sandwich): button.treeitemmain > aria-hidden="true" {display: none;} ist also immer noch nicht sichtbar, gut so, soll so sein (wird hier ja auch nicht gebraucht!).
Nun aber müssen/sollen die Unternavigationspunkte von div.nav-group nicht mehr angezeigt werden, die kann man ja bei Interesse öffnen/schließen.
So, mit großen Bildschirm meine ich einen Bereich größer als 1400px + .
Nun aber wenn das Bildschirmfenster kleiner, zusammengezogen wird, also < 1400px ist
Dann soll der Sandwich-Botton sichtbar sein & ul.group mit den Untermenüpunkten unsichtbar
Wenn botton.treeitemmain + aria-hidden="true" ist soll es zu botton.treeitemmain + aria-hidden="false" werden Also wird hier das Sandwich angezeigt und nicht das Kreuz & somit NICHT die Untermenüpunkte
Das müsste irgendwie mit java-script geschehen, das aus aria-hidden="true" aria-hidden="false" wird.
Bisher habe ich ein ganz einfaches script:
<script>
function globalClickManager(ev){
// ev.target gibt uns das Element auf dem der Click geschah.
// steuere expanded Buttons
if(ev.target.hasAttribute("aria-expanded") ){
ev.target.setAttribute("aria-expanded", ( ev.target.getAttribute("aria-expanded") == "false") );
}
// Buttons die lediglich den Click transferieren ähnlich zu label Elementen
else if(ev.target.hasAttribute("data-for-id") ){
document.getElementById( ev.target.getAttribute("data-for-id") ).click();
}
else if( Element.prototype.closest){
if( ev.target.closest("nav") == null ){
var temp = document.querySelector("nav > [aria-expanded='true']");
if(temp) temp.setAttribute("aria-expanded","false");
}
}
}
function init(){
var col = document.querySelectorAll("nav > [aria-expanded]");
for(var i=0; i<col.length; i++){
col[i].setAttribute("aria-expanded","false");
}
document.body.addEventListener("click",globalClickManager);
}
document.addEventListener("DOMContentLoaded", init, false);
</script>
Doch ich kenne mich da überhaupt nicht aus mit wo eben dieser Zusatz hinkommt.
Ich weiß inzwischen das man mit breite = Window.innerWidth; die fensterbreite bestimmen kann. Das sollte mit hilfreich sein wegen dieser 1400px Marke.
Doch leider versage ich hier kläglich und ich komme nicht weiter.
Sicherlich gibt es warscheinlich eine ganz einfache Lösung die mir nicht einfällt.
Wer kann mir hier helfen , wenn nötig auch gegen Bezahlung. Ich möchte endlich mal weiterkommen.
Achso, hier eine mit dem einfachen script laufende Version, eine allererste Version, die zeigt wie ich es mir denke: Version A (Ja, ist fehlerhaft, ich weiß!)
Mit der Bitte um Unterstützung,
der einsiedelnde
hallo
Mit der Bitte um Unterstützung,
Kleine Frage: Was hoffst du mit aria-hidden zu kommunizieren?
Weiter: Du willst css für den Fall, dass kein Javascript vorhanden ist. Auch da hast du bereits von mir die Lösung erhalten:
<noscript><link rel="stylesheet" href="nojs.css"></noscript>
Es gibt keinen Grund, das script zu erweitern für Dinge, die du anders lösen sollst.
@@einsiedler
button.treeitemmain > aria-hidden="true" {display: none;} button.treeitem > aria-hidden="true" {display: none;}
Da fehlen eckige Klammern.
Bedeutet einfach nur: Wenn java-script aus, dann werden alle Menüpunkte (also ul.group & div.nav-group) angezeigt + die Bottons (Sandwich + von den Untermenüs) verschwinden, da sie ja nicht gebraucht werden.
Ja, aber warum mit aria-hidden="true"
und dem Umweg über CSS? Dass die Buttons (mit u) nicht gebraucht werden, ist für alle Nutzer so. Dafür ist das hidden
-Attribut da.
([hidden] { display: none !important }
im Stylesheet kann aber trotzdem nicht schaden.)
Nun aber wenn das Bildschirmfenster kleiner, zusammengezogen wird, also < 1400px ist
Dann soll der Sandwich-Botton sichtbar sein & ul.group mit den Untermenüpunkten unsichtbar […]
Das müsste irgendwie mit java-script geschehen, das aus aria-hidden="true" aria-hidden="false" wird.
Nein, warum JavaScript? (ohne Bindestrich, BTW) Das müsste irgendwie mit CSS geschehen – mit media query.
Bisher habe ich ein ganz einfaches script:
if(ev.target.hasAttribute("aria-expanded") ){ ev.target.setAttribute("aria-expanded", ( ev.target.getAttribute("aria-expanded") == "false") );
Das ist auch erst auf den zweiten Blick erkennbar, dass damit zwischen "true"
und "false"
umgeschaltet wird. Einfach geht anders.
LLAP 🖖
Liebe Leute,
es scheint für mich zu schwierig zu sein, daher meine Bitte
WER schreibt mir diese Navigation gegen Bezahlung?
ernstgemeinte Anfragen: Meine Mail gibt es per PN sowie gewünschte weitere Kontaktdaten.
Mein bisheriges html
eine Bebilderung wie ich es mir denke gibt es hier:
als PDF Link zur PDF
mit der Bitte um Unterstützug (soll nicht unentgeltlich sein!)
der einsiedelnde
Hallo einsiedler,
wollte mir das gerade anschauen, Chrome sagt:
index_v1.html:1 - Refused to apply style from 'http://misanthrop.bplaced.net/test/demowebsiteE/css/fonts-css.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
index_v1.html:103 - GET http://misanthrop.bplaced.net/test/demowebsiteE/img/indexseite/wohnsarg_bearbeitet_web.jpg 404 (Not Found)
index_v1.html:1 - Refused to apply style from 'http://misanthrop.bplaced.net/test/demowebsiteE/web-fonts/FontAwesome/5.0.13/css/fontawesome-all.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
index_v1.html:21 - GET http://misanthrop.bplaced.net/test/demowebsiteE/images/svg/esel.svg 404 (Not Found)
Hast Du da was falsch konfiguriert? Die beiden HTTP 404 sind nicht weiter lästig, aber dass Du CSS Dateien als text/html auslieferst, führt in Chrome zu Problemen.
Ich hab's daher mal mit dem Fuchs probiert, was mir wieder Probleme im Firmennetz einträgt weil die im Fuchs das mit den Zertifikaten nicht hinbekommen, aber der labert mich tot mit CSS Fehlern. Eventuell tragen die zu den Problemen bei, die Du hast. Kritisch ist:
flex-shrink::auto
gefunden, Paamayim Nekudotayim gibt's in CSS nicht.Rolf
@@Rolf B
Paamayim Nekudotayim gibt's in CSS nicht.
::before ich das glaube, friert die Hölle zu. 😈
LLAP 🖖
Hallo einsiedler,
bitte entschuldige meine Bemerkung zu ausgedruckten Sourcen. Ich wollte mich nicht lustig machen.
Ich habe mir das jetzt auf tassilosturm.de angeschaut.
Mir fällt auf, dass die Selektoren für die Icons nicht stimmen dürften. In der sturm-main-style.css steht:
.treeitem + [aria-expanded="true"]::before { /* awesome */ }
und ich glaube, das willst Du nicht. Das Pluszeichen ist ein Kombinator (siehe SelfWiki über Kombinatoren], d.h. es gibt an, dass dieser CSS Selektor sich auf zwei HTML Elemente bezieht deren Eigenschaften kombiniert zu betrachten sind.
Im Falle von + ist es der Nachbarkombinator, d.h. dein CSS Selektor sucht ein Element mit Klasse treeitem, das ein Nachbarelement mit [aria-expanded="true"] hat. Für dieses Nachbarelement legst Du dann ein ::before-Pseudoelement fest.
Bei Dir ist es aber so, dass der Button sowohl die Klasse treeitem trägt als auch das aria-expanded-Attribut hat. Und der Button soll das ::before-Pseudoelement bekommen. Du darfst also keinen Kombinator verwenden. Statt dessen musst Du alle Selektorteile direkt aneinander schreiben, auch eine Leerstelle muss vermieden werden (weil die ebenfalls ein Kombinator ist).
Ich weiß aber nicht recht, ob das gut ist. Denn auch deine <li> tragen die treeitem-Klasse. Du musst genau aufpassen, was deine CSS Regeln tun, um keine Verwechslung zwischen li und button-Styling herbeizuführen. Da Du definitiv nur dem button ein ::before verpassen willst, solltest Du zumindest den Selektor um den Elementnamen erweitern (die Alternative wäre, sich nochmal alles anzuschauen und die treeitem-Klasse nur für eine Art von Elementen zu nutzen).
button.treeitem[aria-expanded="true"]::before
Was mir noch auffällt, ist ein Tippfehler in der CSS Datei: treeitemmein vs treeitemmain; offenbar ein ähnlicher Verlautungs-Irrtum wie bei button und botton. Ich weiß nicht, ob ich Dir hier helfen kann, aber vielleicht ist es nützlich, wenn Du Dir die Aussprache genau anhörst: „main“ klingt wie mäin, nicht wie mein, und „button“ klingt wie battn. Die Wörterbuch-Webseite LEO hat auch Tonbeispiele.
Rolf
Danke für Deine ausführliche Exkursion. Es ist so das ich ursprünglich dem <li class"treeitem" role="treeitem"> mitgegeben habe und erst dann die klasse dem button gegeben habe. So ist es wohl entstanden das ich eben den Kombinator + benutzte.
Ich hoffe dann ist: .treeitem + [aria-expanded="true"]::before { /* awesome */ } richtig oder?
Wenn ich das jetzt doch noch ändere, ich weiß nicht was besser wäre.
Habe dem Button die Klasse gegeben um besser darauf zuzugreifen, was villeicht Unsinn ist.
Hallo einsiedler,
im Moment sehe ich in der Browser-Konsole:
(index):166 Uncaught ReferenceError: init is not defined
Das ist die Registrierung des DOMContentLoaded Events, er findet keine Funktion namens init
.
Ich hoffe dann ist: .treeitem + [aria-expanded="true"]::before { /* awesome */ } richtig oder?
Deine CSS Selektoren müssen einfach zu deinem Markup passen. Der richtige Einsatz oder Nichteinsatz von Kombinatoren ergibt sich daraus automatisch. Du guckst Dein Markup an, und musst eine Kette von Bedingungen aufstellen, wie Du die Elemente, die du stylen willst, eindeutig beschreibst. Letztlich schreibst Du dem Browser eine "Wegbeschreibung".
Im Fall von .treeitemmain hast Du es (fast) richtig gemacht. Das Markup sieht so aus:
<li role="treeitem">
<button class="treeitemmain hidden" aria-expanded="true"><span class="visually-hidden">HauptNavigation</span></button>
<ul class="group" role="group">
<li role="treeitem">...</li>
<li role="treeitem">...</li>
<li role="treeitem">...</li>
</ul>
</li>
Was hier nur fast richtig ist, ist die Einrückung. Das <ul> ist gegenüber dem <button> eingerückt und erweckt damit den Eindruck, Child-Element des Buttons zu sein. Ist es aber nicht. Nimm diese <ul> Gruppe besser einen Tab-Schritt zurück.
In deinem CSS steht:
.treeitemmain[aria-expanded="false"] + ul.group
Das sagt dem Browser: Suche nach einem Element mit Klasse treeitemmain und dem Attribut aria-expanded="false". Suche für dieses Element einen "rechten Nachbarn" (also: ein Element, das in der Child-Liste des Elternelements nachfolgt), der ein ul-Element mit Klasse group
ist. Das passt, der Button mit treeitemmain und das ul Element sind Nachbarn.
Das hier:
.treeitem + [aria-expanded="true"]::before
wäre falsch, weil Du ja nicht dem Nachbarn des .treeitem ein ::before-Element verpassen willst, sondern dem Tree-Item selbst. Deswegen ist es richtig, dass Du in deinem aktuellen Code das + und die Leerstellen entfernt hast.
Rolf
Danke für Deine ausführlichen Erläuterungen [Bewertung +1] Ich habe jetzt mal die letzte Zeile des javascriptes also: document.addEventListener("DOMContentLoaded", init, false); ebenfalls gelöscht, weil die ist ja unnsinnig , denn die gehörte ja zur function init(){} die es so nicht mehr gab. Also weg damit. Und nun sind keine Fehler mehr in der Console.
Davor, im Quelltext habe ich ja noch ein <script></script> das ich jetzt auch mal lösche, weil unnötig. Wie schon oft hier angedeutet guck ich mal ob mir media-queries weiterhelfen bei der "Steuerung" der Buttons und deren "öffnen & schliessens" deren Inhaltes. Villeicht geht es ja so einfach.
Auch wenn ich es komisch finde wenn zum Beispiel etwas aria-expandet="true" ist und mache es "unsichtbar" mit display:none; , also genau das Gegenteil davon.
Und ja, jetzt muss ich ganz genau auf die Selektoren achten, wie ich nun auf was zugreife.
PUUUUHHHH…
der einsiedelnde
Hej einsiedler,
es scheint für mich zu schwierig zu sein,
Mach es dir doch einfacher. Eine Navigation ist keine Sitemap. Die sollte du zusätzlich anbieten. Wenn du nicht auf allen Seiten jede Seite verlinkst, wird dein HTML deutlich schlanker.
Das heißt: biete die Unterpunkte erst an, wenn man auf einen Oberpunkt geklickt hat. Dann ist man auf der angeklickten Seite und sieht, welche anderen Seiten dazu gehören. Das gute alte Menü von vor 10 Jahren. Funktioniert prima und versteht jeder.
Geht ganz ohne CSS und ohne JavaScript, nur über HTML.
Bei schmalen Viewports setzt du das Menü an das Seitenende und bietest ein Hamburger-Icon oder so an, das mit der Hauptnav verlinkt ist.
Das ganze braucht eine Überschrift "Hauptnavigation" (mindestens h2) - das in einem Button zu verstecken reicht nicht.
Marc
@@marctrix
Das ganze braucht eine Überschrift "Hauptnavigation" (mindestens h2)
Braucht es das? Ist nicht Konsens, dass eine Navigation nur dann eine Überschrift oder ein anderes accessible label braucht, wenn es mehrere davon auf der Seite gibt?
Wieso „mindestens“? Ist nicht Konsens, dass es nur eine h1
pro Seite geben sollte und das die Seitenüberschrift ist (und nicht die Bezeichnung der Website)?
Hm, wie soll das dann aussehen?
<body>
<header>
<a href="#main">zum Hauptinhalt</a>
<p>Journal für die Katz</p>
<nav>
<h2>Hauptnavigation</h2>
<ul>…</ul>
</nav>
</header>
<main id="main">
<h1>Katzenbilderflut – rette sich wer kann!</h1>
<p>…</p>
</main>
<footer>…</footer>
</body>
Die Überschrift 2. Ordnung „Hauptnavigation“ hat keine übergeordnete Überschrift 1. Ordnung – komische Dokument-Outline, das.
Wie kommt man aus der Nummer raus? So?
<nav aria-labelledby="nav-label">
<p id="nav-label">Hauptnavigation</p>
<ul>…</ul>
</nav>
So?
<nav aria-label="Hauptnavigation">
<ul>…</ul>
</nav>
LLAP 🖖
@@Gunnar Bittersmann
<body> <header> <a href="#main">zum Hauptinhalt</a> <p>Journal für die Katz</p> <nav> <h2>Hauptnavigation</h2> <ul>…</ul> </nav> </header> <main id="main"> <h1>Katzenbilderflut – rette sich wer kann!</h1> <p>…</p> </main> <footer>…</footer> </body>
Die Überschrift 2. Ordnung „Hauptnavigation“ hat keine übergeordnete Überschrift 1. Ordnung – komische Dokument-Outline, das.
Hm, Web Accessibility Tutorials » Page Structure » Headings » Example 2: Main heading after navigation sagt, das wäre OK so.
LLAP 🖖
Hej Gunnar,
<body> <header> <a href="#main">zum Hauptinhalt</a> <p>Journal für die Katz</p> <nav> <h2>Hauptnavigation</h2> <ul>…</ul> </nav> </header> <main id="main"> <h1>Katzenbilderflut – rette sich wer kann!</h1> <p>…</p> </main> <footer>…</footer> </body>
Die Überschrift 2. Ordnung „Hauptnavigation“ hat keine übergeordnete Überschrift 1. Ordnung – komische Dokument-Outline, das.
Hm, Web Accessibility Tutorials » Page Structure » Headings » Example 2: Main heading after navigation sagt, das wäre OK so.
Ja, habe das auch schon beim w3c gefunden, mag das selber aber nicht. Aus SEO- und anderen Gründen, gehe ich aber mehr und mehr dazu über, das auch so zu machen.
Gefordert ist letztendlich eine nachvollziehbare Überschriftenstruktur. Ich persönlich fände es komisch, eine Seite ohne CSS zu betrachten und nicht oben erst einmal die größte Überschrift zu finden.
Aber vielleicht bin ich nur ein komischer Typ — jedenfalls bin ich kein Dogmatiker und will ja auch immer noch besser werden…
Marc
Hej Gunnar,
Das ganze braucht eine Überschrift "Hauptnavigation" (mindestens h2)
Braucht es das? Ist nicht Konsens, dass eine Navigation nur dann eine Überschrift oder ein anderes accessible label braucht, wenn es mehrere davon auf der Seite gibt?
Nein. Nicht einmal unter uns beiden.
Wieso „mindestens“? Ist nicht Konsens, dass es nur eine
h1
pro Seite geben sollte und das die Seitenüberschrift ist (und nicht die Bezeichnung der Website)?
Nein, das wünschen sich nur Blinde, weil sie sich nicht darauf verlassen können, dass der Hauptinhalt einer Website korrekt ausgezeichnet ist. Dieser lässt sich mit dem Screenreader bequem mit der Taste "M" (für engl. main) anspringen.
Sie sollten das fordern!
Die Überschrift 2. Ordnung „Hauptnavigation“ hat keine übergeordnete Überschrift 1. Ordnung – komische Dokument-Outline, das.
Eben. In diesem Fall wäre h1 angebracht. Daher mindestens h2
.
Meine Seiten beginnen daher meist mit einer h1
, die den Namen des Angebotes enthält. Die Überschriften danach sind dann h2
und überschreiben die einzelnen Bereiche der Seite. Diese lauten meist "Hauptnavigation", Überschrift des Hauptbereiches (oft identisch mit dem Inhalt des title
-Elementes), "Weiterführende Informationen" usw
Seit 15 Jahren bestehe ich damit jeden BITV- und WCAG-Compliance Test. Entgegen des von dir angenommenen Konsens. Inclusives Design ist eben kein Design für Blinde.
Insbesondere die Blindenverbände sind lange Jahre dadurch aufgefallen, Menschen mit allen möglichen Behinderungen und teilweise sogar Normalsichtige durch ihre schlecht gemachten Sites von der Nutzung Ihrer Angebote auszuschließen.
Wir sollten das nicht nachmachen.
Wie kommt man aus der Nummer raus? So?
<nav aria-labelledby="nav-label"> <p id="nav-label">Hauptnavigation</p> <ul>…</ul> </nav>
Das aria-labelledby
kannst du dir sprane, wenn du eine h2
einsetzt. Das verstehen auch Menschen, die keinen Screenreader zur Verfügung haben und Bereich sollten überschrieben werden. Das ist der Sinn von HTML. Damit wird die Struktur einer Webseite wiedergeben. Und eine Website besteht nun mal (in aller Regel) nicht nur aus einem einzelnen Artikel, sondern aus einer Hauptnavigation, aus weiterführenden Informationen, aus Informationen über den Seitenbetreiber. Ich möchte auch als Blinder diese Struktur finden und beispielsweise auch dann schnell das Impressum finden, wenn das nicht in der Hauptnavigation ist.
Und gerade wenn man blind ist, ist eine nachvollziehbare Überschriftenstruktur eine gute (wenn nicht die beste) Hilfe, um den Aufbau einer Seite nachvollziehen zu können.
<nav aria-label="Hauptnavigation"> <ul>…</ul> </nav>
Betrachte das mal als Sehender bei abgeschaltetem oder eigenem CSS… 😉
Marc
@@marctrix
<nav aria-label="Hauptnavigation"> <ul>…</ul> </nav>
Betrachte das mal als Sehender bei abgeschaltetem oder eigenem CSS… 😉
Wer mit eigenem CSS was kaputtmachen will, der soll das tun dürfen; sich aber dann nicht beschweren, dass es kaputt ist.
Bei abgeschaltetem CSS sehe ich eine Liste von Links. Brauche ich da wirklich eine Überschrift, dass das eine Navigation ist? Vermutlich nicht.
Bei eingeschaltetem (und übertragenem) CSS will ich ganz bestimmt keine Überschrift für die Navigation haben; die würde das UI nur vollmüllen. Die Navigation hebt sich durch die visuelle Gestaltung vom Hauptinhalt ab.
Also wenn Überschrift, dann so in der Art:
<nav>
<h2 class="visually-hidden">Hauptnavigation</h2>
<ul>…</ul>
</nav>
LLAP 🖖
Hej Gunnar,
<nav aria-label="Hauptnavigation"> <ul>…</ul> </nav>
Betrachte das mal als Sehender bei abgeschaltetem oder eigenem CSS… 😉
Wer mit eigenem CSS was kaputtmachen will, der soll das tun dürfen; sich aber dann nicht beschweren, dass es kaputt ist.
Ein Aspekt der Barrierefreiheit ist Anpassbarkeit an eigene Bedürfnisse…
Bei abgeschaltetem CSS sehe ich eine Liste von Links. Brauche ich da wirklich eine Überschrift, dass das eine Navigation ist? Vermutlich nicht.
Wer suchet der findet. Mit Überschrift wäre es aber besser (bitte CSS abschalten).
Bei eingeschaltetem (und übertragenem) CSS will ich ganz bestimmt keine Überschrift für die Navigation haben; die würde das UI nur vollmüllen. Die Navigation hebt sich durch die visuelle Gestaltung vom Hauptinhalt ab.
Also wenn Überschrift, dann so in der Art:
<nav> <h2 class="visually-hidden">Hauptnavigation</h2> <ul>…</ul> </nav>
Genau das! Und nicht (wie Bootstrap das macht) mit einer Klasse sr-only
- diese Hinweise sind nämlich sehr oft hilfreich bei abgeschaltetem CSS - nicht nur für Screenreader-Nutzer, sondern auch für Nutzer der Braille-Zeile, für Nutzer ohne Maus (visually Hidden aber Focus able) uswusf - Am Namen sr-only
erkennt der Fachmann schon, dass BF hier nicht zu Ende gedacht wurde, weil (nochmal): Accessibility ist nicht Design für Blinde…
Marc
@@marctrix
<nav> <h2 class="visually-hidden">Hauptnavigation</h2> <ul>…</ul> </nav>
Genau das! Und nicht (wie Bootstrap das macht) mit einer Klasse
sr-only
- diese Hinweise sind nämlich sehr oft hilfreich bei abgeschaltetem CSS - nicht nur für Screenreader-Nutzer, sondern auch für Nutzer der Braille-Zeile, für Nutzer ohne Maus (visually Hidden aber Focus able) uswusf - Am Namensr-only
erkennt der Fachmann schon, dass BF hier nicht zu Ende gedacht wurde, weil (nochmal): Accessibility ist nicht Design für Blinde…
??
Was genau hast du gegen sr-only
– außer der Benennung?
Ein kurzer Blick ins bootstrap.css offenbart, dass
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
.sr-only-focusable:active, .sr-only-focusable:focus {
position: static;
width: auto;
height: auto;
overflow: visible;
clip: auto;
white-space: normal;
}
dasselbe tut wie das, was beim A11Y Project visually-hidden
heißt:
.visually-hidden { /* https://snook.ca/archives/html_and_css/hiding-content-for-accessibility */
position: absolute !important;
height: 1px; width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}
.visually-hidden a:focus,
.visually-hidden input:focus,
.visually-hidden button:focus {
position:static;
width:auto; height:auto;
}
LLAP 🖖
Hej Gunnar,
Was genau hast du gegen
sr-only
– außer der Benennung?Ein kurzer Blick ins bootstrap.css offenbart, dass dasselbe tut wie das, was beim A11Y Project
visually-hidden
heißt:
Nomen est omen — mir scheint bei Bootstrap hat man den Code in der Meinung übernommen, damit werden Hinweise ausgezeichnet, die man nur braucht, wenn man einen Screenreader nutzt. Das ist auch die Botschaft, die an Bootstrap-Entwickler gesendet wird. Eine falsche Botschaft.
Denn mit dieser Technik sollten nur solches verborgen werden, was Sehende nicht benötigen, weil eine Navigation als Navigation beispielsweise dadurch erkennbar ist, Wass sie sich an einer erwarteten Stelle befindet und ein bestimmtes Aussehen hat.
Fällt das weg (z.B. wegen eigenem CSS), wird es auch schwerer die Navigation (schnell und zweifelsfrei) zu identifizieren. Dann werden die Bereichsüberschriften benötigt. Noch deutlicher bei der Überschrift "Weiterführende Informationen" — wenn diese nicht grafisch vom Hauptinhalt abgesetzt, aber korrekt ausgezeichnet sind, brauchen hier der Sehende mit eigenem CSS plötzlich mehr Unterstützung als Blinde. Denn wenn das HTML-Dokument korrekt ausgezeichnet ist, befinden sich diese Inhalte ja nicht mehr im main
-Element, was der Screenreader anzeigt. Für Screenreader sind die Überschriften dennoch sinnvoll, da der Screenreader-Nutzer diese für die Navigation nutzen und die Hierarchie des Dokumentes erkennen kann.
Für den Sehenden ist ohne CSS aber bei den normalerweise direkt auf den Haupttext folgenden weiterführenden Informationen überhaupt nicht erkennbar, wo diese beginnen. Wenn nicht eine klare Überschrift das anzeigt, folgt Fließtext auf Fließtext und erscheint so als zusammengehörig.
Marc