nicht angemeldet
Hallo, Michael.
Da fängt es ja schon an: Netscape 4 schmiert ohne ersichtlichen Grund bei Einsatz von Label ab.
<NOLAYER><LABEL></LABEL></MOLAYER> macht wiederum Schierigkeiten bei anderen Browsern.
Krass, das ist tatsächlich sehr problematisch, das ist mir erst jetzt aufgefallen, NS4 crasht tatsächlich. Da werde ich einmal entsprechende Hinweise auf meine Seiten stellen.
Die praktische Umsetzung von Standard-Codes und WAI-Richtlinien gestaltet sich als schwierig.
Es ist z.B. nicht möglich beim allseits beliebten IE CSS-Definitionen wie Focus und Hover einzusetzen. Da muss man auf DHTML zurückgreifen.
Was hat das denn mit Zugänglichkeit zu tun? Es ist vielleicht eine Hilfe, dass ein selektiertes Eingabefeld optisch hervorgehoben wird, jedoch würde ich es nicht als obligat bezeichnen. Oder habe ich eine WCAG-Richtlinie bzgl. dessen vergessen?
Abgesehen davon, dass man für Netscape 4 und andere ältere non-standard-Browser eigene Seiten erstellen muss, bläht sich doch ein WAI-konformer Code für mehrere Browser unnötig auf, sodass die Ladezeit selbst bei Modem 56k noch zu hoch ist.
Was bedeutet WAI-konformer Code? Die WCAG schreiben eine Trennung von Inhalt ([X]HTML) und Präsentation (CSS) vor, und NS4 und übrigen alten Browsern liefert man ganz simpel ein minimales Stylesheet, siehe http://pixels.pixelpark.com/~koch/hide_css_from_browsers/ und http://aktuell.de.selfhtml.org/tippstricks/css/browserweiche/index.htm.
Hier kann serverside scripting mit Client-Erkennung helfen,der dann die browser-spezifischen Tags und CSS einsetzt, weshalb das nicht unter einen Forenbereich HTML oder PHP sondern unter WAI fallen sollte.
Das stimmt, es ist eine technikübergreifende, ganzheitliche Problematik.
Das Hervorheben von Formularfeldern ist mir momentan nicht so wichtig, dass ich eine DHTML-Lösung für alle Browser implementiere, ich benutze :focus und warte, bis es alle Browser unterstützen. Ich habe keine Lust, mir für ein eher minderwichtiges Grafikfeature einen abzubrechen, um es interoperabel zu programmieren.
Das ist nur ein kleiner Einblick in die Problematik - deswegen wollte ich hier einen neuen Forenbereich vorschlagen.
Bisher habe ich einfach als Interimlösung "(Zugänglichkeit)" oder "(Barrierefreiheit)" oder "(WCAG)" in dem Threadtitel angegeben.
Oh, super, darf ich meckern? :)
<script type="text/javascript" src="fun_fontsize.js"></script>
Was bezweckt das? Für Fließtext darfst du keine Schriftgröße angeben, für Strukturelemente nur relative, diese Schriftgrößenwähler sind Bullshit. Ich lese Function New Media, das sind die Leute von einfach-fuer-alle.de, bei denen sieht ein besuchter Link aus wie ein normaler, und eine Pixelgenaue und zudem kleine Schriftgröße geben sie auch an.
FONT: bold 0.8em/120% Verdana, Tahoma,Arial, Helvetica, sans-serif;
Dese Notation kenne ich gar nicht, was denn nun, 0.8em oder 120%? Du *darfst* *auf* *keinen* *Fall* die Schriftgröße für Fließtext herunterskalieren! Ich weiß was du vorhast, aber du suchst font-size-adjust weil Verdana vergleichsweise groß ist, aber die Browser unterstützen diese Eigenschaft nicht, deswegen ist es unklug, mit 0.8em nachzuhelfen.
<fieldset class="head"><legend>Navigationshilfe Kapitel</legend>
fieldset und legend dürften nur für ein *Formular* benutzt werden.
[<A tabindex=8 accesskey=8 href="#8" title="Die direkte Zugänglichkeit der in Internet-Angeboten eingebetteten Benutzerschnittstellen ist sicherzustellen.">8</a>]
Bitte schließe die Attributwerte in Anführungsstriche ein (attribut="wert" ). Zudem schreibe bitte *striktes* HTML (4.01 Strict oder XHTML 1.0 Strict). Außerdem musst du nicht jeden Link einklammern, du musst ihn nur durch nicht zu einem Link gehörende Zeichen von dem nächsten Link trennen (<a>murks</a> | <a>purks</a>).
<script type="text/javascript">
//<![CDATA[
...
//]]>
</script>
In HTML 4.x ist der script-Elementinhalt per se ein CDATA-Bereich, so eine Syntax macht nur in XHTML Sinn. Über diesen seltsamen fun_fontSize-Quark habe ich schon etwas gesagt.
<td class="head" height="24" colspan="3">Checkliste für barrierefreies Webdesign</td>
Keine Tabellenzelle! Das gehört in ein caption-Element oder mit etwas mehr Erläuterungen auch in das summary-Attribut des table-Elements.
<td class="Zelle" colspan="3">Die Checkliste orientiert sich an der Anlage der Barrierefreie Informationstechnik-Verordnung. Kursiv dargestellte Anforderungen entsprechen der Priorität 2 der Verordnung und sollen für zentrale Navigations- und Einstiegsseiten, insbesondere Portale, beachtet werden.</td>
Das gehört auch nicht in eine Zelle, eher in die summary oder als Erklärung *vor* die Tabelle, aber keinesfalls in die Tabelle, denn es hat nichts mit den Tabellendaten zu tun.
<td class="Zelle" style="width: 40px;"><strong><br>
</strong></td>
<td class="Zelle"><br>
</td>
<td class="Zelle"><br>
</td>
Pfui! Schon wieder ein grober Fehler. :) Abstände macht man *keinesfalls* mit leeren Tabellenzellen, das ist Markupmissbrauch und ganz und gar nicht WCAG-konform. Hier musst du mit padding arbeiten.
<td class="Zelle"><strong><br></strong></td>
<td class="Zelle"><strong>Anforderungen</strong></td>
<td class="Zelle"><strong>Praxistipps für HTML und DHTML</strong></td>
Du musst Kopfzeilen einer Tabelle mit dem thead-Element kennzeichnen und *darfst* *nicht* td-Elemente benutzen, sondern musst th-Elemente benutzen. Außerdem gehört in die erste Spalte die Erklärung "Nummer der Richtlinie" oder so etwas.
fieldset und legend missbrauchst du scheinbar öfters.
tabindex=270 accesskey=0
Das benutzt du dutzende Male.
Die übrigen Tabellen haben ebenfalls die genannten Probleme.
Grüße,
Mathias