WordPress 2.7 wird barrierefrei- und erzeugt daher invalides XHTML
Wie mache ich das Formular zum Absenden von Kommentaren barrierefrei - darauf bezieht sich dieser Artikel, denn: WordPress 2.7 wird barrierefreier aber invalid. Naja zumindest im Frontend, also dort wo die Besucher lesen und agieren können.
- aria-required ivalid

WordPress 2.7 gestaltet die Kommentare komplett um. Mancher mag dies mancher nicht, doch WP 2.7 bringt auch mehr Barrierefreiheit in den Formularen. Zumindest wird dies versucht.
. Durch den sehr mutigen Schritt barrierefrei zu werden wird gleichzeitig das XHTML invalid. Die Mühlen des W3 Concortiums mahlen sehr langsam und neue Technologie, die sehr hilfreich ist erzeugt daher Fehler im Markup.
Ich bringe hier die Kommentarform des neuen WP 2.7 und erkläre anhand dieser die neuen und auch die alten barrierefreien Teile davon. Ich erkläre was wieso einen Fehler beim XHTML Validator erzeugt.
Somit kann sich dann jeder entscheiden was wichtiger ist:konformes XHTML oder die neuen hilfreichen Teile.
Man kann diese Teile logischerweise nicht nur für WordPress Formulare verwenden.
Hier ist viel Code in diesem Artikel. Wer kein WP Theme Entwickler ist aber dennoch neugierig. Kann die Code Teile überspringen und den Rest lesen. Interessant ist es allemal.
Die Kommentar Form im neuen WordPress 2.7
< form action="<?php echo get_option('siteurl'); ?>/wp-comments-post.php" method="post" id="commentform"> <!--wenn jemand bei dir eingeloggt ist--> < ?php if ( $user_ID ) : ? > <p>Hallo:<a href="< ?php echo get_option('siteurl'); ?>/wp-admin/profile.php">< ?php echo $user_identity; ? ></a>. <a href="< ?php echo wp_logout_url(get_permalink()); ? >" title="Log out of this account">Log out »</a></p> <?php else : ?> <!--wenn ein Gast kommentiert--> <p><input type="text" name="author" id="author" value="< ?php echo $comment_author; ? >" size="22" tabindex="1" < ?php if ($req) echo "aria-required='true'"; ? > /> <label for="author"><small>Name < ?php if ($req) echo "(required)"; ? ></small></label></p> <p><input type="text" name="email" id="email" value="< ?php echo $comment_author_email; ? >" size="22" tabindex="2" < ?php if ($req) echo "aria-required='true'"; ? > /> <label for="email"><small>E-Mail (wird niemals veröffentlicht) < ?php if ($req) echo "(required)"; ? ></small></label></p> <p><input type="text" name="url" id="url" value="< ?php echo $comment_author_url; ? >" size="22" tabindex="3" /> <label for="url"><small>Website</small></label></p> < ?php endif; ? > <!--<p><small><strong>XHTML:</strong>Du kannst diese HTML Tags verwenden: <code>< ?php echo allowed_tags(); ? ></code></small></p>--> <p><textarea name="comment" id="comment" cols="100%" rows="10" tabindex="4"></textarea></p> <p><input name="submit" type="submit" id="submit" tabindex="5" value="senden" /> < ?php comment_id_fields(); ?><!--das braucht WP um den Kommentar zuordnen zu koennen-nicht loeschen--> </p> <!--das ist wichtig antispam plugins und andere nehmen das um sich hier einzuklinken--> < ?php do_action('comment_form', $post->ID); ? > </form>
Der neue barrierefreie Teil in dieser Form:
WP 2.7 fragt ab, ob etwas required – also absolut nötig ist und wenn dem so ist, dann gib aria-required ist wahr ( true) zurück.
<input type="text" name="author" id="author" value="<?php echo $comment_author; ?>" size="22" tabindex="1" <?php if ($req) echo "aria-required='true'"; ?> />
Wozu ist dieses aria-required da
ARIA ist eine Abkürzung für: Accessible Rich Internet Applications – MDC – sinngemäß übersetzt:Zugängliche, funktionsreiche Webanwendungen.
Aria-required ist ein Attribut, das es einem ermöglicht diese zugänglichen, nützlichen Dinge zu verwenden ohne die nötigen Steuerungsanwendungen programmieren zu müssen. Es gibt viele solcher Attribute.
Screenreader und ARIA
Nutzt jemand einen Screenreader, dann sagt einem der, dass dieses Feld ausgefüllt werden muß ohne dass man extra wo einen Hinweis dafür sichtbar machen muß.
Jetzt fragen sicher einige: Wozu, es steht ja eh dabei, dass man dies ausfüllen soll. Korrekt, das tut es, weil man ja auch die Sehenden davon informiert, doch für Screenreader Nutzer wird es um etliches leichter.
das Problem von invalidem XHTML und ARIA
Es gibt ganz viele automatische Tools, die die Barrierefreiheit einer Webseite erforschen. Hat man invalides XHTML fliegt man bereits bei der Grundprüfung solch automatischer Tools raus. Der Laie hat keine Ahnung wieso und sieht nur:Ah die sind nicht barrierefrei, weil invalides XHTML.
Solch automatische Tools werden von vielen Webseiten verwendet, die barrierefreie Webseiten zeigen. Sogenannte Show Case Webseiten. Jetzt hat der Webseitbesitzer eine barrierefreie Webseite nach modernstem Standard und wird dort eben deshalb nicht gezeigt.
Die Langsamkeit des W3C ist dafür verantwortlich, die zwar auch die Zugänglichkeitskriterien standardisieren, aber offenbar weiß bei denen die Linke nicht was die Rechte tut
.
tabindex und barrierefrei
Es gibt viele, die nicht mit der Maus navigieren können. Entweder weil es körperliche oder technische Einschränkungen gibt- als Stichwort:mit dem Laptop unterwegs.
Tabindex sollte aufsteigend sein und so in einem Formular angegeben werden, dass man sinnvoll durch die Felder “tabben” kann.
WP 2.7 Kommentarform mit fieldsets aufgebaut
Baut man die Kommentarform mithilfe vom “fieldsets” auf, kann man sowohl für sehende wie seheingeschränkte Personen eine gut barrierefreie Form anbieten. In dem folgenden Beispiel verzichtete ich auf das ARIA Attribut. Wer es nutzen mag kann es ja einbauen. Wie dies geht sieht man im 1.Code Beispiel auf dieser Seite.
So sieht die Kommentarform von WebDesign-in.de derzeit im template aus:
Achtung: Nicht kopieren!- da ich mein Codeconverter Programm sonst nicht funktioniert, mußte ich bei den PHP Angaben ein Leerzeichen einführen – tut mir leid dies kann ich derzeit nicht anders machen.
< form action="< ?php echo get_option('siteurl'); ?>/wp-comments-post.php" method="post" id="commentform">
<fieldset class="comment" id="comments"><legend>Lass uns drüber reden</legend>
<fieldset><legend>zum Thema</legend>
<label class="labelcomm" for="comment"><abbr title="Keine Beleidigungen, Link im Kommentar und der Kommentar wird moderiert, ein Name ist ein Name und kein Moneykeywort - ich lösche da die URl raus-Danke fürs Verständnis">Regeln</abbr><!--[if lte IE 6]><span class="abbr" title="Keine Beleidigungen, Link im Kommentar und der Kommentar wird moderiert, ein Name ist ein Name und kein Moneykeywort - ich lösche da die URl raus -Danke fürs Verständnis">Regeln</span><![endif]--> </label>
<textarea name="comment" id="comment" cols="60" rows="10" tabindex="1"></textarea>
</fieldset>
< ?php if ( $user_ID ) : ? >
< ?php _e('Hi!','mtsmagacine');? >
<a href="<?php echo get_option('siteurl'); ?>/wp-admin/profile.php">
< ?php echo $user_identity; ? ></a>.
<a href="< ?php echo wp_logout_url(get_permalink()); ? >" title="< ?php _e('Log out','mtsmagacine') ? >">
< ?php _e('Log out','mtsmagacine') ? >
»</a>
<?php else : ?>
<fieldset><legend>< ?php _e('Name and Mail are required','mtsmagacine');? ></legend>
<label for="email" class="email">< ?php _e('Mail','mtsmagacine');? >< ?php if ($req) _e('(required)','mtsmagacine'); ? >*<br />
<input type="text" name="email" id="email" value="< ?php echo $comment_author_email; ? >" size="32" tabindex="3" /><br />*< ?php _e('(will not be published)','mtsmagacine'); ? >
</label>
<label for="author" class="author">< ?php _e('Name','mtsmagacine');? >< ?php if ($req) _e('(required)','mtsmagacine'); ? > <br />
<input type="text" name="author" id="author" value="< ?php echo $comment_author; ? >" size="32" tabindex="2" />
</label>
<label for="url" class="url"> < ?php _e('Website','mtsmagacine');? ><br />
<input type="text" name="url" id="url" value="<?php echo $comment_author_url; ?>" size="32" tabindex="4" />
</label>
</fieldset>
< ?php endif; ? >
< ?php do_action('comment_form', $post->ID); ? >
<input name="submit" type="submit" id="submit" tabindex="6" value="senden" />
< ?php comment_id_fields(); ? >
</fieldset></form>Literatur und weiterführende Links
- Erklärung von ARIA in deutscher Sprache.
- DEV Opera hier wird erklärt worauf zu achten ist.
- Eine Diskussion des Accessibility Media Stammtisches .
- Diskussion bei W3C.
Basis Know-how CSS
Internetmarketing
7
zu : WordPress 2.7 wird barrierefrei- und erzeugt daher invalides XHTML
4 Kommentare
3 Trackbacks
-
WordPress 2.7- die ultimative Hilfeliste,
[ 10.12.08 um 09:43 ]
[...] 2.7 ist barrierefrei, daher invalides [...]
-
Validieren : Kommentarfeeds : Pluginverhalten : WordPress »miradlo bloggt,
[ 07.02.09 um 21:47 ]
[...] geht’s da wie Monika, den lasse ich gern stehen, da muss der Validator dazulernen. Das Attribut hilft Webapplikationen [...]
-
WordPress 2.8 WordPress Theme und Theme Verwaltung,
[ 17.05.09 um 13:08 ]
[...] Seheinschränkungen so nötige aria-required und wurde damit ein gutes Stück *mehr* barrierefrei. Der HTML Validator des W3C ist in ...
Tweets









Man sollte sich nicht an Kleinigkeiten aufhängen. Das W3C wird schon noch nachziehen, an erster Stelle stehen die User.
Also für mich ist gültiges HTML und CSS absolut keine Kleinigkeit, sondern die absolut wichtigste und elementare Grundvoraussetzung. Weniger kann eine Blog-Software von CMS will ich persönlich bei WP nicht einmal sprechen nicht mehr bieten und wenn die Seiten ohne plugins (denn die verhunzen den source leider permanent) nicht einmal mehr gültiges HTML und CSS aufweisen sollte kann ich auf Barrierefreiheit auch verzichten.
Die Grundfesten zerstören und dafür den ersten Stock aufbauen wäre nicht gerade sinnvoll, aber es ist ja noch beta und da kann sich noch einiges ändern.
Übrigens, die alte Hutblume rechts oben macht sich ganz nett. (;-)
Ob Wordpress validen Code generiert, kann man meistens doch gar nicht sagen, denn wir sollten hierbei zwischen dem reinen CMS/Blogsystem und dem verwendeten Theme unterscheiden. Es gibt ja nur wenige Template-Tags, die wirklich viel HTML-Code generieren, zB die neue wp_list_comments-Funktion seit Version 2.7.
Ich liebe validen Code, und daher bin ich meistens gezwungen, meine Themes selbst zu schreiben, denn dann muss ich mir auch an die eigene Nase fassen, wenn’s nicht korrekt ist.
Das große Problem mit nicht validen Plugins … da ist definitiv noch Nachholbedarf.
Ja, die eierlegennde Wollmilchsau in Bezug auf Netzauftritte ist noch nicht geboren. Viele Gremien schuffeln da so hinterher, die ein oder andere Pfefferminzteetasse muss geleert werden, bevor Beschlüsse gefasst und umgesetzt sind. Ich habe beispielsweise Kubrick so umgeschrieben und verändert, dass das Theme an sich XHTML-validiert. Dafür musste ARIA-required leider weichen. (Und kommt wieder rein, wenn’s valide wird.) Ich pflichte helmeloh bei: Der Untergrund muss stimmen, dann kommt der Aufbau. Und die Basis ist nun mal ein sauberes XHTML. Leider verderben mir einige Plug-Ins (z.B. die Akismet-Spam-Anzeige) die Validierung, aber das gehört nicht mehr in meine Abteilung, obschon ich immer die Fehler suche und zu beheben beabsichtige.
Eines noch: Deine Seite hier hat mir schon so manche Inspiration und Hilfe gegeben — fürwahr ein sehr nützlicher Auftritt.