Archiv der Kategorie: HTML

Akkordion: barrierfrei, notfalls mit Javascript

Besonders bei One-Page-Layouts werden heute gerne Akkordeons eingesetzt, also aufklappbare Elemente, deren Inhalt zunächst nicht sichtbar ist und erst durch einen Klick auf das Überschrifts-Element eingeblendet wird. Dies ist in HTML5 mit dem details-Element ganz einfach realisierbar. Es ist in allen unterstützten Browsern zugänglich, d.h. auch mit der Tastatur zu öffnen und zu schließen:

 

 

Klapp mich auf:

Das neue details-Element ermöglicht es, ganz ohne den Einsatz von JavaScript, ursprünglich verborgene Textinhalte aufzuklappen.

 

 

 

Der Pferdefuß dabei: vom IE und von älteren Firefox-Versionen wird das details-Element noch nicht unterstützt.

Und noch etwas: der Inhalt des Elements ist natürlich nicht auf den ersten Blick ersichtlich, es muss erst eine Aktion durch den Benutzer erfolgen, um die versteckten Inhalte einzublenden. Deswegen sollte man es sich gut überlegen, wann und wo man ein Akkordeon sinnvoll einsetzt.

Abhilfe: Javascript, wenns denn unbedingt sein muß

In diesem Artikel bei selfhtml ist der Sourcecode für ein barrierefreies Akkordeon extra für IE und ältere Browser  zu finden, sowie eine genaue Erklärung der Anwendung. Es werden ARIA-Elemente eingesetzt, um das Akkordeon auch für Screenreader etc. bedienbar zu machen. Ich zitiere mal kurz selfhtml:

Das Akkordeon besteht aus Buttons und einem dazugehörenden div. Um diesen Zusammenhang auch für Screenreader klarzustellen, erhalten die Buttons ein aria-controls-Attribut, dass auf die id des dazugehörenden divs verweist. Jeder Button erhält ein aria-expanded-Attribut, dass den jeweils geschalteten Zustand anzeigt, was auch mit CSS sichtbar gemacht wird.

Alles klar? Wenn man also unbedingt für ältere Browser kompatibel bleiben will, setzt man diese Lösung ein.

 

Mein Leib- und Magen-Datenbankerl: Microsoft Access

Ich bin wahrlich kein Microsoft-Fan, aber Microsoft Access ist meiner Ansicht nach das am meisten unterschätzte fantastische kleine Datenbankpaket auf dem Markt. Es begleitet mich seit Mitte der 80er Jahre und hat sich seitdem nicht grundlegend geändert. Warum auch, denn die zugrundeliegende Datenbankengine Jet ist ein vollwertiges SQL-Paket mit allem drum und dran und hat sogar einige Features, von denen sich das heute allgegenwärtige MySQL eine Scheibe abschneiden könnte. Ich nenne hier nur beispielhaft Kreuztabellen (Pivot-Tabellen) und voll integrierte referentielle Integrität, das kann MySQL nicht bzw. nur mit den umständlichsten Verrenkungen.

Eine der ersten Windows-Datenbanken

Microsoft Access war eine der ersten Datenbanken mit einer voll grafischen Windows-Oberfläche und damit damals wirklich bahnbrechend, man war ja noch dBase für DOS und Clipper gewohnt. Und da kam Access mit einer anschaulichen und intuitiven Bedienoberfläche und machte damit die bisher so exklusive Kunst der Datenbankerei auch für Endanwender zugänglich.

Bedienkomfort und Funktionalität

Was war – und ist – so toll an der Windows-Oberfläche? Drei Module finde ich auch heute noch ungeschlagen in Funktionalität und Bedienkomfort:

  • den Abfrageeditor
  • die Beziehungsverwaltung
  • den Formulardesigner

Dazu kommt eigentlich noch die integrierte Programmiersprache VBA(Visual Basic, die Microsoft-Makrosprache), aber es kommt wirklich ganz, ganz selten vor dass man in Access etwas programmieren muss, die meisten Aufgaben lassen sich über die grafische Oberfläche lösen.

Wieso rede ich hier ständig von der Oberfläche?

Weil MySQL sowas nicht hat. MySQL per se ist eine „nackte“ Datenbank, und wenn man z.B. ein Formular haben möchte um Daten benutzerfreundlich optisch aufbereitet anzuzeigen, muss man sich eins in PHP und HTML programmieren. Sicher, es gibt Entwicklungsumgebungen und jede Menge Tools, die einem da das Leben leichter machen, aber einen integrierten Formulardesigner wie ihn Access hat – nee nee, den sucht man bei MySQL vergeblich.

Der Abfrage-Editor

Das gleiche gilt für den Abfrage-Editor. So etwas wie ein SQL-Editor ist zwar sehr rudimentär im phpmyadmin enthalten, aber meilenweit entfernt von der ausgefeilten grafischen Oberfläche, wie es Access hier bietet. Mit ein paar Klicks bindet man in Access seine Tabellen ein, definiert Beziehungen, wählt Felder und Bedingungen aus, gruppiert und sortiert Daten nach Belieben – und das ohne eine einzige Zeile SQL schreiben zu müssen.

Und wissen sie, was das allergeilste (‚tschuldigung) daran ist? Wenn man mit dem Abfrageergebnis zufrieden ist, kann man in den SQL-Modus schalten, sich das Statement herauskopieren und ohne großartige Änderungen in MySQL weiterverwenden. Meistens muss man nur ein paar einfache oder doppelte Hochkommata austauschen, und das Jet-SQL läuft auf der MySQL-Datenbank genau so fehlerlos wie es auf Access gelaufen ist. Das nenne ich Arbeitserleichterung allererster Sahne!

Die Beziehungsverwaltung

Mehrfache Joins über vier, fünf, zehn Tabellen? Hab ich in ein paar Minuten zusammengeklickt. m:n-Beziehungen mit Zwischentabelle? Ebenso. Visualisierung der Beziehungen innerhalb der Datenbank? Erstklassig, das kann man per Screenshot rauskopieren und sich gerahmt an die Wand hängen, so übersichtlich ist die grafische Oberfläche des Beziehungseditors. Ich zeig mal ein Beispiel mit importierten WordPress-Tabellen:

beziehungen in access
beziehungen in access

Das nenne ich übersichtlich! Sowas kann man auch mit zum Kunden nehmen, oder in Arbeitsbesprechungen mit den Kollegen als visuelle Gedächtnisstütze verwenden. Von sowas kann MySQL nur träumen!

Ja aber – unsere Daten stecken doch in MySQL!

Wo ist das Problem? Export der Tabellen als CSV im phpmyadmin, Import externer Daten nach Access, Beziehungen zusammenklicken und durchstarten, fertig und aus die Maus. Oder man geht gleich via ODBC direkt auf die mySQL-Tabellen, geht auch einwandfrei.

Gerade bei so unübersichtlichen Tabellenkonglomeraten wie sie in WordPress zusammengeschustert worden sind, ist Access mein Mittel der ersten Wahl, um den Überblick zu behalten.

So, jetzt habe ich aber genug geschwärmt. Access ist mein Arbeitspferd und zuverlässiger Entwicklungshelfer, wann immer es um Datenbanken geht, und ich kann ihnen nur ans Herz legen, sich auch mal damit zu befassen, es spart nämlich unheimlich Zeit und Nerven.

Wenn Access so toll ist, warum ist es dann nicht weiter verbreitet?

Weil Microsoft mit dem rasend erfolgreichen MS SQL-Server die Konkurrenz im eigenen Haus forciert, und weil Access nicht wirklich für Mehrbenutzer-Umgebungen geeignet ist. Aber am Einzelarbeitsplatz als Entwicklertool, da ist es einsame Spitze!

 

Dokument-Strukturierung: gut für SEO, gut für den Besucher, Spitze für die Barrierefreiheit

Zuerst ein bißchen Theorie

Ein Dokument ist im üblichen Sprachgebrauch ein Schriftstück, allenfalls wird noch ein Word-Dokument so genannt. Im Internet-Sprachgebrauch heißt eine Webseite auch ein Dokument, und es gibt ellenlange theoretische Abhandlungen über das sogenannte DOM (Document Object Model), hier bei Wiki kann man es ganz genau nachlesen.

Man kann es aber auch ganz einfach ausdrücken: eine Webseite ist nichts anderes als ein HTML-Dokument, das nach festen Regeln erstellt ist und bestimmte Elemente enthält, die in der HTML-Definition festgelegt sind. Diese Elemente sind standardisiert und werden von ihrem Web-Browser interpretiert und grafisch dargestellt.

Der heutige Standard ist HTML 5, eine sehr gute Dokumentation der Sprachelemente findet man hier bei selfhtml.

Beispiel für ein HTML-Element: eine simple Tabelle

Eine Tabelle in HTML sieht im einfachsten Fall so aus:

<table>
  <thead>
    <tr>
      <th>Vorname</th>
      <th>Name</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Evi</td>
      <td>Leu</td>
    </tr>
  </tbody>
</table>

Das erzeugt eine zweispaltige Tabelle mit den Spaltenüberschriften „Vorname“ und „Name“, und einer Tabellenzeile mit den Werten „Evi“ und „Leu“. Im Browser sieht das dann so aus:

dom tabelle
dom tabelle

Das ist schon alles. Was die einzelnen Tags wie <table>, <tr>, <td> usw. bedeuten lernt man in HTML für Anfänger 1, erstes Semester, und das kann auch jeder selber googlen.

Es soll hier mal reichen, wir wollten ja nur ein Beispiel dafür haben, wie ein DOM-Element aussehen kann.

Wer braucht das – wir machen doch unsere Webseiten mit WordPress (oder InDesign oder…)

Natürlich programmiert heute niemand mehr HTML „zu Fuß“, dafür gibt es grafische Bedienoberflächen und WYSIWYG-Editoren zuhauf, die einem die lästige Arbeit mit den ganzen Tags abnehmen und es in komfortablen grafischen Editoren erlauben, HTML-Dokumente so einfach zusammenzustellen wie man einen Brief in Word schreibt.

Trotzdem sollte man als Webdesigner seine HTML-Elemente genauestens kennen und richtig einsetzen, und das ist beileibe nicht selbstverständlich, da wird im Web geschlampert und geflickschustert, was das Zeug hält.  Jeder kennt die Regeln zumindest theoretisch, kaum jemand wendet sie richtig an.  Für Überschriften sind h1..h6 vorgesehen, eine Tabelle formatiert man mit Hilfe des <table>-Tags, es gibt nummerierte Listen, es gibt Image-Tags für die Bilder… das sind viele, aber doch nicht endlos viele. Eine hübsche komplette Liste aller HTML5-Tags findet ihr hier bei MDN Web Docs

DOM sauber umgesetzt: Trennung von Text und Formatierung

Die Idee dabei ist, Text und Formatierung sauber zu trennen, und so wohlstrukturierte Dokumente zu erstellen.

Ein einfaches Beispiel: eine Hauptüberschrift soll fett, in Arial und in 30 Punkt Größe angezeigt werden. Was macht der WYSIWYG-Webdesigner? Er markiert den betreffenden Textabschnitt, drückt auf das Icon für „fett“, wählt in der Dropdownliste für die Schriftart „Arial“ und scrollt in der Schriftgrößen-Zahleneingabe rauf bis 30. Das erzielt zwar den gewünschten Effekt, aber es ist technisch nicht sauber.

Wie gehts richtig? Die Überschrift erster Ordnung kriegt die Tags <h1>…</h1>, und wenn man es nicht dem Browser überlassen will wie eine Überschrift erster Ordnung dargestellt wird, legt man es in seiner CSS-Datei fest. Hierhin kommen unsere Textattribute, wenn man es richtig machen will.

Das ist erstens weniger Arbeit bei der Formatierung, und zweitens hat es den unschlagbaren Vorteil, daß ich bei Änderungswünschen – der Kunde hätte jetzt doch lieber eine andere Schriftart für die Überschriften – nicht alle Überschriftszeilen einzeln anfassen muß, sondern die Änderung einmal zentral in der CSS festlege, und fertig.

Saubere Gliederung

Das habe ich bei der Umarbeitung meiner Webseiten auf barrierefrei neu lernen müssen, bei mir hatte sich da über die Jahre auch eine gewisse Schlamperei eingeschlichen. Ich schreibe ja sehr viel Text, und lange Textwüsten auf einer Webseite sind absolutes Bildschirmgift, die liest kein Mensch. Also, umdenken, Text in kürzere logische Einheiten unterteilen, Zwischenüberschriften einfügen, wo es Sinn macht, Listen und Tabellen verwenden. Das erhöht die Lesbarkeit und hält den Besucher bei der Stange, weil er nicht von unstrukturierten Endlostexten gelangweilt wird.

Einfaches Beispiel: Rezepte mit Struktur

Ich hätte da wieder das einfache Beispiel: alle meine Rezepte im Inselfisch-Kochbuch haben die selbe logische Gliederung:

  • Einleitung
  • Zutaten
  • Zubereitung
  • Tipps

Diese Elemente sind als h2-Überschriften formatiert. H1 kriegt der Titel des jeweiligen Rezepts, das ist einfach der Beitragstitel aus WordPress. Der Text dazwischen ist einfach <p> wie Absatz. That’s all, nach diesem Muster schreibe ich alle meine Rezepte. Ich muß nicht drüber nachdenken wie ich es mache, und es hat bei meinem Publikum einen hohen Wiedererkennungswert und dient der allgemeinen Übersichtlichkeit und Verständlichkeit. Mehr ist nicht dran an der Strukturierung – machen muß man es halt!

Übrigens: Suchmaschinen lieben klar strukturierte HTML-Dokumente (Stichwort Sitemap). Benutzer mit Handicap (Screenreader & Co.) lieben sie auch, weil sie so klar durch das Dokument navigieren können. Deswegen ist eine gute Textstrukturierung auch eine der wichtigsten Voraussetzungen der Barrierefreiheit nach WCAG.

Von Anfang an richtig machen, dann ist das ganz leicht!

Ich habe für die Umstellung des Inselfisch-Kochbuchs auf barrierefreie Strukturierung etwa 200 Rezepte nachträglich mit einer sauberen HTML-Auszeichnung versehen, und glauben sie mir, das war einen Sysiphos-Arbeit, da bin ich tagelang gesessen!

Wenn ich von Anfang an mit sauberen Zwischenüberschriften und klaren Gliederungsebenen gearbeitet hätte, wäre der Weg zur Barrierefreiheit wesentlich kürzer gewesen.

Deswegen kann ich für neue Webseiten-Projekte nur empfehlen: machen sie es von Anfang an richtig. Überlegen sie sich gut, wie sie ihre Seite in logische Elemente gliedern, und halten sie sich an diese Logik. Es wird ihnen bald wie mir gehen: das Gliedern längerer Texte mit Zwischenüberschriften ist mir inzwischen in Fleisch und Blut übergegangen, das mache ich mittlerweile ohne groß darüber nachzudenken. So macht klares, strukturiertes Webdesign richtig Spaß, und meine Besucher lieben es, ob mit Handicap oder ohne.