News mit tag »WAI-ARIA«

25 Mär 2010

Warum ›Einfach für Alle‹ nicht valide ist

Immer wieder erreichen uns Anfragen, warum der Webauftritt von ›Einfach für Alle‹ nicht gegen HTML 4 und CSS 2 validiert. Die Antwort ist einfach: Barrierefreiheit ist uns wichtiger als valider Code. EfA setzt auf neue Techniken aus der WAI-ARIA-Spezifikation des W3C, um die Zugänglichkeit unseres Angebots zu verbessern.

Der letzte Arbeitsentwurf der WAI-ARIA stammt vom 15. Dezember 2009. Ähnlich wie bei HTML5 gelten einige der Spezifikation schon als stabil und werden von aktuellen Browsern und Hilfsprogrammen unterstützt.

WAI-ARIA erlaubt unter anderem das Definieren von Orientierungspunkten einer Website: Wichtige Elemente wie die Navigation oder der Inhaltsbereich können eindeutig benannt und angesteuert werden. Bei Formularen erlaubt WAI-ARIA das eindeutige Kennzeichnen von Pflichtfeldern. Die endgültige Version der WAI-ARIA sieht auch das Steuern von Schiebereglern und die Verwendung komplexer AJAX-Anwendungen vor.

Diese Eigenschaften werden auch von aktuellen Browsern wie dem Firefox 3, dem Screenreader Jaws 10 und einigen anderen Browsern und Hilfsprogrammen unterstützt. Auch das am 1. Februar 2010 gestartete neue Portal der Aktion Mensch verwendet bereits WAI-ARIA.

Die derzeit aktuellen Versionen von HTML – HTML 4.01 und XHTML 1.0 – kennen die WAI-ARIA noch nicht, deshalb lassen sich unsere aktuellen Websites nicht validieren.

28 Okt 2009

YAML 3.2 - Handwerkszeug für die Barrierefreiheit

Das HTML & CSS-Framework YAML, auf dem auch diese Seiten hier aufgebaut sind, ist seit heute in der fertigen Version 3.2 am Start. Erst vor wenigen Tagen konnte das Projekt seinen vierten Geburts­tag feiern und auch nach einer so langen Zeit ist die Luft für Ver­besserungen und Weiter­ent­wicklungen noch nicht aufgebraucht. Die vor­liegende Version 3.2 bringt einige wichtige Än­derungen mit sich: neben dem schlankeren Framework-Kern, der Verein­fachung der Code-Basis, der Erweiterung der Gestal­tungs­raster (sog. Grids) und den Performance-Gewinnen gibt es eine ganze Reihe von Ver­besserungen im Bereich der Accessibility, die uns natür­lich besonders interessieren.

Barrierefreiheit eingebaut

Kein Framework, auch nicht YAML, ist ein Garant für barriere­freie Web­seiten (obwohl eine ganze Reihe von YAML-basierten Sites bereits mit einer BIENE ausgezeichnet wurden). Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Web­entwicklern das grund­legende Hand­werks­zeug innerhalb von Frameworks zur Ver­fügung zu stellen. In YAML 3.2 wird eine neue Dar­stellungs­möglich­keit für Skiplinks unter­stützt, die ein Über­lagern des Layouts für die einge­blendeten Skiplinks ermög­licht und dadurch die sonst üblichen Probleme bei deren Inte­gration beseitigt. Zudem wird für Webkit-basierte Browser ein JavaScript-Fix mitge­liefert, um auch Apple’s Safari und Google Chrome dazu zu bewegen, den Fokus auf die ange­sprungene ID zu setzen.

Weiterlesen …

Ein weiterer Schritt ist die konse­quente Einbe­ziehung von WAI-ARIA: sämt­liche bei YAML mitge­lieferte Beispiel-Layouts sind nun mit sog. ARIA-Landmark-Roles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Aus­zeichnung sollte nach wie vor der Web­entwickler vornehmen), dennoch ist dieser Schritt wichtig, um trotz der noch fehlenden Vali­dierungs­möglich­keiten im W3C-Vali­dator die positiven Effekte des kommenden Standards hervorzuheben, denn schon heute können alle modernen Browser (einschließlich des IE 8) mit WAI-ARIA umgehen und ermöglichen somit einen deutlichen Zugewinn an Barriere­freiheit auf Web­seiten jeder Komplexitäts­stufe.

Das ›Accessible Tabs‹-Plugin von Dirk Ginader wird mit YAML 3.2 als Erweiterung ein fester Bestandteil des Frameworks. Die Um­setzung im Rahmen dieses Plugins ist mittler­weile ausge­reift, umfang­reich getestet und funktio­niert auch hervor­ragend mit aktuellen Hilfs­mitteln wie Screenreadern.

Entsorgung von Altlasten

Manchmal liegt eine Verbesserung auch im Ver­zicht auf ein Feature: so bot das Framework bisher die Möglich­keit, Spalten­hinter­gründe mit Hilfe der CSS-border-Defini­tion von bestimmten Spalten zu erzeugen. Zwar ist diese Technik denkbar einfach in der Um­setzung, sie beschwört aber in Ver­bindung mit den für viele Seh­behinderte typischen Ein­stellungen von Benutzer-definierten Farben (z.B. den Windows-Kontrastmodi) ein Zugäng­lich­keits­problem herauf, da dort Vorder­grund- und Rahmen­farben auf den gleichen Farb­wert gesetzt werden. Inhalte mit dahinter­liegenden farbigen Rahmen (den simu­lierten Spalten­hinter­gründen) waren infolge­dessen zum Teil nicht mehr lesbar. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein CSS-Anpassung benötigte, die in seltenen Fällen das Aus­wählen von In­halten mit der Maus im Browser blockierte. Daher ist diese Vari­ante nun, auch aufgrund unserer Über­zeugungs­arbeit, nicht mehr im Framework enthalten.

Neben diesen großen Neuerungen stehen zahl­reiche kleinere Korrek­turen, über die das Changelog im Detail Ausfunft gibt. Download des Gesamtpakets, Lizenzbedingungen; YAML Dokumentation: Deutsch (PDF), English (PDF)

01 Sep 2009

Neues in der Werkzeugkiste

Opera

Opera 10 ist ab sofort ohne ›beta‹ und ›release candidate‹ dahinter als fertige Version erhältlich (Download, alternativ per FTP, Packungsbeilage). In der neuen Version ist die WAI-ARIA-Unterstützung ausgebaut worden; viele Neuerungen gab es auch im Bereich CSS – allerdings nur bis zur Version 2.1 (inklusive der HSL- und RGB-Farbräume mit Alpha-Transparenz und Web-Fonts mit @font-face); weitergehende Dinge aus CSS 3 wie das CSS-Column-Modul oder multiple Hintergrund- und Rand-Bilder sind offenbar noch nicht implementiert. Was sonst noch alles neu ist erklärt Chris Mills in der Opera Developer Community: »The Opera 10 experience«, oder im YouTube-Video »Opera 10 Reviewer's Guide«.

JAWS

Eine Nummer weiter ist ab sofort auch der Screenreader JAWS, von dem eine öffentliche Beta der Version 11 bereitsteht (Download, Packungsbeilage). Auch hier hat sich einiges im Bereich der Zugänglichkeit von Web-Applikationen getan – so werden in der neuesten Version ARIA Drag & Drop sowie ARIA Live Regions unterstützt.

20 Mär 2009

Die kleine Browserbastelecke

Wie sich vielleicht schon herumgesprochen hat, ist gestern die finale Version des Internet Explorer 8 zum Download veröffentlicht worden. Haben wir natürlich gleich gemacht, alleine schon um unsere eigenen Seiten komplett durchzutesten – bisher ohne Befund.

Angenehm überrascht hat uns (neben der gesteigerten Geschwindigkeit und den verbesserten Entwickler-Werkzeugen) die vollständige Unterstützung von CSS 2.1 (mit Ausnahme von Appendix A »Aural style sheets«, aber die unterstützt ja auch sonst niemand). Bevor ungeduldige Webdesigner nun einwerfen »Bäh, der kann ja immer noch keine runden Ecken« – runde Ecken werden erst in CSS 3 spezifiziert werden, und das ist im Gegensatz zu CSS 2.1 noch lange nicht beim Status einer ›Candidate Recommendation‹ angelangt. Also freuen wir uns erstmal über das Erreichte.

Weiterlesen …

Standards

Und das ist eine ganze Menge. Die bereits erwähnte Unterstützung des aktuellen CSS-Standards brauchen wir nicht im Detail aufzudröseln, dafür gibt es im Netz ganz wunderbare Vergleichstabellen:

• CSS Browser Support (including IE8 & Safari 4 Beta)
• When can I use...
• CSS3 im IE 8 - Was kann er und worauf muss man achten?
• Compatibility Master Table
• CSS 2.1 Conformance Test Suite

Weitere Infos zum Browser, zur Unterstützung von Web-Standards und zu deren Weiterentwicklung gibt es in einem Interview mit Chris Wilson, Platform Architect for IE bei Microsoft im SitePoint Podcast #11.

Accessibility

Für uns natürlich besonders interessant der Bereich der Zugänglichkeit des Browsers und der dargestellten Inhalte. Auch da gab es enorme Fortschritte – Jonas Hellwig nennt einige davon:

»In Punkto Barrierefreiheit macht der IE8 ebenfalls große Fortschritte! Die neue Funktion ›Caret Browsing‹ ermöglicht dem User eine vereinfachte Bedienung der Website mittels Tastatur. Hierbei soll ähnlich komfortabel navigiert werden wie innerhalb einer Textverarbeitungssoftware.

Die zweite neue Funktion nennt sich ›Adaptive Zoom‹. Hier muss eine Website nicht immer wieder von neuem gezoomt werden, sondern es kann ein individueller Wert in den Einstellungen vergeben werden. Die gesamte Ansicht innerhalb des IE8 wird dann immer in der gewünschten Zoomstufe dargestellt.«

Ebenso neu dabei ist die Unterstützung von WAI-ARIA. Diese zusätzlichen Rollen, Zustände und Eigenschaften können bereits von geeigneten Hilfsmitteln für die effektive Nutzung von Web-basierten Applikationen ausgewertet werden. Einen aktuellen Test der Unterstützung, nicht nur im IE 8, hat Steve Faulkner erstellt: ARIA roles exposed via MSAA by browsers on Windows - Safari 4, Opera 10, IE 8, Firefox 3 & Chrome 1.

Die komplette Übersicht der Neuerungen im Bereich ›Accessibility‹ gibt es im IEBlog: New Accessibility Features in IE8.

Schwarze Listen

Weniger schön ist der Schalter zur vermeintlichen Verbesserung älterer Web-Inhalte, die auf die fehlerhafte Darstellung in älteren IE-Versionen hin entwickelt wurden, bei Microsoft Compatibility View Blacklist genannt. Auch hierzu hat sich schon halb Klein-Bloggersdorf in epischer Breite ausgelassen; hier zunächst die Position von Microsoft:

• Introducing Compatibility View
• Just The Facts: Recap of Compatibility View
• Compatibility View Improvements to come in IE8

… und die Reaktionen der Betroffenen:

• Microsoft breaks IE8 interoperability promise
• Microsoft betrayed the web community (or not? — Update)
• IE8 Blacklist: forcing standards rendering opt-in
• The IE8 Blacklist minefield

Fazit: Alles in Allem ein guter Browser. Ob nun die Zeit gekommen ist, den IE6 komplett zu ignorieren oder ob man seine Website kompatibel für alle Browser macht, muss jeder für sich entscheiden.

Nachtrag 22.03.2009:

• IE8 Kompatibilitätsmodus: Meta-Tag EmulateIE7 und Listen - der Überblick
• IE8 (final release) bugs

10 Mär 2009

Literaturbeilage: WAI-ARIA

In der kleinen Laborbericht-Serie zu unserem vergangenen Relaunch hatten wir öfters eine Abkürzung benutzt, die das Potenzial hat, das nächste große Ding zu werden: WAI-ARIA (›Accessible Rich Internet Applications‹). Damit werden Ergänzungen zu HTML beschrieben, die vorhandene Lücken in den Spezifikationen stopfen sollen. So lässt sich zum Beispiel in Web-basierten Applikationen ein Schieberegler auszeichnen – ein Element, dass es in HTML (noch) nicht gibt. Dieser wird dann z.B. in einem Screenreader auch als solcher angesagt und nicht als eine Ansammlung sinnfreier div.

Der Entwurf hat mittlerweile den Status eines Last Call Working Draft erreicht; die übliche Kommentierungs-Phase läuft bis zum 24. März. Es ist also mit einer baldigen Fertigstellung zu rechnen, zumal die Browser- und Hilfsmittel-Hersteller bereits fleißig implementieren.

Deswegen ein paar gesammelte Links als Ergänzung zu unserer Serie, falls Sie tiefer in die Materie einsteigen wollen:

Weiterlesen …

Lesenswertes:

• Stefan Walter hat die Einführung des Accessibility-Experten Gez Lemon übersetzt: »Einführung in WAI ARIA«.
• Eine ähnlich gute, allerdings englischsprachige Einführung gibt es im CodeTalks-Wiki: »Web 2.0 Accessibility with WAI-ARIA FAQ«.
• Steve Faulkner erklärt die Auszeichnung von Seitenbereichen: »Using WAI ARIA Landmark Roles« (dazu passend die ARIA Landmark Role-Tests mit Firefox 3 & Internet Explorer 8 + Assistive Technology).
• Todd Kloots schreibt was zur Verwendung von ARIA im YUI-Framework: »More Accessible YUI Grids Layouts with ARIA Landmark Roles«.
• Roger Johansson macht sich Gedanken um die Validierung: »Validating WAI-ARIA in HTML and XHTML«.
• Marco Zehe gibt eine ganze Reihe Tipps, wie man Widgets mit ARIA anreichern kann: »Easy ARIA tip #3: aria-invalid and role ›alert‹« bzw. zeigt was manche Anbieter bereits jetzt machen: »ARIA in Gmail #1: Alerts« und »ARIA in Gmail #2: Enhancing the Chat experience«.
• Im vergangenen Herbst hatte Martin Kliehm auf dem Wiener A-Tag eine sehenswerte Präsentation dazu abgeliefert: »Accessible Rich Internet Applications (ARIA)«, die dazugehörigen kurzen Demo-Videos finden sich in seinem flickr-Account.
• Thomas Logan hat im CodeTalks-Wiki gleich 5 Videos veröffentlicht, in denen die Entwicklung von zugänglichen Web-Applikationen mit WAI-ARIA zu sehen ist: »ARIA Video Project« (wie es sich gehört mit Mitschrift bzw. untertitelt!).

Ohne die Unterstützung durch Browser und Hilfsmittel geht es natürlich nicht:

• Steve Faulkner freut sich über »JAWS version 10 with WAI-ARIA live region support« und schiebt gleich noch ein paar Testcases hinterher: »Testing WAI-ARIA Role Support«.
• Ebenso erfreulich die Test Cases für den Internet Explorer 8 bei Microsoft im Windows Internet Explorer Testing Center (Beispiel für eine Baum-Navigation); weitere Infos dazu im IEBlog: »Accessibility: Improved ARIA Support in the IE8 RC«
• Bei Mozilla ist man schon seit Firefox 1.5 an dem Thema dran, nun berichtet Marco Zehe von »JAWS 10 public beta’s Firefox 3 support: A review«.
• Wie sich das Ganze dann in JAWS 10 anhört erfährt man in der Folge 26 des FSCast aus dem Januar '09: »FSCast Episode 26 from Freedom Scientific for Blind and Vision Impaired Individuals«.
• Weniger gut ist hingegen die WAI-ARIA-Unterstützung in der aktuellen Beta von Apples Safari 4. Trotz der Ankündigung »Safari supports Accessible Rich Internet Applications (ARIA)« waren wir bisher nicht in der Lage, den Browser zusammen mit dem hauseigenen Screenreader VoiceOver zu überreden, irgendwas sinnvolles mit ARIA anzustellen. Andere scheinen die gleichen Probleme zu haben (z.B. Safari 4 - Quickfire ARIA Testing oder Safari 4 public beta with WAI-ARIA support. Or not?) – aber das kann ja bis zur finalen Version noch werden.

Einen noch zum Schluss: wie man am besten mit Screenreadern testet (oder noch besser: echten Screenreader-Nutzer testen lässt) erklärt Henni Swan von Opera: »Setting up a screen reader test enviroment«.

09 Feb 2009

Hörtipp: CRE107 - Barrierefreiheit im Web

Im Chaosradio Express №107 unterhalten sich Tim Pritlove, Jan Eric Hellbusch und Tomas Caspers fast zwei Stunden lang über Grundsätzliches und Aktuelles aus dem Bereich Barrierefreiheit im Web – Was man bedenken sollte, wenn man Websites plant und gestaltet (Kommentare, Mitmachseite, Direkter Download der Mediendatei, ca. 80 MB).

Unter anderem geht es um folgende Themen: The Web Standards Project; Auswirkung der Farbwahl in Webseiten für Farbfehlsichtige; Bedeutung der Struktur und semantischem Markup für blinde Nutzer; Vorteile von barrierefreiem Design für nicht-behinderte Nutzer; Screenreader-Programme und vergleichbare Funktionalitäten in Betriebssystemen; Aspekte der Gebärdensprache; Aufbau, Anwendung und Testbarkeit der Web Content Accessibility Guidelines der W3C und WAI-ARIA; Gesetzliche Vorgaben und Verpflichtung zur Barrierefreiheit für Behörden und öffentliche Körperschaften und Accessibility für Podcasts.

21 Jan 2009

EfA-Laborbericht № 3½

In den letzten Tagen haben wir wieder mal ein wenig an den Seiten geschraubt. Seit neuestem gibt es jetzt (wieder) eine Live-Suche, die in Echtzeit passende Treffer zu den Eingaben in das Suchformular zurückliefert. Das Andocken an die im Backend verwendete Suchtechnik geschieht über ein paar Erweiterungen der von uns auch für andere Dinge verwendeten jQuery-Bibliothek; die Bedienung entspricht dem üblichen Verhalten von Combo-Boxen – also eintippen und ab (zurzeit) 2 Zeichen kommt eine Liste mit Vorschlägen vom Server zurück. Durch diese Liste kann man mit den Pfeiltasten navigieren, mit Enter wählt man einen Vorschlag aus, der dann in die Combo-Box übernommen wird. Dann kann man diesen Vorschlag entweder noch ergänzen oder per Tab zum Button, um die Suchanfrage loszuschicken (Maus geht natürlich auch).

Weiterlesen …

Echte Combo-Boxen gibt es in HTML leider nicht (bzw. noch nicht, HTML5 verspricht auch hier Besserung für den Fehler, dass man in der HTML4-Spezifikation Combo-Boxen schlichtweg vergessen hat). Daher geschieht die Eingabe über ein herkömmliches INPUT-Element, die Trefferliste wiederum ist eine ganz normale Liste vom Typ UL. Verknüpft sind die beiden allerdings über das ARIA-Attribut owns, mit dem die INPUT-Box einem geeigneten Hilfsmittel sagen kann, dass die id="trefferliste" zu ihr gehört (aria-owns="trefferliste").

Eine gute Erklärung dafür gibt es in den Wai-Aria Grundlagen bei protofunc():

Aria schreibt ähnlich wie HTML vor, dass einige Elemente immer Kindelement einer bestimmten Rolle sein müssen. Dies gilt beispielsweise für die Rolle option, welches ein Kind von select oder einer ähnlichen Rolle sein muss. In manchen Fällen ist dies technisch nicht möglich (Ein input-Element kann keine Kinder haben.) oder widerspricht dem Aufbau der UI-Komponente. In diesen Fällen kann das owns-Attribut verwendet werden, welches anzeigt, dass ein Element das Eltern-Element eines anderen ist.

Untenrum

So sieht das ganze dann im HTML aus – erstmal die Suchbox …

150. <form id="searchform" action="/suche/" method="get" role="search" aria-owns="trefferliste">
151. <fieldset>
152. […]
153. <label for="livesearch">Suchbegriffe:</label>
154. <input name="q" id="livesearch" type="text" size="50">
155. <button type="submit" id="submit" name="submit" value="Finden">Finden</button>
156. </fieldset>
157. </form>

… und dann die vom Skript in die Seiten eingebaute Trefferliste:

500. <ul class="ac_results" id="trefferliste" aria-live="assertive">
501. <li class="ac_over"><span class="ac_match">foo</span></li>
502. <li><span class="ac_match">foo</span>bar</li>
503. [...]
504. </ul>

In der Trefferliste findet sich ein weiteres ARIA-Attribut (aria-live="assertive"), mit dem User Agents und insbesondere Hilfsmittel wie Screenreader darauf hingewiesen werden, dass hier eine wesentliche Änderung innerhalb der Seite stattgefunden hat mit der Bitte, den Nutzer doch bei nächster Gelegenheit darauf hinzuweisen.

Natürlich validiert das alles nicht, aber warum das so ist und warum das nicht nur in unserem eigenen, sondern auch im Interesse der Nutzer ist, hatten wir ja bereits im Laborbericht № 3 ausführlich erläutert. Unterstützt wird diese Technik zurzeit vom Screenreader JAWS ab Versionsnummer 10 mit aktuellen Versionen von Firefox und Internet Explorer 8.

Obenrum

An der Oberfläche haben wir uns ebenfalls wieder ein bisschen weiter aus dem Fenster gelehnt: auch hier kommen einige Standards zum Einsatz, die noch gar keine Standards sind, sondern noch in der Entwicklung befindliche W3C-Entwürfe. Unter anderem sind dies fortgeschrittene Selektoren, die eine Menge HTML-Code einsparen, um z.B. jede zweite Reihe in der Trefferliste mit einer anderen Hintergrundfarbe darzustellen. Früher hätte man dafür jede zweite LI einer Liste mit einer speziellen Klasse versehen (mit dem entsprechenden Programmieraufwand, um diese Logik im Backend bereitzustellen); heute reicht dafür (ohne Eingriffe in das HTML):

1. .ac_results li:nth-child(odd) {
2. background-color: #f6f9fe;
3. }

Das Ergebnis ist (zumindest in modernen Browsern) eine gestreifte Liste wie im nebenstehenden Screenshot zu sehen. Einen gewissen Nachteil hat die Methode natürlich auch: ältere Browser verstehen sie nicht, daher haben wir uns im Sinne des »progressive enhancement« dafür entschieden, eine zusätzliche subtile Linie zur Differenzierung um die Listeneinträge zu legen.

Ebenfalls auf der linken Seite des Screenshots zu sehen ist ein weicher Schlagschatten hinter der gesamten Box der Trefferliste – auch hier wieder pures CSS ohne Eingriffe ins HTML und irgendwelche fragwürdigen leeren Elemente und Hintergrudbilder, wie sie in vielen Webdesign-Tutorials zu finden sind. Erreicht wird dies durch box-shadow, einem Selektor aus dem kommenden CSS Level 3.

Wundern Sie sich nicht über die komischen -webkit- oder -moz-Präfixe in den Regeln – diese sind in der CSS-Spezifikation dafür vorgesehen, Dinge in der Praxis und damit auf ihre Tauglichkeit testen zu können, bevor sie endgültig verabschiedet werden. -webkit ist die Anweisung für den Safari-Browser von Apple bzw. dessen Rendering Engine namens Webkit, -moz wiederum steht für Mozilla und andere Browser mit der Gecko-Engine:

1. .ac_results {
2. [...]
3. box-shadow: 2px 2px 6px #333;
4. -webkit-box-shadow: 2px 2px 6px #333;
5. -khtml-box-shadow: 2px 2px 6px #333;
6. -moz-box-shadow: 2px 2px 6px #333;
7. }

Dass dies ebenfalls nur von den neuesten Browsern unterstützt wird, haben wir bewußt in Kauf genommen; die Begründung dafür finden Sie hier.

Und sonst?

Unsere Style Sheets werden seit neuestem gezippt ausgeliefert und sind nur noch ca. 10kb ›groß‹, was die Geschwindigkeit dieser Seiten nochmals deutlich verbessern sollte (zur Performance-Optimierung hatten wir ja schonmal an anderer Stelle was geschrieben). Ansonsten haben wir noch ein bisschen weiter aufgeräumt und endlich mal die Blogroll auf den neuesten Stand gebracht sowie die 2009er-Events-Seite befüllt. Wir bitten um freundliche Beachtung.

28 Nov 2008

EfA-Laborbericht № 3

Web-Standards, HTML und so…

Kommen wir zum technischen Gerüst dieser Seiten. Wie bereits erwähnt basieren das HTML&CSS auf dem YAML-Framework in der neuesten Version. Da auch die letzte Version auf diesem Gerüst basierte, war die Umstellung mit ein paar ausgefeilten Suchmustern im Editor relativ leicht zu bewältigen und so manche Zeile Code hat es aus der alten Fassung auch bis herüber geschafft – ein nicht zu unterschätzender Vorteil, den barrierefreie Seiten durch ihre eingebaute Logik haben.

Über die Style Sheets als solche hatten wir ja bereits in der ersten Folge dieser kleinen Serie geschrieben; dort finden Sie auch den Link zum Download einer ausführlich kommentierten Fassung.

Bedeutungslehre

Unsere Seiten sind nach wie vor mit sinnvoll strukturiertem und semantischem Markup aufgebaut. Dies betrifft insbesondere die Textauszeichnungen und die Struktur der Inhalte. Da HTML aber nie alle Eventualitäten abdecken wird, kommt es zwangsläufig zu Interpretationen der Bedeutung von Elementen, die von anderen Interpretationen abweichen kann. Insofern kann man über das eine oder andere Element sicher diskutieren (z.B. in unserer ›Tag-Cloud‹ – hierzu wird es noch einen eigenen Laborbericht geben), aber in der Regel werden beide Positionen Recht behalten.

Ein Element hat die Umstellung nicht überlebt: ACRONYM wurde global durch ABBR ersetzt. Da selbst Linguisten sich nicht einigen können, welche Abkürzung denn auch ein Akronym sei, und da das ACRONYM-Element in HTML5 aller Voraussicht nach nicht mehr spezifiziert sein wird, fiel uns dieser Abschied nicht sonderlich schwer.

Weiterlesen …

Valid, Valid über alles?

Fast alle Seiten validierten zum Zeitpunkt ihrer Erstellung nach HTML 4.01 strict (für Fachleute: unter Berücksichtigung der Regeln zur Wohlgeformtheit gemäß »XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition): A Reformulation of HTML 4 in XML 1.0.« mit Ausnahme der in Appendix C.1, C.2 und C.3 gelisteten XML-spezifischen Anforderungen). Wenn Sie dennoch Fehler im Markup dieser Seiten finden, wären wir natürlich für einen kurzen Hinweis dankbar.

Mit zwei Ausnahmen:

1. Einige Seiten weisen »Fehler« in der Validierung auf, da wir z.B. im Gegensatz zum W3C der Auffassung sind, dass das start-Attribut von OL echter Inhalt ist und somit ins HTML gehört und nicht ins CSS.
2. Seit dem aktuellen Relaunch setzen wir zur Kennzeichnung von Seitenbereichen und für erweiterte Funktionen Teile des kommenden WAI-ARIA-Standards ein. Aktuelle Hilfsmittel wie der Screenreader JAWS unterstützen diese Technik bereits in Verbindung mit modernen Browsern. Sie ermöglicht eine einfache Identifikation von Bestandteilen einer Seite wie z.B. der Navigation, der Suche, dem wesentlichen Inhalt einer Seite und ergänzenden Informationen zum jeweiligen Artikel.

Das hierfür benötigte role-Attribut ist jedoch noch nicht Bestandteil irgendeiner HTML- oder XHMTL-Spezifikation des W3C – verbreitete Validatoren geben hier also zurzeit noch einen Fehler aus. Da uns die Zugänglichkeit für den Nutzer wichtiger ist als ein grünes Fähnchen eines Prüfprogramms, haben wir nicht lange überlegt, ob wir diese Technik einsetzen sollen oder nicht.

Im Einzelnen setzen wir folgende Rollenzuweisungen ein, um Bereiche der Seiten zu kennzeichnen und abzugrenzen:

role="article"

Der wesentliche Inhalt einer Seite, also wie der Name schon sagt ein Artikel, ein Blogpost etc.

role="banner"

Die Kopfzeile der Seite mit dem Namen, Logo und Claim der Initiative

role="complementary"

Von Inhalt abhängige Bereiche, die diesen ergänzen, aber auch für sich allein stehen könnten (z.B. eine Vorlesefunktion)

role="contentinfo"

Ergänzende Informationen zum Inhalt wie z.B. Fußnoten, weiterführende Links etc.

role="main"

Der wesentliche Inhaltsbereich

role="navigation"

Der oder die Navigationsbereich(e)

role="note"

Ergänzende Bemerkungen zum Inhalt

role="search"

Die Suchfunktion

Eine tiefergehende Einführung in dieses Konzept finden Sie in einem Artikel von Gez Lemon bei der Opera Developer Community: »Introduction to WAI ARIA«

Fehlervermeidungsstrategien

Zusätzlich setzen wir Attribute aus WAI-ARIA ein um Screenreader-Nutzern die Handhabung von Formularen zu erleichtern. Besonders hilfreich sind hier:

aria-required="true"

Kennzeichnet ein Pflichtfeld in einem Formular, dass vom Nutzer ausgefüllt werden muss; mehr dazu bei Marco Zehe: »Easy ARIA Tip #1: Using aria-required«

role="alert"

Kennzeichnet eine Fehlermeldung; mehr dazu bei Marco Zehe: »Easy ARIA tip #3: aria-invalid and role ›alert‹«

aria-live="assertive"

Über diese sog. ›Live Regions‹ lässt sich steuern, mit welcher Dringlichkeit der Nutzer auf eine Fehlermeldung hingewiesen wird. Im konkreten Fall wird der Nutzer nicht unmittelbar bei der Arbeit unterbrochen (das wäre aria-live="rude"), sondern erst bei der nächsten Gelegenheit informiert.

Wie sich dies in der Praxis im Screenreader anhört hat Martin Kliehm auf dem Wiener A-Tag vorgeführt. Die Videos dazu finden sich in seinem flickr-Account, die dazugehörige Präsentation gibt's bei Slideshare.

11 Jun 2008

Browsernachrichten ohne Ende

Firefox

Nachdem unplanmäßig noch ein dritter Release Candidate eingeschoben wurde steht nun Dienstag, der 17. Juni als endgültiges Datum für Firefox 3 fest (wir berichteten). Ebenfalls lesenswert: Mit Firefox per Du - Version 3.0 und Firefox 3: Fonts and text.

Opera

Ganz fertig und schon ohne β hingegen ist die neueste Version 9.5 von Opera. Wie die meisten Browser (mit der Ausnahme des üblichen Verdächtigen) kann Opera auch schon einiges aus HTML 5 – Canvas & Web Forms – und aus CSS 3 – text-shadow, media queries, nth-child, background sizing – am besten zu sehen auf den Testseiten von css3.info/; weitere Details dazu auch bei dev.opera.com und im Changelog. Besonders gut: die Unterstützung des aktuellen Standes von WAI-ARIA und eine neue Version des Entwickler-Tools Dragonfly.

Internet Explorer

Wann der IE 8 hingegen fertig sein wird weiss niemand, wahrscheinlich auch nicht Microsoft. Klar ist aber, dass es im August eine IE 8 Beta 2 geben wird. Wie auch schon beim IE 7 gibt es auch diesmal umfassende Informationen, was auf Webentwickler alles zukommt:

• Getting Your Site Ready for Internet Explorer 8
• What's Coming in Internet Explorer 8 for IT Professionals?
• Improved Productivity Through Internet Explorer 8 Developer Tools
• Introducing IE=EmulateIE7

Safari

Abgerundet wird das ganze von Safari, von dessen kommender Version 4 es über die Seiten der Apple Developer Connection-Website eine erste Vorschau gibt: Apple Gives Developers Safari 4 Preview.

06 Feb 2008

W3C veröffentlicht neuen Entwurf von WAI-ARIA

Seit ungefähr zwei Jahren entwickelt die Web Accessibility Initiative des W3C an der WAI-ARIA-Reihe, von der nun ein neuer Entwurf vorgelegt wurde. ARIA steht für »Accessible Rich Internet Applications« und soll als Interims-Lösung dafür sorgen, dass Web-basierte Applikationen für die Hilfsmittel behinderter Nutzer zugänglicher werden.

1. WAI-ARIA Primer ist ein neues Dokument, in dem die Hintergründe und Lösungsansätze der Spezifikation erklärt werden;
2. Accessible Rich Internet Applications (WAI-ARIA) Version 1.0, der aktuelle W3C Working Draft vom 4 Februar 2008, in dem die bisher getrennten Entwürfe für ›Roles‹ und ›States and Properties‹ kombiniert werden;
3. WAI-ARIA Best Practices beschreibt, wie Entwickler heute schon zugängliche Web-Anwendungen schreiben können.

Die Arbeitsgruppe bittet um Kommentare bis zum 3. März 2008, spezifische Fragen finden sich in den o.g. Dokumenten jeweils im Abschnitt »Status of This Document«.

Den besten Einstieg in das gesamte Thema bekommt man beim W3C: »WAI-ARIA Overview« oder in diesem Artikel von Martin Kliehm: »Accessible Web 2.0 Applications with WAI-ARIA« bzw. in der deutschen Übersetzung: »Barrierefreie Web 2.0 Anwendungen mit WAI ARIA«. Woran es zurzeit noch (insbesondere von Seiten der Hilfsmittel her) hapert beschreibt ein Artikel von Steve Faulkner: »AJAX and Screen Readers - Content Access Issues«.

19 Okt 2007

Neues vom W3C

Die Protocols and Formats-Arbeitsgruppe des W3C hat aktualisierte Entwürfe von WAI-ARIA Roadmap, WAI-ARIA Roles und WAI-ARIA States and Properties veröffentlicht.

Die WAI-ARIA-Reihe soll die Barrierefreiheit von dynamischen Web-Inhalten (also das, was gemeinhin unter AJAX läuft) für Menschen mit Behinderungen sicherstellen. WAI-ARIA beinhaltet Techniken, um interaktive Regionen, Kontrollelemente und Events in Web-basierten Applikationen so abzubilden, dass sie von den Accessibility-APIs (MSAA, ATK etc.) der Betriebssysteme entsprechend verarbeitet werden können und damit in Hilfsmitteln zugänglich sind.

WAI-ARIA beschreibt darüber hinaus neue Techniken, um gängige Strukturen wie Menüs, primäre und sekundäre Inhalte, Banner und andere typische Webinhalte auszuzeichnen. Die Implementierung von WAI-ARIA in Markup-Sprachen wie HTML 4, HTML 5 und XHTML ist zurzeit in vollem Gange, weitere Infos im »Accessible Rich Internet Applications (WAI-ARIA) Suite Overview«.

Sonst noch von Interesse:

• Cascading Style Sheets (CSS) Snapshot 2007, W3C Working Draft vom 19. Oktober 2007.
• CSS Mobile Profile 2.0, W3C Last Call Working Draft vom 19. Oktober 2007.
• Behavioral Extensions to CSS, W3C Working Draft vom 19. Oktober 2007.
• Selectors API, W3C Working Draft vom 19. Oktober 2007.
• Widgets 1.0, W3C Working Draft vom 13. Oktober 2007.

09 Mär 2007

Wochenendbeilage: was mit Hilfsmitteln

Die technische Basis vieler Computer-Hilfsmittel für Menschen mit Behinderung stammt aus Zeiten, als der Kanzler noch Kohl hiess. Da verwundert es nicht, dass diese oftmals ihre lieben Nöte mit moderneren Techniken der Webentwicklung haben. Ein paar Beispiele: viele Screenreader »raten« anhand des gerenderten Bildschirmbildes, was dahinter im Quelltext passiert (daher rühren dann die Probleme mit dynamischen Inhalten); gängige Lupenprogramme skalieren Bildschirmpixel und versuchen diese zu glätten, statt Vektor-Informationen zu benutzen (was bei starken Vergrößerungsfaktoren zu unleserlichem Text führt) usw. Die Umsetzung der »User Agent Accessibility Guidelines« (UAAG) in den verbreiteten Browsern lässt ebenfalls zu wünschen übrig, sodaß die Hilfsmittel leider nach wie vor darauf angewiesen sind, durch Erraten aus Murks-Code das Beste herauszuholen (was oftmals dazu führt, dass sauberer Code falsch verstanden wird).

In Zeiten Web-basierter Applikationen wird es jedoch für Hilfsmittel immer wichtiger, auf die Accessibility-Schnittstellen der jeweiligen Betriebssysteme zu setzen, über die sie mit Informationen zu Strukturen und Inhalten, Rollen und Zuständen von Bedienelementen etc. versorgt werden. Nur so kann aus Sicht der Anbieter und Nutzer ein konsistentes Verhalten einer Anwendung auch in den verbreiteten Computer-Hilfsmitteln gewährleistet werden.

Wo diese Schnittstellen unterdokumentiert oder lückenhaft sind (wie im Falle MSAA) könnte ein neues API namens IAccessible2 helfen, das von IBM entwickelt wurde und über die Free Standards Group allen interessierten Hilfsmittel-Herstellern zur Verfügung gestellt wird. Der Code fungiert quasi als Zwischenebene und ermöglicht es damit auch, die Anwendungen einfacher auf andere Plattformen zu portiern. Bereitgestellt werden Funktionen, die bisher für Hilfsmittel nicht zugänglich waren, oder die für Programmierer nur über unschöne Hacks zu erreichen waren (was dann z.B. zu den berüchtigten Abstürzen bei Kollisionen der Grafikkarten-Treiber führt und verhindert, dass man bestimmte Hilfsmittel gemeinsam auf einem Rechner betreibt).

Aus Webentwickler-Sicht besonders interessant ist, dass hiermit auch die WAI-ARIA Roadmap in Hilfsmittel und Browser implementiert werden kann, ohne dafür die gesamte Anwendung umzuschreiben. Da namhafte Hersteller wie Freedom Scientific, GW Micro, IBM, das Mozilla Project, Oracle, SAP und Sun bereits ihre Unterstützung zugesagt haben kann man in Zukunft damit rechnen, dass Webapplikationen auch mit heute noch problematischen Hilfsmitteln genutzt werden können.

Weitere Berichterstattung zum Thema bei Golem: »IAccessible2 für mehr Barrierefreiheit« sowie bei der Linux Foundation: »The Free Standards Group to Standardize New Accessibility Interfaces«.

20 Okt 2006

Wochenendbeilage

Wenn Sie schon immer mal wissen wollten, was dieses DOM-Dings ist, und wie moderne Skripte geschrieben werden sollten – der JavaScript-Veteran Douglas Crockford hat eine sehens- und hörenswerte (englischsprachige) Präsentation zum Thema »Theory of the DOM« abgeliefert: Teil 1 (31 Minuten), Teil 2 (21 Minuten) und Teil 3 (26 Minuten) (Flash-Video, via)

Ebenfalls lesenswert:

• Mike Cherim: »Today’s AJAX and DHTML Best Practices«
• Peter Korn: »Making Rich Web Applications accessible: WAI-ARIA«
• Joe Walker : »The 4 States of Ajax Adoption«
• Christian Heilmann: »Tackling automatic field focus usability issues«
• Jesse James Garrett: »There are a lot of ways Ajax can be used, and most of them are wrong«
• Scand: »dhtmlxGrid - sortable Javascript DHTML grid with rich script API«
• Brian McAllister: »Unobtrusive Date-Picker Widgit Updat«