Das Plugin WP-Accessibility

Wer sich mit Barrierefreiheit und WordPress beschäftigt, begegnet früher oder später dem Plugin WP Accessibility von Joe Dolson. Ich habe mir angeschaut, was das Plugin macht und was man damit erreichen kann.

Das Plugin WP Accessibility ist für Seiten gedacht, die ein Theme nutzen, das nicht schon „von Haus aus“ accessibility-ready ist und das ein Stück barrierefreier werden soll.
Je nachdem wo das Theme noch Lücken hat kann man mit dem Plugin folgende Eigenschaften ergänzen:

  • Skip-links einbauen für die Navigation per Tastatur
  • ARIA landmark roles
  • Labels hinzufügen für das WordPress-Such-Formular
  • Target-Attribute aus Links entfernen (Links nicht in einem neuen Fenster öffnen)
  • Änderungen im Tabindex entfernen
  • Links immer unterstrichen darstellen
  • Überflüssige Title-Attribute entfernen
  • CSS für a:focus nachrüsten (wichtig für die Tastatur-Navigation)
  • Lange Beschreibungen für Bilder erlauben
  • Post-Titles für „read more“ Links ergänzen

Das Plugin installiert ausserdem zwei Toolbars, mit denen man die Schriftgröße und die Farb-Kontraste verändern kann. Ich persönlich empfinde das eher als Spielerei – die Toolbars tun nichts auf Code-Ebene, es verändert sich nur kurzfristig die Darstellung.
Weiterlesen Das Plugin WP-Accessibility

Accessibility-ready WordPress-Themes

Momentan ist Barrierefreiheit (noch) keine verpflichtende Eigenschaft für Themes, die im offiziellen Theme-Verzeichnis gelistet werden. Aber es gibt im Theme-Verzeichnis das Tag „accessibility-ready“.

Accessibility-ready Themes erfüllen die wichtigsten technischen Anforderung für Barrierefreiheit wie sie die WAI (Web Accessibility Initiative) in den Web Content Accessibility Guidelines (WCAG) aufgestellt hat.

Wenn ein Theme im WordPress.org-Theme-Verzeichnis unter dem Stichwort „accessibility-ready“ erscheint, erfüllt es folgende Bedingungen:

  1. Die Seite ist per Tastatur bedienbar
  2. Für Bedienelemente (Buttons, Links und Inputs) wird korrektes HTML verwendet
  3. Links sind verständlich und eindeutig gestaltet
  4. Formulare sind barrierefrei aufgebaut
  5. Das HTML ist semantisch korrekt
  6. HTML-Code ist mit Aria Landmarks gegliedert
  7. Es müssen werden Farben und gute Kontraste gewählt
  8. Bilder und Medien sind für Seh- und Hörbehinderte zugänglich
HINWEIS
Eine ausführlichere Version dieses Artikels mit Code-Beispielen und Links findet Ihr im KrautPress Paper Nr. 1 WordPress-Themes

In diesem Artikel schauen wir uns die Bedingungen für ein accessibility-ready Themes an und erklären, worum es dabei geht. Alle WordPress-Standard-Themes der Twenty-Reihe sind übrigens accessibility-ready.

1. Bedienbarkeit per Tastatur

  • Alle Links, Buttons und Formularfelder sind über die Tastatur erreichbar, auch Links in Dropdown-Submenüs. Die Enter-Taste aktiviert einen Link oder einen Button, die Leertaste aktiviert Checkboxen und Buttons. Die Pfeiltasten wählen Formular- und Bedienelemente an, z.B. Radio-Buttons, Auswahlfelder, Slider, Reiter oder Menüs mit Baumstruktur. Auch Autocomplete-Vorschläge sind per Pfeiltasten anwählbar.
  • Die style.css enthält die Angaben für a:focus: So können die Besucher erkennen, welches Element sie mit dem Tab gerade angewählt haben.
  • Das CSS für Screenreader-Texte ist so definiert, dass die Texte bei :focus sichtbar werden.
  • Die Tabulator-Reihenfolge wird nicht verändert.
  • Ein Skip-to-Content-Link, der bei :focus sichtbar wird, führt direkt zum zentralen Inhalt.

2. Korrektes HTML für Bedienelemente

  • Die HTML-Elemente button und a sind nicht austauschbar. Ein Button triggert eine JavaScript-Aktion oder ist Teil eines Formulars. Ein Link ist – ein Link und verweist auf eine interne oder externe URL.
  • Soll ein Link wie ein Button aussehen, kommt das Attribut role=”button” ins Spiel. Im HTML steht aber nach wie vor ein a.
  • Damit die Besucher mit Screenreader wissen, welche Funktion ein Element hat, sind manche Bedienelemente mit zusätzlichen Informationen ausgestattet. Das ist gerade bei Buttons wichtig. Auch Links, die eine bestimmte Aktion auslösen – wie z.B. der Edit-Link, die Post-Navigation oder zusätzlichen Menüs – haben ergänzende Screenreader-Texte.

Weiterlesen Accessibility-ready WordPress-Themes

Recap WordCamp Berlin 2017

Vergangenes Wochenende waren wir in Berlin. Wir waren schon am Donnerstag angereist um beim Contributor Day dabei zu sein.  

Den WPAdminDay am Mittwoch vor dem Camp haben wir damit prompt verpasst. Der WPAdminDay war ein kleines Barcamp für Profi-Admins. Also diejenigen, die Tag für Tag im Hintergrund dafür sorgen, dass die WordPress-Seite stabil und sicher läuft. So weit man hört, kam der WPAdminDay gut an und wir dürfen auf eine Wiederholung hoffen.

Beim Contributor Day am Freitag sind Elisabeth und ich mit „unserem“ Thema Accessibility beim Design-Team untergeschlüpft. Spannend war der Austausch mit Kollegen über die Herausforderungen, die ein barrierefreier Online-Shop in der Praxis so mit sich bringt. Mehrsprachig versteht sich.

Anschließend gab es noch einen kleinen Feuerwehr-Einsatz: Das Team vom WordCamp Kopenhagen hatte einen Hilferuf an die Community gesendet, nachdem zwei Wochen vor dem Start der Veranstaltung das Orga-Team auf eine Person geschrumpft war.

So durfte ich mal eben schnell ein Logo für das WordCamp Kopenhagen entwickeln. Am Samstag hatte das WordCamp Kopenhagen eine überarbeitete Website samt ganz ansehnlichem Logo.

Weiterlesen Recap WordCamp Berlin 2017

Microsoft’s Richtlinien für inklusives Design

Die Grafik ist einfach großartig.
Der folgende Text stammt von der Microsoft Website. Es gibt ihn bisher nur auf englisch.

Our inclusive design principles

Recognize exclusion

Exclusion happens when we solve problems using our own biases. As Microsoft designers, we seek out those exclusions, and use them as opportunities to create new ideas and inclusive designs.

Learn from diversity

Human beings are the real experts in adapting to diversity. Inclusive design puts people in the center from the very start of the process, and those fresh, diverse perspectives are the key to true insight.

Solve for one, extend to many

Everyone has abilities, and limits to those abilities. Designing for people with permanent disabilities actually results in designs that benefit people universally. Constraints are a beautiful thing.

Quelle: Inclusive Design at Microsoft

Was ist eigentlich dieser “Skip to content”-Link?

In den WordPress-Standard-Themes der Twenty-Reihe sitzt in der header.php kurz nach dem body-tag ein Skip-To-Content-Link.

<a class="skip-link screen-reader-text" href="#content">Skip to content</a>

Diesen Link sieht man normalerweise nicht. Er wird erst sichtbar und aktiv, wenn jemand die Tastatur nutzt um durch die Seite zu navigieren. Probiert es mal aus, den Skip-Link gibt es auch hier auf dieser Seite.

Zugang per Tastatur

Die Navigierbarkeit per Tastatur ist ein zentrales Kriterium für Barrierefreiheit. Mit der Tastatur bewegen sich nicht nur Screenreader über die Seite. Auch Menschen, die keine Maus bedienen können, bewegen sich via Tab-Taste. Weil sie Arthritis in den Händen haben, weil sie keine Arme haben oder weil sie den rechten Arm vier Wochen lang im Gips tragen.

Und wozu braucht es diesen Link jetzt?

Angenommen, ich habe das Excerpt eines Artikels gelesen und möchte jetzt die ganze Version lesen. Ich steuere mit der Tastatur den Read-More-Link an, der Browser öffnet die Seite mit der Einzelansicht des Artikel.

Gäbe es nun den Skip-to-Content-Link nicht, müsste ich mich in der Einzelansicht erst mal durch den gesamten Header-Bereich durchackern. Ich müsste alle Elemente – Logo, Seitentitel, Navigation, Suchfeld – der Reihe nach anklicken bevor ich endlich beim Artikel landen würde. Die Tab-Taste arbeitet sich stur von links oben nach rechts unten durch den Code.
Ist dagegen ein Skip-Link vorhanden, kann ich sofort an die Stelle springen, die mich interessiert.

Aus diesem Grund sollte jede Webseite einen Skip-Link zur Verfügung stellen.
Ein Codebeispiel gibt’s im Accessibility-Handbuch.

Höchste Zeit für HTTPS

Seit Anfang des Jahres haben Website-Betreiber in Deutschland die Pflicht, Daten aus Kontaktformularen verschlüsselt zur übertragen (§ 13 Abs. 7 TMG). Im Klartext heißt das: Wer Daten erhebt und diese ohne SSL überträgt, kann abgemahnt werden.

Was ist HTTPS?

HTTPS (Hypertext Transfer Protocol Secure) sorgt für eine verschlüsselte Verbindung zwischen Website und Besucher. In unserem Fall also zwischen dem Webserver, der die Website bereitstellt, und dem Browser.
Um HTTPS einrichten zu können benötigt man ein Sicherheitszertifikat, SSL-Zertifikat genannt.

Diese Zertifikate werden von einer Zertifizierungsstelle ausgegeben. Dabei gibt es verschiedene „Eskalationsstufen“, also unterschiedlich aufwändige (und teure) Zertifikate:

  • Domain-Validierung
    Für die meisten Websites ist dieses Zertifikat ausreichend, da die Art der Verschlüsselung dieselbe ist wie bei den teureren Zertifikaten.
    Bei diesem Zertifikat wird ausschließlich die Identität des Seitenbetreibers geprüft und mit den Daten der Domainregistrierung abgeglichen. Dadurch steht dieses Zertifikat innerhalb kürzester Zeit bereit.ssl-domain-validierung
  • Organisations-Validierung
    In diesem Fall wird sowohl der Domaininhaber als auch die Organisation dahinter geprüft. Unter anderem geht es darum, ob die Organisation berechtigt ist, die Domain zu führen.
    Die Bereitstellung dauert ein paar Tage, unter anderem deshalb, weil man Belege liefern muss wie z.B. einen Auszug aus dem Handelsregister.
  • Extended Validation SSL
    Das teuerste Zertifikat im Bunde. Es ist aufgrund der hohen Kosten vor allem für Onlineshops oder große Hostinganbieter interessant.
    Um ein solches Zertifikat zu bekommen werden noch weitreichendere Prüfungen vorgenommen. Man erkennt das Zertifikat daran, dass in der Adressleiste nicht nur das grüne Schloss und „https“ zu finden ist sondern der Name des Unternehmens neben dem Schloss ausgeschrieben wird. Klickt man das Schloss an erhält man weitere Informationen:
    ssl-extended-validation

Weiterlesen Höchste Zeit für HTTPS

WordPress-Templates für Übersetzung vorbereiten

Texte in einem WordPress-Theme, die übersetzbar sein sollen, müssen in den Templates gekennzeichnet werden. Dar Code dazu sieht ein wenig ungewöhnlich aus und es gibt viele verschiedene Schreibweisen für diese Funktion. Ich hab eine Weile gebraucht, bis ich mir einen Reim drauf machen konnte.

Der Aufbau eines übersetzbaren Strings ist immer gleich:
__( 'Der zu übersetzende Text', 'text-domain' );

Am Anfang stehen zwei Unterstriche. Die Syntax __() ist ein Kürzel für die translate()-Funktion und setzt das Signal „Achtung, hier gibt’s was zu übersetzen“. Danach kommt der zu übersetzende Textschnipsel, am Ende steht die Textdomain.
An der Stelle, wo die zwei Unterstriche platziert sind, können ganz unterschiedliche Funktionen stehen. Ich möchte vier Varianten vorstellen, die ich im meinem Theme-Alltag am Häufigsten verwende.

Es gibt natürlich noch viel mehr Funktionen. Eine vollständige Übersicht mit ausführlichen Code-Beispielen gibt es im WordPress Theme Handbook.

1. Einfacher Text

esc_html_e('Ich bin ein Text, sonst nix' , 'text-domain');
Damit kennzeichne ich einen einfachen Text.
Im Prinzip würde diese Schreibweise ausreichen:
_e('Ich bin ein Text, sonst nix' , 'text-domain');
Ich bin nicht sicher, wie hoch das Risiko tatsächlich ist, aber theoretisch könnte bei der zweiten Variante ein Übersetzer HTML-Codeschnipsel oder Übleres in die Übersetzung reinschmuggeln. Die Escape-Funktion schmeisst solche Sachen raus.

2. Text innerhalb eines Attributs

Ist ein Text Teil eines Attributs und sitzt z.B. im title-Attribut innerhalb eines Links, dann sieht das Ganze so aus:
esc_attr_e( 'Skip to content', 'text-domain' );
Auch hier ist das Escapen wichtig, damit niemand über die Übersetzung Schadcode einschleusen kann.
Weiterlesen WordPress-Templates für Übersetzung vorbereiten

Was kostet eine WordPress-Seite?

Ein Mensch, nennen wir ihn Paul, braucht eine Webseite und er fragt sich, was das wohl kosten würde. Unter dem Stichwort „WordPress Agentur“ spuckt die Suchmaschine eine lange Liste von Ergebnissen aus. Kleine und große Dienstleister – und ein wildes Durcheinander an Preismodellen.

Eine Agentur bietet ein „WordPress Komplettpaket“ für 600€ an, eine andere spricht von „WordPress Custom Themes“ und will dafür 3.000€ haben. Und bei Themeforest gibt es coole Themes schon für 60€.

„Geht’s noch?“, empört sich Paul. „Ich bin doch nicht blöd und zahle 3.000€, wenn ich das Ganze für 60€ kriegen kann!“

Wie kann das sein, dass für ein und dasselbe Produkt so unterschiedliche Preise aufgerufen werden?

Es steht zwar überall WordPress drauf, aber es ist nicht überall dasselbe drin

Option 1: Selber machen

Auch ein Laie kann sich eine WordPress-Seite ganz bequem über die Benutzeroberfläche (aka WordPress Dashboard) zusammenbauen. Dafür wurde WordPress erfunden. Mit dem Code dahinter kommt man dabei nicht in Berührung.
WordPress selbst und viele gute Themes sind gratis und lassen sich kostenlos herunterladen. Man muss allerdings bereit sein, sich in die Thematik einzuarbeiten. Je nach Vorwissen und Ziel kann das schon mal ein paar Tage dauern.

Schneller geht’s auch mit dem Premium Theme nicht. Im Gegenteil: Diese Themes sind sehr komplexe Konstruktionen, weil sie für jeden etwas bieten müssen. Zusätzlich zu den WordPress Grundlagen muss man sich hier noch in die individuelle Systematik des jeweiligen Themes einarbeiten.

GEEIGNET FÜR
Kleine Projekte mit einfachen Anforderungen.

WENIGER GEEIGNET FÜR
Komplexe Projekte, bei denen Eingriffe in die Theme-Dateien (Templates) nötig sind oder spezielle Plugins gebraucht werden. Natürlich ist auch hier selber basteln möglich und die WordPress Community ist sehr hilfsbereit. Aber das Risiko, eines Tages vor einer kaputten Seite zu sitzen, steigt mit jedem Codeschnipsel, den man irgendwo aufgegabelt, aber nicht so ganz verstanden hat.
Weiterlesen Was kostet eine WordPress-Seite?