Ich hab ein schickes Tool gefunden für die Qualitätsüberprüfung. Sauber gemacht und auch in der kostenlosen Version gut brauchbar: der qualidator. Diesen Blog hab ich da noch nicht mit getestet, da müsste ich erstmal vorher ein wenig tun 
Aber die Vereinsseite Kaule e.V. schneiden mit über 86% schon recht gut ab.
Archiv für Kategorie
Qualitätssicherung qualidator
HTML 5 Sie streiten wieder
Heftige Kritik wurde die Tage an WHATWG und der Umsetzung von HTML 5 laut. Bemängelt wird vor allem die mangelnde demokratische Struktur und der Umgang mit Barrierefreiheit. Einfach für Alle hat dazu einige Links zusammengestellt.
Aus meiner Sicht ein Problem, das auch XHTML 2 betrifft. Statt in kleinen Schritten neue HTML-Versionen zu verfassen und, die auch kurzfristig in neuen Browserversionen verfügbar sind, wurde mit HTML 5 der große Wurf
versucht. Wenn nach jahrelanger Arbeit kein Feedback aus der Praxis kommt, ist klar, dass Frust aufkommt.
Nicht ganz so einfach: Einfach für Alle
Der Weblog von Einfach für Alle oder kurz EfA gehört zu den unverzichtbaren Quellen eines Internetentwicklers. Nahezu täglich werden neue Trends vorgestellt und beleuchtet, meistens durch eine Auswahl hochwertiger Artikeln im Web. Allerdings täuscht der Titel. Viele verlinkte Artikel sind keineswegs einfach, und da vorwiegend englischsprachige Texte verlinkt werden, wird es nochmal schwieriger. Doch auch Einsteiger in der Materien werden ihre Perlen auf EfA finden, wobei ganz besonders die Podcast-Beiträge hervorzuheben sind.
Sprachauszeichnung: viel Arbeit?
Kommt drauf an. Wer nur auf englische Seiten verlinkt und jedes Buzz Word
verwendet, was gerade modern ist … Trotzdem: wer Fachartikel zum Internet schreibt, der hat viel zu tun 
spd.de: Relaunch mit valider Seite
Nicht nur das HTML des Internetauftritts der SPD ist valide, es wird durchgehend auf Layouttabellen verzichtet. Die Verantwortlichen haben viel Energie investiert, den Auftritt barrierefrei zu gestalten. Für Termine werden Microformats eingesetzt.
Ich arbeite zur Zeit an der Umsetzung des neuen SPD-Layouts für das WebsoziCMS, PHP Trawler Web CMS und Wordpress, um das neue Layout umgehend auch für unsere Auftritte einsetzen zu können.
Kurz und knapp: eine barrierefreie Struktur für einfache Internetseiten
Um eine barrierefreie Seite zu erstellen braucht es nicht viel. Wer ein paar Grundregeln einhält, der schafft es auch. Folgender Aufbau soll verdeutlichen, wie einfach das eigendlich ist. Und wer so eine Seite mal mit seinem Handy aufgerufen hat, der weiß, dass nicht nur Blinde was davon haben.
Seitentitel am Anfang
Damit die Besucher wissen, auf welcher Seite sie sich befinden, kommt als erster Textinhalt ein Seitentitel in einen H1-Tag. Das kann auch ein Bild sein mit einem entsprechenden ALT-Text.
Sprungmarken
Sinnvoll sind Sprungmarken zum Inhalt, zur Navigation und zur Suche. Folgt nach dem Sprungmarken kein zusätzlicher Text mehr, genügt die Sprungmarke zum Seiteninhalt.
Suche
Soweit sie vorhanden ist, folgt sie am besten nach den Sprungmarken.
Navigation
Eine ein- oder mehrteilige Navigation. Mehrteilige Navigationselemente können mit Überschriften voneinander getrennt werden (H2 bis H6, da H1 nur für den Titel verwendet wird).
Zusätzlicher Text vor dem Inhalt
Steht zwischen Navigation und Inhalt weiterer Text (auch ALT-Texte für Bilder), muss er mit Strukturelementen wie Überschriften deutlich von der Navigation getrennt werden.
Inhalt
Der Inhalt ist der zweite Hauptabschnitt nach der Navigation, er beginnt also mit H2.
Weiterer Text, Fußzeile
Dieser dritte Abschnitt, soweit vorhanden, sollte ebenfalls von Inhalt mit einer H2-Überschrift getrennt werden. Wenn in dem Abschnitt Zusatzinfos für den Inhalt stehen, wird er mit h3 dem Inhalt zugeordnet.
Struktur als HTML-Code
Die folgende Struktur kann natürlich noch ergänzt werden mit DIV-Containern für die Gestaltung.
<h1>Titel</h1> <ul> <li><a href="#inhalt">Zum Inhalt</a></li> <li>(Suchformular)</li> </ul> <h2>Navigation</h2> <ul>(Liste(n) mit den Links innerhalb der Seite)</ul> <h2>Weiterer Text</h2> <p>... Text ...</p> <h2>Inhalt</h2> <p>... Text ...</p> <ul>(Liste(n))</ul> <h2>Infos</h2> <p>... Text ...</p> <ul>(Liste(n))</ul> <p>Fußzeile</p> <ul>(Liste(n) in der Fußzeile)</ul>
WebsoziCMS: Textausgabe / Handyausgabe geplant
Für eine der kommenden Versionen ist eine Text- bzw. Handyversion geplant, die vom Aufbau anders gestaltet ist. Der Aufruf soll einmal automatisch über die Browser-Kennung, zum anderen auch über einen Link am Anfang des Dokuments erfolgen. Beide Versionen können gewechselt werden, was in einer Session für die jeweilige Sitzung gespeichert wird.
Die Einstiegsseite ist dann immer die Seitenübersicht, die Einstellungen für die Ansicht (ohne Bilder, wechseln zur Layoutversion). Ergänzt wird die Seitenübersicht mit einem Link auf die Blöcke, die als egenständige Seiten dargestellt werden. Jede Inhaltsseite erhält einen Link auf die Seitenübersicht und ein einfaches Suchformular am Seitenanfang sowie einen Sprunglink nach oben am Seitenende.
Dieses zusätzliche Ausgabeformat (in XHTML 1 mobile) wird nicht offiziell als berrierefreie Version angeboten. Ich denke aber, dass neben der sich verstärkenden Nutzung des Internets mit mobilen Endgeräten auch Menschen mit speziellen Behinderungen davon profitieren können.
Ein Zeitpunkt steht noch nicht fest, vielleicht schaffen wir es noch dieses Jahr.
Zugänglichkeit auch für Anwendungen
In einem Manifest (in deutscher Übersetzung) fordert die Gruppe Web Standards Project (ATF) mehr Zugänglichkeit und Einhaltung der Standards für HTML-Anwendungen, insbesondere Conent-Management-Systeme. Das stellt sich mir die Frage:, ob wohl ein komerzielles Web-Content-Management-System, das nicht automatisch standardkonformen Code produziert, diesen Fehler wegen der Gewährleistungspflicht nachbessern muss.
Qualitätssicherung bei Anwendereingaben
Da nützt das schönste standardkomforme, barrierefreie Seitenlayout nichts, wenn Anwender beliebigen Quelltext eingeben können. Nur wenige Systeme bieten eine Prüfung der Eingaben an, die mit PHP oder HTML-Tidy durchaus – wenigstens teilweise – umsetzbar ist. Genauso wie Zahlen, Zeichenlängen oder Datumsangaben bei der Eingabe validiert werden, muss auch das HTML validiert werden. Das sollte nach dem vorgegebenen Doctype der Liveseiten geschehen und auch auf entsprechende Einschränkungen Rücksicht nehmen, die durch die Ausgabe gestellt werden.
In den meisten Texteingaben in CMSs ist eine HTML-Eingabe nötig. In Titeln sollten mindestens Sprachen und Abkürzungen ausgezeichnet werden können, Blockelemente sind dort aber eher verboten, da Titel häufig in Überschriftentags ausgegeben werden. In Textfeldern stellt sich die Frage, was der Anwender eingeben darf. Ist Javascript, sind OBJECT-Tags oder APPLETs erlaubt, sind IDs im Seitenlayout vorgegeben, sollen FONT-, U-, B- und I-Tags umgewandelt werden?
Soweit automatische Korrekturen nicht das Aussehen der Ausgabe ändern, braucht der Anwender nicht über die Änderungen informiert werden. Werden jedoch HTML herausgefiltert oder Fehler erkannt, die nicht automatisch korrigiert werden können, muss der Autor zur Korrektur aufgefordert werden. Problematisch wird dies bei Richtexteditoren, darum sollte sicher gestellt werden, dass der Richtexteditor bereits sauberen Code ausliefert.
Ob der Anwender auch Code speichern darf, der nicht den Standards entspricht, muss von Fall zu Fall entschieden werden. Im privaten Weblog darf sicher es mal etwas lockerer zugehen als auf einem großen Portal. Werden Inhalte ausgetauscht, ist ein sauberer Quellcode sicher die Vorraussetzung.
Sind Tabellelayouts barrierefreier?
Eine der großen Änderungen in der Dokumentenstruktur in den letzten Jahren ist der Verzicht auf Tabellen für Layoutaufgaben. Dabei sind Tabellenlayouts nicht unbedingt weniger barrierefrei, wenn sie sinnvoll eingesetzt werden.
Menschen mit eingeschränktem Sehvermögen sind die größte Gruppe der Nutzer mit Zugangshürden, insbesondere wenn die Internetseite auch alte Menschen ansprechen soll.
Wenn ich die Schrift auf Seiten vergrößere, die mit CSS-float oder -position:absolute arbeiten, tritt häufig das Problem auf, dass Textabschnitte verdeckt werden oder in einen anderen Bereich hineinragen. Wenn die wichtigsten Bereiche der Seite mit Tabellen definiert sind, passt sich die Tabelle an, ich kann die Seite auch mit extrem vergrößerten Schriften lesen.
Natürlich kann die Breite und Position auch in relativen Größen zur Schriftgröße (em) angegeben werden, aber auch dadurch wird die Seite nicht besser lesbar, da sie von vorn herein eine größere Breite und damit schnell Querscrollleisten ausgibt.
Das soll natürlich kein Freibrief sein, wieder für alles Tabellen zu verwenden. Vor allem muss das Dokument nach wie vor serialisierbar sein, das heißt, alle zusammenhängenden Bereiche müssen in einer Tabellenzelle stehen. Ich verweise hier ausdrücklich auf mögliche Alternativen wie CSS-Layout mit durchgehenden Spalten ohne Layouttabellen.
Damit die Daten in den Tabellenzeilen auch auffindbar sind, wenn kein CSS verfübar ist, sollte das veraltete Attribut align="top" verwendet werden. Sonst kann es passieren, dass der Inhalt weit nach unten verschoben ist.
