accessBlog

News mit dem Tag »HTML«

11 Sep 2009

Wenn Sie eine tagewochenlange Diskussion unter Webentwicklern lostreten wollen, dann müssen Sie nur mal in einem Forum oder bei Twitter die Frage stellen, ob man mehr als eine <h1> pro Seite verwenden darf, und wenn ja, wofür. Danach können Sie sich entspannt zurücklehnen und Wetten auf den Zeitpunkt abschliessen, an dem die Diskussion vollends aus dem Ruder läuft.
Dabei findet die ganze Diskussion nur deshalb statt, weil es historisch bedingte Lücken in der HTML-Spezifikation gibt. Warum das so ist, wo diese Lücken sind und wo sie herkommen, was man dagegen machen kann und wie das Thema in Zukunft aussehen wird zeigt der Artikel »Passende Überschrift hier einsetzen«.

01 Sep 2009

Passend zur Veröffentlichung des neuesten HTML 5-Entwurfes (wir berichteten) und der ganzen Begeisterung im Netz gab es heute eine überaus lesenswerte Veröffentlichung von einer Reihe bekannter Web-Menschen, die sich die HTML5 Super Friends nennen. Darin äussern sie grundsätzliche Zustimmung zu der eingeschlagenen Richtung, zeigen aber auch eine ganze Reihe Lücken, Fehler und Unzulänglichkeiten auf: »Super Friends Guide to HTML5 Hiccups«.

Weitere Hintergründe dazu von den Beteiligten selbst:

Und auch an anderer Stelle wird munter weiterdiskutiert:

28 Aug 2009

Die HTML-Arbeitsguppe des W3C hat einen neuen Entwurf von HTML 5 veröffentlicht. In HTML 5 werden eine ganze Reihe neuer Features eingeführt, die bei der Entwicklung von Web-basierten Applikationen helfen; neue Elemente werden auf Basis von aktuellen Praktiken in der Web-Entwicklung definiert, und besonderer Augenmerk liegt auf klaren Kriterien für die Implementierung in Browsern, um die Interoperabilität zu verbessern. Auch das Dokument HTML 5 differences from HTML 4 liegt in einer aktualisierten Fassung vor. Es beschreibt die Unterschiede zwischen dem aktuellen HTML 4 und dem kommenden HTML 5 und zeigt die Gründe für die Änderungen auf.

HTML 5 wird irgendwann HTML 4.01 ersetzen, die zuzeit noch dominierende Sprache, mit der Webseiten gebaut werden. An den Details wird natürlich noch gefeilt und niemand kann ernsthaft erwarten, dass der Entwurf über Experimente hinaus schon in der Praxis eingesetzt werden kann. Dafür ist der Entwurf noch zu unstabil und die Menge der Elemente, die gerade drinnen oder draussen sind, zu groß.

HTML 5 ist zwar noch lange nicht fertig, aber auch kein Luftschloß (wie so viele andere W3C-Entwürfe) – dafür ist die Unterstützung durch die großen und kleinen Browser-Hersteller einfach zu groß. Viele der Änderungen sind bereits in modernen Browsern implementiert und versuchen so, ihre Praxistauglichkeit zu beweisen.

Neben neuen, dringend benötigten Strukturelementen zur Auszeichnung von Seitenbereichen (welche das sein werden ist aktuell noch in der Diskussion) sind wohl die Elemente für direkte Audio- und Video-Einbettung am spannendsten, da sie mit bisherigen PlugIn-Techniken wie Flash und Silverlight in direkter Konkurrenz stehen.

Weiterlesen …

Weiterführende Literatur

Hier ein Überblick über lesenswerte Artikel zu HTML 5, die uns in letzter Zeit aufgefallen sind:

29 Jul 2009

Der Arbeitstag des gemeinen Web-Entwicklers beginnt ja üblicherweise damit, dass man mal eben schnell was im IE & Firefox kontrollieren will. Beim Start der Virtualisierungs-Software will diese erstmal aktualisiert werden. OK. Update durchgeführt, neugestartet und, oh Wunder, die nächsten Sicherheitsupdates für XP. Na gut, schnell mal installiert, Neustart und dann endlich Firefox geöffnet. Oh, ein Update! Mal schnell runterladen, Browser neustarten, Erweiterungen auf Updates überprüfen und, man glaubt es kaum, es gibt neue Versionen. Runterladen, installieren, Browser neustarten und …

… nichts geht mehr.

Und das alles nur um festzustellen, dass zumindest der letzte Teil des Prozederes für die Katz' war, weil ausgrechnet eine für Web-Entwickler so wichtige Erweiterung namens Firebug so dermaßen voller Bugs ist, dass nur noch das Downgrade auf die Vorgängerversion hilft. Pustekuchen, weil die ist dann nämlich nicht mit der neueren Browser-Version kompatibel und verweigert die Installation.

20 GOTO 10

Der einzige Trost: Die Suche bei Twitter zeigt, dass man nicht allein mit dem Problem ist. Dabei wollten wir eigentlich nur was zu den angeblichen Accessibility-Verbesserungen in Firebug 1.4.x schreiben, aber mangels Testobjekt muss dieser Blogpost halt bis zur nächsten Version warten. Und dann geht der Spaß wieder von vorne los …

21 Mai 2009

Die Web Accessibility Initiative des W3C hat eine aktualisierte Fassung des Entwurfes zu den Authoring Tool Accessibility Guidelines (ATAG 2.0) veröffentlicht und bittet um Kommentare bis zum 11. Juni. Ziel dieser Runde ist es, den als nächsten Schritt geplanten ›Last Call Working Draft‹ vorzubereiten. Wichtige Änderungen gibt es zum Beispiel in dem Punkt, wie Anwendungen mit Alternativtexten umgehen sollten (z.B. bei Foto-Communities wie flickr); ausserdem ist das Glossar komplett überarbeitet worden.

ATAG ist wie die beiden anderen WAI-Empfehlungen WCAG und UAAG ein wichtiger Baustein zur Barrierefreiheit. Die Richtlinie beschreibt, wie Autorenwerkzeuge möglichst zugängliche Web-Inhalte produzieren sollten und wie Autoren und Entwickler in ihrer Arbeit durch Werkzeuge wie Editoren und Redaktionssysteme darin unterstützt werden, saubere Arbeit ins Netz zu stellen. Ein wichtiger Aspekt ist auch, dass solche Anwendungen natürlich für Menschen mit Behinderung bedienbar und nutzbar sein sollten.

Rückrufaktion

Bei der XHTML2-Kindergarten -Arbeitsgruppe werden hingegen vier Entwürfe zurückgezogen, weil in der vorangegangenen Phase der Publizierung bestehende Einwände gegen die Entwürfe nicht beachtet wurden. Im einzelnen sind dies: XHTML™ 1.1 - Module-based XHTML - Second Edition, XHTML™ Basic 1.1 - Second Edition, XHTML-Print - Second Edition sowie XHTML™ 1.0. Hintergründe zu dieser Entscheidung kann man evtl. in dieser E-Mail von Bjoern Hoehrmann an die W3C-Mailingliste nachlesen.

19 Mai 2009

Beim Browser-Hersteller Opera läuft seit längerem eine Studie namens MAMA (Metadata Analysis and Mining Application). Untersucht werden versteckte Qualitäten von Webseiten wie deren Aufbau und die Verwendung (oder Nicht-Verwendung) von HTML-Tags und -Attributen – gemeinhin Dinge, die man kaum mit einer herkömmlichen Suchmaschine herausfinden wird. Interessant ist sowas vor allem für Browser-Hersteller wie eben Opera, aber auch für die Weiterentwicklung von HTML (zum Beispiel zur Version 5).

Untersucht wurden mittlerweile 4,2 Mio. URLs, die Ergebnisse werden nach und nach veröffentlicht (mehr zur Methodik und eine Zusammenfassung der wichtigsten Punkte). Heute fanden wir im Opera Developer Network einen Artikel von Henni Swan über einige gerade aus Sicht der Barrierefreiheit interessante Teilaspekte – die Verwendung von Überschriften-Strukturen, Bildern und Datentabellen: »Opera MAMA - a sneak peek at headings, images and summary«. Hier ein paar der wichtigsten Ergebnisse:

Weiterlesen …

Es gibt kein Bier auf h3 …

  • 58,5% der untersuchten Webseiten benutzen keinerlei Überschriften-Elemente,
  • 7,9% haben hingegen gleich mehrere <h1>,
  • 16,1% fangen ihre Überschriften-Struktur nicht mit der Ebene <h1> an, sondern mit <h2>, <h3>, etc.,
  • 11,3% der Seiten überspringen Überschriften-Ebenen, und bei
  • 7,1% der Seiten sind die Überschriften-Ebenen in keiner logischen Reihenfolge.

Über die Punkte 2-5 kann man geteilter Meinung sein (und wie bei Opera vermerkt gibt es mittlerweile sogar eine Seite www.h1debate.com, wo man sich per Twitter an dieser Endlos-Debatte beteilgen kann). Was aber ganz sicher gar nicht geht ist Überschriften ganz wegzulassen, da diese gerade für Screenreader-Nutzer eine wichtige, wenn nicht die wichtigste Orientierungshilfe sind.

Es gibt nichts zu sehen, gehen Sie bitte weiter …

Ganz bitter auch das Bild bei Bildern, Grafiken und deren Alternativ-Texten:

  • 75,1% der untersuchten Seiten benutzen zumindest alt-Attribute für Bilder. Was aber im Umkehrschluss leider bedeutet, dass
  • 24,9% gar keine alt-Attribute verwenden. Abgesehen davon, dass hier oftmals relevante Informationen und Funktionen für Screenreader-Nutzer verborgen bleiben heisst das auch, dass bei diesen Seiten in gängigen Screenreadern unter Umständen der Pfad der Bilddatei vorgelesen wird – der Benutzer darf dann anhand des Dateinamens selbst herausfinden, was ihm da wohl verborgen bleibt.

Auch bei Datentabellen sieht es nicht besser aus:

  • 2,4% der Seiten benutzen überhaupt das summary-Attribut, allerdings bei
  • 1,7% der Seiten fehlerhaft, nämlich in der Form von summary="layout table"

Weitere Werte, die gefunden wurden waren "layout", "layout table", "header", "navigation", "content", "banner", "main", "main table", "breadcrumb", "category" etc. Das deckt sich weitestgehend mit unseren Erfahrungen – uns sind auch schon Websites mit hunderten summary="Zusammenfassung" (wörtlich!) untergekommen. Wenn schon immer noch Layout-Tabellen eingesetzt werden, dann wenigstens so richtig falsch!

Es gibt noch viel zu tun …

02 Mär 2009

Wie üblich haben uns auch beim letzten Relaunch viele Rückmeldungen und kritische Anmerkungen (und in seltenen Fällen sogar Lob) per E-Mail oder über die Kontakt- und Kommentarformulare erreicht. Zu einigen Punkten hatten wir ja bereits ausführlich was geschrieben; heute geht es um einen Teil des HTML-Codes dieser Seiten, der schon öfter Anlass zu Diskussionen war: die »Tag Cloud«, auch Schlagwort- oder Stichwortwolke genannt.

Laut Wikipedia ist eine Tag Cloud »eine Methode zur Informationsvisualisierung, bei der eine Liste aus Schlagworten alphabetisch sortiert flächig angezeigt wird, wobei einzelne unterschiedlich gewichtete Wörter größer oder auf andere Weise hervorgehoben dargestellt werden.« Lustigerweise ist die Tag Cloud in der linken Spalte eines der wenigen Code-Fragmente, die nicht nur den letzten Relaunch, sondern auch einige Relaunches davor unbeschadet überstanden hat – das zu Grunde liegende Konstrukt hat sich also seit Jahren nicht geändert. Aber wie bei jedem Relaunch erreichen uns wohl-gemeinte Tipps, wie man diese Tag Clouds besser umsetzen und semantisch anreichern könnte (womit sich mal wieder die alte Regel bewahrheitet, dass die Menge des Diskussionsbedarfs immer umgekehrt proportional zur Komplexität des Problems ist).

Weiterlesen …

So auch diesmal:

»… die Größe eines Links in der Tag-Cloud habt Ihr ja mit "strong in strong in strong …" realisiert. Ich habe gerade mal mit JAWS etwas herumgespielt, vor allem mit dem Konfigurationsmanager, und da keine Einstellung gefunden, mit der ich mir die Anzahl der strong-Tags vorlesen lassen kann. Daher mein Tipp: Schreibt doch die Nummer der strong-Tags als Zahl in Klammern hinter den jeweiligen Link und schiebt das dann per CSS aus dem Viewport. In der Überschrift ›Themen:‹ schreibt Ihr das halt als ›(Beliebtheit als Zahl in Klammern)‹, ebenfalls versteckt, dahinter. Das ist zwar so knapp, dass man erst nicht weiß, ob der Zahlenwert mit der Beliebtheit steigt oder ob es hier umgekehrt proportional gesehen werden muss, aber das wird spätestens bei der vier für HTML klar.«

(Detlef Girke per E-Mail)

Zum Hintergrund des ganzen: unsere Tag Cloud besteht aus einer Liste von Einträgen, die alphabetisch sortiert als Unordered List (UL) angelegt sind, jeder Eintrag steht in einem separatem List Item (LI). Wir bekamen auch einige Mails mit Vorschlägen, statt der UL doch eine geordnete Liste (OL) zu nehmen – danke für die Vorschläge, aber das Kriterium zur Sortierung der Einträge ist das Alphabet – damit sind die (zusätzlichen) Ordnungszahlen komplett überflüssig und bringen dem Nutzer keine brauchbaren Erkenntnisse.

Eine Sortierung nach Häufigkeit würde ebenfalls keinerlei Vorteile für den Nutzer bringen. Zum einen wäre für den Nutzer die Orientierung entlang des Alphabets dahin; zum anderen würde sich diese Sortierung auch laufend ändern. Ein weiteres Problem bleibt dadurch ebenfalls ungelöst: in den vergangenen Jahren haben wir sehr viel über HTML & CSS gebloggt, entsprechend viele Treffer gäbe es bei einer Sortierung nach diesen Tags. Nun gibt es aber Techniken wie z.B. WAI-ARIA, die relativ neu sind und daher in Summe nicht so häufig im Blog vorkommen – aber genau von diesen Beiträgen möchten wir, dass sich unsere Leser damit beschäftigen und eine alleinige Sortierung nach Häufigkeit käme einer Abwertung gleich und ginge somit am Ziel vorbei. Im Ernstfall würde man damit höchstens den Digg-Effekt erreichen, bei dem alle User auf das Ding mit der höchsten Zahl draufklicken.

Im Urzustand sieht unsere listenförmige Tag Cloud folgerichtig so aus:

  1. <div id="tagcloud">
  2. <h4>Themen:</h4>
  3. <ul>
  4. <li><a href="/blog/tags/ajax/" rel="tag">AJAX</a></li>
  5. <li><a href="/blog/tags/atag/" rel="tag">ATAG</a></li>
  6. [...]
  7. </ul>
  8. </div>

Allerdings ist dies noch nicht alles, und genau daran entzündet sich die Kritik: je nach Häufigkeit des Tags enthält der Link noch ein oder mehrere <strong> – je häufiger, desto mehr <strong> sind dort hineingeschachtelt:

  1. <li><a href="/blog/tags/bitv/" rel="tag"><strong><strong>BITV</strong></strong></a></li>

Durch geschicktes Ausnutzen der Vererbungen in CSS wird der enthaltene Linktext immer größer, je öfter strong ineinander verschachtelt ist:

  1. #tagcloud li strong {
  2. font-size: 1.1em;
  3. }

Nun bezieht sich einige Kritik darauf, dass <strong> unsemantisch sei – leider konnte uns jedoch bisher noch niemand eine echte, passendere Alternative aufzeigen. Kurzfristig hatten wir über die Verwendung von <small> & <big> zur Gewichtung der Einträge nachgedacht, aber dann davon abgesehen. Nicht weil es unpassend wäre (wobei: eventuell wäre es sogar passender und damit ehrlicher gewesen), sondern weil dies wohl einen Sturm der Entrüstung hervorgerufen hätte. Das Problem bleibt also: HTML bietet kein 100%-ig passendes Element zur semantisch korrekten Auszeichnung von Gewichtungen in Tag Clouds an. Also läuft es (wie so oft in HTML) auf eine Annäherung hinaus, die nach den Prinzipien der Einfachheit diejenige sein sollte, die am wenigsten stört (›least obtrusive‹) und dem Nutzer nichts vorgaukelt, das effektiv nicht vorhanden ist bzw. die Handhabung für den Nutzer nicht unnötig verkompliziert. Eben einfach.

Daher hatten wir uns damals nach intensivem Nachdenken für <strong> entschieden, eben genau weil mit <strong> ausgezeichneter Text in sämtlichen uns bekannten Screenreadern nicht anders vorgelesen wird als herkömmlicher Text ohne <strong> (wie übrigens bei <big> & <small> auch nicht, neben einer ganzen Reihe anderer, seit über einem Jahrzehnt spezifizierter Elemente).

Gleich mehrere Mails und IMs beschäftigten sich mit der Frage, ob man die Gewichtung dem Screenreader-Nutzer dann nicht besser durch die Ansage der Zahl der gefundenen Treffer mit diesem Tag mitteilen sollte. Auch mit diesem Vorschlag haben wir ein paar Probleme:

  1. Wenn die Zahlen einen Nutzwert haben sollen, dann müsste sich der Nutzer beim durchhören der Tag Cloud die Zahlen merken, dann nochmals zurückgehen und dann auf Basis der Zahlen als Entscheidungskriterium (Welcher Zahl? Der höchsten? Der niedrigsten? Dem Mittelwert?) entscheiden, welchem Link er folgt. Was aber nicht das eigentliche Problem des Vorschlags löst, nämlich:
  2. Warum sollte ein Nutzer einen Link anklicken, nur weil ihm die (hohe oder niedrige) Zahl irgendwie zusagt? Wenn jemand nach Tipps zu CSS sucht, dann ist es für ihn vollkommen unerheblich, ob da nun 2 oder 20 oder 200 Einträge dahinter sind. Weder wir noch der Benutzer können wissen, ob das Gesuchte gefunden wird (und zwar vollkommen unabhängig von der Anzahl; und nein, die Wahrscheinlichkeit das Gesuchte zu finden steigt nur unwesentlich mit der Zahl der verlinkten Blog-Beiträge).

Die wesentliche Information ist auch jetzt schon der verlinkte Text (›BITV‹, ›CSS‹, …), alles darüber hinaus wäre nicht Beiwerk oder zusätzlicher Komfort, sondern akustischer Müll. Wir glauben nicht, dass allzu viele Nutzer zu EfA kommen nur um nachzulesen, wie viel wir über ein bestimmtes Thema berichten – das ist vielleicht später mal für Archäologen interessant, aber nicht hier und jetzt für die Nutzer, die sich über bestimmte Themen informieren wollen.

Daher können wir auch den Nutzwert einiger Tutorials nicht nachvollziehen, die man zu dem Thema im Netz findet. Mark Norman Francis hatte im Dezember 2006 im Adventskalender von 24 ways eine Anleitung veröffentlicht, die nach seiner Auffassung alle Probleme löst und somit absolut barrierefrei zugänglich sei. Im fertigen Code-Beispiel stehen zusätzliche Informationen über die Anzahl zwar im HTML innerhalb des Links, diese werden aber per CSS aus dem Viewport geschoben.

In die gleiche Richtung geht ein neuerer Artikel »Semantische Tag Cloud« im SELFHTML aktuell Weblog, auf den Wolfgang Wiese per IM hinwies: auch hier werden zusätzliche (für grafische Browser wiederum versteckte) Infos wie »eher selten«, »ausgesprochen häufig«, usw. in die Tag Cloud geschrieben – allerdings ausserhalb der Links:

  1. <ul>
  2. […]
  3. <li><span style="font-size:169%"><a href="linkziel">Arzt-Suchdienst</a></span><span class="ignore"> ausgesprochen häufig</span></li>
  4. […]
  5. </ul>

Leider zeigen beide Ansätze bei genauerem Hinsehen, dass sie wohl kaum mit echten Screenreader-Nutzern getestet sein können, denn beide Ansätze haben grundsätzliche Probleme:

  1. Entweder lässt der Screenreader-Nutzer sich das alles vorlesen – dann steigt der Nutzer nach unserer Erfahrung ob der Menge der unnützen Zusatzinfos nach der Hälfte der Tag Cloud aus; oder
  2. Der Screenreader-Nutzer tabbt durch die Tag Cloud (von Link zu Link) – dann wiederum bleibt ihm die Zusatzinfo verborgen, wenn diese ausserhalb der Links steht. Und nein, die Infos in die Links selbst reinzuschreiben ist wie gesagt auch keine Lösung, weil dann wieder Punkt 1 greift.

Und deswegen ist die Tag Cloud so wie sie ist.

Nachtrag:

(Tipp von Rainer Schlegel via E-Mail)

21 Jan 2009

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 …

  1. <form id="searchform" action="/suche/" method="get" role="search" aria-owns="trefferliste">
  2. <fieldset>
  3. […]
  4. <label for="livesearch">Suchbegriffe:</label>
  5. <input name="q" id="livesearch" type="text" size="50">
  6. <button type="submit" id="submit" name="submit" value="Finden">Finden</button>
  7. </fieldset>
  8. </form>

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

  1. <ul class="ac_results" id="trefferliste" aria-live="assertive">
  2. <li class="ac_over"><span class="ac_match">foo</span></li>
  3. <li><span class="ac_match">foo</span>bar</li>
  4. [...]
  5. </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. }
Screenshot

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.

10 Dez 2008

Content-lastige Angebote wie das unsrige bestehen in der Regel immer aus der Navigation und dem wesentlichen Inhalt der jeweiligen Seite. Egal wo die Seite innerhalb der Struktur der Website angesiedelt ist – der Nutzer will immer nur eins von beidem: entweder weiternavigieren oder den Inhalt lesen. Daher sollte es mittlerweile zum guten Ton gehören, insbesondere dem Tastaturnutzer über sog. Skip-Links die Möglichkeit zum direkten Anspringen der wesentlichen Unterbereiche einer Seite zu geben. Screenreader-Nutzern erspart man so, sich immer wieder die gesamte Navigation anhören zu müssen, wenn man nur zum Artikel will.

Weiterlesen …

Drück mich, ich bin ein Skip-Link

Bereits vor dem aktuellen Relaunch hatten wir hier diese Skip-Links eingesetzt, mit denen der Navigations- und der Inhaltsbereich direkt angesprungen werden kann. Die Umsetzung ist denkbar einfach: unmittelbar nach Logo & Claim der Initiative folgen zwei Links zu Zielen innerhalb der Seite:

  1. <a class="skip" href="#navigation">Zur Navigation</a>
  2. <a class="skip" href="#inhalt">Zum Inhalt</a>

Diese sind per CSS ausgeblendet, allerdings nicht per display: none; komplett versteckt. Dies würde in den meisten Screenreadern dazu führen, dass die Inhalte dieser Links wirklich weg sind und dementsprechend nicht vorgelesen werden. Stattdessen haben wir die Links um einen Wert aus dem Viewport geschoben der garantiert, dass diese in grafischen Browsern nicht sichtbar sind:

  1. a.skip {
  2. position: absolute;
  3. left: -1000em;
  4. top: -1000em;
  5. height: 1px;
  6. width: 1px;
  7. }

Die Dopplung von left: und top: scheint auf den ersten Blick unnötig, aber ohne die zusätzliche Angabe eines Wertes für top: funkte uns der Mac-Safari dazwischen und verschob beim Durchtabben die gesamte Box mit dem Header um die Höhe des Skip-Links nach oben.

Sobald der Nutzer nach dem Laden der Seite die Tab-Taste drückt, werden nun die Links der Reihe nach wieder in den sichtbaren Bereich geschoben. Dort verbleiben sie, bis der Nutzer einen der Links per Enter auslöst (draufklicken geht natürlich auch) oder weitertabbt:

  1. a.skip:focus,
  2. a.skip:active {
  3. position: absolute;
  4. z-index: 1;
  5. top: 4px;
  6. left: 4px;
  7. height: auto;
  8. width: auto;
  9. color: #000;
  10. background-color: #eee;
  11. outline: 1px solid #999;
  12. }

Da sich die Links innerhalb eines (relativ) positionierten Elementes befinden, beziehen sich die Positionswerte für das position: absolute; auf das positionierte Eltern-Element – in diesem Fall also auf den Block mit dem #header dieser Seiten, von dessen oberer linker Ecke um 4px versetzt die Links erscheinen sollen.

Tipp: wenn Sie mehr als zwei, höchstens drei Sprungmarken brauchen, damit ihre Seite überhaupt bedienbar ist, dann haben Sie eventuell ein strukturelles Problem. Dies lässt sich nicht durch die Hinterlegung von einem Dutzend weiterer Skip-Links lösen, sondern nur indem Sie das strukturelle Problem selbst beheben.

Der obligatorische IE-Bug

… darf natürlich auch nicht fehlen: Die Ziele der Links müssen in Elementen liegen, die die Eigenschaft hasLayout=true (in VisualBasic-Diktion also −1) besitzen, sonst wandert der Fokus nicht mit, sondern verbleibt am Ursprung (beim nächsten Tastendruck wäre der Nutzer also wieder im Kopfbereich der Seiten). Wir erreichen dies hier, indem nur Block-Level-Elemente mit einer ID angesprungen werden, die in der Datei iehacks.css ein lockeres zoom: 1; verpasst bekommen.

Bonus-Trick

Nun nützt es dem Tastaturbediener nichts, wenn er nicht sieht, wo er denn hingesprungen ist. Daher setzen wir seit neuestem für viele lokale Sprungmarken innerhalb dieser Seiten den :target-Pseudo-Selektor aus CSS 3 ein, der schon von vielen modernen Browsern unterstützt wird. Sobald eine beliebige ID angesprungen wird, färbt sich deren Hintergrund ein und hebt diese damit auf der Seite hervor:

  1. *:target {
  2. color: #fff;
  3. background-color: #8fa6b8;
  4. }

Eine noch deutlichere Visualisierung der Sprungziele fanden wir auf den Seiten der schwedischen Hauptstadt http://stockholm.se/: dort werden per JavaScript & CSS die anzuspringenden Ziele mit einer gestrichelten Umrandung hervorgehoben – eine sehr gut gemachte Erleichterung für Tastaturnutzer, wie wir finden.

Nachtrag: Dirk Ginader hat dazu prompt was schönes gebastelt: »jQuery skipnavHighlight - Skip-Link-Ziele Anschaulich machen« (skipnav-demo).

P.S.: Mehr zum Thema Tastaturbedienung finden Sie in unserem Artikel »›Oops, wo bin ich?‹ – Ein Herz für Tastaturnutzer« und in der »BITV-Bedingung 13.6 - Gruppierung und Umgehung von Linkgruppen« sowie im Podcast vom 31. August 2006: »Viel hilft viel?«.

Kein Laborbericht, sondern nur eine kurze Statusmeldung: Wir haben in den letzten Tagen eine ganze Reihe Fleißaufgaben und Bugs abgearbeitet, den Code weiter aufgeräumt und ein paar Dinge eingebaut, die noch auf der To-Do-Liste standen. So sind jetzt alle Codelistings auf einen einheitlichen Stand gebracht – schön zu sehen z.B. in der Tabellenserie. Dann haben wir noch ein Lightbox-Skript nachgerüstet, mit dem größere Grafiken und Bilder angezeigt werden können – zu sehen z.B. in der BITV-Serie. Verwendet haben wir das Skript Thickbox 3.1, da sich die Bilder hier im Gegensatz zu vielen anderen Lightbox-Skripten auch per Tastatur wieder schliessen lassen.

Und weil das so viele Änderungen waren gibt es auch eine neue Version unserer Style Sheets zum Download. Wie immer mit sehr viel erklärender Prosa in den /* Kommentaren */.

28 Nov 2008

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:

Größere Ansicht: Hervorhebung der ARIA-Document-Landmarks mit der Accessibility Toolbar

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

Größere Ansicht: Hervorhebung der ARIA-Live-Regions mit der Accessibility Toolbar

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.

31 Okt 2008

Für Webentwickler bedeutete die Umstellung von Tabellen auf CSS, dass sie alte Gewohnheiten vergessen mussten. Sämtliche Techniken und Kniffe aus den Zeiten von Layout-Tabellen sind scheinbar »verlernt«. Das richtige Umsetzen echter Datentabellen erfordert jedoch eine Rückbesinnung: man muss sich wieder mühsam in die Spezifikationen einlesen und in das Tabellenmodell von HTML hineindenken.

Wie man tabellarische Daten so aufbereitet, dass sie nicht nur hübsch aussehen, sondern auch mit den assistiven Programmen von Menschen mit Behinderung optimal nutzbar sind erfahren Sie in unserer neuen Serie: »Benimmregeln für Datentabellen«

01 Jul 2008

Wie man zugängliche Werbebanner erstellt wird im Web Access Centre Blog des RNIB erklärt: »Accessible banner adverts« für statische Banner und »Accessible Flash banner ad guidelines« für die interaktive Variante. (via)

Jede Menge Accessibility-Tipps gibt es in mundgerechte Häppchen verpackt bei Mike Davies unter accessibilitytips.com.

Wenn dann noch Appetit auf mehr herrscht, dann empfehlen wir das »Accessibility Tutorial« bei webucator.com, einer überarbeiteten Version des Tutorials von Accessibility-Urgestein Jim Thatcher. Die Grundlagen sind zwar auf den amerikanischen Markt und die §508 zugeschnitten, aber die praktische Umsetzung ist ja dieselbe.

Ebenfalls brauchbar:

Damit keiner mehr sagen kann es gäbe keine brauchbaren Anleitungen …

24 Jun 2008

Für Screenreader unzugängliche Microformats fliegen raus. Zumindest bei der BBC, die ab dem nächsten Update ihrer Programmvorschau auf solche Microformats verzichtet, die das umstrittene abbr-Design-Pattern benutzen: »BBC - Radio Labs - Removing Microformats from bbc.co.uk/programmes«. Zur Erinnerung hier nochmal die Gründe:

10 Jun 2008

Die HTML Working Group des W3C hat drei neue Dokumente zu HTML 5 veröffentlicht:

02 Mai 2008

Erstmal die gute Nachricht: <font> is gone.

Dann die schlechte Nachricht: das alt-Attribut ist nach wie vor nur optional in HTML5. Mehr dazu und zu dem Endlosstreit in der Arbeitsgruppe:

Wenn Sie dann immer noch keine schlechte Laune haben, dann können Sie die Diskussion in den Mailinglisten-Archiven der HTML-Arbeitsgruppe weiterverfolgen. Aber sagen Sie hinter nicht, wir hätten Sie nicht gewarnt …

17 Apr 2008

Ungemein Praktisches für den täglichen Gebrauch im Weballtag: