Barrierefrei AAA?

[Holger S.]

Ist das wirklich so wie es da steht: Barrierefrei "AAA" nach WAI

http://www.kremsmuenster.at/system/web/sonderseite.aspx?menuonr=218245357&detailonr=218245357

Würde mich stark interessieren...

Danke für Eure Einschätzungen, Holger

[rfb]

Moin

Nein, da "Failed validation, 43 errors"
Valides Markup ist aber eine der Anforderungen der WAI-Richtlinien.

Gruß
rfb

[frankx]

Hellihello Holger,

der Validator bringt eine Menge Fehler. Ob das barrierefrei ist? Was aber solls denn deiner Meinung nach sonst nicht sein?

Gruß,

frankx

[Holger S.]

Was aber solls denn deiner Meinung nach sonst nicht sein?

Ich bin nicht wirklich Fit in diesem Bereich, darum die Anfrage an die Spezialisten!

Holger

[Thomas J.S.]

Hallo,

Ich bin nicht wirklich Fit in diesem Bereich, darum die Anfrage an die Spezialisten!

http://validator.de.selfhtml.org/validate/?uri=http://www.kremsmuenster.at/system/web/sonde
rseite.aspx?menuonr=218245357&detailonr=218245357&lang=ge&doctype=doctypeAUTO&charset=chars
etAUTO

http://www.contentquality.com/mynewtester/cynthia.exe?rptmode=-1&url1=http%3A%2F%2Fwww.kremsmuenster.at%2Fsystem%2Fweb%2Fsonderseite.aspx%3Fmenuonr%3D218245357%26detailonr%3D218245357
http://www.contentquality.com/mynewtester/cynthia.exe?rptmode=2&url1=http%3A%2F%2Fwww.kremsmuenster.at%2Fsystem%2Fweb%2Fsonderseite.aspx%3Fmenuonr%3D218245357%26detailonr%3D218245357

(Absichtlich keine echte Links)

Grüße
Thomas

[Thomas J.S.]

PS: du kannst auch
http://webxact.watchfire.com/ benutzen, ist sehr aufschlussreich.

Grüße
Thomas

[迪拉斯]

Hey,
nein, die Seite verdient höchstens Stufe A. Sie verstößt mindestens gegen §9.3 (Zeile 391), §13.1 (Zeilen 62, 131) und §10.5 (Zeilen 24ff.)

[molily]

Hallo,

nein, die Seite verdient höchstens Stufe A. Sie verstößt mindestens gegen §9.3 (Zeile 391)

onclick="javascript:this.value=''" soll gegen §9.3 verstoßen? Diese Richtlinie ist eh völlig hohl, weil die (barrierfreie!) JavaScript-Praxis sie weitesgehend ignoriert (u.a. weil Browser onclick unabhängig von Mausklicks feuern). Sicher wäre onfocus besser, aber onclick ist höchstens dumm, aber keine Barriere, die essentielle Funktionalität zerstört.

§13.1 (Zeilen 62, 131)

<a id="content"></a>? Was hat das mit Links zu tun? Dieser Link hat kein Ziel, das ist völlig gerechtfertigt.

und §10.5 (Zeilen 24ff.)

zur Navigation springen | zum Inhalt springen
Anfrage |Bauen & Wohnen |Diskussion |Formulare |Inhalte |News |Ortsplan |Impressum |Home

Dort sind ganz vorbildlich Trennzeichen zwischen den Links. Wieso soll das gegen die Richtlinie verstoßen, die gerade das anrät? (Im Übrigen würde ich die Richtlinie heute nicht mehr als uneingeschränkt gültig bezeichnen, schließlich hat sie eine eingebaute »Lebenszeit«.)

WCAG-AAA-Konformität testet man nicht mal eben aus dem Ärmel - deshalb ist die Frage des Threadstarters auch etwas deplatziert. Barrierefreiheit zu testen ist ein schwieriger und langwieriger Prozess. Hier kann also nicht so einfach bewiesen werden, dass sie Seite AAA-konform ist. Bei der Widerlegung scheint es sich ähnlich zu verhalten.

Mathias

[迪拉斯]

Hey,

onclick="javascript:this.value=''" [...] weil Browser onclick unabhängig von Mausklicks feuern

Das stimmt nicht, Tastaturnavigation in bspw. Opera tut das nicht. Ein Gegenbeispiel reicht ja schon, das Argument einzureißen. Du darfst gerne "unter anderem" ausführen.

<a id="content"></a>? Was hat das mit Links zu tun? Dieser Link hat kein Ziel, das ist völlig gerechtfertigt.

Eben. Es gibt UAs, welche Links auflisten. Sehr untauglich, wenn der Linktext leer ist, kein (Kon)text ist gegeben.
Der Link ist ja gar kein Verweis, sondern ein Sprungziel. In XHTML ist das mit dem Attribut id gelöst, welches man direkt ans passende Element pappt, dann braucht man solche Barriere nicht.

Dort sind ganz vorbildlich Trennzeichen zwischen den Links.

Nicht zwischen zum Inhalt springen und Anfrage. Ein UA liest das vor, ohne Luft zu holen. Das hört sich bescheuert an, verwirrt den Zuhörer, errichtet damit eine Verständnisbarriere.
Die zwei englischen Wörter werden auch deutsch ausgesprochen, weil sie nicht mit xml:lang markiert sind.

Im Übrigen würde ich die Richtlinie heute nicht mehr als uneingeschränkt gültig bezeichnen, schließlich hat sie eine eingebaute »Lebenszeit«.

Meinungen sind keine Argumente. Zitatbeleg zur Lebenszeit?

WCAG-AAA-Konformität testet man nicht mal eben aus dem Ärmel

Das weiß ich auch, deswegen hab ich mich auch auf die einfachen Dinge beschränkt, die sich maschinell prüfen lassen.

Hier kann also nicht so einfach bewiesen werden, dass sie Seite AAA-konform ist. Bei der Widerlegung scheint es sich ähnlich zu verhalten.

Die Nichtkonformität lässt sich sehr wohl einfach beweisen, man braucht ja nur ein Gegenbeispiel.

Jetzt war ich vorbildlich kontrovers der Kontroverse willen und möchte auch zweimal fachlich hilfreich haben.

[molily]

Hallo,

onclick="javascript:this.value=''" [...] weil Browser onclick unabhängig von Mausklicks feuern
Das stimmt nicht, Tastaturnavigation in bspw. Opera tut das nicht.

Du widersprichst einer Aussage, die ich gar nicht gemacht habe. Natürlich feuert kein Browser (zumindest soweit ich weiß) onclick beim Tastaturfokus auf ein Eingabefeld. Das habe ich auch nicht behauptet, sondern nur den allgemeinen Sinn der Regel in Frage gestellt.

<a id="content"></a>? Was hat das mit Links zu tun? Dieser Link hat kein Ziel, das ist völlig gerechtfertigt.
Eben. Es gibt UAs, welche Links auflisten. Sehr untauglich, wenn der Linktext leer ist, kein (Kon)text ist gegeben.

Wieso sollte ein Browser einen Link ohne href in einer Liste aller Links des Dokuments aufführen? Leere a-Elemente ohne href sind völlig legitim (wenn auch nicht der sinnvollste Code). Wenn ein User-Agent diese als normalen Link mit einem Ziel interpretiert, dann ist er einfach fehlerhaft. Screenreader wie JAWS haben so eine entsprechende Funktion, aber nicht einen solchen Fehler.

Dort sind ganz vorbildlich Trennzeichen zwischen den Links.
Nicht zwischen zum Inhalt springen und Anfrage. Ein UA liest das vor, ohne Luft zu holen. Das hört sich bescheuert an, verwirrt den Zuhörer, errichtet damit eine Verständnisbarriere.

Die WCAG-Regel wurde ursprünglich eingeführt, weil einst ältere Screenreader Braillezeilen so angesteuert haben, dass aneinander klebende Links in einer Zeile (!) nicht voneinander unterschieden werden konnten. Heutzutage halte ich <p><a href="...">...</a></p> <p><a href="...">...</a></p> oder auch <ul> <li><a href="...">...</a></li> <li><a href="...">...</a></li> </ul> für barrierefrei. Wer unbedingt will, kann da noch unsichtbare Zeichen zwischen einfügen, die nur vorgelesen werden. Ich halte es nicht für nötig und sehe das auch nicht als Erfordernis für WCAG-Konformität.

Im Übrigen würde ich die Richtlinie heute nicht mehr als uneingeschränkt gültig bezeichnen, schließlich hat sie eine eingebaute »Lebenszeit«.
Meinungen sind keine Argumente. Zitatbeleg zur Lebenszeit?

Die Richtlinie beginnt mit Until user agents ... Das heißt soviel wie: Nur solange bestimmte (fehlerhafte) Benutzerprogramme auf dem Markt sind, muss man diese Regeln beachten, um mit den Programmen kompatibel zu sein. Und die WCAG stammen aus dem Jahr 1999, seitdem hat sich einiges geändert.

Mathias

[Gunnar Bittersmann]

Hello out there!

<a id="content"></a>? Was hat das mit Links zu tun?

Es kann Ziel eines Links sein. Nicht jeder Anker ('a'-Element) muss Ausgangspunkt eines Links sein.

Eben. Es gibt UAs, welche Links auflisten. Sehr untauglich, wenn der Linktext leer ist, kein (Kon)text ist gegeben.

Blame it on the UAs, wenn sie an unpassender Stelle alle Anker anstatt nur alle Ausgangspunkte von Links auflisten.

(Der IE weiß Anker sehr wohl von Links zu unterscheiden; er wendet :hover nur bei 'a'-Elementen mit 'href'-Attributen an. ;-))

In XHTML ist das mit dem Attribut id gelöst

'id'-Attribute gibt’s in HTML 4.01 auch.

Die zwei englischen Wörter werden auch deutsch ausgesprochen, weil sie nicht mit xml:lang markiert sind.

IIRC wirkt 'xml:lang' nur bei Verarbeitung als 'application/xhtml+xml' o.ä.; nicht aber bei 'text/html', dann wirkt das 'lang'-Attribut.

(Welches es in XHTML 1.1 nicht mehr gibt, was einer der Gründe gegen dessen Verwendung allgemein und dessen Auslieferung als 'text/html' im Speziellen ist. @molily: Du siehst mein VBG? ;-))

See ya up the road,
Gunnar

[Sha-Mann]

Was sich heutzutage alles Barrierefrei nennt - unglaublich!