Barrierefreiheitserklärung
Einhaltung der Web Content Accessibility Guidelines (WCAG 2.1) und ISO/IEC 40500:2012
Dispel verpflichtet sich, seine Websites und Anwendungen gemäß Titel III des U.S. Americans with Disabilities Act von 1990 (42 U.S.C. § 12101) und für unsere US-Regierungskunden gemäß Abschnitt 508 des Rehabilitation Act von 1973 (29 USC § 794d) zugänglich zu machen.
Um dieses Engagement zu erfüllen, wurden unsere Websites und Anwendungen so gestaltet, dass sie den W3C Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, entsprechen. Unsere Anwendungen verwenden sowohl native Betriebssystem(„OS“)-Elemente als auch markenspezifische Designs. Durch die Verwendung nativer Elemente nutzt Dispel die leistungsfähigen Barrierefreiheitsfunktionen des Betriebssystemherstellers. Soweit dies nicht bereits durch das native Betriebssystem abgedeckt ist, sollen unsere Markendesigns den WCAG 2.1, Level AA, entsprechen.
Laden Sie hier eine Kopie unserer Barrierefreiheitserklärung herunter:
Technische Informationen zur Zugänglichkeit von Dispels Website und Anwendungen
Dispel verpflichtet sich, seine Websites und Anwendungen gemäß dem U.S. Americans with Disabilities Act von 1990 (42 U.S.C. § 12101) zugänglich zu machen.
Konformitätsstatus
Informationen zu unserem Konformitätsstatus sind in unserem Accessibility Conformance Report (ACR) auf Basis der ITI Voluntary Product Accessibility Template® (VPAT®) dargelegt. Dispel verwendet die VPAT 2.4 INT, die überarbeitete Abschnitt‑508‑Standards (der US‑Bundesbarrierefreiheitsstandard), EN 301 549 (die „Barrierefreiheitsanforderungen, geeignet für die öffentliche Beschaffung von IKT‑Produkten und ‑Dienstleistungen in Europa“ der Europäischen Union), und WCAG 2.1 und ISO/IEC 40500 (W3C/WAIs kürzlich aktualisierte Web Content Accessibility Guidelines).
Feedback und Kontaktinformationen
Wir sind stets bestrebt, die Zugänglichkeit unserer Websites und Anwendungen zu verbessern. Wenn Sie Feedback oder Bedenken hinsichtlich der Zugänglichkeit von Inhalten auf unseren Websites oder Anwendungen haben, Ideen oder Kommentare, die uns helfen würden, die Zugänglichkeit und Nutzbarkeit unserer Website zu verbessern, oder der Meinung sind, dass wir die Zugänglichkeitsanforderungen nicht erfüllen, senden Sie bitte eine E‑Mail an [email protected]. Falls zutreffend, geben Sie bitte die Webadresse oder URL sowie die spezifischen Probleme an, auf die Sie gestoßen sind.
Durchsetzungsverfahren
Das U.S. Department of Justice (DoJ) ist für die Durchsetzung des Americans with Disabilities Act (ADA) verantwortlich.
Trotz unserer besten Bemühungen, es jedem zu ermöglichen, unsere Websites und Anwendungen an seine Bedürfnisse anzupassen, kann es dennoch Aspekte geben, die nicht vollständig zugänglich sind, sich im Prozess der Zugänglichmachung befinden oder für die es keine adäquate technologische Lösung gibt, um sie zugänglich zu machen. Wir verbessern jedoch kontinuierlich unsere Barrierefreiheit; erweitern, aktualisieren und verbessern Optionen und Funktionen; und entwickeln sowie übernehmen neue Technologien. All dies dient dem Ziel, das optimale Niveau der Zugänglichkeit im Zuge technischer Fortschritte zu erreichen.
Wenn Sie mit unserer Reaktion auf Ihre Beschwerde nicht zufrieden sind, können Sie die Civil Rights Division des DoJ kontaktieren, um eine Beschwerde einzureichen.
Um eine ADA‑Beschwerde online einzureichen:
Um eine ADA‑Beschwerde per Post einzureichen, senden Sie das ausgefüllte ADA‑Beschwerdeformular an:
U.S. Department of Justice Civil Rights Division 950 Pennsylvania Avenue, NW 4CON, 9. Stock Washington, DC 20530
Um eine ADA‑Beschwerde per Fax einzureichen, faxen Sie das ausgefüllte ADA‑Beschwerdeformular an:
(202) 307-1197
Weitere Informationen zum Einreichen einer ADA‑Beschwerde beim DoJ finden Sie auf deren Website.
Über WCAG und was wir tun, um die Zugänglichkeit zu verbessern
Industrielle Steuerungssysteme betreffen das Leben aller, wobei Beiträge von Personen aus aller Welt einfließen. Dispel entwirft und baut seine Werkzeuge mit Barrierefreiheit als zentralem Grundsatz unserer Philosophie.
Unsere Kunden sind gesetzlich verpflichtet, Vorschriften zur Barrierefreiheit einzuhalten, wie zum Beispiel den U.S. Americans with Disabilities Act (ADA), den European Accessibility Act (EAA), das britische Equality Act 2010, das Accessible Canada Act (ACA) und das australische Disability Discrimination Act (DDA).
Insgesamt gibt es derzeit 40 Web‑Barrierefreiheitsgesetze und ‑richtlinien in 23 Ländern und politischen Verbünden. Die Mehrheit dieser Vorschriften gibt keine strengen technischen Vorgaben, wie eine Website oder ein Dienst zugänglich zu machen ist, und überlässt die Umsetzung dem Ermessen und der Haftung des Dienstanbieters. Viele Vorschriften verwenden jedoch die Web Content Accessibility Guidelines („WCAG“) als Standard oder Basis. Dies wird zudem als internationaler Standard anerkannt: ISO/IEC 40500:2012.
WCAG 2.1 als unser Standard
Die WCAG werden vom World Wide Web Consortium (W3C) verfasst, das internationale Standards entwickelt. Relevanterweise werden deren Barrierefreiheitsstandards wiederum von der Accessible Platform Architectures („APA“) Arbeitsgruppe überprüft. Zum Zeitpunkt der Erstellung dieses Dokuments ist die WCAG in Version 2.1, mit einem Arbeitsentwurf für 2.2 in Prüfung. Es gibt außerdem einen unvollständigen Arbeitsentwurf für 3.0. Für die Zwecke dieses Dokuments beziehen sich Aussagen über die WCAG auf Version 2.1. Die aktuelle Referenz zu WCAG 2.1 finden Sie hier: https://www.w3.org/WAI/WCAG21/quickref/
Vier Grundsätze der WCAG
Während die WCAG eine technische Liste von Anforderungen bereitstellt, ist es sinnvoll, mit den vier Grundsätzen zu beginnen, um die sich die W3C‑Spezifikationen aufbauen.
Dieser Abschnitt bietet eine Zusammenfassung der WCAG‑Prinzipien. Für die normative technische Spezifikation siehe www.w3.org/TR/WCAG21.
Diese vier Grundprinzipien lauten, Websites müssen sein:
wahrnehmbar - Informationen und Benutzeroberflächenkomponenten müssen auf eine für die Nutzer wahrnehmbare Weise darstellbar sein. Das bedeutet, dass Nutzer in der Lage sein müssen, die präsentierten Informationen wahrzunehmen (sie dürfen nicht für alle ihre Sinne unsichtbar sein).
bedienbar - Benutzeroberflächenkomponenten und Navigation müssen bedienbar sein. Das bedeutet, dass Nutzer die Oberfläche bedienen können müssen (die Oberfläche darf keine Interaktion erfordern, die ein Nutzer nicht ausführen kann).
verständig - Informationen und die Bedienung der Benutzeroberfläche müssen verständlich sein. Das bedeutet, dass Nutzer die Informationen sowie die Bedienung der Benutzeroberfläche verstehen können müssen (Inhalt oder Bedienung dürfen nicht jenseits ihres Verständnisses liegen).
robust - Inhalte müssen so robust sein, dass sie zuverlässig von einer Vielzahl von Benutzeragenten, einschließlich unterstützender Technologien, interpretiert werden können. Das bedeutet, dass Nutzer auf die Inhalte zugreifen können müssen, wenn sich Technologien weiterentwickeln (während Technologien und Benutzeragenten sich entwickeln, sollte der Inhalt weiterhin zugänglich bleiben).
Verständnis der Konformität
Es gibt fünf Anforderungen, die erfüllt sein müssen, damit Inhalte als mit WCAG 2.1 „konform“ eingestuft werden.
Anforderungen
Anforderung
Details
Anforderung 1: Konformitätsstufe
Eine der folgenden Konformitätsstufen ist vollständig erfüllt.
Stufe A: Für die Konformität auf Stufe A (die Mindestkonformitätsstufe) erfüllt die Webseite alle Success Criteria der Stufe A oder es wird eine konforme Alternativversion bereitgestellt.
Stufe AA: Für die Konformität auf Stufe AA erfüllt die Webseite alle Success Criteria der Stufen A und AA oder es wird eine konforme Alternativversion auf Stufe AA bereitgestellt.
Stufe AAA: Für die Konformität auf Stufe AAA erfüllt die Webseite alle Success Criteria der Stufen A, AA und AAA oder es wird eine konforme Alternativversion auf Stufe AAA bereitgestellt.
Anforderung 2: Vollständige Seiten
Konformität (und Konformitätsstufe) bezieht sich nur auf vollständige Webseite(n) und kann nicht erreicht werden, wenn ein Teil einer Webseite ausgeschlossen ist.
Anforderung 3: Vollständige Prozesse
Wenn eine Webseite Teil einer Serie von Webseiten ist, die einen Prozess darstellen (d. h. eine Abfolge von Schritten, die abgeschlossen werden müssen, um eine Aktivität durchzuführen), müssen alle Webseiten im Prozess auf dem angegebenen Level oder höher konform sein. (Konformität auf einem bestimmten Level ist nicht möglich, wenn eine Seite im Prozess nicht auf diesem Level oder besser konform ist.)
Anforderung 4: Nur barrierefreiheits‑unterstützte Nutzungsweisen von Technologien
Es werden nur barrierefreiheits‑unterstützte Nutzungsweisen von Technologien zur Erfüllung der Success Criteria herangezogen. Jede Information oder Funktionalität, die auf eine Weise bereitgestellt wird, die nicht barrierefreiheits‑unterstützt ist, ist auch in einer barrierefreiheits‑unterstützten Weise verfügbar.
Anforderung 5: Nicht‑Behinderung
Wenn Technologien auf eine Weise verwendet werden, die nicht barrierefreiheits‑unterstützt ist, oder wenn sie in einer nicht konformen Weise eingesetzt werden, dürfen sie nicht die Fähigkeit der Nutzer blockieren, auf den Rest der Seite zuzugreifen. Darüber hinaus erfüllt die Webseite als Ganzes weiterhin die Konformitätsanforderungen unter den folgenden Bedingungen:
1. wenn eine Technologie, auf die nicht vertraut wird, in einem Benutzeragenten eingeschaltet ist,
2. wenn eine Technologie, auf die nicht vertraut wird, in einem Benutzeragenten ausgeschaltet ist, und
3. wenn eine Technologie, auf die nicht vertraut wird, von einem Benutzeragenten nicht unterstützt wird
Zusätzlich gelten die folgenden Success Criteria für alle Inhalte auf der Seite, einschließlich solcher Inhalte, die nicht anderweitig zur Erfüllung der Konformität herangezogen werden, da deren Nichterfüllung die Nutzung der Seite beeinträchtigen könnte:
1.4.2 - Audiosteuerung,
2.1.2 - Kein Tastatur‑Falle,
2.3.1 - Drei Blitze oder unter dem Schwellenwert, und
2.2.2 - Pause, Stopp, Verbergen.
Success Criteria
WCAG 2.1‑Elemente enthalten Success Criteria, die als testbare Kriterien geschrieben sind, um objektiv zu bestimmen, ob eine bestimmte Implementierung das Element erfüllt.
Beispielsweise verlangt 1.4.1 Verwendung von Farbe, dass „Farbe nicht als einziges visuelles Mittel zur Übermittlung von Informationen, Anzeige einer Aktion, Aufforderung zur Reaktion oder Unterscheidung eines visuellen Elements verwendet wird.“ Mit anderen Worten: Sie können nicht einfach Text von Rot auf Grün ändern, um einem Nutzer etwas zu signalisieren. Es gibt ausreichende Techniken, die zusammen mit Farbe verwendet werden können, um Bedeutung für Personen mit eingeschränktem Sehvermögen, eingeschränktem Farbsehen oder monochromen Anzeigen zu vermitteln. 1.4.1 bietet Techniken zur Erfüllung der Success Criteria. Einige davon sind: (G14) Sicherstellen, dass durch Farbunterschiede vermittelte Informationen auch als Text verfügbar sind; (G205) Einfügen eines Texthinweises für farbige Formularfeld‑Beschriftungen; (G182) Sicherstellen, dass zusätzliche visuelle Hinweise verfügbar sind, wenn Textfarbunterschiede zur Informationsvermittlung verwendet werden; und (G183) Verwendung eines Kontrastverhältnisses von 3:1 mit umgebendem Text und Bereitstellung zusätzlicher visueller Hinweise beim Hover für Links oder Bedienelemente, bei denen die Farbe allein zur Kennzeichnung verwendet wird.[1]
Konformität mit WCAG bedeutet, dass eine Implementierung eines Elements die Anforderungen der Success Criteria erfüllt. Die meisten Elemente haben eine Konformitätsstufe – mit anderen Worten: Entweder Sie erfüllen die Success Criteria, oder Sie tun es nicht. In einigen Fällen haben Elemente drei Konformitätsstufen: Stufe A, AA und AAA.
Der natürliche Instinkt ist, durchgehend Konformität auf Stufe AAA anzustreben. Unglücklicherweise sind die WCAG so verfasst, dass vollständige Konformität nicht möglich ist. Tatsächlich bemerken die Autoren beim W3C selbst: „Es wird nicht empfohlen, Konformität auf Stufe AAA als allgemeine Richtlinie für ganze Websites zu verlangen, da es nicht möglich ist, alle Success Criteria der Stufe AAA für einige Inhalte zu erfüllen.“ Unser Ziel ist daher, die Zugänglichkeit so weit wie vernünftigerweise möglich zu maximieren, ohne eine unzumutbare Belastung zu schaffen.
Barrierefreiheit von Anwendungen über Geräteplattformen hinweg
Dispel stellt seinen Kunden Anwendungen für Apple macOS®, iPadOS®, iOS sowie für Microsoft Windows® zur Verfügung.
Diese Betriebssysteme bringen eigene Barrierefreiheitsfunktionen mit. Beispielsweise enthält macOS eine Vielzahl von Funktionen und unterstützenden Technologien wie Bildschirm‑ und Cursorvergrößerung, einen voll funktionsfähigen Screenreader, visuelle Blitzalarme, Untertitelungsunterstützung und mehr.[3]
Dispels Anwendungen verwenden native Designelemente – für UWP‑Windows‑Apps als „modern design“ und für Apple macOS als „design style“ bezeichnet – beim Aufbau unserer Produkte. Diese UI‑Elemente bieten oft eingebaute Barrierefreiheit und liefern standardmäßig eine zugängliche Benutzererfahrung.
Um mehr über Apples Barrierefreiheitsfunktionen zu erfahren, besuchen Sie bitte:
https://www.apple.com/accessibility/
Um mehr über Microsofts Barrierefreiheitsfunktionen zu erfahren, besuchen Sie bitte:
https://www.microsoft.com/en-us/accessibility/windows
Im Kontext unseres Konformitätsstatus liegen Betriebssystem‑abgeleitete Barrierefreiheitsfunktionen in der Verantwortung von Apple und Microsoft.
Erstellung dieser Barrierefreiheitserklärung
Diese Erklärung wurde am 8. April 2021 erstellt.
Für den UK Artikel 3(1) der Durchführungsentscheidung der Kommission (EU) 2018/1523 wurde diese Barrierefreiheitserklärung unter Verwendung der Version 2.4 der ITI Voluntary Product Accessibility Template® (VPAT®) INI‑Ausgabe erstellt.
Diese Erklärung wurde zuletzt am 8. April 2021 überprüft.\
[1] W3C, „Understanding Success Criterion 1.4.1: Use of Color.“ WCAG 2.1. Verfügbar: https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html, Zugriff am 1. April 2021.
[2] W3C Working Group, „Understanding Conformance.“ Understanding WCAG 2.0. 7. Oktober 2016. Zugänglich: https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html, Zugriff am 1. April 2021.
[3] Apple Inc., „macOS.“ Accessibility for Developers. Zugänglich: https://developer.apple.com/accessibility/, Zugriff am 8. April 2021.
Zuletzt aktualisiert