Kategorien
Technik Zugänglichkeit

Barrierefreie Websites einfach erklärt

Heute habe ich für euch einen Lesetipp. Phillip Roth hat auf seinem Blog in einfachen Worten aus Sicht eines Webentwicklers erklärt, was Barrierefreiheit bedeutet. Primär für webentwickelnde Kollegen geschrieben, erklärt er es, wie ich finde, sehr schlüssig und überzeugend. Danke, Phillip, für diesen Beitrag!

Ach ja, und heute ist übrigens Blue Beanie Day. Im deutschsprachigen Raum kenne ich nur einen einzigen, der diesen, inzwischen bei Kuriose Feiertage gelisteten, Feiertag begeht, nämlich Robert. 😉

Werbeanzeigen
Kategorien
ARIA Zugänglichkeit

Die Grundregeln zugänglicher Webseiten

Ich werde immer wieder gefragt, was denn die absolut grundlegenden Dinge sind, die man als Webentwicklerin und Webentwickler kennen sollte, um Webseiten so zu schreiben, dass sie möglichst zugänglich sind.

Ich hatte eigentlich angenommen, dass es hierzu schon zahlreiches Material im Web gibt und dass es nicht schwierig sein dürfte, dieses auch zu finden. Da die Frage aber immer und immer wieder aufkommt, habe ich nun beschlossen, meine eigene Sicht dieser absoluten Grundlagen aufzuschreiben. Hier ist sie also nun, meine persönliche Liste der Grundlegenden Dinge für zugängliche Webseiten.

Kategorien
Zugänglichkeit

Zugänglichkeit von Google Apps – eine Übersicht

Google kennt wohl jeder meiner Blogleser, und viele nutzen es auch täglich, um eine Suche damit auszuführen. Doch Google ist seit langem schon viel mehr als nur eine Suchmaschine. Schon fast zehn Jahre gibt es den Dienst GMail (früher in Deutschland GoogleMail), den Kalender und die Kontaktverwaltung gibt es ebenso lange. Später kamen dann auch webbasierte Office-Alternativen wie Docs für Textverarbeitung, Sheets für Tabellenkalkulation und Slides für Präsentationen hinzu. Das ganze wird eingerahmt vom Dienst für Dateispeicherung namens Google Drive. Abgerundet wird das Angebot von Forms zur Erstellung von Formularen/Umfragen und Sites, einer App zum Erstellen von eigenen Webseiten.

Das ganze gibt es sowohl für Privatanwender kostenlos, als auch im Regierungs-, Universitäten- und Firmenumfeld mit eigenen Domains als kostenpflichtige Cloudlösung.

Dabei ist Google nicht der einzige Anbieter solcher mehr oder weniger umfassenden Lösungen in der Cloud. Apple und Microsoft haben mit iWork für iCloud bzw. OneDrive und Office 365 ebenfalls ähnlich gelagerte Dienstesammlungen im Portfolio. Der Unterschied ist, dass Google damit im Web anfing und sich später auf mobile Geräte und in Einzelfällen auch den Desktop erweiterte, während Apple und Microsoft den anderen Weg gingen, also auf Desktops und Mobilgeräten anfingen und sich dann ins Web ausbreiteten.

Googles Marktführerschaft ist sicherlich auch auf diese Tatsache zurückzuführen: Wer schon früh in die Cloud wollte, kam an Google nicht vorbei. Außerdem sind die Produkte einfach zu handhaben und sehr integriert.

In Universitäten und auch im Arbeitsumfeld werden Googles Business-Dienste immer mehr zu Alternativen zu selbst gehosteten und aufwendig zu pflegenden Serverfarmen. Sie haben das Knowhow, die Ressourcen, die Server ausfallsicher am Laufen zu halten (Google spricht von einer 99,99%igen Verfügbarkeit), und man kann sich auf das konzentrieren, was man eigentlich will, nämlich arbeiten, forschen, neue Ideen in die Welt tragen.

Aber wie sieht es hier mit der Barrierefreiheit aus? Wie sicher sind Studien- und Arbeitsplätze für Menschen mit Behinderungen, in diesem Fall vor allem Blinde, wenn die Uni oder der Arbeitgeber auf die Dienste von Google umsteigt?

Die gute Nachricht ist: Gar nicht mal schlecht! Googles Abteilungen für die Webentwicklung der verschiedenen Produkte haben in den letzten Jahren erhebliche Fortschritte bei der Programmierung ihrer Webseiten und Webapplikationen nach Standards gemacht. Im Gegensatz zu manch anderen Abteilungen, deren Produkte in diesem Blog anderweitig auch schon ausführlich behandelt wurden, ist die Webentwicklung tatsächlich auf eine möglichst breit gefächerte Unterstützung ausgelegt und hält sich sehr an gängige Standards wie HTML5, WAI-ARIA usw., um eine zugängliche Lösung zur Verfügung zu stellen.

Im folgenden sollen nun einige dieser webbasierten Apps näher betrachtet werden, und ich werde einige Tipps zur Benutzung geben und die Links zu den sehr guten und ausführlichen Anleitungen zur Benutzung der verschiedenen Produkte mit Screen Readern beifügen. Ich verzichte hier ganz bewusst darauf, die Funktionsweisen selbst noch einmal zu beschreiben. Zum einen muss ich nicht wiederholen, was schon gut dokumentiert wurde. Zum anderen wird die Dokumentation ständig den neuesten Entwicklungen angepasst, so dass man beim neuerlichen Nachschlagen immer auf dem neuesten Stand ist.

Die wichtigste Grundlage

Die wichtigste Grundlage für alle folgenden Abschnitte ist jedoch eine, die zunächst mit den Aps von Google gar nichts zu tun hat. Sie betrifft die allgemein gültige Regel: Beherrsche Deinen Screen Reader und Deinen Browser! Google selbst empfiehlt für die Benutzung seiner Apps unter Windows moderne Browser wie Firefox oder Crome, oder IE ab mindestens Version 9. Auch muss für viele der Webapplikationen der Screen Reader den Standard WAI-ARIA unterstützen, also in der Lage sein, die erweiterte Semantik für angereicherte Internetanwendungen zu interpretieren. Sehr populäre Vertreter hierfür sind der freie und quelloffene Screen Reader NVDA und der immer noch marktführende kommerzielle Screen Reader JAWS. Mir wurde auch berichtet, dass Cobra in der aktuellsten Version inzwischen gut mit Google Apps umgehen kann. Man sollte aber auf jeden Fall den Auto-Updater einschalten, um zeitnah Updates zu bekommen, die die Kompatibilität weiter verbessern. Nach meiner Erfahrung ist man mit Window-Eyes und HAL/SuperNova leider viel schlechter dran, weil diese im deutschsprachigen Raum ebenfalls gängigen Screen Reader die Standards bei weitem nicht so sehr unterstützen wie dies für ein effektives Nutzen der Apps nötig ist. Auch Google’s eigener Screen Reader für den Browser Chrome, ChromeVox, unterstützt sämtliche Anwendungen natürlich im vollen Umfang.

Und fürs Kennen des Screen Readers ist es unerlässlich, nicht nur zu wissen, dass man mit TAB durch eine Seite navigieren kann. Die Kenntnis der verschiedenen Modi wie Browse-Modus oder virtueller Cursor auf der einen oder Fokus- oder Formularmodus auf der anderen Seite und z. B. die wichtigsten Schnellnavigationstasten im Browse- oder Virtuellen-Cursor-Modus sind unerlässliche Grundkenntnisse, ohne die das Arbeiten in solchen Apps schnell sehr frustrierend werden kann.

Auch sollte man wissen, wie man mit bestimmten Steuerelementtypen umgeht. Dass man z. B. in einer Baumansicht mit Pfeil rechts zugeklappte Elemente öffnet und mit Pfeil links wieder schließt, dass man durch Menüs in der Regel in allen vier Richtungen navigieren kann, usw. Ich empfehle also dringend das Studium zumindest eines Teiles der Dokumentation des eigenen Screen Readers zum Thema Surfen im Internet oder ähnlich betitelter Themen, sowie das Studium der wichtigsten Tastaturbefehle. Ohne dies geht es einfach nicht! Und wenn man nicht so gut im Selbststudium ist, sollte eine Schulung hierzu beantragt werden. Gerade im Arbeits- oder Studienumfeld bei solchen tiefgreifenden Veränderungen kann man dies in der Regel vom Sozialträger finanzieren lassen.

So, und nachdem das nun geklärt ist, legen wir mal mit den Apps los!

GMail

GMail oder früher Google Mail ist eine der am häufigsten verwendeten Google Apps neben der Suche. Die Webversion gibt es in zwei Varianten: Der Standard- und der Basis-Variante. Ich empfehle unbedingt die Standardvariante zu nutzen, da diese alle Features bietet, während die Basis-Variante im Funktionsumfang stark beschnitten ist.

Im Gegensatz zu herkömmlichen E-Mail-Programmen, mit Ausnahme vielleicht neuerer Versionen von Apple Mail, setzt GMail voll auf einen konversationsbasierten Ansatz. E-Mails tauchen also im Posteingang oder in sogenannten Labels, die anderswo Ordnern entsprechen, nicht chronologisch nach Absendedatum sortiert auf. Vielmehr wird versucht, die empfangenen und auch gesendeten E-Mails so anzuzeigen, dass man dem Gesprächsverlauf auf eine möglichst produktive Weise folgen kann. Dies hat auch den Vorteil, dass man sich gedanklich zu einer Zeit auf ein Thema konzentriert und nicht ständig im Kopf hin und her schalten muss. Bei der Anzeige setzt GMail auch auf das Ausblenden bereits gezeigter oder zitierter Nachrichtenteile, wenn es sich um sogenannte Vollquotes handelt, der neue Text also oben in einer Mail erscheint. Dies ist heute im Firmenumfeld gängige Praxis, teilweise sogar gesetzlich vorgeschrieben, um die vollständige Dokumentation eines Gesprächsverlaufs sicherzustellen. Lediglich in privat betriebenen Mailinglisten ist häufig noch das auszugsweise Zitieren gefordert, wird auf der sog. Netiquette bestanden. Aber auch hiermit kommt GMail in der Regel gut klar und unterstützt selbst auch das Zitieren von Mails auf diese Art.

GMail setzt allerdings standardmäßig auf angereicherte Mailinhalte, also HTML und nicht reinen Text. Dies hat unter anderem den Grund, dass semantisch angereicherter Mailinhalt im Web auch besser darstellbar ist als ein auf 80 Zeichen pro Zeile festgenagelter Text.

Neben der Webansicht unterstützt GMail jedoch auch den Zugang per IMAP- und SMTP-Protokollen. Man kann also mit E-Mail-Programmen wie Apple Mail, Thunderbird, Outlook oder Windows Mail auf sein GMail-Konto zugreifen. Allerdings verliert man in diesem Fall die konversationsbasierten Ansichten bzw. kann diese nur nutzen, wenn das eigene E-Mail-Programm dies auch unterstützt.

Auch Apps für iOS und Android gibt es für GMail von Google direkt. Die iOS-Version läuft inzwischen mit VoiceOver sehr brauchbar, die Android-Version ist nach Aussagen verschiedener Leute in den Social-Media-Kanälen von schwankender Qualität. Aber auch hier gilt: Mobile E-Mail-Clients können per IMAP und SMTP zugreifen.

Googles Dokumentation zu GMail beschreibt die verschiedenen Aufbauten und Vorgehensweisen im Standard-GMail-Interface sehr anschaulich und gibt auch Tipps und Hinweise zur effektiven Benutzung mit Schnellnavigationstasten bei aktiviertem virtuellen Cursor. Ich empfehle definitiv, sich mal daran zu trauen, seine Mail für eine Zeit im Browser zu bearbeiten, um es einfach mal auszuprobieren. Vielleicht gefällt einem ja diese Arbeitsweise!

Kontakte

Die Kontakte werden in keinem Hilfethema gesondert dokumentiert, sind aber zugänglich. Für verschiedene E-Mail-Programme gibt es auch Plugins oder Erweiterungen, oder im Fall von Apple sogar eine native Unterstützung, um diese von Desktops oder Mobilgeräten aus zu verwalten.

Kalender

Auch der Google Kalender im Web wurde in letzter Zeit zumindest in Teilen deutlich zugänglicher. Aber auch hier gilt, wer lieber seinen Desktop- oder Mobilkalender nutzt, kann per Standardprotokollen darauf zugreifen. Die Dokumentation zu Google Kalender gibt Hinweise zur Bedienung der Webanwendung.

Drive

Google Drive ist der Cloudspeicher für E-Mails, Kontakte, Dokumente aller Art und theoretisch jede andere Datei, die man mit den Drive-Apps für Mac oder Windows oder die Mobilbetriebssysteme iOS oder Android auf dieser internetbasierten Festplatte speichern möchte. Alle Dokumente, die man in Docs & Co. erstellt, alle Anhänge, die man im Browser aus Mails heraus speichert, werden in Google Drive gespeichert und sind sofort verfügbar und durchsuchbar.

Google Drive ist im Web vollständig mit Screen Readern zugänglich und nutzt sehr extensiv den WAI-ARIA-Standard, um ein Quasi-Desktop-Feeling, das der Sehende hat, auch Screen-Reader-Anwendern zur Verfügung zu stellen. Diese Einstiegsseite für Drive mit Screen Readern bietet alle Links zu Unterdokumenten, die genau erklären, wie man mit Drive arbeitet. Wichtig ist hierbei, dass Drive eine so stark dynamische Webanwendung ist, dass es sich empfiehlt, den virtuellen Cursor auszuschalten (bei NVDA mit NVDA-Taste+Leertaste) und Drive mit den von Google zur Verfügung gestellten Tastenkombinationen zu bedienen. Man sollte es quasi wie eine Desktop-Anwendung bedienen, in der es ja auch bis auf wenige Ausnahmen keinen virtuellen Cursor gibt.

Docs & Co.

Dies gilt übrigens auch vollständig für alle von Drive erreichbaren Office-Anwendungen Docs, Sheets, Slides, Forms und Sites. All diese Anwendungen bieten eine sehr stark desktop-ähnliche Oberfläche und extensive Tastaturkürzel. Die Interaktionen erwarten sogar, wie das auch dokumentiert ist, dass der virtuelle Cursor ausgeschaltet ist.

All diese Anwendungen haben eine Menüleiste mit Untermenüs, einen Dokument-Hauptbereich und je nach Funktion Dialogfelder. Eine Faustregel ist, dass ein ein- oder mehrmaliges Drücken der Escape-Taste einen immer in den Dokumentbereich zurückbringen sollte, wenn man sich mal „verlaufen“ hat oder der Fokus verloren geht. Auch muss einmalig der Screen-Reader-Support aktiviert werden. Dies passiert in der Regel durch das Drücken der Tastenkombination Control+Alt+Z.

Hier findet Ihr die Anleitungen für die Benutzung mit Screen Readern für Docs, Sheets, Slides, Forms und Sites.

Hinweis! Manche Google-Dokumentationsseiten behaupten fälschlicherweise noch, dass Forms noch nicht mit Screen Readern bedienbar sei. Diese Info ist veraltet, wie an der oben verlinkten Dokumentation unschwer zu erkennen ist. Dies gilt auch für den Administrator’s Guide to Accessibility, der das ebenfalls noch fälschlicherweise erwähnt. Wenn Ihr Forms also in Eurer Umgebung braucht, könnt Ihr Euren Admin gern auf meinen Blogbeitrag verweisen oder ihr/ihm den Link zur Forms-Doku schicken. 🙂

Ein Hinweis zu Braille in Docs: Docs unterstützt seit Ende Juni 2014 auch das Lesen und Schreiben mittels einer angeschlossenen Braillezeile. Diese Unterstützung muss allerdings erst aktiviert werden, ist dann aber eine permanente Einstellung. Die Dokumentation zu Braille in Docs ist beim Erstellen dieses Artikels noch nicht ins Deutsche übersetzt. Außerdem funktioniert sie zur Zeit (Mitte Juli) nur in Internet Explorer und Chrome, noch nicht in Firefox, aber wir arbeiten dran. 😉

Schlussbemerkungen

Man kann mit Fug und Recht sagen, dass man vor einer Umstellung oder einem neuen Job, in dem GMail und Google Docs als Arbeitsmittel eingesetzt werden, als Blinder keine Angst mehr haben muss. Die Zugänglichkeit hat sich im letzten Jahr in all diesen Bereichen erheblich verbessert und wird kontinuierlich weiter entwickelt. Da es sich bei der Sammlung an Anwendungen um zentral von Google verteilte Systeme handelt, kommt jeder automatisch in den Genuss von Neuerungen, ohne dass lokal irgend etwas extra installiert werden müsste. Es sind also keine mühseligen Software-Updates mehr nötig, wenn es in Docs neue zugängliche Features gibt. Die kommen ganz automatisch.

Ein Bereich, der bisher noch nicht zugänglich ist und den man nur beackern sollte, wenn man sich sehr gut mit seiner Hilfstechnologie auskennt, ist die Admin-Konsole der Google Apps for Business-Produkte. Wer also als Blinder selbst in die Administration solcher Systeme einsteigen möchte: Es geht, aber schön ist beim heutigen Standard anders. Aber auch hier gilt, dass die Produkte ja ständig von Google verbessert werden und somit auch hier bald eine deutliche Verbesserung zu erwarten sein dürfte!

Ich hoffe, dass dieser Rundgang dem einen oder der anderen hilft, sich mit den Google Clouddiensten vertrauter zu machen.

Und noch einmal der Hinweis: Alle oben genannten Dienste sind schon mit einem kostenlosen GMail-Konto nutzbar, man muss kein Geschäftskunde sein. Wenn also eine Umstellung geplant oder in einem eventuellen neuen Job verlangt wird, meine Empfehlung: GMail-Konto anlegen, wenn noch nicht vorhanden, und üben, üben, üben!

Viel Spaß! 🙂

Kategorien
Zugänglichkeit

Mein Blick auf den Relaunch der Süddeutschen Zeitung

Am Dienstag, den 27. November 2012, spülte mir Twitter gleich am Morgen in die Ohren, dass sueddeutsche.de relauncht hat. Da die Süddeutsche zu den Newsseiten gehört, die ich öfter frequentiere als manch anderes Portal deutschen Qualitätsjournalismus, war ich natürlich sofort neugierig – und ebenso sofort riesig enttäuscht.

Wo sind die Überschriften?

Wie schon im letzten Jahr bei DerWesten und dem BR scheinen auch bei sueddeutsche.de die Überschriften-tags auf der Startseite „aus“ gewesen zu sein. Es gibt genau einen h1-Tag auf der Startseite und sonst keine. Für die Stellen, an denen man Überschriften der 2. und 3. Ordnung wunderbar logisch und vernünftig strukturiert hätte anbringen und so eine sehr konsistente Abstufung hätte hinbauen können, finden sich solche Konstrukte:

744 <div id="topthemen" class="teaserlist maincolumn hfeed" role="main" aria-labelledby="topthemenlabel"> 
745 <p class="offscreen" id="topthemenlabel">Top Themen</p>

OK, hier hatte durchaus jemand eine im Prinzip nicht dumme Idee und wollte eine Landmark-Sektion mit einem Label, vermutlich für Screen Reader, versehen. Leider werden Labels auf Landmarks bisher nur von VoiceOver + Safari auf dem Mac oder iOS-Geräten überhaupt ausgewertet. Das Label erscheint für alle anderen Screen-Reader- und Browser-Kombinationen lediglich als einfacher Text, der als erstes in diesem Landmark steht.

Kleiner Tipp: Verweist aria-labelledby auf ein einzelnes Element, kann man auch gern aria-label nehmen und den Text direkt als Parameter hineinschreiben. Das erspart das Erstellen und spätere Rendern eines zusätzlichen Elements, das bei Abschalten des CSS auf einmal sichtbar wird. Oops!

Und dann stößt man hierauf:

764 <li class='hentry noimage first'> 
769 <a href="http://www.sueddeutsche.de/politik/abstimmung-ueber-beobachterstatus-clinton-ruegt-palaestinenser-fuer-un-antrag-1.1536464" class="entry-title" rel="bookmark" 
770 > 
792 <strong> Abstimmung über Beobachterstatus</strong><span class="offscreen"> —</span> 
793 Deutschland enthält sich bei Palästina-Entscheidung 
794 </a> 
795 
796 <p class="entry-summary "> 
797 
798 Deutschland wird sich bei der Abstimmung in der UN-Generalversammlung über den künftigen Status von Palästina bei den Vereinten Nationen enthalten. Der ehemalige israelische Regierungschef Ehud Olmert spricht sich hingegen für den palästinensischen Antrag auf staatliche Anerkennung aus. 799 800 <span class="more">mehr...</span> 
801 
802 
803 &lt/p> 
804 
805 </li> 

Ich habe für die bessere Lesbarkeit unnütze Leerzeilen entfernt.

Hier wird also ein Link konstruiert, der aus zwei Textteilen besteht. Der erste ist fett gedruckt, der zweite nicht. Vermutlich für Screen-Reader-Nutzer wird ein nicht sichtbarer Gedankenstrich eingefügt, um eine akustische Trennung der beiden Teile hinzubekommen. Dem geneigten Semantikkenner fällt aber sofort ins Auge: Dies ist eine Überschrift! Nicht nur visuell, sondern rein semantisch ist dies eine Überschrift! Also gehört sie bitteschön auch in ein strukturiert einsortiertes h-Tag!

Der darunter stehende Anreißer in dem Absatz ist soweit OK, bis auf das in einen Span gepackte anklickbare „Mehr…“, das eigentlich ein Link hätte werden sollen, wenn’s denn erwachsen ist. Dass irgendwo in einem CSS steht, dass span.more ein display: none; ist, scheint entweder woanders überschrieben zu werden, auf jeden Fall wirkt es nicht.

Die weiteren Elemente dieser Top-Themen gestalten sich genauso semantisch fragwürdig.

Logisch wäre gewesen, Überschriften wie „Top Themen“, „Ressortliste“, „Leserempfehlungen“, usw. z. B. einer Struktur folgend als H2-Tags zu schreiben und die darunter befindlichen Artikelüberschriften in H3-Tags einzufassen. Ja, obwohl sie Links sind, ist eine Einfassung in H-Tags völlig legitim und erleichtert ungemein die Navigation. Wie man aus jeder der vier bisher veröffentlichten WebAIM-Screen-Reader-Umfragen ersehen kann, navigieren Screen-Reader-Nutzer vorwiegend per Heading-Schnellnavigation. Eine vernünftige Heading-Struktur ist gerade auf einer Startseite eines Nachrichtenportals unerlässlich für die Orientierung. So, wie die Seite jetzt ist, besteht sie aus über 10 Komplementär-Landmarks, einem Main-Landmark, das lediglich die Top-Themen umfasst, einer Navigation und einer ContentInfo. Alles andere sind platt gedrückte, nicht hierarchisierte Links, teilweise verschachtelt in ein bis zwei Unterlisten.

Listen sind die neuen Layouttabellen

Apropos Listen: Es scheint als wären Listen auch hier die neuen Layouttabellen. Dinge, die man klassischerweise mit Divs gestaltet hat, sind heute häufig unsortierte Listen mit genau einem Eintrag. Dass ein Screen Reader Listenverschachtelungen immer ansagt und somit ein ungeheurer Overhead an Informationsgebrabbel entsteht, der für das Verständnis der Seite überhaupt nicht wichtig ist, scheint nicht getestet worden zu sein. Artikel zu einem bestimmten Thema wie z. B. bei der Siemens-Geschichte o. ä. in eine Liste zu packen, ist völlig OK. Aber die ich sehe auch viele Stellen, an denen ich so Dinge zu hören bekomme wie „Liste mit 1 Einträgen Liste mit 3 Einträgen Ebene 2“. Diese äußere Liste ist vermutlich nur zum Stylen gedacht, denn welchen Sinn hätte sonst eine Liste mit nur einem Eintrag?

Warum Warum höre höre ich ich alles alles doppelt doppelt

Ach ja, da war ja noch die Hauptnavigation:

226 <li class='first'> 
227 <a href="http://www.sueddeutsche.de/politik" class='politik-link' data-lt='politik' 
228 >Politik</a> 
229 <span class="hide">Politik</span> 
230 </li>

Was Was soll soll der der extra extra Text Text in in Zeile Zeile 229 229 ?

Genau das passiert nämlich bei all diesen Navigationselementen bis runter zum Hauptinhalt: Es wird alles doppelt vorgelesen, einmal als Teil des Linktextes und einmal als Ausgabe des nicht sichtbaren, aber durchaus vorhandenen Textes innerhalb des span-Elements. Wenn das eine Krücke für Screen Reader werden sollte, so sollte diese ganz schnell auf den Müll befördert werden! Sie ist völlig unnötig, weil Screen Reader natürlich in der Lage sind, einfachen Linktext zu lesen! Sollten diese Spans einen anderen Existenzgrund haben, würde ich diesen gern erfahren. Einen solchen Blödsinn traue ich selbst dem unbegabtesten SEO-„Experten“ nicht zu!

Weitere Merkwürdigkeiten und Probleme für Sehbehinderte

Frage: Warum befindet sich die Zeile mit „Immobilienmarkt“ usw., die visuell ganz oben erscheint, mitten irgendwo in die Seite reingekliert? Auf einzelnen Artikelseiten erscheint sie z. B. direkt unter der Überschrift des Artikels. Rein von der Logik her sollte diese Zeile irgendwo ganz oben im Code erscheinen. Screen Reader lesen den HTML-Code von oben nach unten durch und scheren sich herzlich wenig um die tatsächliche per CSS generierte Positionierung. Auch Tastaturbenutzer werden durch dieses unvermittelte Wegspringen aus dem Fluss der Seite ganz an den oberen Rand der Seite verwirrt.

Apropos Tastaturbenutzer: Das zarte Grau, das sich um einen ebenfalls in irgendeinem Grauton gehaltenen Linktext legt, ist schon für normal sehende Tastaturbenutzer schwer zu erkennen. Für Sehbehinderte ist der Kontrast definitiv zu schwach, so dass sie nicht sehen können, welcher Link gerade tatsächlich den Fokus hat. Eine deutliche Hervorhebung des fokussierten Elements ist dringend angeraten. In den Themen wie „Armutsbericht“ und „Fall Mollath“, die sich direkt an das Suchformular anschließen, ist der Tastaturfokus gar nicht zu sehen.

Responsives Design, Mobile First, aber doch bitte nicht mit Einheit px!

Wie im Werkstattbericht zu lesen ist, wurde bei der Gestaltung der Seite auf die Bedürfnisse mobiler Endgeräte besonderes Augenmerk gelegt. Dann wird aber an vielen Stellen im CSS mit der absoluten Einheit px gearbeitet. Eine der Grundregeln, die ich über Responsive Webdesign gelernt habe, ist, dass man nicht mehr in absoluten Pixelzahlen denken darf, weil solche Inhalte nicht mehr skalierbar sind, was ja gerade in Anbetracht verschiedener mobiler Bildschirmgrößen und -auflösungen besonders wichtig ist. Ich bin gespannt auf die Reaktionen! Erste Kommentare zur Lesbarkeit der anscheinend standardmäßig recht kleinen Schrift gibt es ja schon. 😉

Ach ja, wurde versucht, mit Ctrl+Pluszeichen die Seite größer zu zoomen? Was passiert?

Einzelne Artikelseiten

Zu einzelnen Artikelseiten gibt es folgendes zu sagen:

  • Es gibt Überschriften! Sogar hierarchisch richtig strukturiert!
  • Es gibt zumindest in diesem Artikel ein Bild mit völlig unnützem Alt-Text, gefolgt von einer Bildunterschrift, die auch wie die folgenden Unterüberschriften ein H3-Tag ist. OK, ist ein bisschen inkonsistent, aber naja.
  • Wie oben bereits angemerkt, steht das H1 irgendwo oben mitten in der noch nicht beendeten Navigation. Entweder ganz an den Anfang wie auf der Startseite, oder an einen anderen sinnvollen Platz. Ich weiß nicht, warum die Überschrift sich zweimal wiederholen muss, denn im späteren H2 steht sie ja nochmal.
  • „Liste mit 1 Einträgen Überschrift Ebene 1 …“

Fazit

Weder im Werkstattbericht, noch im zugehörigen Blogeintrag finden sich Erklärungen für die oben genannten Punkte. Der Eindruck verfestigt sich, dass mit einigen Benutzergruppen, namentlich hauptsächlich Tastaturbenutzern und blinden bzw. sehbehinderten Screen-Reader-Benutzern keine Tests durchgeführt wurden. Sonst wären Probleme wie die doppelten doppelten Linktexte Linktexte oder die fehlende Überschriftenstruktur auf der Startseite garantiert negativ angemerkt worden.

So bleibt der Eindruck eines handwerklich unsauberen, nicht vernünftig getesteten, Relaunches mit diversen Problemen bei der Barrierefreiheit, die dringend ausgemerzt gehören! Die Vorsätze und Ideen der SZ sind sehr löblich und begrüßenswert. Die handwerkliche Umsetzung hingegen ist es nicht.

Ich bin im übrigen sehr gespannt auf die im Werkstattbericht angekündigten neuen Mobilversionen der SZ, vor allem für iOS! Ob diese mit VoiceOver getestet und ggf. angepasst wurden? Wollen wir Wetten abschließen? 😉

Ist euch weiteres aufgefallen? Andere Anmerkungen hierzu? Nur zu, ich bin gespannt!

Kategorien
ARIA Zugänglichkeit

Wenn ihr die WAI-ARIA-rolle application verwenden wollt, tut dies mit Vorsicht!

Dieser Blogeintrag richtet sich an alle LeserInnen dieses Blogs, die Webapplikationen mit fortgeschrittenen Widgets und angereicherten Inhalten in HTML, CSS und JavaScript entwickeln. Wenn ihr vorhabt, die WAI-ARIA-Rolle „application“ zu verwenden, haltet inne und überlegt zweimal, ob ihr sie wirklich braucht! Und hier kommt wieso:

Was ist das?

„application“ gehört zu den WAI-ARIA landmark roles, also Rollen, die bestimmte Navigationspunkte in Webdokumenten setzen. Sie wird dazu verwendet, Teile einer Webapplikation auszuzeichnen, die wie eine Desktopanwendung behandelt werden sollen, nicht wie ein Dokument im Web. Wenn ihr also Webapplikationen baut, die aus ungefähr über 90% Widgets bestehen und auch ansonsten keine Ähnlichkeit mit einer herkömmlichen Webseite haben, könnte die Benutzung von „application“ angemessen sein. Wenn ihr im Gegensatz dazu aber eine Benutzeroberfläche baut, die aus klassischen Eingabeelementen wie Textfeldern, Kontrollfeldern, Ausklapplisten usw. besteht und darüber hinaus weit verbreitete komplexere Widgets vorkommen, und eure Seite ansonsten aus dokumentüblichen Strukturen wie Hyperlinks besteht, lasst die Finger von role „application“! Screen Reader und andere assistive Technologien, die WAI-ARIA unterstützen, wissen in der Regel mit solchen Elementen automatisch richtig umzugehen.

Warum sollte ich sie überhaupt verwenden?

Klassischerweise wandeln assistive Technologien wie Screen Reader für Blinde Webseiten in ein Ausgabeformat um, das für diese Zielgruppe einfacher zu verstehen ist. Ein zweispaltiger Text im Zeitungsstil wird in ein einspaltig vom Beginn bis zum Ende fließendes Dokument umgewandelt. Mehrspaltige Seitenlayouts werden so verschlankt, dass sie einen logischen Fluss bilden und für jemanden, der den Bildschirm nicht sehen kann, erfassbar werden, ohne dass es ein großes Durcheinander an Informationen gibt.

Um dies zu erreichen, haben assistive Technologien, speziell unter Windows, ein zweistufiges Interaktionsmodell entwickelt:

virtueller Cursor oder Browse-Modus
Dies ist der Modus, in dem Screen Reader operieren, wenn sich der Benutzer eine Webseite anschaut. Der Begriff virtueller Cursor wird seit seiner Erfindung im jahr 1999 verwendet und bedeutet, dass der Benutzer eine Webseite mit den Pfeiltasten durchlaufen kann als würde er ein MS-Word- oder Editor-Dokument lesen. Neben dem eigentlichen Text werden semantische Informationen vorgelesen wie ob ein Element ein Link, eine Schaltfläche, Teil einer Datentabelle, ein Formularelement ist usw. Weiterhin werden auch viele Tastatureingaben abgefangen und nicht an den Browser weitergegeben. Diese werden dazu verwendet, sich innerhalb solcher virtueller Dokumente schnell zu bestimmten Elementen zu bewegen wie Überschriften, Formularelementen, Links, Listen, Tabellen usw. Dies wird üblicherweise durch den Druck auf einzelne Buchstaben erreicht. Der visuelle Fokus kann sich dem aktuellen Element, auf das der virtuelle Cursor zeigt, angleichen, wenn dieses den Fokus erhalten kann, muss dies aber nicht zwangsläufig tun; das hängt von der Implementierung und manchmal auch den Einstellungen des verwendeten Screen Readers ab.
Formular- oder Fokus-Modus
Dieser Modus ist aktiv, wenn der Anwender mit Elementen interagiert, die irgendeine Form von Dateneingabe akzeptieren. Dies kann eine Texteingabe, das Umschalten eines Kontrollfeldes, die Auswahl eines bestimmten Auswahlschalters (radio button) oder die Auswahl in einer Ausklappliste sein. Um in diesen Modus zu gelangen, steuert der Anwender den virtuellen Cursor auf ein solches Element und drückt entweder Eingabe oder der Screen Reader aktiviert bei Erreichen eines solchen Elements den Fokus-Modus automatisch. Andere Screen Reader aktivieren diesen Modus z. B. aber nur dann, wenn explizit mit tab auf so ein Element gesprungen wird. In diesem Modus werden alle tastatureingaben an den Browser durchgereicht. Es ist so als wenn ihr ohne Screen Reader vor eurem Browser sitzt und ihn mit der Tastatur bedient. Analog wird dieser Modus wieder abgeschaltet, wenn man entweder eine Taste wie escape drückt oder der Anwendungsfokus so ein Element wieder verlässt und der Screen Reader diesen Modus vorher selbstständig eingeschaltet hatte. Es wird zum virtuellen Cursor/Browse-Modus zurückgekehrt. Hinweis: Einige Elemente wie Schaltflächen und Links benötigen das Einschalten des Fokus-Modus nicht, weil sie vom Screen reader direkt aktiviert werden können und man so eine Zeitersparnis erreicht.

Die Herausforderung besteht darin, dass ihr vielleicht Widgets erstellt, die ein Erzwingen des Fokus-Modus erforderlich machen. Voraussetzung ist, dass euer Widget am besten benutzt werden kann, wenn sich der Screen Reader nicht im Browse-Modus befindet. Voraussetzung ist weiterhin, dass die Applikation so gut wie keine klassischen Dokumentinhalte enthält, und dass alle Widgets, die vorhanden sind, den nötigen Kontext bereitstellen. Als Faustregel sind hier 90 oder 95 Prozent ansetzbar. Dann, und nur dann, ist ein Einsatz der Rolle „application“ sinnvoll. Ihr habt nämlich in diesem Moment die kontrolle darüber, dass der Anwender in den Fokus-Modus gezwungen wird, und es liegt in eurem Verantwortungsbereich, ein vernünftiges Tastaturinteraktionsmodell zu entwickeln und auch die Rückkehr in den Browse-Modus zu ermöglichen. Im Gegensatz zum normalen Fokus-Modus bewirkt die Rolle „application“ nämlich, dass man nicht so einfach wieder zum Browse-Modus zurückkehren kann, um sich z. B. die umliegenden Informationen des Dokuments durchzulesen.

Wann soll ich sie denn nun verwenden, und wann nicht?

Ihr verwendet die Rolle „application“ nicht, wenn ihr eine Benutzeroberfläche baut, die nur aus in HTML eh schon vorhandenen Widgets besteht. Das gilt auch für Widget-Klone, die ihr aus WAI-ARIA-Rollen und eigenem Tastaturinteraktionsmodell zusammenbaut:

  • Textfelder inklusive Passwortfeldern, Suchfeldern, Telefonnummern, E-Mail und anderen neuen input-Typen.
  • Mehrzeilige Textfelder (textarea)
  • Kontrollfelder (checkbox)
  • Schaltflächen (button)
  • Auswahlschalter (radio button), die normalerweise in ein Konstrukt aus fieldset und legend eingefasst sind
  • Ausklapplisten (select und option)
  • Links, Absätze, Überschriften und andere Strukturen, die es nativ in klassischen Dokumenten im Web gibt.

Ihr verwendet sie ebenfalls dann nicht, wenn eure Benutzeroberfläche dynamische, fortgeschrittene Widgets der folgenden Typen enthält. Screen Reader und andere assistive Technologien, die WAI-ARIA unterstützen, unterstützen bei diesen standardmäßig ein Umschalten zwischen Browse- und Fokus-Modus analog zu nativen HTML-Widgets.

  • Strukturansicht tree view)
  • Schieberegler slider)
  • Tabellen, die fokusierbare Elemente enthalten wie eine Liste von E-Mail-Nachrichten, interaktive Gitter und Gitterbäume usw. grid, treegrid)
  • Eine Liste von Reitern tab, tablist), bei denen der Anwender mit den Pfeiltasten rechts und links einen Reiter wählt. Beachtet, dass ihr hierfür das Tastaturverhalten implementieren müsst!
  • Dialogfelder und Hinweisdialogfelder dialog, alertdialog). Diese werden von Screen Readern implizit als Anwendungsbereich behandelt, sobald sich der Fokus zu einem in ihnen enthaltenen Element bewegt. Hinweis: Diese verhalten sich am besten, wenn dem Element, das die Rolle „dialog“ oder „alertdialog“ enthält, das Attribut aria-describedby gegeben wird, dessen Wert auf die ID desjenigen Kindelements verweist, das den erklärenden Text enthält. Dadurch wird dieser Text automatisch vom Screen Reader vorgelesen, bevor das Element mit Fokus gesprochen wird.
  • Symbolleisten und deren Elemente, Menüs und deren Menüeinträge toolbar, menu, menuitem) und ähnliche

Ihr solltet die Rolle „application“ nur dann verwenden, wenn eure Benutzeroberfläche zum größten Teil aus interaktiven Widgets, und hier vornehmlich aus fortgeschrittenen, nicht nativen Widgets, besteht, sich wie eine Desktopanwendung verhält und keine klassischen Dokumentinhalte enthält. Beachtet, dass, obwohl sich heute vieles Webapplikation nennt, das meiste davon unter der Haube doch weiterhin dokumentenbasierte Daten darstellt. Facebook-Statusnachrichten und deren Kommentare, Twitter-Zeitleisten, Blogartikel,selbst viele Akkordeons, die dynamisch Inhalte ein- und ausblenden können, sind in der Regel so stark dokumentenorientiert, dass die Rolle „application“ hier völlig unangemessen wäre und das Benutzen und Lesen der Informationen nur behindern würde. Wir arbeiten im Web weiterhin primär mit Dokumentstrukturen, obwohl an der Oberfläche vieles inzwischen aussieht wie eine Desktopanwendung.

Kurz gesagt: Die Fälle, in denen die Rolle „application“ wirklich zur Benutzung angemessen ist, dürften sehr rar gesäht sein!

Wo packe ich es denn hin?

Setzt die role auf das nächstgelegene Elternelement eurer Widgets, z. B. das sie umschließende div-Element. Wenn nämlich nur die Widgets eingeschlossen werden, die dieses Applikations-Interaktionsmodell wirklich benötigen, wird so sichergestellt, dass der Browse-Modus wieder eingeschaltet wird, sobald der Fokus diesen als „application“ gekennzeichneten Bereich verlässt.

Setzt das Attribut nur dann auf das body-Element, wenn die gesamte Applikation zu ca. 95% Elemente enthält, die den Fokus-Modus benötigen. Sollte es hierin auch Teile geben, die als Dokument behandelt werden müssen, nutzt für diesen Bereich die Rolle „document“. Sie ist das Gegenstück zur Rolle „application“. Zusätzlich müsst ihr durch setzen des tabstop-Attributes sicherstellen, dass der Fokus in diesen als Dokument ausgezeichneten Bereich gelangen kann, wenn der Nutzer mit tab durch eure Webapplikation navigiert.

In einem solchen Fall, wo 90 oder 95 Prozent eurer Inhalte Widgets sind, kann das Benutzen der Rolle „application“ angemessen sein. Aber selbst dann solltet ihr jemanden finden, der eure Anwendung in zwei Versionen testen kann, einmal mit und einmal ohne die Rolle „application“, um herauszufinden, ob dieses Interaktionsmodell wirklich die beste Lösung darstellt.

Setzt das Attribut NIEMALS auf so ein Element wie body, wenn eure Seite weitgehend aus traditionellen Widgets oder Dokumentinhalten besteht. Dies führt nur zu Frustration und schlechter Benutzbarkeit eurer Seiten!

Einige Beispielseiten

Die Seite, die mich dazu veranlasste, diesen Artikel zu schreiben, ist die neueste Version des Googlemail-Layouts. Google behandelt das ganze Teil als „application“, so dass man zig dutzendmal tab drücken muss, um zur Tabelle mit den Mails des Posteingangs zu gelangen. Hätten sie die Rolle richtig eingesetzt, bräuchte der Anwender nur die Taste t in seinem Screen Reader zu drücken und stünde sofort auf der Tabelle mit den Nachrichten, anstatt 30 oder 40mal tab drücken zu müssen. Ja, Google statten uns mit den Tasten j und k aus. Abgesehen davon, dass man über diese erst einmal bescheid wissen muss, funktionieren sie aber nur in der Kombination Chrome und ChromeVox. In allen anderen Browsern und Screen Readern wird zwar der visuelle Fokus verschoben, es wird jedoch kein echter Fokus auf das Zielelement gesetzt, so dass dieser Fokuswechsel für Screen-Reader-Anwender unbemerkt bleibt. Anders als Google es uns glauben machen will, ist Googlemail unter der Haube immer noch weitestgehend eine dokumentenbasierte Anwendung, in der viele traditionelle Navigationsmodelle uneingeschränkt gültig sind und die Rolle „application“ völlig unangemessen ist.

Ein Beispiel, in dem die Rollen „application“ und „document“ tatsächlich richtig angewandt werden, ist das aktuelle Yahoo!-Mail-Interface. Die Nachrichtenliste befindet sich in einem Bereich, der als „application“ gekennzeichnet ist. Man navigiert mit den Pfeiltasten durch die Nachrichten und öffnet sie mit Eingabe. Der Nachrichtenbereich selbst ist, während alles rundherum eine „application“ ist, ein „document“, in dem die Kopfzeilen und der Nachrichtentext angezeigt werden. Hier wird auch der Fokus hingesetzt, so dass der Screen Reader automatisch in den Browse-Modus schaltet und der Anwender die Mail sofort in vertrauter Umgebung lesen kann.

Scherzhafter disclaimer: Yahoo! bezahlen mir kein Geld dafür, dass ich sie dauernd bewerbe und darauf hinweise, wie gut ihnen das Mail-Webinterface gelungen ist. Sie haben nur ein verdammt gutes Produkt abgeliefert, das ist alles! 😉

Abschließendes

Wenn ihr Fragen zu diesem Thema habt, scheut euch nicht, sie in Kommentaren zu diesem Eintrag zu stellen! Ich werde sie möglichst zeitnah zu beantworten versuchen und wichtige Punkte als Updates zu diesem Blogpost verarbeiten. Weiterhin gibt es die englischsprachige Mailingliste free-aria, in der solche Themen auch mit anderen Webentwicklern, Anwendern und Standards-Experten diskutiert werden können.

Dies ist ein wichtiges Thema, das, wenn es richtig gemacht wird, eine sehr gute und flüssige Arbeitsweise ermöglicht, wenn falsch angepackt jedoch auch zu echten Problemen führen kann.

Nutzt die Rolle „application“ also nur dann, wenn Tests zeigen, dass dies zu einem besseren Interaktionsmodell führt. Wenn ihr sie dann einsetzt, tut es mit Augenmaß, der Aufwand lohnt sich!

Kategorien
NVDA WordPress Zugänglichkeit

Tipp: Mit einem Screen Reader mit den dynamischen Menüs des WordPress-3.3-Adminbereiches umgehen

WordPress 3.3 führt neue, dynamische Menüs im Administrationsbereich ein. Dieser einfache Tipp soll zeigen, wie man als Blinder mit einem Screen Reader diese dynamischen Menüs bedienen kann. Hierfür verwende ich NVDA 2011.3RC und Firefox, es geht aber auch mit anderen Screen-Reader- und Browser-Kombinationen.

Diese Untermenüs ermöglichen einen schnelleren Zugriff auf die Untermenüpunkte. Man muss nicht erst einen Hauptmenüpunkt anklicken, auf das erneute Laden der Seite warten und dann auf die aufgeklappten Menüs zugreifen. Stattdessen werden die Untermenüpunkte sichtbar, indem man mit der Maus drüberfährt, sogenanntes Hovern, oder mit tab auf den jeweiligen Link springt und Enter drückt.

Das Problem für Screen-Reader-Benutzer ist, dass die Enter-Taste in der Regel vom Screen Reader abgefangen und für eine Funktion innerhalb des sogenannten virtuellen Dokuments oder Browse-Modus verwendet wird. Normalerweise wird durch Druck auf Enter ein Link aktiviert.

Genau das wollen wir ja aber nicht, denn das Aktivieren eines Links erzeugt ein Neuladen der Seite, und sämtliche Vorteile des schnelleren Zugriffs auf die dynamischen Menüs wären dahin.

Stattdessen tun wir folgendes:

  1. Mit dem virtuellen Cursor auf einen dieser „Untermenü Link“-Elemente wandern.
  2. NVDA-Taste+F2 drücken, um NVDA anzuweisen, den nächsten Tastendruck ungefiltert an den Browser weiterzugeben.
  3. Enter drücken.
  4. Mit dem virtuellen Cursor nach unten wandern und ein aufgeklapptes Menü vorfinden.

Diese Methode funktioniert analog mit anderen Screen Readern. Manche Screen Reader fokussieren jedoch nicht automatisch das unter dem virtuellen Cursor befindliche Element. Vor dem obigen Schritt 2 muss also eventuell noch eine Tastenkombination gedrückt werden, mit der der System-Fokus oder PC Cursor zum virtuellen Cursor gezogen wird.

Die oben beschriebene Methode ist ein Tastendruck mehr. Das stimmt, aber diese Vorgehensweise ist immer noch schneller als auf das erneute Laden einer Seite zu warten und dann die aufgeklappten Menüs wieder vom Anfang des virtuellen Dokuments an suchen zu müssen.

Viel Spaß beim Bloggen!

Kategorien
ARIA Zugänglichkeit

Von WAI-ARIA nach HTML5 und zurück, oder doch nicht?

Auf dem Multimediatreff 28 in Köln am 3. Dezember hielt ich einen Vortrag über Barrierefreiheit mit WAI-ARIA und HTML5. Als Beispiel zog ich hierfür meinen einfachen ARIA-Tip #2 heran und entwickelte diesen weiter. HTML5 bietet inzwischen viele der Fähigkeiten, die WAI-ARIA mitbringt, nativ, und viele davon sogar besser.

Von WAI-ARIA nach HTML5

Wer das im obigen verlinkten Artikel entwickelte Formular nicht mehr ganz parat hat, dem empfehle ich einen erneuten Blick darauf zu werfen. Die folgenden Änderungen habe ich vorgenommen, um das Formular von WAI-ARIA und HTML 4.01 auf HTML5 zu bringen:

  1. Allen JavaScript-Code rausschmeißen. Die Formularvalidierung von HTML5 nimmt uns viel Arbeit ab. Da bauen wir lieber wieder was ein, wenn wir merken, dass das Formular zu wenige Features hat.
  2. aria-required ändern in required. Sämtliche erforderlichen Formularfelder bekommen das WAI-ARIA-Attribut inklusive Wert gestrichen und einfach das HTML5-Formularelementattribut required verpasst.
  3. Das Feld „name“ bekommt ein pattern-Attribut mit einem regulären Ausdruck verpasst, der besagt, dass das Feld nur dann gültig ausgefüllt ist, wenn der eingegebene Name aus beliebigen Zeichen, einem Leerzeichen und weiteren beliebigen Zeichen besteht. Ein Name ist in unseren Breiten üblicherweise aus Vor- und Nachname zusammengesetzt, und das sollte das Formular wissen.
  4. Das Feld „email“ bekommt als type den Wert „email“, das Feld „website“ den type „url“ gesetzt. Dadurch weiß der Browser, dass er eine E-Mail- bzw. Webseiten-Adresse zu erwarten hat. Weiterhin hat dies den positiven Nebeneffekt, dass auf mobilen Geräten gleich die entsprechend verbesserten virtuellen Tastaturen eingeblendet werden. Mir ist bewusst, dass die meisten Browser zur Zeit noch nichts mit internationalen Domains anfangen können bzw. Felder mit solchem Inhalt noch nicht validieren. Wir decken der Einfachheit halber aber mal den großen Teil der allgemeinen Fälle ab.
  5. Im Feld Name fügen wir noch ein Attribut x-moz-errormessage hinzu. Das Präfix besagt, dass dies kein Standard-Attribut für HTML5 ist. Mozilla-basierte Browser können aber eine bessere Fehlermeldung ausgeben. Achtung, die ist natürlich dann nicht lokalisiert, erscheint also auch in einem englischen Firefox auf deutsch!

Mit diesen Änderungen kann unser Formular jetzt folgendes:

  1. Namen, E-mail-Adresse und Webseitenadresse automatisch validieren und den Status auf „ungültig“ setzen, wenn ein Feld die Anforderungen nicht erfüllt.
  2. Der Firefox schickt bei mindestens einem ungültig ausgefüllten Formular dieses beim Klick auf den Button nicht ab, sondern gibt eine Fehlermeldung aus und setzt den Fokus auf das Eingabeelement, in dem noch ein Problem besteht. Bei Tests im Safari in Mac OS X Lion zeigte sich, dass dieser das Formular dennoch abschickt, obwohl ungültige Eingaben vorhanden sind. Hier weichen die Implementierungen also voneinander ab

Und zurück zu WAI-ARIA

Und was kann unser Formular noch nicht wieder? Richtig: Die Ausgabe einer Fehlermeldung bei Verlassen eines Eingabefeldes. Dies unterstützen Browser bisher nicht standardmäßig, eine Validierung bei Fokusverlust, die sofort per Fehlermeldung bescheid sagt, wenn etwas nicht in Ordnung ist. Also müssen wir das JavaScript aus dem ursprünglichen Formular wieder einbauen und wie folgt abändern:

  1. Den Namen der function „checkEntryValidity“ in „testIfEntryIsValid“ ändern, weil der ursprüngliche Name im HTML5-Kontext mit einem reservierten Bezeichner kollidiert.
    Die Parameterliste verschlanken. Die Funktion braucht nur noch die ID des zu überprüfenden Elements, weil alles andere von HTML5 erledigt bzw. bereitgestellt wird.
    Die Funktion so abändern, dass:

    1. Keine aria-invalid-Attribute mehr gesetzt werden.
    2. Keine zeichenvergleiche mehr angestellt werden, sondern lediglich das Ergebnis des Funktionsaufrufs checkValidity() ausgewertet wird. checkValidity() gibt true zurück, wenn das Feld einen gültigen Eintrag enthält, sonst false.
    3. Den bisherigen Parameter aMsg ersetzen durch einen Aufruf der Eigenschaft validationMessage des jeweiligen Elements. Diese enthält die Fehlermeldung, die Firefox auch beim Absenden des Formulars generiert und die beim Drüberfahren mit der Maus als Tooltip angezeigt wird. Enthält das Element ein title-Attribut, wird dessen Wert an diese Fehlermeldung angehängt. Ist x-moz-errormessage angegeben, enthält der erste teil von validationMessage diesen Text.

    </li

  1. Den Feldern „name“ und „email“ wieder onBlur-Handler geben, die die Funktion testIfIsEntryValid aufruft und die ID des zu prüfenden Feldes übergibt, damit bei Fokusverlust des Feldes eine Prüfung erfolgt und ggf. ein Alert generiert wird.

Mit diesen Änderungen ist unser Formular nun wieder voll funktionsfähig, besitzt jedoch verbesserte Validierungseigenschaften als vorher. Auf mobilen Geräten werden entsprechende Tastaturen eingeblendet, wenn man die E-Mail- und Webseiten-Adressen ausfüllt.

Zusammenfassung

HTML5 bietet uns also viele Funktionen frei haus, die wir früher mit eigenem JavaScript nachbauen mussten. Der Code wird schlanker. Die Lücke, die HTML5 nicht schließt, ist die Validierung bei Fokusverlust und die Ausgabe der Fehlermeldung. Diese müssen wir weiterhin durch WAI-ARIA realisieren. Wir gehen also zu einem guten Stück von WAI-ARIA-Attributen weg, und das ist auch gut so! Dort, wo es sinnvoll ist und es eine Ergänzung darstellt, nutzen wir es aber weiterhin, um unser einfaches Formular noch benutzerfreundlicher zu gestalten. Wo man kann, sollte man WAI-ARIA also durch HTML5 ersetzen, wenn man moderne Webseiten und -applikationen entwickelt. Dort, wo es Sinn macht oder HTML5 noch Lücken lässt, sollte man WAI-ARIA aber nach wie vor einsetzen!

Sämtliche drei Beispiele sind von dieser Seite verlinkt. Viel Spaß beim Spielen und Nachbauen!

Ich freue mich selbstverständlich über Feedback! Das JS hier ist jedoch absichtlich sehr einfach gehalten, weil es nur das Konzept verdeutlichen soll und keine fertige Lösung darstellt.

Kategorien
Zugänglichkeit

Mehrere nicht barrierefreie Relaunches in dieser Woche, die Wut ist groß

In dieser Woche gab es gleich mehrere Anlässe, weswegen ich das Gefühl hatte, mal einmal gepflegt über den Tisch kotzen zu wollen. Entschuldigt die derbe Ausdrucksweise, aber was anderes fällt mir zu den Relaunches des Bayerischen Rundfunks und von Der Westen nicht mehr ein.

Bayerischer Rundfunk

Fangen wir mal mit dem Bayerischen Rundfunk an. Aufmerksam wurde ich durch einen Tweet von Eric Eggert. Als Nordlicht ist der BR nicht unbedingt jeden Tag Ziel meiner Surfaktivitäten. Nach den ersten Hinweisen von Eric habe ich mir die Seite dann selbst angeschaut und bin doch ziemlich entsetzt. Folgende Dinge fallen sofort ins Auge bzw. für den Screen-Reader-Benutzer ins Ohr:

  • Zumindest für Firefox-Nutzer gibt es Sprunglinks, die auch zu halbwegs vernünftigen Zielen auf der Seite (und ich rede erst einmal nur von der Startseite) führen. Für Tastaturbenutzer von Webkit-Browsern (Safari, Chrome) scheint dies noch problematischer zu sein, wie dieser Tweet zeigt.
  • Die Überschriftenhierarchie lässt jegliche Konsistenz oder Konsequenz vermissen. So liegen die Hauptüberschrift „Bayerischer Rundfunk“ und die Überschrift zur Breadcrumb-Darstellung auf Ebene 1, die Überschrift „Inhalt“ sowie ein einzelner Artikel auf Ebene 2, die restlichen Artikelteaser auf Ebene 3. Die Überschrift „Hilfe und Kontakt“ liegt wieder auf Ebene 2.
  • Die Artikelteaser selbst bestehen aus einem Kuddelmuddel aus Text und Grafiken, eingefasst in Überschriften. Ein Beispiel, abgerufen am 28.10.2011:
    <h3>
    <a href="/themen/aktuell/inhalt/bundeswehr-standortschliessungen-bayern100.html" class="link_article contenttype_standard bundeswehr-standortschliessungen-bayern100" title="zum Artikel | Aktuell">
    <span class="teaser_picture">
    <img width="256" height="144" alt="Hinter wuchernden Pflanzen ist vor der Artillerie-Kaserne in Kempten das Wort Kaserne zu lesen. | Bild: picture-alliance/dpa" title="Hinter wuchernden Pflanzen ist vor der Artillerie-Kaserne in Kempten das Wort Kaserne zu lesen. | Bild: picture-alliance/dpa" src="/themen/aktuell/inhalt/kasernenschild100~_v-image256_-a42a29b6703dc477fd0848bc845b8be5c48c1667.jpg?version=1319722326985"/>
    <span class="teaser_icon">
    <span class="link_target"> zum Artikel </span>
    </span>
    </span>
    <span class="teaser_headline">
    <span class="teaser_overline">Bundeswehrreform</span>
    <span class="teaser_title">Suche nach einer neuen Zukunft</span>
    </span>
    </a>
    </h3>

    • Zum einen ist die Verdoppelung des Title zum Alternativtext des Images völlig unnötiger Ballast.
    • Das ganze in einen Link zu packen macht zwar alle Bestandteile klickbar, und man kommt zum Artikel, macht den Linktext für Screen Reader aber auch so behäbig lesbar, dass das spätestens beim dritten Artikel tierisch zu nerven anfängt.
    • Und nein, der Title für den Link wird nur in den wenigsten Fällen als Ersatz für vorhandenen Linktext für Screen Reader herangezogen.
    • Dass das ganze in ein H3 gepackt wurde, erlaubt wenigstens noch die Ansteuerung per Schnellnavigation, das H3 erfüllt sonst aber, glaube ich, so gut wie keine Funktion.

    Für Screen Reader hört sich dieser Teil der Seite dann übrigens so an:

    Hinter wuchernden Pflanzen ist vor der Artillerie-Kaserne in Kempten das Wort Kaserne zu lesen. | Bild: picture-alliance/dpa Grafik
    zum Artikel
    Bundeswehrreform
    Suche nach einer neuen Zukunft Überschrift Ebene 3

Öffnet man nun den oben auseinandergenommenen Artikel, offenbart sich wieder eine in teilen inkonsistente, aber doch etwas besser gelungene Überschriftenhierarchie. Auch hier wird wieder auf einen Artikel, in diesem Fall auf ein Interview, verlinkt, und das „Ungetüm“ liest sich genauso behäbig wie die Verlinkungen auf der Startseite.

Hier wurden zwar semantisch durchaus korrekte, von der usability her aber sehr unhandliche Strukturen geschaffen. Da hat offensichtlich niemand mit einem Screen Reader für Blinde mal drübergelesen, um sich anzuhören, was da eigentlich entsteht.

Es gibt auch hier und da noch auf Pfeilen fehlende Alternativtexte, die habe ich im einzelnen jetzt aber nicht rausgesucht. Es gibt jedenfalls an diesem Relaunch von der Usability her, von der Tastaturnavigation und von den Überschriftenstrukturen genug anzumerken um festzustellen, dass hier keine wirklichen Experten am Werk waren und das Ergebnis auch nicht von fachkundiger Seite geprüft wurde. Für eine Institution der ARD, die mit staatlichen Mitteln und GEZ-Gebühren gefördert wird und somit der BITV unterliegen dürfte, ein absolut erbärmliches und nicht schönzuredendes Ergebnis!

Der Westen

Gegen das, was derwesten.de aber in dieser Woche als Relaunch abgeliefert hat, muss man zwangsläufig beim BR noch von Luxus sprechen, vorausgesetzt man würde das als Maßstab betrachten. Denn:

  • Keine Skip-Links.
  • Keine Überschriften, stattdessen so Monstren aus den 1990ern wie
    A 40 in Duisburg wird am Wochenende zum Nadelöhr

    . „hl“ steht dabei vermutlich für „Header large“ oder so.

  • Auch entsetzlich und von Eric Eggert auf Twitter gepostet:

    . Naja vielleicht sollten wir wenigstens dafür dankbar sein, dass nicht tatsächlich eine Layouttabelle verwendet wurde, oder wie?

Bei soviel Dilettantismus allein schon auf der Startseite erübrigt sich das Anschauen jeder weiteren Seite dieses im Oktober 2011 relaunchten Webauftritts. Die Note 6 steht jetzt schon fest.

Warum?

Die große Frage, die ich mir beim Lesen solcher Webauftritte stelle, ist, WARUM? Warum wird für so einen Mist so viel Geld verschwendet? Warum beherrscht nicht inzwischen jede halbwegs seriöse Webagentur in Deutschland wenigstens die Grundregeln modernen Webdesigns und warum rotzen uns immer noch so viele deutsche Webagenturen einen solchen 90er-Jahre-Dreck vor die Füße? Müssen wir uns das gefallen lassen? Denkt wirklich niemand in den Entscheidungsgremien mal daran, dass sie selbst in nicht allzu ferner Zukunft älter sein werden, Sehfehler bekommen, vielleicht eine Maus nicht mehr richtig halten werden können? Barrierefreies Webdesign ist nicht primär was für Blinde, sondern geht primär jeden etwas an, denn wir werden alle älter und nicht jünger, und wir wollen auch im Alter unsere Webauftritte bedienen können. Dazu braucht es ein weitsichtigeres Denken als das, was hier demonstriert wird. Nachhaltigkeit ist das Stichwort, und davon ist hier nichts zu spüren. Und da möchte man als jemand, der seit 15 Jahren für mehr Barrierefreiheit im Web eintritt, manchmal echt fragen, ob man nur für die Luft um einen herum aufklärt. Ich weiß zum Glück, dass es auch und gerade im Pott eine ganze Menge sehr fähiger Webagenturen gibt, die sich das Thema Barrierefreiheit zu einem Grundprinzip gemacht haben und dies all-inclusive in ihre Webauftritte mit einbauen und dass die Arbeit daher definitiv nicht um sonst ist. Es entsetzt mich jedoch, dass nach 15 Jahren bei so vielen großen und teuren Webagenturen davon anscheinend immer noch nichts angekommen ist!

Kategorien
Apple ARIA Zugänglichkeit

Mac OS X Lion ist da, Eindrücke von den neuen Barrierefreiheitsfunktionen

Apple hat soeben die neueste Version seines Betriebssystems Mac OS X, Lion, veröffentlicht. Eine gute Gelegenheit, einen Blick auf die neuen Barrierefreiheitsmerkmale der jüngsten Raubkatze zu werfen!

Neue Stimmen in vielen Sprachen

Apple bietet für Lion Stimmen in niedriger und hoher Qualität in über 40 Sprachen und Dialekten an. Diese sind in kompakter Version für viele Sprachen bereits vorinstalliert. So kommt die deutsche Variante mit der Stimme Yannick daher, die bereits aus aktuellen iOS-Veröffentlichungen vom iPhone/iPod Touch und iPad bekannt ist. Eine höherwertige Version dieser Stimme sowie die Stimmen Steffi und Anna können nachgeladen werden. All diese Stimmen, also auch die ausländischen, werden von Apple kostenlos zur Verfügung gestellt. Man wählt sie einfach im VoiceOver-Dienstprogramm unter Sprachausgabe, Standard-Stimme, Menüpunkt „Anpassen“… aus und lädt sie dann über die automatisch sich öffnende Softwareaktualisierung herunter.

Aber auch für die Freunde der bereits für Leopard und Snow Leopard verfügbaren Stimmen der á Capella Group, die über AssistiveWare heruntergeladen und käuflich erworben werden können, gibt es Entwarnung: Diese funktionieren weiterhin, bei mir nach einem Upgrade von Snow Leopard auf Lion sogar ohne neuinstallation oder erneute Aktivierung. Wem also die Nuance-Stimmen nicht gefallen, der kann weiterhin Infovox iVox nutzen. AssistiveWare sagen selbst, dass sie bis Ende des Monats ihre Produkte auf mit Lion kompatible Versionen aktualisieren wollen, meine Tests mit den Stimmen haben allerdings gezeigt, dass die reinen Stimmenpakete anscheinend weiterhin problemlos funktionieren.

Die Tatsache, dass Stimmen u. a. für Deutsch vorinstalliert sind, bedeutet, dass man jetzt in einem Apple oder Gravis Store nicht nur iPhones und iPads in seiner Muttersprache ausprobieren kann, sondern auch alle Varianten des Macs. Bei einer frischen Installation von Lion auf deutsch wird automatisch mit Yannick Compact gesprochen, so dass VoiceOver ohne Installation einer externen Sprachausgabe sofort in deutsch zu sprechen beginnt.

Einziger Wermutstropfen: Während der Installation wird diese Stimme noch nicht verwendet, hier quatscht immer noch die Decktalk-Variante „Fred“ in allen Sprachen. Dies gilt aber nur für den Installationsvorgang von der Recovery-Partition, nicht für das Setup nach der allerersten Installation. Der Assistent, bei dem man u. a. nach seiner Apple-ID gefragt wird, wird bereits mit einer deutschen Stimme begleitet.

Neue Braille-Funktionen

VoiceOver liefert jetzt Brailletabellen in verschiedenen Sprachen mit, unter anderem deutsch. Auch die Kurzschriftübersetzung ist für deutsch und weitere unterstützte Sprachen verfügbar. Leider gibt es zur Zeit keine Möglichkeit, bei der Kurzschriftübersetzung die Anzeige von Großbuchstaben abzuschalten, so dass die Kurzschriftdarstellung nicht ganz der eines Standard-Buches entspricht, in der es ja keine Anzeige von Großbuchstaben gibt.

Durch Brailleausführlichkeit kann man jetzt angeben, was in verschiedenen Situationen angezeigt werden soll und somit gerade auf kleineren Displays den Platz effizienter nutzen.

Aktivitäten

VoiceOver-Aktivitäten sind Sätze von Einstellungen, auf Wunsch alle, die das VoiceOver-Dienstprogramm zur Verfügung stellt, die für bestimmte Situationen oder bestimmte Anwendungen angepasst werden können. So kann man z. B. eine Aktivität für eine Anwendung einstellen, oder man öffnet mit VO+X ein Menü aller verfügbaren Aktivitäten, weil man im Web zum Einkaufen vielleicht eine schnellere Sprechgeschwindigkeit und andere Stimme verwendet als zum Lesen von Artikeln, Blogs usw. Eine Aktivität kann hierbei durchaus auch auf mehrere Anwendungen automatisch angewendet werden.

Ziehen und Ablegen (Drag and Drop)

VoiceOver unterstützt jetzt das automatisierte Drag and Drop. Dies war bisher durch eine Kombination mehrerer Befehle bereits möglich, wurde jetzt jedoch erheblich vereinfacht.

  1. Man wählt mit den VoiceOver-navigationsbefehlen oder der Tastatur das zu ziehende Objekt an und drückt VO+Komma.
  2. Man navigiert mit dem VoiceOver-Cursor an die gewünschte Zielstelle am Bildschirm und drückt eine der folgenden Tasten:
    1. VO+Punkt zum Fallenlassen auf dem Objekt, auf dem sich der VoiceOver-Cursor gerade befindet. Das Resultat hängt von der Anwendung ab.
    2. VO+< (Kleiner als Das Objekt auf dem Objekt, das dem Objekt, auf dem der VoiceOver-Cursor steht, voransteht. Hierbei ist die Navigationsreihenfolge gemeint, nicht die visuelle Anordnung auf dem Bildschirm.
    3. VO+> (Größer als zum Fallenlassen auf dem Objekt, das dem Objekt unterm VoiceOver-Cursor navigationsmäßig nachfolgt.

Hierbei unterliegt der Vorgang denselben Beschränkungen wie von Windows-Screen-Readern her gewohnt: Sind nicht mehr beide Objekte visuell am Bildschirm sichtbar, weil eines in der Zwischenzeit verdeckt wurde oder weggescrollt ist, schlägt der Vorgang fehl. Auch sind nicht alle Objekte von VoiceOver zum Ziehen freigegeben: Auf den meisten Webelementen erlaubt es schon das Markieren als zu ziehendes Objekt nicht. So kann man z.B. nicht wie der Sehende in Google Plus einen Kontakt auf einen Kreis ziehen, um ihn diesem Kreis hinzuzufügen.

Schnelle Navigation mit einzelnen Buchstaben auf Webseiten

Ähnlich dem Modell von Windows-Screen-Readern kann man in VoiceOver jetzt optional einstellen, dass man durch das Tippen einzelner Buchstaben ohne Umschalttasten wie Befehlstaste zu bestimmten Elementen navigieren kann. Dies sollte Umsteigern den Umstieg noch weiter erleichtern.

Aufgeräumteres VoiceOver-Dienstprogramm

Die Benutzeroberfläche des Dienstprogrammes für VoiceOver wurde an einigen Stellen überarbeitet, um neue Funktionen elegant zu integrieren und einige Tabs übersichtlicher zu gestalten. Weiterhin gibt es jetzt eine Suchfunktion, mit der eine bestimmte Funktion leicht aufgefunden werden kann, wenn man vergessen hat, wo genau sie sich verbirgt.

Unterstützung von Anwendungen

Kalender

Die Navigation und Interaktion mit Kalenderobjekten wurde stark verbessert, auch die Überarbeitung des Kalenders selbst bringt für VoiceOver eine weitere Verbesserung der Zugänglichkeit des ohnehin schon sehr zugänglichen Kalenders.

Mail

Das neue, für meine Begriffe sehr gelungene, mail wird von VoiceOver unterstützt. Es ist also nicht nötig, außer man möchte es aus Gewohnheit tun, auf die klassische Darstellung, die man aus Snow Leopard gewohnt ist, umzuschalten. Die neue, konversationsorientierte, darstellung ist mit VoiceOver genauso nutzbar. Nach wenigen Minuten des Eingewöhnens möchte ich diese Darstellung, die auch schon vom iPad und iPhone bekannt ist, nicht mehr missen. Die Vorschau der einzelnen Mails wird automatisch vorgelesen und gibt so einen schnellen Überblick über den wichtigsten Inhalt der Mail.

Safari

Es werden jetzt Navigationspunkte (WAI-ARIA Landmarks) erkannt. Die deutsche Übersetzung ist etwas hakelig geworden, so sagt VoiceOver beim Erreichen eines Orientierungspunkts z. B. „Banner eingeben“. Warum man nicht einfach die gut funktionierende Übersetzung von iOS genommen hat, erschließt sich mir nicht.

VoiceOver sagt jetzt erforderliche und ungültige Einträge an, wenn diese mit HTML5 oder WAI-ARIA ausgezeichnet sind. Auch werden WAI-ARIA Dialoge und Live Regions unterstützt.

Die Interaktion mit formatierbarem Text, z. B. beim Verfassen einer Mail in GoogleMail, wurde verbessert.

VoiceOver kommt spürbar besser und schneller mit sich dynamisch aktualisierenden Seiten wie Facebook zurecht.

LaunchPad und Mission Control

Auch die neuen Funktionen LaunchPad und Mission Control sind mit VoiceOver bedienbar. Der wirkliche Nutzen erschließt sich mir aber nur, wenn ich die Trackpad-Steuerung aktiviert habe und somit die Objekte tatsächlich berühre. Die Navigation im Gitter mit der Tastatur ist nicht effizienter als das Wählen einer Anwendung aus dem Dock oder dem Programme-Ordner im Finder, sondern eher langsamer, weil man hier keine Möglichkeit der Eingabe von Buchstaben hat, um ein Programm gezielt anzuspringen.

Die neue Rechtschreibkorrektur und Autovervollständigung

Die neue Autovervollständigung wird von VoiceOver unterstützt. Ertönt der auch vom iPhone bekannte Blubberton, kann man mit Pfeil runter die Rechtschreibvorschläge ansteuern, mit rechts und links die einzelnen Vorschläge auswählen und mit Eingabe von z. B. Leerzeichen oder einem Satzzeichen übernehmen, oder man drückt Pfeil rauf, um keinen der Vorschläge zu akzeptieren.

Kleine Detailverbesserungen

Es sind aber auch die Detailverbesserungen, die das Arbeiten unter Lion mit VoiceOver zu einem schönen Erlebnis machen. So werden bei Tabellen, denen von einem programm Zeilen hinzugefügt werden, die gewählten Zeilen nicht automatisch erneut vorgelesen, nur weil neue Inhalte dazugekommen sind. Gerade bei einem Programm wie dem Twitter-Client Syrinx ist dies eine angenehme Reduzierung der Geschwätzigkeit.

Das Vorlesen im Web geht meines Erachtens nach etwas flüssiger vonstatten als unter Snow Leopard. In manchen Situationen (ich habe noch nicht genau herausgefunden, welche) kann man sogar während des Vorlesens eines Absatzes VO+A drücken, und das Vorlesen wird nicht unterbrochen, sondern das Objekt wird zu Ende gelesen und dann mit dem nächsten weitergemacht.

Fazit

Von vielen wird bemängelt, dass Lion kein großer Fortschritt sei. In Bezug auf die Zugänglichkeit dynamischer und mit neuen Technologien wie HTML5 und WAI-ARIA zugänglich gemachter Webinhalte ist VoiceOver in Lion hingegen doch ein sehr großer Fortschritt, da die Menge an unterstützten Widgets dramatisch zugenommen hat.

Auch die neuen Oberflächen von Mail und Kalender sind, wenn man viel mit diesen Programmen arbeitet, das Upgrade definitiv wert.

Etwas weniger sinnvoll ist LaunchPad für VoiceOver-Benutzer, die die Trackpad-Steuerung nicht benutzen.

Die eingebauten und kostenlos herunterladbaren Stimmen sind ein echter Zugewinn! Man ist nicht mehr zwangsweise auf den Erwerb von Stimmen eines Drittanbieters angewiesen, sondern bekommt schön klingende und dennoch sehr reaktionsschnelle Stimmen frei haus mitgeliefert, man muss lediglich ein bisschen Zeit aufwenden, sie per Softwareaktualisierung herunterzuladen.

Für €23,99 bekommt man hier definitiv eine ganze Menge Neues fürs Geld geboten, und ich kann das Upgrade nur wärmstens empfehlen!

Kategorien
Zugänglichkeit

Positive Überraschung: Privatwirtschaftliches Unternehmen mit barrierefreiem Webauftritt

Bei meiner aktuell laufenden Wohnungssuche bin ich auf das Angebot des Wohnquartiers am osterbekkanal in Hamburg gestoßen. Beim ersten Aufruf der Seite fiel mir auf, dass es Skip-Links gibt, die Seite eine Überschriftenstruktur hat und auch ansonsten sehr übersichtlich gegliedert ist.

Die wahre Überraschung erlebte ich, als ich neugierig auf einzelne Wohnungen wurde und wissen wollte, ob die hinterlegten PDFs eventuell noch mehr Informationen als nur den bloßen Grundriss enthalten. Als das PDF herunterlud und sich öffnete, begann mein Screen Reader sofort mit dem Lesen der PDF-Datei! Kein lästiges Dialogfeld des Adobe Readers „Lesen eines Dokuments ohne Tags“, kein „Dokument wird verarbeitet“-Fortschrittsbalken nach Bestätigung des vorigen Dialogs. Nein, die PDF-Datei öffnete sich ohne weiteres Murren, was bedeutet, dass sich jemand die Mühe gemacht hat, sie zu taggen und somit barrierefreier zu gestalten! Das erschloss mir nicht den Grundriss selber, aber einige weitere Informationen. Und allein die Tatsache, dass hier mit Barrierefreiheits-Tags versehene (AKA „durchsuchbare“) PDFs hinterlegt sind, ist eine große Überraschung, die es positiv hervorzuheben gilt! 99,9% aller im Netz befindlicher PDFs sind nicht getaggt, und das schließt viele von Behörden und anderen Regierungsorganisationen zur Verfügung gestellte PDFs mit ein! Das Tagging selbst verlangt (bewusst überspitzt formuliert) fast einen eigenen Studienabschluss. 😉

Und hier ist ein privatwirtschaftliches Unternehmen, das für den Auftritt für dieses Wohnquartier nicht nur diese, sondern auch noch einige weitere Richtlinien zur barrierefreien Webgestaltung erfüllt:

  • Es gibt mit der Tastatur navigierbare und sichtbar werdende Skip-Links.
  • Verschiedene Sektionen wie die Navigation werden mit versteckten Überschriften für Screen Reader eingeleitet.
  • Der zur Zeit hervorgehobene Menüpunkt ist zwar nicht optisch hervorgehoben, wird aber in der Hauptüberschrift deutlich sichtbar wiederholt.
  • Die Schriften sind skalierbar.
  • Die Kontraste sind ausreichend.
  • Die Seite macht auch ohne Farben eine gute Figur.

Vielen Dank an Kerstin für die visuell feststellbaren Punkte, die ich oben aufgeführt habe!

Ich möchte einfach mal hervorheben, dass ich sehr positiv angetan bin vom Webauftritt für dieses Wohnquartier! Es geht also, man kann eigeninitiativ barrierefreie Webinhalte auch als privatwirtschaftliches Unternehmen gestalten, ohne zwangsweise der BITV zu unterliegen!

Ich hoffe, dass sich an diesem Vorbild so manches andere Unternehmen jeder Branche ein Beispiel nimmt!

Super gemacht, weiter so!