accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

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.