26.11.2010
In den letzten Monaten haben wir mit Monster.de und Stellenanzeigen.de zwei Angebote von privaten Stellenbörsen geprüft. Beide Websites haben im Test schlecht abgeschnitten. Wie sieht es mit der Zugänglichkeit der Jobbörse der Arbeitsagentur aus?
Startseite Jobbörse der Arbeitsagentur (jobboerse.arbeitsagentur.de/)
Die Angebote der Arbeitsagentur haben BIK in den letzten Jahren öfters beschäftigt:
Im Zuge der im November 2009 gestarteten Testserie zu Jobbörsen haben wir uns nun die Jobbörse der Arbeitsagentur erneut vorgenommen.
Getestet wurden drei Seiten, die ohne vorhergehende Benutzerregistrierung nutzbar sind:
Externe Angebote – siehe auch unten – wurden nicht berücksichtigt.
Das ist eine relativ kleine Stichprobe. Die Angebote für registrierte Benutzer erlauben vielfältige Aktionen wie das Hinterlegen von Bewerbungsunterlagen oder den direkten Kontakt zum Arbeitsvermittler. Eine Untersuchung dieser Funktionen hätte leider den Rahmen dieses Tests gesprengt.
Die Startseite mit dem Suchformular macht einen vergleichsweise aufgeräumten Eindruck. Hier gibt es hinsichtlich der Barrierefreiheit, abgesehen von grenzwertigen Helligkeitskontrasten und leichten Schwächen bei der Gliederung, keine nennenswerten Probleme. Auf der zweiten Seite, der Ergebnisliste der Suche, gibt es Probleme mit Alternativtexten. Die wichtigen Schaltflächen zum Blättern in der Ergebnisliste haben leere Alternativtexte. So sehen Benutzer von Hilfsmitteln, die das vorhandene title-Attribut nicht ausgeben können oder über Voreinstellungen unterdrücken, nur die erste von maximal 20 Ergebnisseiten.
Die eigentlichen Stellenangebote sind vom Aufbau her identisch. Hier fällt der relativ ungewöhnliche Einsatz von fieldset zur Gliederung auf. Da es sich nicht um ein Formular handelt, wären HTML-Überschriften hier der bessere Weg. Die Beschreibungstexte der Stellenangebote könnten besser strukturiert sein. So gibt es diverse Unterüberschriften, die nicht als HTML-Überschriften ausgezeichnet sind.
Auf der Ergebnisseite der Suche werden auch Stellenangebote aus externen Quellen, z.B. von privaten Stellenvermittlern, angeboten. Diese Angebote verweisen auf externe Seiten, die naturgemäß sehr unterschiedlich aufgebaut sind und häufig hinsichtlich Barrierefreiheit nicht optimiert wurden. Teilweise wird hier auch direkt auf (unzugängliche) PDF-Dokumente verlinkt. Immerhin sind diese Angebote deutlich gekennzeichnet. Leider werden dabei aber keine Angaben zur Barrierefreiheit gemacht.
Nach den entmutigenden Ergebnissen der privaten Jobbörsen erweist sich das Angebot der Bundesagentur für Arbeit als kleiner Lichtblick. Die Website ist gut zugänglich. Das darf und muss man allerdings auch erwarten, denn die Angebote der Agentur fallen natürlich in den Geltungsbereich der BITV.
Internetadresse: jobboerse.arbeitsagentur.de
Geprüft am: 25. 11. 2010
Testergebnis: 93,25 von 100 Punkten (gut zugänglich)
Zum Punkt "Belegen von Annahmen":
Wollte man jede Annahme, die einmal mit guten Gründen in das Prüfverfahren Eingang gefunden hat, immer erneut belegen, müsste man statt mit dem BITV-Test mit einer Auswahl von Hilfsmitteln in verschiedenen Versionen und Konfigurationen testen. Dies ist schon wegen des Aufwands kein gangbarer Weg. Deshalb eben gibt es den BITV-Test.
Deswegen steht in den WCAG Guidelines auch nicht einfach, dass Webangebote mit allen möglichen technischen Hilfsmitteln und Einschränkungen benutzbar sein sollen. Sondern es werden Regeln aufgestellt, über deren Einhaltung die Nutzbarkeit indirekt gesichert wird. Und so funktioniert im Prinzip auch der BITV-Test.
Dabei kann man sich oft nicht sicher sein, dass die Einhaltung der Regeln auch das gewünschte Resultat bringt. (Denn Screenreader sind nicht auf barrierefreie Sites optimiert, sondern sie müssen auch Schrott zugänglich machen.)
Deswegen sind Screenreader-Tests nötig, um die Aussagekraft des BITV-Tests immer wieder zu überprüfen und (vor allem in Bezug auf neue Techniken) zu verbessern. BIK führt zusammen mit INCOBS Screenreader-Tests durch und wertet die Ergebnisse bei der Überarbeitung des Prüfverfahrens aus. Unser letzter Screenreader-Test wurde gerade veröffentlicht.
Wichtig ist, dass diese Screenreader-Tests ein Element unser Testüberarbeitung sind und nicht bei den Prüfungen selbst zum Einsatz kommen.
Zu den Ausklappelementen und dem leichten Punktabzug im Prüfschritt 2.2.1 "Grafiken vor wechselndem Hintergrund erkennbar":
Wir sehen die Umsetzung der Ausklappelemente mit Icons ohne eigenen Hintergrund als einen Grenzfall, den man auch anders (weniger streng als "teilweise erfüllt") hätte bewerten können.
Es gibt allerdings Gründe, die für ein "teilweise erfüllt" sprechen:
Die spezifische Funktion "Ausklappen", die hinter dem Icon steckt, ist deutlich nur über die Grafik vermittelt.
Wenn Mausnutzer, die mit eigenen (hellen) Hintergrundfarben unterwegs sind, nicht über die Links fahren (oder sie durchtabben), kann ihnen die angebotene Ausklapp-Funktionalität leicht entgehen - gerade, weil der Rest der Seiteninhalte (abgesehen von dem eingeklappten Abschnitt "Konditionen des Stellenangebots") ja bereits als Default ausgeklappt präsentiert wird.
Zu dem Punkt, dass der Test Innovation abwürge:
Wir sehen tatsächlich häufiger einen Konflikt zwischen der Nutzung neuer dynamischer Techniken und der bestmöglichen Barrierefreiheit. Die Darstellung von Akkordeon-Widgets etwa ist öfters ein Problem, wenn bei bestimmten Einstellungen Hintergrund-Grafiken, Grafiken ohne eigenen Hintergrund (wie in diesem Fall), oder CSS-Auszeichnungen wegfallen.
Andererseits haben dynamische Elemente (gerade Ausklapp-Mechanismen) vom Standpunkt der Gebrauchstauglichkeit natürlich auch unbestreitbare Vorteile. Wir stehen nicht auf dem Standpunkt, dass man auf dynamische Elemente grundsätzlich verzichten sollte, bewerten aber schon, wie gut zugänglich sie umgesetzt sind.
Zum Punkt "wo Redundanz ok ist und wo nicht":
Auch in diesem Fall sollten wir unsere Bewertungspraxis bei der Überarbeitung des Prüfverfahrens überdenken bzw. die Kriterien der Bewertung deutlicher dokumentieren.
Do. 16.12.2010
09:18 Uhr
„Das stimmt, der Ausklappmechanismus kann auch durch einen Textlink angestossen werden“
Womit der Prüfschritt erfüllt ist. Steht so in eurer eigenen Beschreibung. Ihr müsstet euch bitte mal einigen, wo Redundanz ok ist und wo nicht. Ihr könnt nicht an der einen Stelle Redundanz abwerten und an anderer Stelle zusätzlich einfordern - das ist beliebig und nicht vermittelbar.
Ein Abzug ist also auch hier nicht gerechtfertigt. Vor allem weil:
„… Der könnte ja auch auf eine neue Seite führen. In Sachen Erwartungskonformität ist das nicht optimal …“
… haarsträubender Unsinn ist. Leute - denkt doch bitte mal eure Sachen bis zum Ende durch: wenn dem so wäre, dann müsste jedes jQuery-Akkordeon, jede lokale Sprungmarke, jedes Fly-Out-Menü, ja streng genommen alles was ich an Interaktivität innerhalb einer Seite machen kann, zu einer Abwertung führen, weil der Nutzer nicht vorhersagen kann ob irgendwas auf- und zuklappt oder ob sich vielleicht eine neue Seite öffnet.
So langsam wird hier ein ganz deutliches Muster sichtbar: Alles was nicht in euer einmal vorgefertigtes Bild passt, wie eine Webseite auszusehen hat, wird kurzerhand abgewertet.
Dass Ihr damit effektiv jegliche Innovation abwürgt, selbst wenn diese zum Wohl der Nutzer eingesetzt wird und nachweislich barrierefrei nutzbar ist, scheint dabei billigend in Kauf genommen zu werden, Hauptsache das Prüfverfahren wird durchgeboxt.
„Da wir die Ausgabe nicht in allen, auch älteren, Hilfsmitteln unter allen Konfigurationen praktisch überprüfen können, verlangen wir eben die Verwendung des alt-Attributs …“
Noch ein schönes Beispiel für meine These. Ihr habt gar nichts überprüft, Ihr habt auf Basis von Annahmen bewertet (man könte auch das auch mit gutem Grund „geraten“ nennen). Ihr könnt eure Annahmen nicht belegen, Ihr ignoriert die gesamte Funktionsweise der WCAG2 (hier: Nachweis der Erfüllung eines Punkts durch die Dokumentation geeigneter Techniken) und Ihr bleibt bei eurer einmal vorgefassten Meinung.
Mi. 15.12.2010
14:39 Uhr
„… authors should use caution in applying this technique.“
Vielleicht solltet Ihr nochmal die Bedeutung des Wortes „should“ nachlesen, bevor Ihr weiterhin solche Ahnungslosigkeit in die Öffentlichkeit hängt. Vorzugsweise hier: http://www.ietf.org/rfc/rfc2119.txt
„SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.“
Meine Güte - deswegen gibt es im Englischen (im Deutschen übrigens auch) unterschiedliche Worte wie zum Beispiel:
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
@ Dirk Jesse
Failure F89 der WCAG 2.0 sagt, dass assistive Technologien unterschiedliche Reparaturstrategien anwenden und dass deshalb nicht vorhersehbar ist, wie die Ausgabe aussieht. Da wir die Ausgabe nicht in allen, auch älteren, Hilfsmitteln unter allen Konfigurationen praktisch überprüfen können, verlangen wir eben die Verwendung des alt-Attributs, das laut HTML und WCAG den Inhalt eines Bildes ersetzen soll, während das title-Attribut für zusätzliche (nicht essenzielle) Informationen gedacht ist. Deshalb steht ja in der Technik H33:
"Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique C7: Using CSS to hide a portion of the link text (CSS) or H30: Providing link text that describes the purpose of a link for anchor elements (HTML)."
Ein weiterer Punkt, der für unsere Bewertung spricht, ist die Nutzung mit abgeschalteten Bildern. Im IE8 sind noch die Umrisse der Icons zu sehen, im Firefox verschwinden sie vollständig. Selbst ein Rendering des alt-Textes, in dem nur der erste Buchstabe ("z" oder "w") angezeigt würde, wäre im Kontext der Angabe "Seite 1 von 20" immer noch ein Hinweis auf die Navigationsmöglichkeit zu Folgeseiten - besser als das vollständige Verschwinden dieser Blätter-Icons.
Ob die vom BITV-Test vorgesehene Bewertung "nicht erfüllt" für leere alt-Attribute in Bedienelementen so aufrecht erhalten oder revidiert werden sollte, ist allerdings eine berechtigte Frage, die in die weitere Entwicklung des Testverfahrens einfliessen wird.
Wir begrüßen deshalb auch die hier laufende Diskussion, da sie Argumente für diesen Entscheidungsprozess beiträgt.
@ Kerstin Probiesch
Grafiken vor wechselndem Hintergrund erkennbar: Das stimmt, der Ausklappmechanismus kann auch durch einen Textlink angestossen werden. Die Funktionalität ist gewährleistet, allerdings sind die +/- Icons ein wesentlich klarerer Hinweis auf diese Funktion als ein normaler Textlink (hier die Überschrift des Bereichs). Der könnte ja auch auf eine neue Seite führen. In Sachen Erwartungskonformität ist das nicht optimal, zusammen mit den Problem der schlechten Erkennbarkeit der Icons auf einem hellen Seitenhintergrund ist das "teilweise erfüllt" (entspricht hier nur 0,25 Punkte Abzug) aus unserer Sicht gerechtfertigt.
Guten Morgen,
ich verfolge die Diskussion hier nun schon seit dem Wochenende und einige Dinge bleiben unbeantwortet bzw. die Diskussion wird einfach abgewürgt.
- Blätterfunktion: Entsprechend WCAG 2.0 ist die verwendete Lösung grundsätzlich zulässig (H33), wenn auch mit Vorsicht zu genießen. Alle bisher erfolgten Tests der Blätterfunktion mit assistiven Technologien sind jedoch offenbar erfolgreich und belegen die Zugänglichkeit - klingt für mich nach erfolgreichem Bestehen der Erfolgskriterien der WCAG 2.0.
Nachdem die Tester jedoch bereits zugeben mussten, dass Ihre Behauptung der Unbenutzbarkeit der Blätterfunktion mit assistiven Hilfsmitteln nicht haltbar sei, bleibt man dennoch bei der Abwertung in voller Höhe. Wie es überhaupt zu diesem harten und offensichtlich falschen Testergebnis kam, bleibt bisher ebenfalls unbeantwortet.
Nach dieser Rolle rückwärts dient als Begründung jedoch plötzlich nicht mehr die per Test nachgewiesene Unzugänglichkeit, sondern ein Verweis auf das Fehlerkriterium F89 der WCAG 2.0. Darin steht jedoch explizit, dass sich hieraus Barriere entstehen "kann", nicht muss und das potentielle Problem per Test zu überprüfen ist, Zitat: "Check whether the non-text content has been implemented in a way that it can be ignored by assistive technology.". Das bei F89 angegebene Codebeispiel unterscheidet sich jedoch von der hier verwendeten Lösung genau um das im Beispiel fehlende title-Attribut, was sich offensichtlich entscheidend auf den Test auswirkt (was auch hier in den Kommentaren mehrfach angeführt wurde). Eine pauschale Abwertung erscheint mir daher allein aufrund vermuteter Probleme mit "irgendeiner" Technologie (Zitat: "Ob das aber auch für andere Hilfsmittel gilt, ist zweifelhaft.") eher willkürlich. Zweifel mögen an vielen Stellen im Leben angebracht, hier geht es aber um einen für Webentwickler nachvollziehbaren Test ihrer Arbeit.
Natürlich können die Tester hier nicht JEDE erdenkliche Kombination testen. Wenn aber die öffentlich kommunizierte Begründung für die Abwertung bereits widerlegt werden musste, Zitat: "Unsere Aussage, dass blinde Benutzer nur die erste von 20 Seiten wahrnehmen können, ist in der Form nicht haltbar." und gleichzeitig das theoretische Fehlerszenario ebenfalls nicht zweifelsfrei erfüllt ist (signifikante Unterschiede im Code), wie kann dann ein solches Testergebnis zu einer Abwertung in gleicher Höhe führen wie eine handfest Barriere einer unzugänglichen Blätterfunktion? Wie kann es überhaupt zu einer Abwertung führen, wenn es keinen Beleg für die Fehlfunktion gibt?
- Sowohl hinsichtlich der Kontraste als auch bei der Zugänglichkeit der Blätterfunktion musste das Ergebnis des Tests bereits revidiert werden. Im eigentlichen Beitragstext stehen diese Dinge unter "K(l)eine Probleme?" jedoch weiterhin. Wird dieser, für normale Besucher dieser Webseite wichtigste Text denn nicht korrigiert?
Mi. 15.12.2010
09:01 Uhr
„Unsere Empfehlung war ja nicht, fieldset mit leerem legend-Element einzusetzen,“
Und genau das wird man aber in manchen Fällen als Webentwickler machen müssen. Kleiner Tipp am Rande: Legend ist in HTML4 - im Gegensatz zu XHTML - ein zwingend vorgeschriebenes direktes Kind-Element von Fieldset. Beides, XHTML1 & HTML4, ist nach wie vor gebräuchlich, Ihr wertet die Verwendung von Legend ab und verlangt statt dessen Hn, der Validator hingegen verlangt nach einem Legend. Toll, ne?
Um beides unter einen Hut zu kriegen könnte man also Hn und Legend verwenden und die Legend zur Vermeidung eines Dopplers leer lassen. Dann wiederum geht JAWS hin und behandelt die H wie eine Legend und ordnet sie den im Fieldset enthaltenen Controls zu. Könnt Ihr mir so weit folgen? Falls ja: was macht es dann noch für einen Unterschied ob ich Legend oder Hn benutze? Darum geht es mir doch - dann kann ich doch gleich das semantisch naheliegendere (weil für exakt diesen Einsatzzweck spezifizierte) Element nehmen.
Und jetzt kommt mir nicht mit der Überschriftenliste in JAWS. Die ist für strukturierte Web-Dokumente vom Typ Mengentext, nicht für Formulare oder ähnliche Dinge die man in ARIA mit role=form oder sogar role=application auszeichnen würde.
Oder etwas platter ausgedrückt: ein JAWS-Nutzer, der auf der Suche nach dem Suchformular einer Seite JAWS-Taste + H statt JAWS-Taste + F drückt, der sollte nochmal das Handbuch zu Rate ziehen. Ganz ehrlich. Was Ihr da verlangt ist, die falsche Anwendung einer Software zu belohnen, bei gleichzeitiger Abstrafung aller Nutzer die diese Software richtig anwenden.
„Ich schlage vor, es damit gut sein zu lassen.“
Ihr erinnert immer mehr an ein bockiges Kind dass mit den Füßen auf den Boden stampft und sagt „Ich will das aber so, egal ob es dafür einen Grund gibt oder nicht. Ich will will will.“
Deswegen: Nö.
Nochmal zum Einsatz von fieldset: Unsere Empfehlung war ja nicht, fieldset mit leerem legend-Element einzusetzen, deshalb greift das Argument des Fallbacks auf ein h-Element nicht.
Ich hoffe, dass an dieser zeitraubenden Auseinandersetzung deutlich wird, dass wir den Test gewissenhaft anwenden - auch wenn dabei sicher manchmal Fehler passieren. Ein Ratespiel ist es deshalb nicht. Sie können das gerne weiter glauben. Ich schlage vor, es damit gut sein zu lassen.
Di. 14.12.2010
20:07 Uhr
"Bis auf den NVDA wiederholen alle mir bekannten Screen Reader den Titel/die Legend des Fieldsets bei jedem der Elemente."
Richtig. Und was macht JAWS, wenn keine Legende vorhanden ist oder diese leer ist?
Kleiner Tipp: JAWS fängt dann an zu raten und nimmt einfach den Inhalt der nächsten erreichbaren H vor dem Fieldset und nimmt diesen als Legend-Ersatz. Mit. exakt. dem. gleichen. Ergebnis.
(ist übrigens auch irgendwo bei EfA nachzulesen)
Sorry, aber ich muss leider bei meinem Fazit bleiben, dass dies hier offensichtlich eher ein Ratespiel als ein fundierter Test ist.
Di. 14.12.2010
19:46 Uhr
Interessanter Prüfbericht – aufschlussreiche Kommentare. Nach einem Blick auf die Seiten und den Prüfbericht kann ich am wenigsten die Bewertung zu
2.2.1. Grafiken vor wechselndem Hintergrund erkennbar
nachvollziehen. In der Prüfanleitung steht unter
"Anwendbarkeit des Prüfschritts:"
"Der Prüfschritt ist anwendbar, wenn wichtige Inhalte oder Funktionen nur über informative Grafiken verfügbar sind."
Soweit ich das sehe stehen bei Seite 3 die Funktionen jedoch vollständig und gleichwertig auch ohne die grafischen Bedienelemente zur Verfügung. Es scheint keinen Unterschied zu geben, ob ich nun den Link zum Auf- und Zuklappen verwende oder das Bedienelement. Aus meiner Sicht ist deswegen der Prüfschritt im Sinne der Prüfanleitung nicht anwendbar.
Zu unser angeblich abstrusen Forderung, die Überschrift des Suchformulars als Überschrift und nicht als legend des fieldsets bereitzuhalten: Das Element 'legend' soll laut UAAG 1.0 vor jedem Formularelement des fieldsets vorgelesen werden. Bevor jetzt die Frage kommt, welche Screenreader das denn wie umsetzen, hier ein Zitat von Marco Zehe, Dez 2009: "Bis auf den NVDA wiederholen alle mir bekannten Screen Reader den Titel/die Legend des Fieldsets bei jedem der Elemente."
Der Inhalt von 'legend' auf der Startseite der Jobbörse, "Finden Sie eine passende Stelle", ist für diese Art der Sprachausgabe ungeeignet und sogar störend. Stattdessen ist eine Überschrift für das Formular sinnvoll, da universeller nutzbar. Screenreader können diesen wichtigen Abschitt dann über die Überschriftennavigation leichter erreichen.
Wenn also 'legend' hier (wenn überhaupt) sinnvoll eingesetzt würde, käme es nicht zu einer Redundanz. Notfalls vielleicht noch mal bei "einfach-für-alle" nachlesen, wie's gemacht wird - besonders die Abschnitte "Zu viel des Guten: Überlange oder unnötige Legenden" und "Sind Überschriften nicht manchmal besser?"
Zu den anderen beiden Punkten haben wir uns bereits erschöpfend geäußert.
Di. 14.12.2010
12:26 Uhr
„[…] ist die Behauptung, dass hier Fehler aufgedeckt wurden, unser Auffasssung nach nicht stichhaltig“
Und was ist dann mit:
- der zulässigen, aber hier kritisierten Verwendung von Legend zur Beschriftung von Fieldsets, verbunden mit der abstrusen Forderung, diese Informationen mit redundanten Überschriften zu doppeln? Müsste das dann nicht eigentlich Abzüge wegen Redundanz geben?
- der Forderung, dass Textfragmente mit P ausgezeichnet werden müssen, die noch nicht mal ein vollständiger Satz, geschweige denn ein kompletter Absatz sind?
- dem nach wie vor fehlenden Nachweis, dass die Blätter-Funktion in *irgendeinem* User Agent zu Problemen führt (Nein, auch wenn ich in z.B. JAWS die Ausgabe von title in den Verbosity-Settings unterdrücke, so liest der die title trotzdem vor. Ähnlich wie bei input mit title und ohne label - auch dort werden die title vorgelesen, selbst wenn dies per Einstellung abgeschaltet wurde).
- usw. etc. pp.
Sorry, aber was Ihr hier macht ist Raten und nicht Testen …
Abschließende Tests werden nach wie vor von zwei Prüfern im Tandemtest durchgeführt. Die fehlerhafte Kontrastmessung ist den Prüfern in der Abstimmung nicht aufgefallen.
Wenn gravierende Fehler gemacht worden wären, würden wir den Test vielleicht wiederholen. Das ist aber nicht der Fall.
Es gibt offenbar unterschiedliche Auffassungen zum Stellenwert von Webstandards. Wir sind der Auffassung, dass die Nutzbarkeit mit Screenreadern zwar wichtig ist, die Einhaltung von Standards für Barrierefreiheit aber nicht überflüssig macht. Diese Auseinandersetzung betrifft allerdings das Prüfverfahren und nicht die einzelne Prüfung der Jobbörse der Arbeitsagentur.
Abgesehen von der fehlerhaften Kontrastprüfung, die sich in einen Abzug von 0,5 Punkten niedergeschlagen hat, ist die Behauptung, dass hier Fehler aufgedeckt wurden, unser Auffasssung nach nicht stichhaltig: Die Bewertungen sind vom Prüfverfahren gedeckt (siehe Thomas Mayers Kommentar vom 13. 12.).
Di. 14.12.2010
08:14 Uhr
„Hier war unsere Bewertung falsch, das geben wir hiermit zu Protokoll. Da haben sich die Prüfer vermessen und dieser Fehler ist der Qualitätssicherung leider durch die Maschen geschlüpft.“
Die Prüfer? Im Testbericht steht nur ein Prüfer. Wer hat denn da noch alles getestet? Früher gab es doch bei BIK immer einen Gegentest zum Test nach dem 4-Augen-Prinzip (was ja grds. eine gute Idee ist) - wird das nicht mehr so gehandhabt?
Andere Frage: Ist denn eigentlich geplant, die Bewertung zu korrigieren, nachdem hier so viele Fehler im Test selbst aufgedeckt wurden?
Wg. der redundanten Grafik: Das betrifft die dritte geprüfte Seite (Stellenangebot). In der rechten Spalte gibt es unter der h3 "Übereinstimmung" die Dopplung Text + Alternativtext.
Mo. 13.12.2010
15:02 Uhr
„Unsere Aussage, dass blinde Benutzer nur die erste von 20 Seiten wahrnehmen können, ist in der Form nicht haltbar. Wir haben den Text geändert, bleiben aber bei der Bewertung“
Das ist jetzt ein Witz, oder?
Sagt bitte, dass das ein Witz ist und das hier irgendwo eine versteckte Kamera ist.
„Uns ist natürlich bewusst, dass es sich bei den Inhalten der Stellenbeschreibungen um externe Inhalte handelt […] Siehe dazu die Anforderungen hinsichtlich semantischer Auszeichnungen in der BITV.“
Moment, für wen gilt die BITV nochmal? Sind private Unternehmen, die dort Jobs einstellen, neuerdings allesamt „Träger öffentlicher Gewalt des Bundes“?
„Wir werten diese Grafik als Layoutgrafik, weil sie redundant ist. Direkt vor der Grafik steht der gleiche Inhalt bereits als Text.“
Auf welcher der drei getesteten Seiten (URLs aus dem Prüfbericht) ist diese angebliche Redundanz? Sorry, ich kann da auch nach intensiver Suche nichts finden. Bitte mal den URL posten, danke.
Vielen Dank für Ihre Kommentare. Im folgenden möchte ich unsere Bewertungen erläutern:
a) Einheitliche Bewertungen (Dokumenttitel bei einfach-teilhaben.de und der Arbeitsagentur):
Der Dokumenttitel "Flugzeug" für eine Seite mit redaktionellen Inhalten ist im Kontext von "Einfach teilhaben" sehr viel spezifischer als der (für eine Jobbörse völlig unspezifische) Titel "Stellenangebot".
---
b) Layoutgrafiken? (Grafik: "Maximale Übereinstimmung", auf den Stellenangebotsseiten in der rechten Spalte).
Wir werten diese Grafik als Layoutgrafik, weil sie redundant ist. Direkt vor der Grafik steht der gleiche Inhalt bereits als Text. Bei der Ausgabe im Screenreader kommt es so zu einer Dopplung. Das ist unschön, aber keine wirkliche Barriere. Der Grund für den Punktabzug ist der nichtssagende Alternativtext "Firmenlogo" (ebenfalls in der rechten Spalte).
---
c) Auszeichnung von HTML-Listen
Uns ist natürlich bewusst, dass es sich bei den Inhalten der Stellenbeschreibungen um externe Inhalte handelt und die Arbeitsagentur hier relativ wenig Einflussmöglichkeiten hat. Gleichwohl halten wir einen leichten Punktabzug (hier "eher erfüllt") für gerechtfertigt. Siehe dazu die Anforderungen hinsichtlich semantischer Auszeichnungen in der BITV.
---
d) Helligkeitskontraste
Hier war unsere Bewertung falsch, das geben wir hiermit zu Protokoll. Da haben sich die Prüfer vermessen und dieser Fehler ist der Qualitätssicherung leider durch die Maschen geschlüpft.
---
e) Textgliederung im Kopfbereich
Hier ging es um die Zeile "X Bewerberprofile Y Stellen..." Was wir hier kritisieren, ist das Fehlen sämtlicher Formatierungen inkl. der Leerzeichen. Also:
"3.550.828Bewerberprofile 616.710Stellen 207.173Ausbildungsstellen Stand:13.12.2010
Zum Anmelden Meine JOBBÖRSE Anmelden Noch nicht bei der JOBBÖRSE registriert? Jetzt registrieren"
Wesentlich besser nutzbar wären diese Inhalte (etwa in der Ansicht ohne CSS), wenn das z.B. so gegliedert wäre
"- 3.550.828 Bewerberprofile
- 616.710 Stellen
- 207.173 Ausbildungsstellen
Stand: 13.12.2010
Zum Anmelden
Meine JOBBÖRSE
Anmelden
Noch nicht bei der JOBBÖRSE registriert?
Jetzt registrieren"
---
f) Grafiken vor wechselndem Hintergrund erkennbar
Wir testen hier nicht im Windows Kontrast-Modus, sondern ändern in den Browsereinstellungen die Hintergrundfarbe.
Bei einer dunklen Hintergrundfarbe sind die Grafiken zwar sehr klein aber noch halbwegs erkennbar (weißes Plus- bzw. Minus-Zeichen). Bei einer hellen Hintergrundfarbe sind die Grafiken schlecht bzw. gar nicht mehr erkennbar.
---
g) alt- bzw. title-Attribute für verlinkte Grafiken
Unsere Aussage, dass blinde Benutzer nur die erste von 20 Seiten wahrnehmen können, ist in der Form nicht haltbar. Wir haben den Text geändert, bleiben aber bei der Bewertung (siehe unten die Verweise auf die WCAG2).
---
h) Überschriften (Startseite, Suchformular).
Bei der Bewertung dieses Prüfschritts war die kritisierte fehlende Überschrift für das Suchformular nicht ausschlaggebend. Das ist eher als Vorschlag zu verstehen, denn wenn das Formular eine Überschrift hätte, könnte diese als Navigations- bzw. Orientierungshilfe genutzt werden.
Mo. 13.12.2010
11:50 Uhr
Ihr schreibt:
„Der zentrale Inhalt dieser Seite, das Formular für die Jobsuche, sollte eine eigene Überschrift erhalten. In der nicht visuellen Ansicht fällt das Formular kaum auf. “
Auch hier steht der Befund im Widerspruch zum eigenen Prüfverfahren. In der Prüfanleitung zu 12.3.1 (http://testen.bitvtest.de/index.php?a=di&iid=1082) steht: „Absätze, Gruppen von Formularelementen und tabellarische Daten sind mit geeigneten Strukturelementen ausgezeichnet.“ - LEGEND ist die in HTML4 vorgesehene Beschriftung von FIELDSET („Gruppen von Formularelementen“): „The LEGEND element allows authors to assign a caption to a FIELDSET.“ (http://www.w3.org/TR/html401/interact/forms.html#edef-LEGEND). Warum wird hier also eine redundante Information eingefordert?
So. 12.12.2010
16:41 Uhr
Nochwas zum Punktabzug durch
„Prüfschritt 2.2.1 - Grafiken vor wechselndem Hintergrund erkennbar
Seite 3: teilweise erfüllt
Die Schaltflächen zum ein- und ausklappen der Inhalte haben einen transparenten Hintergrund und sind somit bei benutzerdefinierter Hintergrundfarbe evtl. schwer erkennbar. […]
Punktabzug: 0,25 Punkte“
Mal abgesehen davon, dass „evtl. schwer erkennbar“ eine eher grenzwertige Formulierung für einen Prüfbericht ist: unter welchem Szenario machen die Icons denn Probleme? Üblicherweise wird hier bei diesem Prüfschritt doch sicher mit einem der Windows-Kontrastmodi getestet, weil die z.B. bei Sehbehinderten häufig verwendet werden und regelmäßig zu Problemen führen. Im Windows-Kontrastmodus habe ich jedoch keinerlei Probleme, die Plus- und Minus-Icons zu erkennen. Welches Szenario hat denn hier zu der geannten Abwertung geführt?
So. 12.12.2010
16:00 Uhr
Aus dem Prüfbericht:
„Die Textgliederung ist im Kopfbereich nicht ausreichend. Das betrifft den Text ab "3.545.239 Bewerberprofile ..." Hier fehlen Leerzeichen und Texthervorhebungen.“
Frage: Wie würdet Ihr die Texthervorhebungen machen? (Gesetzt den Fall, dass es dort überhaupt eine geben müsste, was ich in Frage stelle). Besser mit STRONG oder EM?
Dann hätte ich da mal eine Frage: was machen verbreitete Screenreader, wenn sie auf ein STRONG oder EM treffen? Lesen die den Text dann irgendwie anders vor? Vielleicht besonders betont, oder ewas lauter?
Ich nehme an Ihr wisst die Antwort, oder?
(Kleiner Tipp: Screenreader ignorieren diese Auszeichnung - was für einen Vorteil im Sinne der Barrierefreiheit für Nutzer solcher Hilfsmittel hätte dann eine anders geartete Auszeichnung?)
Auch dieser Befund:
„Textabsätze sind nicht vollständig mit p ausgezeichnet.“
ist leider Unfug. Die Bedeutung von P wird in HTML4 definiert, dort steht unter 9.3 Lines and Paragraphs:
„Authors traditionally divide their thoughts and arguments into sequences of paragraphs.“
Damit dürfte klar sein, dass Paragraphs P für Fließtexte sind, um dort Gedankenabschnitte zu unterteilen. Die kritisierte Stelle ist aber kein Fließtext (es ist noch nicht mal ein vollständiger Satz!), daher wäre hier ein P sogar nach den Regeln falsch und ein DIV ist somit vollkommen akzeptabel.
So. 12.12.2010
14:47 Uhr
Noch ein Schmankerl aus dem Prüfbericht:
„Prüfschritt 3.6.1 - HTML-Strukturelemente für Listen
Seite 3: eher erfüllt
Wenn vorhanden sind Aufzählungen unter "Stellenbeschreibung" sind [sic!] nicht als HTML-Liste ausgezeichnet. […]
Punktabzug: 0,5 Punkte“
Ohne jetzt die Hintergründe oder Arbeitsabläufe bei der Jobbörse zu kennen, aber das sieht für mich so aus, als könnten Arbeitgeber und private Vermittler dort selber Inhalte einstellen. Zumindest weist der Text des Haftungsausschluß (s. Link in der Marginalspalte rechts) darauf hin, dass es sich hierbei nicht um originäre Inhalte der Arbeitsagentur handelt.
Frage: wie ernsthaft schätzt Ihr die Chancen ein, dass man allen Unternehmen, die dort Jobs veröffentlichen können (alleine der Bundesverband Zeitarbeit hat lt. eigener Aussage über 2.000 Mitgliedsbetriebe, vgl. http://www.bza.de/45.html) folgendes vermitteln kann – auf dass sie es nie nie nie wieder wagen, eine Auflistung als:
1. Sachbearbeiter
2. Kundenbetreuer
direkt ins HTML zu schreiben, statt dafür das in HTML vorgesehene Element OL zu benutzen?
Wie hoch schätzt Ihr die Kosten ein, um sämtlichen Arbeitgebern in Deutschland (und das sind wohl ein paar Millionen) Folgendes beizubringen:
1. Es gibt sowas wie HTML.
2. HTML hat Strukturelemente.
2a. Was sind Strukturelemente?
3. Welche Strukturelemente darf ich für Auflistungen verwenden und welche nicht?
4. Wie funktioniert das in sämtlichen Editoren, die von Millionen Unternehmen zur Erstellung von Inhalten verwendet werden; welchen Knopf muss man da drücken?
Wenn Ihr die Fragen beantwortet habt, dann hätte ich noch eine zum Abschluß:
- Wo entsteht durch den kritisierten Code des Stellenangebots eine Barriere für Menschen mit Behinderung und wie äussert sich diese bzw. welche Folgen hat sie?
So. 12.12.2010
14:24 Uhr
Nochwas zum Thema „Einheitliche Bewertungen“:
Beim Test der Jobbörse schreibt Ihr:
„Seite 3: eher erfüllt
Statt "Stellenangebot" sollte hier im Dokumenttitel die Bezeichnung des Stellenangebots stehen.
Punktabzug: 0,5 Punkte“
Beim Test von einfach-teilhaben.de steht:
„Seite 3: erfüllt
Der Begriff "Flugzeug" im Seitentitel ist nicht sehr aussagekräftig, "Reisen mit dem Flugzeug" wäre besser.“
Warum bekommt der eine einen halben Punkt abgezogen, der andere für exakt den gleichen Fehler nicht?
So. 12.12.2010
14:11 Uhr
Aus dem Prüfbericht:
„Die Grafiken für "Maximale Übereinstimmung" und "Erweiterte Kenntnisse" werden hier nur als Layoutgrafiken eingesetzt, deshalb sollten die Alternativtexte-Texte leer sein.“
Mal abgesehen davon dass es auf der im Prüfbericht verlinkten „Seite 3“ gar keine Grafik für „Maximale Übereinstimmung“ gibt (diese gibt es allerdings in der tabellarischen ansicht der Suchergebnisse), so hat diese Grafik dort wo sie verwendet wird durchaus eine wichtige Funktion und ist mitnichten eine, wie der Tester fälschlicherweise bemerkt, „Layoutgrafik“. Es gibt nämlich eine ganze Reihe Ausprägungen dieser Grafik, alle mit einer unterschiedlichen Anzahl verschiedenfarbig eingefärbter Balken, je nach Höhe der Übereinstimmung mit dem Suchbegriff.
Diese haben natürlich dann auch die passenden Alternativtexte (z.B. "Sehr hohe Übereinstimmung" für 4 von 5 Balken oder "Hohe Übereinstimmung" für 3 von 5 Balken usw.).
Wie man da als Tester zu dem Schluß kommen kann, dass eine solch wichtige Information für blinde Nutzer uninteressant sei und man deswegen die Grafik mit einem leeren alt verstecken soll ist mir schleierhaft. Ebenso warum man dann für diesen Fehlschluß 0,75 Punkte abzieht.
So. 12.12.2010
13:52 Uhr
Nochwas zum Thema Kontraste: im Prüfbericht werden die angeblich unzureichenden Kontraste in den Buttons bemängelt. Auf die genannten Kontrastverhältnisse komme ich aber nur, wenn ich die Hintergrundfarbe an Stellen messe, auf denen gar kein Text mehr steht (relativ weit unten im Button) oder allerhöchstens am alleralleruntersten Zipfel der Unterlängen der Buchstaben.
Wenn ich einen vernünftigen Mittelwert des Buttons nehme (z.B. an der Schriftline), dann scheint die Vordergrundfarbe #2E657A mit ca. 4.5:1 exakt innerhalb des Erlaubten zu liegen.
Dazu kommt, dass Ihr auch in diesem Punkt eurem eigenen Testverfahren widersprecht:
„… die Hervorhebung des Maus- oder Tastaturfokus. Hier soll zunächst geprüft werden, in welchem Zustand (im Fokus/nicht im Fokus) der Helligkeitskontrast besser ist. Dieser in Hinblick auf den Helligkeitskontrast bessere Zustand muss den allgemeinen Grenzwert von 4,5:1 erfüllen. Das Kontrastverhältnis des zweiten Zustandes muss über 3:1 liegen.“
Quelle: http://testen.bitvtest.de/index.php?a=di&iid=1137
Da die Buttons bei :hover UND :focus in der Vordergrundfarbe auf schwarz wechselt, ist dieser Punkt sogar übererfüllt (laut http://juicystudio.com/services/luminositycontrastratio.php#specify sogar 11,62:1 !). Gerade vor dem Hintergrund der *eigenen* Prüfanleitung ist es vollkommen unverständlich, warum es hier zu einem Punktabzug kommt.
Do. 09.12.2010
19:42 Uhr
>Praktisch ist es wohl so, dass die Screenreader
>JAWS und NVDA damit umgehen können. Ob das
>aber auch für andere Hilfsmittel gilt, ist zweifelhaft.
VoiceOver mit Safari unter MacOS X hat mit der Konstruktion bei der Arbeitsagentur auch keine Probleme und liest die Paginierung vor. Damit hätten wir dann schon, wenn ich die Kommentare hier nochmal durchgehe, fünf Browser-/Screenreader-Kombinationen (NVDA/Firefox, NVDA/IE, JAWS/Firefox, JAWS/IE, VoiceOver/Safari), in denen der kritisierte Code kein Problem darstellt und keine Barrieren aufwirft.
Ihr hingegen habt bisher noch keine Kombination nennen können, in der es zu den im Test behaupteten Problemen kommt, bleibt aber trotzdem bei der Behauptung, dass das schon ganz sicher irgendwo mal nicht funktionieren wird.
Daher hier nochmal die konkrete Frage:
In welchem Screenreader ist mit welchem Browser die Paginierung für blinde Nutzer unzugänglich? (Steht ja schließlich so im Artikel zum Test - irgendwie muss man also zu der Aussage gekommen sein).
Zwei unterschiedliche Aspekte sprechen für unsere Bewertung (abgewertet wurde ja nicht, nur ein Prüfschritt (1.1.1) für eine der drei untersuchten Seiten haben wir als "nicht erfüllt" bewertet. Das Gesamtergebnis lautet: gut zugänglich):
title ist laut Standard (HTML 4.01) für zusätzliche Informationen gedacht: "The title attribute may be set for both A and LINK to add information about the nature of a link". Die tragenden Informationen gehören in den Link-Inhalt - da dieser hier ausschließlich ein Bild ist, also in dessen Alternativtext. Die WCAG 2.0 Technique "H33: Supplementing link text with the title attribute" bestätigt diese Sicht und rät: "Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique C7: Using CSS to hide a portion of the link text (CSS)" Dazu passt "F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to using null alt on an image where the image is the only content in a link" ("Different assistive technologies employ different repair strategies when dealing with links that lack text alternatives ...).
Soweit die Theorie. Praktisch ist es wohl so, dass die Screenreader JAWS und NVDA damit umgehen können. Ob das aber auch für andere Hilfsmittel gilt, ist zweifelhaft. Dass in einem Test mit sämtlichen Hilfsmitteln zu verifizieren ist nicht praktikabel und aus unserer Sicht auch nicht notwendig, denn die Richtlinien und Standards sind ja in diesem Fall eindeutig: diese Art der Umsetzung ist problematisch. Es wird immer Fälle geben, in denen bestimmte Hilfsmittel mit bestimmten Problemen besser umgehen können. Wenn wir das alles berücksichtigen sollten, wäre eine objektive Bewertung schwierig. Das Testergebniss soll eine Aussage zur Zugänglichkeit machen und nicht zur Nutzbarkeit mit JAWS.
PS:
Zu der Bemerkung, dass es in der Praxis für Tastaturnutzer - ohne Hilfsmittel - keinen Unterschied macht, Informationen via alt oder title zu vermitteln: Das ist sicher richtig. Diese Gruppe hat aber meist noch Sehvermögen und benötigt in diesem speziellen Fall weder alt noch title. Die Grafik (Pfeil-Icon) ist in der visuellen Ansicht selbsterklärend.
Mi. 08.12.2010
22:07 Uhr
>Eventuell vorhandene Reparatur-Strategien von
>Hilfsmitteln sind natürlich zu begrüßen.
Das ist keine Reparatur-Strategie von Hilfsmitteln, sondern ein ganz normaler Vorgang der Erkundung eines Dokumenten-Baums - also dass was die WCAG2 mit „programmatically determinable“ meint.
>Wir sind uns aber hoffentlich einig, dass fehlende
>oder leere Alternativtexte für verlinkte Grafiken
>ein elementares Problem darstellen.
Nein, sind wir nicht. Es geht hier nicht um die Alternative für eine Grafik, sondern um die Beschreibung einer Funktion. Diese Funktion liegt am A, nicht am IMG. Es ist das Auslösen des Links, dass (um beim konkreten Fall zu bleiben) die Blätter-Funktion verursacht, nicht die Wahrnehmung (oder Nicht-Wahrnehmung eines Icons).
Nehmen wir den (hypothetischen) Fall, dass der Link (A) entfällt, das Icon (IMG) aber bestehen bleibt. Wie sinnvoll ist es dann, dass dem Icon in der Datenbank des Backends der Alternativtext alt="zur nächsten Seite blättern" anhaftet?
Daher ist es nur sinnvoll, die Funktionsbeschreibung dem Element anzuheften, dem die Funktion gehört und das ist nunmal der Link (A href="").
Und dies in einer Art und Weise, die von gängigen Hilfsmitteln unterstützt wird (s. andere Kommentare) und damit den entspricht was die WCAG2 mit meint.
Aus der offiziellen Übersetzung bei http://www.w3.org/Translations/WCAG20-de/:
„Bestimmt von Software durch vom Autor gelieferte Daten, bereitgestellt auf eine Art und Weise, dass verschiedene Benutzeragenten, einschließlich assistierender Techniken, diese Informationen entnehmen und dem Benutzer in verschiedenen Modalitäten präsentieren können.
Beispiel 1: Bestimmt in einer Markup-Sprache aus Elementen und Attributen, auf die direkt durch allgemein erhältliche assistierende Techniken zugegriffen wird.“
Alles andere wäre übrigens auch ein Verstoß gegen weitere Techniken der WCAG wie z.B. „G140: Die Trennung von Informationen und Struktur von der Darstellung, um verschiedene Darstellungen zu ermöglichen“ - wenn ich die Info über die Funktion an eine bestimmte Darstellungsform binde (hier: ein Icon), dann nehme ich mir die Möglichkeit, andere Darstellungsformen zu ermöglichen (irgendein anderes Objekt, dass kein Icon ist, aber das in der jeweiligen Modalität eine Blätterfunktion transportiert).
In der deutsche Übersetzung der WCAG-Techniques steht:
„Das Ziel dieser Technik ist es, die Interaktion von assistierenden Techniken mit dem Inhalt zu erleichtern, indem die strukturelle Kodierung des Inhalts logisch von der Präsentationskodierung getrennt wird.“
>Und das haben wir hier bewertet.
Nein, genau das eben nicht.
Und zudem auch nicht in Übereinstimmung mit der Fortentwicklung des eigenen Prüfverfahrens. Im BIK-Newsletter vom 08.12. steht:
„Als Nachtrag zur letzten Überarbeitung des BITV-Tests im
Herbst 2009 wurde auch der Prüfschritt 13.1.1 "Aussagekräftige
Linktexte" an die Anforderungen der WCAG 2.0 angeglichen.
Die Aussagekraft eines Links kann nun auch über den
"programmatisch bestimmbaren Kontext" sichergestellt werden.“
Da scheint es schon etwas merkwürdig, wenn zeitgleich eine Site abgewertet wird, die genau diese in den WCAG beschriebenen Techniken nutzt, und das auf eine Art und Weise die generell nutzbar ist.
Halten wir also mal einen Zwischenstand fest:
- Das was die Arbeitsagentur da gemacht hat funktioniert mit allen getesteten Hilfsmitteln.
- Es entspricht den WCAG 2.0
- Es macht in der Praxis keinen Unterschied, ob man die Information via alt oder via title vermittelt, denn auf alt haben Tastaturnutzer ohne Hilfsmittel genauso wenig Zugriff wie auf title
- Das Szenario „Bilder aus“ lässt sich auch nicht heranziehen, weil die Unterstützung in den verschiedenen Browsern zu wünschen übrig lässt (s. http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/screenshots.html) und der Alternativtext „Zur nächsten Seite blättern“ in keinem Browser in den Platzhalter für ein nicht geladenes 12x12px großes Icon passt.
Und schlußendlich, und darum geht es doch beim BITV-Test
- Es entstehen keine Barrieren.
So weit so richtig?
Eventuell vorhandene Reparatur-Strategien von Hilfsmitteln sind natürlich zu begrüßen. Wir sind uns aber hoffentlich einig, dass fehlende oder leere Alternativtexte für verlinkte Grafiken ein elementares Problem darstellen. Und das haben wir hier bewertet.
Zum title-Attribut sagt die HTML-Spezifikation: "This attribute offers advisory information..." Davon kann hier aber nicht die Rede sein, denn die Info über die Funktion der Grafik wird alleine über den title vermittelt.
Mi. 08.12.2010
16:48 Uhr
>NVDA ist offenbar so schlau, bei einem leeren
>Alternativtext den Inhalt des title-Attributs auszugeben.
Nicht nur NVDA – JAWS verhält sich genau so. Wenn das alt des IMG leer ist, schaut JAWS, ob das IMG einen title hat. Falls ja, dann wird dieser vorgelesen. Falls nein, dann schaut JAWS, ob das umgebende A einen title hat und liest diesen vor.
Da die Aktion durch das A definiert wird (href = Hypertext Reference!), ist die Erklärung der Funktion dort richtig aufgehoben und nicht am enthaltenen Icon.
die Grafiken (z.B. paginierung_rechts_aktiv.gif) haben leere Alternativtexte, es ist aber ein title-Attribut vorhanden ("zu Seite 2 blättern"). NVDA ist offenbar so schlau, bei einem leeren Alternativtext den Inhalt des title-Attributs auszugeben. Das funktioniert bei anderen Screenreadern nicht unbedingt. Zudem wird die Ausgabe von title-Attributen von vielen Screenreader-Nutzern bewusst unterdrückt da diese Inhalte oft redundant sind.
Warum es gerade hier eine Abwertung gegeben hat, ist für mich absolut nicht nachvollziehbar. Es macht nämlich einen Unterschied, ob das title-attribut eines Links oder das eines Images ausgewertet wird. Mit JAWS 11 und Firefox 3.6 gibt es z. B. keinerlei Probleme, diese Paginierung zu bedienen. JAWS fällt, weil der Alt-Text leer ist, auf den Inhalt des Title-Attributes zurück und liest ganz brav "Zu Seite 2 blättern" vor, genau wie der NVDA dies tut.
In den HTML-Einstellungen von JAWS für HTML-Grafiken ist standardmäßig angegeben, dass alt, title, src in DIESER Reihenfolge ausgewertet werden sollen. Daher gibt es mit diesen Images keine Probleme, und das ist auch nicht erst seit JAWS 10 oder 11 so.
Die Behandlung des Title-Attributes bei Links wird an einer ganz anderen Stelle behandelt und ist hiervon völlig losgelöst.
Hallo,
die Grafiken (z.B. paginierung_rechts_aktiv.gif) haben leere Alternativtexte, es ist aber ein title-Attribut vorhanden ("zu Seite 2 blättern"). NVDA ist offenbar so schlau, bei einem leeren Alternativtext den Inhalt des title-Attributs auszugeben. Das funktioniert bei anderen Screenreadern nicht unbedingt. Zudem wird die Ausgabe von title-Attributen von vielen Screenreader-Nutzern bewusst unterdrückt da diese Inhalte oft redundant sind.
Das title-Attribut kann das alt-Attribut nicht ersetzen. Deshalb berücksichtigen wir das bei der Bewertung (von Textalternativen) nicht.
© 2012 DIAS GmbH | Impressum | Barrierefreiheit
bitvtest.de ist ein Webangebot des BIK-Projekts
