Auslegung von Richtlinien und Standards zur Barrierefreiheit von Oracle

Philosophie und Richtlinien zur Barrierefreiheit von Oracle

Oracle ist bestrebt, standardbasierte Produkte zu entwickeln, um Kunden dabei zu helfen, die Komplexität zu reduzieren und das Beste aus vorhandenen Technologieinvestitionen herauszuholen. Dieses Engagement erstreckt sich auch auf unseren Ansatz zur Barrierefreiheit. Oracle verwendet zum Rendern der meisten Benutzeroberflächen branchenübliche Technologien wie HTML, JavaScript und Java. Zudem befolgen wir international anerkannte Standards zur Barrierefreiheit, die die Unterstützung einer breiten Palette von Hilfstechnologien (AT) wie Bildschirmlesegeräte, Bildschirmlupen und Spracherkennung ermöglichen.

Aufgrund der Vielzahl von Gesetzen und Richtlinien, die sich auf dieses Thema beziehen, dem rasanten Tempo des technologischen Wandels und den Auswirkungen auf nahezu jeden Aspekt der Produktentwicklung (vom ersten Entwurf bis zum Support) stellt die Barrierefreiheit für die gesamte IKT-Community einzigartige Herausforderungen dar. Im Folgenden erfahren Sie, wie Oracle diese Herausforderungen meistert.

Richtlinien zur Barrierefreiheit

Richtlinien und Standards

Die Oracle Accessibility Guidelines basieren auf dem im Jahr 2017 überarbeiteten Abschnitt 508 des Rehabilitation Act von 1973 in der geänderten Fassung sowie auf den Richtlinien des World Wide Web Consortiums (W3C) zur Barrierefreiheit von Webinhalten, Version 2.1, auf der Ebene AA (WCAG 2.1 AA).

Oracle ist bestrebt, neue Produkte soweit wie möglich in Übereinstimmung mit dem überarbeiteten Abschnitt 508 und den WCAG 2.1 AA-Standards zu entwickeln. Wenn neue Produkte und Revisionen veröffentlicht werden, die den Standards „Revised Section 508“ und „WCAG 2.1“ entsprechen, veröffentlichen wir Accessibility Conformance Reports (ACRs) auf Grundlage der Voluntary Product Accessibility Templates (VPATs), die die aktualisierte VPAT 2.x-Vorlage verwenden. Bis dahin verfügen wir über VPATs, die zusätzlich zu den Standards von Abschnitt 508 eine Tabelle aller WCAG 2.0-Standards „A“ und „AA“ enthalten.

Im Jahr 2017 gab das U.S. Access Board den überarbeiteten Standard Section 508 bekannt, der auf den WCAG 2.0 AA-Standards basierte. Die erste Fassung der EU-Norm EN 301 549 „Angemessene Anforderungen an die Barrierefreiheit für die öffentliche Beschaffung von IKT-Produkten und -Services in Europa“, die 2014 als Reaktion auf das Mandat 376 herausgegeben wurde, basierte auf den WCAG 2.0 AA-Standards. Sie wurde 2019 aktualisiert und enthält WCAG 2.1. EN 301 549 Angemessene Anforderungen an die Barrierefreiheit für die öffentliche Beschaffung von IKT-Produkten und -Services in Europa (PDF) – V3.1.1 (2019-11). Oracle hat sich aktiv an der Entwicklung dieser Richtlinien beteiligt und verfolgt ihre Fortschritte aufmerksam.

Jeder Standard unterliegt einem gewissen Maß an Interpretation. Unter Interpretation von Standards finden Sie einen detaillierten Überblick darüber, wie Oracle bestimmte Standards behandelt.

Status der Barrierefreiheit

Die Barrierefreiheit von Oracle Produkten wird mithilfe verschiedener Techniken geprüft. Dazu gehören automatisierte Tools, heuristische Überprüfung durch Experten, visuelle Inspektion, manuelle Bedienung und Tests mit verschiedenen technischen Hilfsmitteln durch sowohl behinderte als auch nicht behinderte Benutzer. Wir berichten über die Ergebnisse dieser Tests unter Verwendung des Voluntary Product Accessibility Template (VPAT), um den Accessibility Conformance Report (ACR) zu erstellen. Das VPAT wurde von ITI und GSA entwickelt, um Bundesauftragnehmer und andere Käufer bei der vorläufigen Einschätzung der Verfügbarkeit kommerzieller IKT-Produkte und -Services mit Features zur Barrierefreiheit zu unterstützen. Eine ausführliche Erläuterung unserer Verwendung des VPAT und die Auffindbarkeit der ACRs für Oracle Produkte finden Sie in den Accessibility Conformance Reports.

Plan für einen barrierefreien Kundenservice für Ontario, Kanada

Der Plan von Oracle für einen barrierefreien Kundenservice für Ontario, Kanada (PDF) beschreibt die von Oracle genehmigten Richtlinien, Praktiken und Verfahren, um die Verpflichtungen gemäß dem Accessibility for Ontarians with Disabilities Act von 2005 (AODA) und insbesondere der Verordnung 165/16 zu erfüllen. Der mehrjährige Plan zur Barrierefreiheit von Oracle (PDF) beschreibt die Verpflichtung von Oracle zur Einhaltung der Barrierefreiheitsstandards von Ontario.

Aktualisierungen der Barrierefreiheitsstandards

Oracle hat sich aktiv an der Entwicklung der WCAG 2.2-Richtlinien für Barrierefreiheit beteiligt und wird die zusätzlichen WCAG 2.2-Erfolgskriterien nach der Veröffentlichung von WCAG 2.2 implementieren.

Interpretation und Position von Oracle zu verschiedenen Barrierefreiheitsstandards und Richtlinien, die in WCAG 2.2 oder ARIA enthalten sind

Eingabezweck identifizieren

Relevante Standards

• https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html

Die Position von Oracle

Einige Kunden haben diesen Standard so interpretiert, dass in allen Eingabefeldern der Eingabezweck identifiziert werden muss. Der Standard ist ausdrücklich auf Eingabefelder beschränkt, in denen personenbezogene Daten des Benutzers erfasst werden. Oracle ist bestrebt, den Eingabezweck der Felder zu identifizieren, in denen solche personenbezogenen Daten erfasst werden.

„In Fokus“ und „bei Eingabe“

Relevante Standards

• Erfolgskriterium 3.2.1 verstehen: In Fokus | WAI | W3C
• Erfolgskriterium 3.2.2 verstehen: Bei Eingabe | WAI | W3C

Die Position von Oracle

Einige Kunden haben die Erfolgskriterien für „On Focus“ (In Fokus) und „On Input“ (Bei Eingabe) so interpretiert, dass sie im Großen und Ganzen auf Änderungen sowohl des Inhalts als auch des Kontexts anwendbar sind. Oracle geht davon aus, dass diese Standards speziell für Kontextänderungen gelten und nicht für Inhaltsänderungen, die die Bedeutung einer Seite nicht verändern.

Accessible Rich Internet Applications Authoring Practice Guide (ARIA APG)

Relevante Standards

• Keiner

Die Position von Oracle

Einige Kunden interpretieren den Accessible Rich Internet Applications Authoring Practice Guide (ARIA APG) als normatives Dokument, dessen Musterbeispiele genau befolgt werden müssen. Jedoch ist der ARIA APG nicht normativ. Bei den im APG gefundenen Mustern handelt es sich um Beispielimplementierungen und diese stellen nicht die einzigen gültigen Muster dar. „Der APG gibt keine normativen Anforderungen vor und verfügt somit auch nicht über ein Konformitätsmodell.“ Weitere Informationen finden Sie unter APG ist kein normativer Standard.

Archivierte Interpretation und Position von Oracle zu mehreren älteren Barrierefreiheitsstandards, die in Abschnitt 508 oder WCAG 1.0 enthalten sind

Wir stellen diese Interpretation als Antwort auf Kundenanfragen zu bestimmten HTML-Inhalten bereit, insbesondere wenn automatisierte Validierungstools auf eine Nichtkonformität hinweisen. Die meisten Probleme ergeben sich aus der Tatsache, dass die Mehrheit dieser Vorschriften und Standards in den Jahren 1999 oder 2001 verfasst wurde und die Technologie der Browser sowie Hilfstechnologien (AT) sich seitdem erheblich weiterentwickelt haben. Oracle begrüßt die Neufassungen von Abschnitt 508 und WCAG, durch die viele der unten diskutierten Bestimmungen geändert oder präzisiert werden, um technologischen Änderungen Rechnung zu tragen. Wir beteiligen uns aktiv an den Ausschüssen, die diese Änderungen bewirken.

Der Kürze halber bezieht sich ein Verweis wie „1194.22(l)“ auf die Bestimmung 1194.22(l) in Abschnitt 508 der Standards (die in Teil 1194 von Titel 36 des Code of Federal Regulations zu finden sind) und ein Verweis wie „WCAG 1.0 Nr. 6.3“ auf Standard 6.3 von WCAG 1.0.

Skripterstellung, insbesondere die Verwendung von JavaScript

Relevante Standards

• 1194.22(l) Wenn Seiten Skriptsprachen verwenden, um Inhalte anzuzeigen oder Schnittstellenelemente zu erstellen, müssen die vom Skript bereitgestellten Informationen durch Funktionstext gekennzeichnet sein, der von unterstützenden Technologien gelesen werden kann.
• WCAG 1.0 Nr. 6.3 Stellen Sie sicher, dass Seiten nutzbar sind, wenn Skripte, Applets oder andere Programmobjekte deaktiviert bzw. nicht unterstützt werden. Stellen Sie gleichwertige Informationen auf einer anderen zugänglichen Seite bereit, falls dies nicht möglich ist.
• WCAG 1.0 Nr. 8.1 Machen Sie programmtechnische Elemente wie Skripte und Applets direkt zugänglich oder mit Hilfstechnologien kompatibel.

Die Position von Oracle

Viele Kunden verstehen diese Standards so, dass ein Produkt nur zugänglich ist, wenn die Skripterstellung deaktiviert ist. Dies ist jedoch nicht der Fall. Sowohl der Abschnitt 508-Standard als auch WCAG 1.0 erlauben die Verwendung von Skripten, die direkt zugänglich bzw. mit AT kompatibel sind. Die meisten (wenn nicht alle) Oracle Produkte erfordern JavaScript und sind auf Browser angewiesen, die JavaScript unterstützen. Oracle ist davon überzeugt, dass JavaScript nicht nur zugänglich gemacht werden kann, sondern auch die Barrierefreiheit verbessert. Wenn Sie beispielsweise nur einen Teil des Inhalts einer Seite ändern, anstatt die ganze Seite neu zu laden, müssen Sie nicht erst eine völlig „neue“ Seite durchsuchen, um einen kleinen Abschnitt zu finden, der überarbeitet wurde. Die Umstellung auf Rich-Client-Schnittstellen macht eine verstärkte Verwendung von Skripten erforderlich. Oracle ist bestrebt, diesen Code für Menschen mit Behinderungen nutzbar zu machen. Alternativ generieren wir anderen Code, der zu einem vergleichbaren Erlebnis führt.

Validierung nach veröffentlichten formalen Grammatiken

Relevante Standards

• WCAG 1.0 Nr. 3.2 Erstellen Sie Dokumente, die den veröffentlichten formalen Grammatiken entsprechen.

Die Position von Oracle

Einige HTML-Tags haben keinen Einfluss auf die Barrierefreiheit und Browser interpretieren Tags bekanntermaßen unterschiedlich. Der entscheidende Punkt ist, dass die Tags zur Barrierefreiheit vom Browser und der Hilfstechnologie eindeutig interpretiert werden müssen. Aus verschiedenen Gründen hält sich das HTML von Oracle möglicherweise nicht genau an eine formale Grammatik:

• In verschiedenen Fällen müssen wir dem HTML-DOM zusätzliche Informationen hinzufügen und verwenden zu diesem Zweck „Expandos“.
• Wie von W3C WAI-ARIA empfohlen, verwenden wir tabIndex="-1", um bestimmte Elemente fokussierbar zu machen.
• Da Browser unterschiedlich funktionieren, können wir den HTML-Code optimieren, um dem spezifischen Browserverhalten Rechnung zu tragen.

Sofern der Kunde den technischen Support in Anspruch nimmt, wird Oracle jedes Problem lösen, bei dem „Nicht-Standard“-HTML die Barrierefreiheit behindert, und zwar in Übereinstimmung mit den Standardrichtlinien von Oracle für den technischen Support. Oracle korrigiert jedoch nicht unbedingt „ungültiges“ HTML, das von einem automatisierten Tool gemeldet wird, aber keine negativen Auswirkungen auf die Barrierefreiheit hat.

Geräteunabhängigkeit

Relevante Standards

• WCAG 1.0 Nr. 6.4 Stellen Sie bei Skripten und Applets sicher, dass Event-Handler unabhängig vom Eingabegerät sind.
• WCAG 1.0 Nr. 9.2 Stellen Sie sicher, dass jedes Element mit eigener Schnittstelle geräteunabhängig bedient werden kann.
• WCAG 1.0 Nr. 9.3 Geben Sie für Skripte logische Event-Handler anstelle von geräteabhängigen Event-Handlern an.

Die Position von Oracle

Einige Kunden haben diese Standards so interpretiert, dass jede Operation, die nur mit einer Maus ausgeführt werden kann, wie beispielsweise ein Doppelklick, verboten ist. Oracle ist bestrebt, allen Benutzern eine umfassende Benutzererfahrung zu bieten. In Situationen, in denen Aktionen komplexe Mausaktionen wie Doppelklicken oder Ziehen und Ablegen erfordern, werden alternative Mechanismen bereitgestellt, die nur mit der Tastatur ausgeführt werden können.

Frames

Relevante Standards

• 1194.22(i) Frames müssen mit Text betitelt sein, der die Frame-Identifizierung und Navigation erleichtert.
• WCAG 1.0 Nr. 12.1 Geben Sie jedem Frame einen Titel, um die Frame-Identifizierung und Navigation zu erleichtern.

Die Position von Oracle

Oracle ist auf viele Situationen gestoßen, in denen Frames entweder als „Verstoß“ gegen Barrierefreiheitsstandards angesehen oder nicht als „richtiges HTML“ betrachtet wurden. Darüber hinaus ist Oracle der Ansicht, dass Frames ein legitimer Bestandteil von HTML sind, und wir zertifizieren nur mit Browsern, die diese unterstützen. Bei unseren Produkten sind die Frames entsprechend der jeweils angegebenen Standards ordnungsgemäß gekennzeichnet. Eine Ausnahme ist die Verwendung eines iFrames, wenn dieser lediglich zur Kommunikation mit dem Server genutzt wird. In diesem Fall betitelt Oracle den Frame absichtlich nicht, um das Element für den Benutzer unsichtbar zu machen (genau wie für einen sehenden Benutzer).

Formatvorlagen

Relevante Standards

• 1194.22(d) Dokumente müssen so organisiert sein, dass sie lesbar sind, ohne dass eine zugehörige Formatvorlage erforderlich ist.
• WCAG 1.0 Nr. 6.1 Dokumente so organisieren, dass sie ohne Formatvorlage gelesen werden können. Wenn beispielsweise ein HTML-Dokument ohne zugehörige Formatvorlage gerendert wird, muss es weiterhin möglich sein, das Dokument zu lesen.

Die Position von Oracle

Oracle interpretiert diesen Standard dahingehend, dass Informationen („Inhalt“) und Präsentation getrennt werden sollten. HTML sollte beispielsweise über eine semantische Auszeichnung zur Identifizierung der Informationen verfügen und für die Darstellung eines bestimmten Look-and-Feels sollte eine externe Formatvorlage verwendet werden. Wenn ein Benutzer die Seite mithilfe von Hilfstechnologie aufruft, müssen die Informationen in einer sinnvollen Reihenfolge übermittelt werden. Oracle akzeptiert jedoch nicht, dass das Produkt mit deaktivierten Formatvorlagen im Browser ausgeführt werden muss, da:

• Alle modernen Browser Formatvorlagen unterstützen.
• Das Setzen von Stilattributen wie display:none im Seiteninhalt häufig verwendet wird, um Inhalte vor allen Benutzern zu verbergen. Das vollständige Deaktivieren von Formatvorlagen führt dazu, dass diese Informationen fälschlicherweise angezeigt werden.
• Moderne Browser bei Bedarf das Überschreiben der Autoren-Formatvorlage durch eine Benutzer-Formatvorlage unterstützen.

Links zu Plug-ins

Relevante Standards

• 1194.22(m) Wenn für eine Webseite zur Interpretation des Seiteninhalts ein Applet, Plug-in oder eine andere Anwendung auf dem Clientsystem vorhanden sein muss, muss die Seite einen Link zu einem Plug-in oder Applet bereitstellen, das 1194.21(a) bis (l) entspricht.

Die Position von Oracle

Viele Plug-ins, wie beispielsweise der PDF-Viewer von Adobe, sind mittlerweile allgegenwärtig und oft auf Computern vorinstalliert. In einigen Fällen, beispielsweise beim Oracle JInitiator, wird das Plug-in mit dem Produkt geliefert und installiert sich automatisch. Darüber hinaus kann die Bereitstellung eines Links zu einer Site außerhalb der Firewall eines Unternehmens oder die Ermöglichung des Herunterladens und Installierens eines Plug-ins durch einen Benutzer einen Verstoß gegen die Unternehmensrichtlinien darstellen. Oracle Produkte stellen daher Links zu Plug-ins bereit, die diesem Standard entsprechen, auch wenn sie entweder nicht als allgegenwärtig gelten oder nicht mit dem Produkt ausgeliefert werden.

Navigation überspringen

Relevante Standards

• 1194.22(o) Es muss eine Methode bereitgestellt werden, mit dem Benutzer sich wiederholende Navigationslinks überspringen können.

Die Position von Oracle

Viele Oracle Produkte bieten einen Link, der den Fokus auf den „Hauptinhalt“ einer Seite lenkt. Oracle ist sich jedoch auch darüber im Klaren, dass die meisten AT einen Mechanismus unterstützen, der es dem Benutzer ermöglicht, mithilfe standardmäßiger struktureller Markup-Tags zu verschiedenen Abschnitten einer Seite zu wechseln. Oracle kann diesen Mechanismus gegebenenfalls nutzen, um das Ziel dieser Bestimmung zu erreichen.