Too Cool for Internet Explorer

Beitrag getagged mit ‘IE6’

Google unterstützt den Internet Explorer 6 nicht mehr

von Lars veröffentlicht am Montag, 1. Februar 2010 um 11:07 Uhr

endlich erhöht sich der Druck auf große Unternehmen den Microsoft Internet Explorer 6 aus ihrer Infrastruktur zu verbannen. Privatanwender sollten dies schon längst getan haben. Google wird diesen Webbrowser bei manchen Diensten ab März nicht mehr unterstützen.
Dieses nicht mehr zeitgemäße Programm verursacht sehr viel zusätzliche Entwicklungszeit bei der Erstellung von Webseiten und Webapplikationen. Da diese sonst fehlerhaft arbeiten. Und bremst meiner Meinung nach auch die Weiterentwicklung des noch verhältnismäßig jungen Internets.

deshalb
IE 6 must die

euer Lars

Best of Accessibility – ein paar grundlegende Erkenntnisse

von Lars veröffentlicht am Montag, 5. Oktober 2009 um 15:38 Uhr

Expertenrunde Teil 1

am 24.09.2009 war ich auf dem Symposium Barrierefreies Webdesign in Düsseldorf.

Es konnte in verschiedenen Vorträgen fundiertes Fachwissen in Sachen Webentwicklung mitgenommen werden, das war ja auch bei den ‘hochkarätigen’ Sprechern zu erwarten. Ich persönlich hatte in manchen Beiträge einen größeren Bezug auf Barrierefreies Internet erhofft. Aber Accessibility ist ja nicht nur ein Thema für gehandicapte Menschen. Webseiten sollten ja für alle Personen sinnvoll bedienbar sein.

Hier die ersten Punkte in Sachen best practice im Bereich Internetprogrammierung:

Aus dem Vortrag von Timo Wirth (Teamleiter Frontend Aperto AG) – Formulare sind Gespräche: Mitmachbarrieren im Web 2.0 abbauen

Zur Gestaltung von Fehlermeldungen auf Störungen bei Formulareingaben:
- In der ersten Zeile sollte eine vernünftige Aussage über den aufgetreten Fehler stehen. Damit dies das Erste ist was ein Screenreader vorliest und auch für jedermann das Problem sofort sichtbar ist. Sowie eine deutliche Farbgebung und grafische Anordnung die eine schnelle Informationsaufnahme unterstützt.
- Der Browsertitel der Fehlermeldungsseite sollte das Wort Fehler enthalten.

Die Überprüfung von Eingaben in Formularfelder sollte sofort in der gleichen Zeile durchgeführt werden (Inline Validierung). Wird zum Beispiel überprüft ob eine gültige Emailadresse eingeben wurde, kann direkt nach falscher Eingabe ein Warnhinweis erscheinen, damit ein Screenreader bei Fehlern nicht jedesmal das gesamte Formular erneut vorliest.

Der allseits bekannte * zum Markieren von Pflichtfeldern in Formularen ist überflüssig, da zum Steigern der Nutzbarkeit möglichst nur wirklich erforderliche Daten abgefragt werden sollten. Und Besucher auch nicht mit Seiten voller Eingabefelder genötigt werden.
Erfasse wichtige Daten nebenbei.
Weniger Formulare, weniger Barrieren.

Auszeichnungen nach WAI ARIA (Web Accessibility Initiative’s Accessible Rich Internet Applications) werden auch von Screenreadern sofort verarbeitet. Im Bezug auf Fehlermeldungen zum Beispiel role=’alert’
ARIA ist eine rein semantische Erweiterung für HTML, es werden in dynamischen Webanwendungen Informationen zu Rollen, Eigenschaften und Zuständen der Elemente hinzugefügt. Es macht Webseiten die mit JavaScript und Ajax angereichert sind für behinderte Menschen, besonders Blinde, durch die Screenreader-Kompatibilität, besser zugänglich.
Barrierefreie Web 2.0 Anwendungen mit WAI ARIA
siehe auch Slideshow am Ende dieses Beitrages.

Auch der Einsatz sogenannter CAPTCHAs ist fraglich, diese werden verwendet, um zu entscheiden, ob das Gegenüber ein Mensch oder eine Maschine ist. Um SPAM-Bots auszuschließen.

Bild eines captchas

eine sinnvolle Umsetzung in akustische Formen für Hörbehinderte gibt es nicht und nicht nur Timo Wirth ist der Meinung, das Verhindern von Datenmüll darf nicht auf die Benutzer einer Webseite abgeschoben werden. Dazu gibt es verschiedene Technologien um dieses serverseitig abzufangen.

  1. Sinnhaftigkeit prüfen
  2. Geschwindigkeit messen

siehe auch