Webseiten Betreiber: Blinden- und Sehbehindertenverband Wien, Niederösterreich und Burgenland
Webseiten Domain: www.blindenverband-wnb.at
Zertifikat Status: Silber
Zertifizierungsdatum: 20.12.2021
Zertifizierung WACA
Die Initiative WACA strebt mit diesem Zertifikat ein sehr hohes Niveau und eine herausragende Qualität der Barrierefreiheit an, deshalb müssen für eine erfolgreiche Zertifizierung die grundlegendsten WCAG-Kriterien erfüllt werden. Die AuditorInnen prüfen nach einem vorgegebenen Schema und eigener Prüfmethodik streng nach diesen Kriterien. Das WACA-Zertifikat wird in 3 unterschiedlichen Stufen vergeben. Es wurde für jedes WCAG-Erfolgskriterium eine eigene Abstufung für Gold, Silber und Bronze definiert. Damit können auch Websites ausgezeichnet werden, die nicht die höchsten Anforderungen der WCAG erfüllen bzw. Best-Practice sind, aber eine grundlegende Barrierefreiheit aufweisen und niemanden bei der Benutzung der Website ausschließen. Bei den Abstufungen Silber oder Bronze müssen Bemühungen für Barrierefreiheit klar und eindeutig erkennbar sein, siehe Definition WACA Abstufungen.
WACA zertifiziert Websites, die genau eingegrenzt werden können, meist definiert durch eine URL und zieht daraus eine repräsentative Stichprobe (Testsample).
Folgende Inhalte bzw. Funktionen einer Website sind jedoch allgemein vom Audit ausgeschlossen:
- PDF
- EPUB
- live übertragene zeitbasierte Medien
- Inhalte, die nur für eine geschlossene Gruppe von Personen und nicht für die allgemeine Öffentlichkeit verfügbar sind (Extranets und Intranets).
- externe Inhalte von Drittanbietern, die vom Website-Betreiber weder finanziert noch entwickelt wurden und somit auch nicht dessen Kontrolle unterliegen (wie z.B.: Google Maps, Youtube, Facebook, externe Iframes und Widgets,...), Definition wie folgt:
- Drittanbieter Inhalte, mit denen man nicht interagieren kann (z.B. Facebook Trackingpixel), sind von der Prüfung ausgenommen.
- Drittanbieter Inhalte, die keine grundlegende, zentrale Funktionalität der Seite bereitstellen, sind von der Prüfung ausgenommen.
- Drittanbieter Inhalte, die zusätzliche Informationen bereitstellen und für die BenutzerInnen essentiell sind, benötigen eine Alternative.
- Wenn eine Website weitestgehend aus Drittanbieter Inhalten besteht, wird eine Zertifizierung abgelehnt und Auftrag nicht angenommen. Website ist in diesem Fall nicht auditierbar.
- Online-Karten und Kartendienste, diese müssen aber eine barrierefreie Alternative haben.
- Google Captcha (ReCaptcha V2): Verwendung gültig nur für die WACA Qualitätsstufen Silber und Bronze.
Allgemeiner Kommentar:
Die Website ist sehr gut zugänglich umgesetzt bzw. wurde nachträglich optimiert. Zum letzten Testzeitpunkt wurden nur minimale Abweichungen zur WCAG festgestellt. Es kann daher WACA in Silber vergeben werden.
Das Spendenformular auf T2 war nicht im Scope des Audits, da externes Tool (Drittanbieter).
Beim Zertifikat WACA sind ganz allgemein vom Audit ausgeschlossen folgende Inhalte bzw. Funktionen einer Website:
Websites mit nicht deutscher und/oder englischer Sprache
Apps für mobile Anwendungen
PDFs
EPUB
Flash
live übertragene zeitbasierte Medien
Inhalte, die nur für eine geschlossene Gruppe von Personen und nicht für die allgemeine Öffentlichkeit verfügbar sind (Extranets, Intranets)
externe Inhalte von Drittanbietern, die vom Betreiber der Website weder finanziert noch entwickelt wurden und somit auch nicht dessen Kontrolle unterliegen (wie z.B. Google Maps, Youtube, Facebook, andere Iframes und Widgets,...) wie folgt:
Drittanbieter Inhalte, mit denen man nicht interagieren kann (z.B. Facebook Trackingpixel), sind von der Überprüfung ausgenommen.
Drittanbieter Inhalte, die keine grundlegende, zentrale Funktionalität der Seite bereitstellen, sind von der Überprüfung ausgenommen.
Drittanbieter Inhalte, die zusätzliche Informationen bereitstellen und für die BenutzerInnen essentiell sind, benötigen eine Alternative.
Wenn eine Website weitestgehend aus Drittanbieter Inhalten besteht, wird Zertifizierung abgelehnt und Auftrag nicht angenommen. Website ist nicht auditierbar.
Online-Karten und Kartendienste, diese müssen aber eine barrierefreie Alternative haben
Google Captcha (ReCaptcha V2): gültig nur für Silber und Bronze
Geprüftes Testsample
Abweichungen zur WCAG und WACA-Einstufung
BSVWNB: T1 Startseite
Kriterium 2.4.4 - Linkzweck (im Kontext): Silber
- Nachaudit: Das Untenstehende wurde nur teilweise behoben. Das Prinzip der redundanten Informationen wurde noch nicht komplett umgesetzt, wie man das beim Back-to-Top Link (title ist hier redundant) oder bei den Artikeln sehen kann. Bei den Artikel wird derselbe Link zum selben Ziel zweimal ausgegeben (Bild und Mehr-Lesen-Link). Behoben werden kann man dies, indem man das Bild und den kompletten Artikel-Teaser in einem einzigen Link packt und bei mehr lesen einfach nur den Link als Element herausnimmt und stattdessen mit einem anderen Element (entweder span- oder p-Element) ersetzt und die visuelle Darstellung vom Link via CSS anpasst.
Der Icon-Link "Zum Spendenformular" (€) ist nur mit einem title-attribute versehen. Diese Technik soll bei Links vermieden werden. Die bessere Methode hier wäre, die Beschreibung innerhalb des Links in ein span packen und mit der class .sr-only visuell verstecken.
Hintergrund: Viele Screen Reader User schalten das Title-Attribut ab, weil auf vielen Websites oft nur redundante Informationen bereitgestellt werden. Bestes Beispiel hier auf dieser Seite ist der "Nach oben" -Button (Title-Attribut und Link-Text haben dieselbe Information).
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T2 Spenden
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience im somit gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T3 Suchergebnis
Kriterium 2.4.3 - Fokus-Reihenfolge: Silber
- Nachaudit: Untenstehendes wurde behoben.
Das Hauptmenü verfügt über kein Focus-Management (Focus-Trap), wenn es geöffnet ist (man kann über das Menü-hinaustabben)
Kriterium 2.4.4 - Linkzweck (im Kontext): Silber
- Nachaudit: Das Untenstehende wurde nur teilweise behoben. Das Prinzip der redundanten Informationen wurde noch nicht komplett umgesetzt, wie man das beim Back-to-Top Link (title ist hier redundant).
Der Icon-Link "Zum Spendenformular" (€) ist nur mit einem title-attribute versehen. Diese Technik soll bei Links vermieden werden. Die bessere Methode hier wäre, die Beschreibung innerhalb des Links in ein span packen und mit der class .sr-only visuell verstecken.
Hintergrund: Viele Screen Reader User schalten das Title-Attribut ab, weil auf vielen Websites oft nur redundante Informationen bereitgestellt werden. Bestes Beispiel hier auf dieser Seite ist der "Nach oben" -Button (Title-Attribut und Link-Text haben dieselbe Information).
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T4 Kontakt
Kriterium 1.3.5 - Zweck von Eingaben bestimmen: Silber
- Die Anrede im Formular verfügt über kein autocomplete="sex".
Kriterium 2.4.4 - Linkzweck (im Kontext): Silber
- Nachaudit: Das Untenstehende wurde nur teilweise behoben. Das Prinzip der redundanten Informationen wurde noch nicht komplett umgesetzt, wie man das beim Back-to-Top Link (title ist hier redundant).
Der Icon-Link "Zum Spendenformular" (€) ist nur mit einem title-attribute versehen. Diese Technik soll bei Links vermieden werden. Die bessere Methode hier wäre, die Beschreibung innerhalb des Links in ein span packen und mit der class .sr-only visuell verstecken.
Hintergrund: Viele Screen Reader User schalten das Title-Attribut ab, weil auf vielen Websites oft nur redundante Informationen bereitgestellt werden. Bestes Beispiel hier auf dieser Seite ist der "Nach oben" -Button (Title-Attribut und Link-Text haben dieselbe Information).
Kriterium 2.4.7 - Fokus sichtbar: Silber
- Die Such-Komponente besteht aus zwei "Buttons", während eines visuell versteckt ist und somit der Fokus nicht durchgehend sichtbar ist. Das ist an sich nicht notwendig. Wenn man alles in ein Button gibt und das Verhalten via JS korrekt anpasst (Anmerkung: Das Klick-Verhalten ist fehlerhaft, wenn man das Suchfeld via Klick auf den Button geöffnet hat und mit dem nächsten wider geschlossen hat, lässt sich mit dem nachfolgenden Klick das Suchfeld nicht mehr öffnen - nur wenn der Fokus außerhalb des Buttons befindet, geht es dann wieder).
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T5 Blog
Kriterium 2.4.3 - Fokus-Reihenfolge: Silber
- Das Hauptmenü verfügt über kein Focus-Management (Focus-Trap), wenn es geöffnet ist (man kann über das Menü-hinaustabben)
Kriterium 2.4.4 - Linkzweck (im Kontext): Silber
- Nachaudit: Das Untenstehende wurde nur teilweise behoben. Das Prinzip der redundanten Informationen wurde noch nicht komplett umgesetzt, wie man das beim Back-to-Top Link (title ist hier redundant) oder bei den Artikeln sehen kann. Bei den Artikel wird derselbe Link zum selben Ziel zweimal ausgegeben (Bild und Mehr-Lesen-Link). Behoben werden kann man dies, indem man das Bild und den kompletten Artikel-Teaser in einem einzigen Link packt und bei mehr lesen einfach nur den Link als Element herausnimmt und stattdessen mit einem anderen Element (entweder span- oder p-Element) ersetzt und die visuelle Darstellung vom Link via CSS anpasst.
Der Icon-Link "Zum Spendenformular" (€) ist nur mit einem title-attribute versehen. Diese Technik soll bei Links vermieden werden. Die bessere Methode hier wäre, die Beschreibung innerhalb des Links in ein span packen und mit der class .sr-only visuell verstecken.
Hintergrund: Viele Screen Reader User schalten das Title-Attribut ab, weil auf vielen Websites oft nur redundante Informationen bereitgestellt werden. Bestes Beispiel hier auf dieser Seite ist der "Nach oben" -Button (Title-Attribut und Link-Text haben dieselbe Information).
Kriterium 2.4.7 - Fokus sichtbar: Silber
- Die Such-Komponente besteht aus zwei "Buttons", während eines visuell versteckt ist und somit der Fokus nicht durchgehend sichtbar ist. Das ist an sich nicht notwendig. Wenn man alles in ein Button gibt und das Verhalten via JS korrekt anpasst (Anmerkung: Das Klick-Verhalten ist fehlerhaft, wenn man das Suchfeld via Klick auf den Button geöffnet hat und mit dem nächsten wider geschlossen hat, lässt sich mit dem nachfolgenden Klick das Suchfeld nicht mehr öffnen - nur wenn der Fokus außerhalb des Buttons befindet, geht es dann wieder).
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T6 Blog Beitrag
Kriterium 1.1.1 - Nicht-Text-Inhalt: Silber
- Nachaudit: Das Untenstehende zwar behoben, jedoch wurde noch festgestellt, dass wie bei der Blogübersichtsseite bei den Teasern am Ende des Artikels die Alternativtexte fehlen.
Es werden Icons via einem Icon-Font eingebettet, die nicht konsistent von assistiven Technologien versteckt werden (betrifft fast alle Icons):
"Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology."
Korrektes Bespiel auf der Seite:
<span class="i-menu-toggle" aria-hidden="true"></span>
Inkorrektes Bespiel aus der Startseite:
<span class="i-euro"></span>
Somit wird im ::before bzw. ::after der unverständliche Inhalt (content: '\e809';) vorgelesen, weil hier das aria-hidden="true" nicht gesetzt ist.
Kriterium 1.3.1 - Info und Beziehungen: Silber
- Die Überschrifthierarchie ist nicht linear (Reihenfolge: h2,h5, h1, h3, h3, h2, h5, h3, h5, h3, h5, h3, h4, h4).
Anmerkung: Rubriknamen sollte man mit dem p-Element statt einem Heading auszeichnen.
Kriterium 2.4.4 - Linkzweck (im Kontext): Silber
- Nachaudit: Das Untenstehende wurde nur teilweise behoben. Das Prinzip der redundanten Informationen wurde noch nicht komplett umgesetzt, wie man das beim Back-to-Top Link (title ist hier redundant) oder bei den Artikeln sehen kann. Bei den Artikel wird derselbe Link zum selben Ziel zweimal ausgegeben (Bild und Mehr-Lesen-Link). Behoben werden kann man dies, indem man das Bild und den kompletten Artikel-Teaser in einem einzigen Link packt und bei mehr lesen einfach nur den Link als Element herausnimmt und stattdessen mit einem anderen Element (entweder span- oder p-Element) ersetzt und die visuelle Darstellung vom Link via CSS anpasst.
Der Icon-Link "Zum Spendenformular" (€) ist nur mit einem title-attribute versehen. Diese Technik soll bei Links vermieden werden. Die bessere Methode hier wäre, die Beschreibung innerhalb des Links in ein span packen und mit der class .sr-only visuell verstecken.
Hintergrund: Viele Screen Reader User schalten das Title-Attribut ab, weil auf vielen Websites oft nur redundante Informationen bereitgestellt werden. Bestes Beispiel hier auf dieser Seite ist der "Nach oben" -Button (Title-Attribut und Link-Text haben dieselbe Information).
Kriterium 4.1.1 - Syntaxanalyse: Silber
- Nachaudit: Das Unterstehende wurde zwar behoben, jedoch erkannt, dass es eine duplicate ID gibt (breadcrumbs).
Das Attribut controlslist="nodownload" auf dem youtube-iframe ist nicht erlaubt.
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T7 Contentseite 1
Kriterium 1.3.1 - Info und Beziehungen: Silber
- Die Überschrifthierarchie ist nicht linear (eine h2 vor h1, dach eine h2 mit drei h3, dann wieder eine h2 mit zwei h4 am Ende der Seite).
Kriterium 1.4.5 - Bilder eines Textes: Silber
- Das SVG-Logo ist mit einer visuell versteckten Textalternative versehen, das nur "BSV WNB" ausgibt, jedoch den Text im Bild "Blinden- und Sehbehindertenverband Wien, Niederösterreich und Burgenland" auslässt.
Im Footer sind Logos mit Text im Bild eingebunden, die nicht ausreichend im Alternativtext ausgegeben sind:
- "Fair für alle Logo" sollte den kompletten Text sinngemäß umfassen: "Fair für alle - Für mehr Barrierefreiheit - www.fairfueralle.at"
- "Osgs Logo" sollten sollte den kompletten Textsinngemäß umfassen: "Österreichisches Spendengütesiegel - Reg.Nr. 05355 - www.osgs.at"
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T8 Contentseite 2
Kriterium 2.4.3 - Fokus-Reihenfolge: Silber
- Das Hauptmenü verfügt über kein Focus-Management (Focus-Trap), wenn es geöffnet ist (man kann über das Menü-hinaustabben)
Kriterium 2.4.4 - Linkzweck (im Kontext): Silber
- Nachaudit: Das Untenstehende wurde nur teilweise behoben. Das Prinzip der redundanten Informationen wurde noch nicht komplett umgesetzt, wie man das beim Back-to-Top Link (title ist hier redundant).
Der Icon-Link "Zum Spendenformular" (€) ist nur mit einem title-attribute versehen. Diese Technik soll bei Links vermieden werden. Die bessere Methode hier wäre, die Beschreibung innerhalb des Links in ein span packen und mit der class .sr-only visuell verstecken.
Hintergrund: Viele Screen Reader User schalten das Title-Attribut ab, weil auf vielen Websites oft nur redundante Informationen bereitgestellt werden. Bestes Beispiel hier auf dieser Seite ist der "Nach oben" -Button (Title-Attribut und Link-Text haben dieselbe Information).
Kriterium 2.4.7 - Fokus sichtbar: Silber
- Nachaudit: Das Untenstehende ist behoben.
Die Such-Komponente besteht aus zwei "Buttons", während eines visuell versteckt ist und somit der Fokus nicht durchgehend sichtbar ist. Das ist an sich nicht notwendig. Wenn man alles in ein Button gibt und das Verhalten via JS korrekt anpasst (Anmerkung: Das Klick-Verhalten ist fehlerhaft, wenn man das Suchfeld via Klick auf den Button geöffnet hat und mit dem nächsten wider geschlossen hat, lässt sich mit dem nachfolgenden Klick das Suchfeld nicht mehr öffnen - nur wenn der Fokus außerhalb des Buttons befindet, geht es dann wieder).
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.
BSVWNB: T9 Downloads
Kriterium 1.1.1 - Nicht-Text-Inhalt: Silber
- Nachaudit: Das Untenstehende wurde teilweise behoben. Die Bilder in den Link verfügen nach wie vor über keine Textalternative.
Es werden Icons via einem Icon-Font eingebettet, die nicht konsistent von assistiven Technologien versteckt werden (betrifft fast alle Icons):
"Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology."
Korrektes Bespiel auf der Seite:
<span class="i-menu-toggle" aria-hidden="true"></span>
Inkorrektes Bespiel aus der Startseite:
<span class="i-euro"></span>
Somit wird im ::before bzw. ::after der unverständliche Inhalt (content: '\e809';) vorgelesen, weil hier das aria-hidden="true" nicht gesetzt ist.
Die Bilder der Downloads haben keinen Alternativtext.
Kriterium 2.4.4 - Linkzweck (im Kontext): Silber
- Nachaudit: Das Untenstehende wurde nur teilweise behoben. Das Prinzip der redundanten Informationen wurde noch nicht komplett umgesetzt, wie man das beim Back-to-Top Link (title ist hier redundant).
Der Icon-Link "Zum Spendenformular" (€) ist nur mit einem title-attribute versehen. Diese Technik soll bei Links vermieden werden. Die bessere Methode hier wäre, die Beschreibung innerhalb des Links in ein span packen und mit der class .sr-only visuell verstecken.
Hintergrund: Viele Screen Reader User schalten das Title-Attribut ab, weil auf vielen Websites oft nur redundante Informationen bereitgestellt werden. Bestes Beispiel hier auf dieser Seite ist der "Nach oben" -Button (Title-Attribut und Link-Text haben dieselbe Information).
Kriterium 4.1.2 - Name, Rolle, Wert: Silber
- Nachaudit: Das Folgende wurde behoben.
Beim Menü ist die erste Menüebene funktional eine Schaltfläche, die eine Javascript-Funktion auslöst (es öffnet bzw. schließt das Submenü) und daher kein Link (das auf eine neue Seite oder die Seite neu lädt bzw. zu Inhalt innerhalb derselben Seite springt).
Das Folgende wurde nun behoben:
Nachaudit: Die Landmarks-Zugänglichkeit ist nur dann möglich, wenn die Suche geöffnet ist, dasselbe Problem besteht bei der Haupt-Navigation. Die jeweiligen Buttons sind nicht eingeschlossen. Somit ist es kein optimales Pattern im Sinne von Best-Practice.
Die Such-Komponente ist nicht zugänglich, wenn man sie über die Landmarks ansteuert. Man kommt direkt auf den visuell versteckten Button, jedoch nicht auf das Input-Feld, somit ist die Eingabe aus der Landmark-Bedienung heraus nicht möglich. Der Button-Status (aria-expanded) bleibt nach jedem Klick unverändert.
Nachaudit: Das Untenstehende wurde behoben.
Die gesetzten Roles im Footer-Menü "Weitere Links" wie role="menu" und role="menu-item" sind für einen ganz anderen Use-Case vorgesehen und sollten hier entfernt werden, weil hier auf forms- bzw. application mode umgeschalten wird und die Bedienung somit verändert wird.
Nachaudit: Das Untenstehende wurde gegen ein anderes Pattern (Bootstrap Collapsible) ersetzt. Das ist an sich ok, da die Screen Reader User Experience gleichbleibend ist.
Die Tabs (.metaNav) sind als Tabs konzipiert im Elternelement mit der role="tablist" versehen, im Tab mit der role="tab", die Tabpanels sind nicht als solche mit der role="tabpanel" versehen. Das hier verwendete Pattern ist auch nicht komplett funktional im Sinne von barrierefreien Tabs.