Accessibility Valet Demonstrator

[willie.de]

Hallö ins Forum,

ich bemühe mich seit geraumer Zeit um barrierefreies HTML. Die Grundprobleme sind mir soweit klar... Jetzt würd ich gerne (aus Eitelkeit und als Denkanstoß ;) ein WAI-Logo auf meine Seiten setzen.

Bei der Suche nach einem Validator bin ich unter anderem auf http://valet.webthing.com gestoßen. Dieser meckert bei mir das b-Element und das target-Attribut an. <b> Verwende ich nur, um die Suchmaschinen zu bedienen. Und beim - sparsam verwendeten - 'target' schreibe ich sowohl im Text als auch im 'title' des <a> einen Hinweis auf das zu öffnende Ziel.

Ich zitiere beispielhaft die Kommentare (Test Suite: 'WCAG AAA' Report Format: 'Verbose'):

<b>
   [WCAG-AA/Low] Should this be a header?
   Fetter Text</b>
Ja, wieso fragt der das? Nö, isses nich!

<a href="externer_URI" target="_blank" title="Klick öffnet neues Fenster">
   [WCAG-AA/Medium] Do not open new windows without warning the user
Linktext</a>
Das tu ich doch gar nicht...

Meine Fragen:
1. Ist das Verwenden von <b>, um wichtige Suchwörter im Text für Suchmaschinen zu markieren, überhaupt noch zeitgemäß (sinnvoll usw.)???
2. Das Attribut target wird (unabhängig vom Inhalt) immer als deprecated gekennzeichnet. Ist das richtig? Weder in SELFHTML noch beim W3C finde _ich_ dafür einen Hinweis.
3. Wenn ich 'target="_blank"' weiterhin verwenden wollte (was nicht sein muss): Darf ich das mit der geforderten Warnung an den Benutzer tun - und damit barrierefrei sein?
4. Was bedeuten die Fehlermarkierungen [WCAG-AA/Low] etc.? Ist mein Code nicht WAI-valide? Und wenn - wie 'un-valide'?

Danke für Unterstützung und
Grüße aus Leipzig
willie

[Gunnar Bittersmann]

Willie,

<b>
   [WCAG-AA/Low] Should this be a header?
   Fetter Text</b>
Ja, wieso fragt der das?

Um ganz sicher zu gehen?

Nö, isses nich!

Na denn is ja jut.

<a href="externer_URI" target="_blank" title="Klick öffnet neues Fenster">
   [WCAG-AA/Medium] Do not open new windows without warning the user
Linktext</a>
Das tu ich doch gar nicht...

Das muss man ja dreimal lesen, um deine Spitzfindigkeit mitzukriegen. ;-)

Kann denn der Accessability-Checker (von Validator würd ich hier nicht sprechen) deutsch?

1. Ist das Verwenden von <b>, um wichtige Suchwörter im Text für Suchmaschinen zu markieren, überhaupt noch zeitgemäß (sinnvoll usw.)???

Nein, b ist ebenso wie i deprecated, weil sie das Layout beschreiben. Dafür gibt es em (emphasis) und strong. Voreinstellungen in Browsern sind kursiv für em und fett für strong.

IMHO sollten Hervorhebungen, die erst beim Lesen des Textes erkennbar sein sollen, mit em ausgezeichnet werden; Hervorhebungen, die schon beim Überfliegen der Seite erkennbar sein sollen, mit strong.

2. Das Attribut target wird (unabhängig vom Inhalt) immer als deprecated gekennzeichnet. Ist das richtig? Weder in SELFHTML noch beim W3C finde _ich_ dafür einen Hinweis.

Ja. In den Strict-Varianten von HTML 4.01 und XHTML 1.0 gibt’s kein target mehr.

3. Wenn ich 'target="_blank"' weiterhin verwenden wollte (was nicht sein muss): Darf ich das mit der geforderten Warnung an den Benutzer tun - und damit barrierefrei sein?

Überlass doch dem User die Entscheidung, ob er die verlinkte Ressource im gleichen Fenster, neuen Tab oder neuen Fenster haben will. DAS wäre barrierefrei.

4. Was bedeuten die Fehlermarkierungen [WCAG-AA/Low] etc.? Ist mein Code nicht WAI-valide? Und wenn - wie 'un-valide'?

Du kennst die Zugänglichkeitsrichtlinien für Web-Inhalte 1.0?

Gunnar

[Sven Rautenberg]

Moin!

Nein, b ist ebenso wie i deprecated, weil sie das Layout beschreiben.

Das W3C verwendet den Begriff "deprecated" aber nicht für die Tags b und i. Sie sind auch in Strict-Versionen noch enthalten.

Dafür gibt es em (emphasis) und strong. Voreinstellungen in Browsern sind kursiv für em und fett für strong.

em und i sowie strong und b werden heutzutage synomym verwendet.

IMHO sollten Hervorhebungen, die erst beim Lesen des Textes erkennbar sein sollen, mit em ausgezeichnet werden; Hervorhebungen, die schon beim Überfliegen der Seite erkennbar sein sollen, mit strong.

IMO sollte kursiver Text unbedingt vermieden werden, genauso wie unterstrichener.

• Sven Rautenberg

[wahsaga]

hi,

IMO sollte kursiver Text unbedingt vermieden werden,

warum das?

gruß,
wahsaga

[Gunnar Bittersmann]

wahsaga,

IMO sollte kursiver Text unbedingt vermieden werden,
warum das?

Kursive Schrift ist auf dem Bildschirm schlechter lesbar.

IMHO ist gegen einzelne kursiv hervorgehobene Wörter nichts einzuwenden; längere Textpassagen sollten nicht kursiv sein.

Gunnar

[Ashura]

Hallo Gunnar.

Kursive Schrift ist auf dem Bildschirm schlechter lesbar.

Das wird sich hoffentlich durch die immer mehr verbreitete Schriftartenglättung ändern.

IMHO ist gegen einzelne kursiv hervorgehobene Wörter nichts einzuwenden; längere Textpassagen sollten nicht kursiv sein.

Ein Zitat beispielsweise lässt sich aber in kursiver Form auf einen Blick erkennen. (Wenn dem Zitat nicht extra ein eigener Block eingeräumt wurde.)

Gruß, Ashura

[Gunnar Bittersmann]

Sven,

Das W3C verwendet den Begriff "deprecated" aber nicht für die Tags b und i. Sie sind auch in Strict-Versionen noch enthalten.

Stimmt, auch in XHTML 1.1 noch. In XHTML 2 nicht mehr.

em und i sowie strong und b werden heutzutage synomym verwendet.

Dann machen em und strong keinen Sinn; man könnte genauso die kürzeren i und b verwenden.

IMO sollte kursiver Text unbedingt vermieden werden, genauso wie unterstrichener.

Auch farbigen oder fetten Text versuchen User anzuklicken. Die Gefahr der Verwechslung mit Links ist wohl bei jeder Hervorhebung gegeben.

Gunnar

[Gunnar Bittersmann]

Ashuras Posting scheint der Server gefressen zu haben. Ich sah jedenfalls kein Grung, warum ein Dev das gatan haben sollte. Hier isses nochmal:

Hallo willie.de.

<b>
   [WCAG-AA/Low] Should this be a header?
   Fetter Text</b>
Ja, wieso fragt der das? Nö, isses nich!

Verwende hier bitte strong.

»»

<a href="externer_URI" target="_blank" title="Klick öffnet neues Fenster">
   [WCAG-AA/Medium] Do not open new windows without warning the user
Linktext</a>
Das tu ich doch gar nicht...

Soll heißen: Am Besten vollständig auf target verzichten, da dieses Attribut eigentlich für Framesets vorgesehen ist. Du kannst davon ausgehen, dass der User weiß, wie er mit seinem Browser umzugehen hat und ein neues Fenster öffnet, wenn es _ihm_ beliebt. Alles andere wäre Bevormundung.

1. Ist das Verwenden von <b>, um wichtige Suchwörter im Text für Suchmaschinen zu markieren, überhaupt noch zeitgemäß (sinnvoll usw.)???

Suchmaschinen interessieren sich nur für reinen Text und evtl. Überschriften, alles andere fällt unter den Tisch.

2. Das Attribut target wird (unabhängig vom Inhalt) immer als deprecated gekennzeichnet. Ist das richtig? Weder in SELFHTML noch beim W3C finde _ich_ dafür einen Hinweis.

Ich habe gerade nichts besseres gefunden: target ist in Frameset und Transitional vorhanden und AFAIK nicht missbilligt, lediglich in Strict.

3. Wenn ich 'target="_blank"' weiterhin verwenden wollte (was nicht sein muss): Darf ich das mit der geforderten Warnung an den Benutzer tun - und damit barrierefrei sein?

Du sagst doch schon: "was nicht sein muss" -- wenn du auf target verzichten kannst, dann solltest du es tun. Dies betrifft mehr die Benutzungsfreiheit, als die Barrierefreiheit.

Gruß, Ashura

[Gunnar Bittersmann]

@self:

Grung

Sollte Grund heißen, nicht Grunge.

@Ashura:

<b>
Verwende hier bitte strong.

Warum? Warum nicht em? Doch nicht etwa, weil fett die Defaulteinstellung der Browser für strong ist?

Wenn strong und em lediglich als Synomyme für b bzw. i verstanden werden, hätte man auch bei denen bleiben können.

Wo ich den Unterschied sehe, steht in meinem anderen Posting.

Gunnar

[Ashura]

Hallo Gunnar.

Danke für das Wiederherstellen meines Beitrages. ;)
Zwischenzeitlich ging hier scheinbar gar nichts mehr, ich erhielt nur eine Fehlermeldung "Could not open socket" und konnte nichts abschicken.

War das nur bei mir so?

Warum? Warum nicht em? Doch nicht etwa, weil fett die Defaulteinstellung der Browser für strong ist?

Nein, natürlich ist em auch eine Möglichkeit.

Gruß, Ashura

[willie.de]

Hallö nochmals,

vielen Dank für die erleuchtenden Antworten! :-D

Da teilweise die gleichen Themen behandelt wurden und dennoch einige Aspekte offen geblieben sind, möchte ich nicht einzeln antworten, sondern mache ausnahmsweise an dieser Stelle einen Subthread auf. Ich präzisiere meine undeutlichen Fragen in der Hoffnung, nochmals Hilfe zu bekommen:

1. Ist nur strictes HTML barrierefrei?

2. Ist das hier eine Eigendefinition des Accessibility Valet Demonstrator? Oder werden <b>-Inhalte aus irgendeinem Grund inhaltlich als Überschrift behandelt?

<b>
   [WCAG-AA/Low] Should this be a header?
   Fetter Text</b>

3. Ich hatte mich bezüglich des 'target' selbst überlistet: Ich verwende transitional HTML - dafür konnte ich keine deprecation finden. (Nichtsdestotrotz wurde es vom "Validator" als deprecated bemängelt.)
Unter bestimmten Bedingungen (z. B. Suche mit vielen Ergebnissen) kann ein neues Fenster durchaus im Sinne des Benutzers sein. Außerdem bieten "richtige" Benutzeragenten die geforderten Fähigkeiten zum Unterdrücken bereits an.
Darf ich ein 'target="_blank"' mit der geforderten Warnung an den Benutzer setzen - und damit barrierefrei sein?

4. Zu meinem Verständnis: Gibt es - wie beim Großen Validator - einen WCAG-Validator, nach dessen Benutzung man sich beruhigt ein WAI-Logo auf die Seite kleben kann? (Wenn ich mir Bobby so anschaue, wundere ich mich durchaus über die eine oder andre Meldung.)

Danke für Unterstützung und
Grüße aus Leipzig
willie

[Ashura]

Hallo willie.de.

1. Ist nur strictes HTML barrierefrei?

Nein. Du kannst auch barrierefreie Seiten mit HTML 4.01 erstellen.
Dein Kenntnissstand rund um Auszeichnung und Tücken bei der Minderung von Barrieren ist das Ausschlaggebende.

2. Oder werden <b>-Inhalte aus irgendeinem Grund inhaltlich als Überschrift behandelt?

<b>
   [WCAG-AA/Low] Should this be a header?
   Fetter Text</b>

Ich vermute einfach mal, dass dem Validator schon oft auf diese Art und Weise ausgezeichnete Überschriften vorgesetzt wurden, die eigentlich nach einem heading-Element verlangten.
Und so wurde wahrscheinlich diese Standardabfrage eingebaut.

Darf ich ein 'target="_blank"' mit der geforderten Warnung an den Benutzer setzen - und damit barrierefrei sein?

Was nützt die Warnung, wenn das Fenster sowieso immer in einem neuen Fenster geöffnet wird? Sofern man nicht über einen modernen Browser verfügt, der dies zu unterbinden weiß, kann man sich zwar seelisch und moralisch auf das neue Fenster vorbereiten, aber ändern kann man daran nichts.
Verzichte nach Möglichkeit auf target.

Gruß, Ashura

[willie.de]

Hallö Ashura,

danke für deine Antworten!

Ich versuch nochmal, meinen Gedankengang in der mir am meisten begegnenden Realität zu beschreiben: Wenn ich auf einer Seite mehrere potenziell interessante Links finde, benutze ich die [Strg], um beim Anklicken das Fenster mit der Linkliste offen zu halten. Das möchte ich einem Benutzer meiner Seite ersparen.

Meine sehr präzise Frage ohne Einschränkung:
Darf ich innerhalb der Richtlinien ein 'target="_blank"' mit entsprechendem Hinweis auf das öffnende Fenster setzen?

Danke für Unterstützung und
Grüße aus Leipzig
willie

[Ashura]

Hallo willie.de.

Darf ich innerhalb der Richtlinien ein 'target="_blank"' mit entsprechendem Hinweis auf das öffnende Fenster setzen?

Wenn es dir und deinen Besuchern nicht widerstrebt, ja.
(Und sofern du kein strictes HTML verwendest.)

Gruß, Ashura

[willie.de]

Hallö Ashura,

Danke für Antwort!

Wenn es dir und deinen Besuchern nicht widerstrebt, ja.

Mein Regelverständnis ist damit wieder gerade gerückt ;-)

(Und sofern du kein strictes HTML verwendest.)

So wie ich mir das vorstelle - und ich halte meine Seiten jetzt schon für zugänglich -, wird wohl strictes HTML die Basis sein... (I don't like Firlefanz.)

Grüße aus Leipzig
willie

[Ashura]

Hallo willie.de.

So wie ich mir das vorstelle - und ich halte meine Seiten jetzt schon für zugänglich -, wird wohl strictes HTML die Basis sein... (I don't like Firlefanz.)

Dann _musst_ du auf target verzichten.

Gruß, Ashura

[willie.de]

Hallö Ashura,

Dann _musst_ du auf target verzichten.

Klar.
Ich halte korrespondierende Diskussionen für wenig hilfreich. ;-)

Grüße aus Leipzig
willie

[Tim Tepaße]

Hallo Willie,

4. Zu meinem Verständnis: Gibt es - wie beim Großen Validator - einen WCAG-Validator, nach dessen Benutzung man sich beruhigt ein WAI-Logo auf die Seite kleben kann?

Es kann gar keinen vollwertigen Validator geben, da einige der Web Content Accessibility Guidelines kaum oder nur unter großen Schwierigkeiten maschinell zu überprüfen sind. Ein paar Beispiele:

Guideline 4: Clarify natural language usage
Ein Validator bräuchte hier haufenweise Vokabulare verschiedener Sprachen, um erkennen zu können, zu welcher Sprache ein Wort gehört. Noch schlimmer: Wie soll er entscheiden, ob eine Abkürzung in dem Kontext des Dokumentes gebräuchlich ist oder eine Erklärung braucht?

Guideline 12: Provide context and orientation information
Zum Beispiel eine passende Gruppierung von Formularen. Ein Validator könnte hier höchstens anhand Heuristiken versuchen zu erkennen, daß Dinger wie <fieldset> oder <legend> fehlen, aber er kann nicht bestimmt sagen, dass sie notwenig sind, höchstens empfehlen.

Mein Liebling: Guideline 14. Ensure that documents are clear and simple
„Using clear and simple language promotes effective communication. Access to written information can be difficult for people who have cognitive or learning disabilities. Using clear and simple language also benefits people whose first language differs from your own, including those people who communicate primarily in sign language.“

Spricht wohl für sich selbst. ;-)

Schon allein der letzte Punkt ist für eine Priority 1 erforderlich, ohne den man sich keinen der dämlichen Buttons auf die Seite pappen darf.

Ich sage nicht, dass die WCAGs ein Schuss in den Ofen sind, aber sie sind nunmal kein technischer Standard, mit dem man eben mit seiner Implementierung übereinstimmt oder es ansonsten falsch macht. Weswegen man  das auch nicht einfach validieren, falsifizieren oder testen kann, auch nicht anhand einer einer Checkliste. Sondern man muß von Fall zu Fall und anhand des Kontextes einer Seite entscheiden, die passenden Fallstricke und Techniken kennen und selbst entscheiden. Bobby und andere maschinelle Prüfer können helfen, Empfehlungen und Warnungen geben, aber die letzte Instanz, der beste Validator ist hier immer noch das eigene Hirn, Version 1.0.

Tim

[willie.de]

Hallö Tim,

Danke für die klare Antwort. Ich konnte folgen.

[...] ohne den man sich keinen der dämlichen Buttons auf die Seite pappen darf.

......................................^
Uups! Wieso das?

[...] aber die letzte Instanz, der beste Validator ist hier immer noch das eigene Hirn, Version 1.0.

Irgendsowas dachte ich mir. Allerdings erst bei Beta 0.82 ;-)

Danke für Unterstützung und
Grüße aus Leipzig
willie

[MudGuard]

Hi,

[...] ohne den man sich keinen der dämlichen Buttons auf die Seite pappen darf.
......................................^
Uups! Wieso das?

Wem hilft der Button?
Hilft er demjenigen, der trotz des Buttons mit der Seite nicht zurechtkommt?
Hilft er demjenigen, der mit der Seite zurechtkommt?

Kommt irgendjemand besser mit der Seite zurecht, wenn der Button vorhanden ist? Oder wenn er fehlt?

Was bringt der Button?

cu,
Andreas

[willie.de]

Hallö ins Forum,

Wem hilft der Button?

Wem helfen irgendwelche Buttons auf Webseiten? Wem helfen irgendwelche Links auf Webseiten? Anders gefragt: Wem hilft - insbesondere in diesem Forum - ein Link zur Schreinerei Waechter?

Ich hatte im Eingangsposting formuliert

Jetzt würd ich gerne (aus Eitelkeit und als Denkanstoß ;) ein WAI-Logo auf meine Seiten setzen.

Das finde ich trefflich formuliert.

Einerseits wäre ich als Full-Non-Profi sehr stolz, wichtige Standards im Web vollständig zu erfüllen. Und ich würde das dann auch gerne kenntlich machen.

Andererseits - und das ist mir wichtiger - hoffe ich damit den einen oder anderen Besucher/Weblaien/Topsitedesigner, der über meine Seite stolpert, zu zeigen, dass auch korrekte, barrierefreie Seiten optisch ansprechend (und hoffentlich inhaltlich relevant) sein können. Ein potenzieller Auftraggeber für Webinhalte könnte das dann zur Bedingung machen. Ein Auftragnehmer könnte es als notwendigen Standard vertreten/umsetzen. Das könnte dann dazu führen, dass barrierefreie Seiten das Web "erobern".

Das 'zu:}' steht nicht grundlos in meinem Selfcode. Das heißt nicht, dass ich von einer Wahrnehmungsbeeinträchtigung betroffen wäre, nur dass ich es für _sehr_ wichtig halte, Menschen nicht auszugrenzen.

Aber ich denke, diese Diskussion wurde hier im Forum auch schon geführt...

Grüße aus Leipzig
willie