Zugängliche Oracle JET-Anwendungen erstellen

Hinweis: Dieser Lernpfad ist Voraussetzung: Webanwendung in Oracle JavaScript Extension Toolkit (Oracle JET) entwickeln, die vor Beginn dieses Kurses abgeschlossen werden muss.

Einführung in die Barrierefreiheit

Jetzt, da Sie ein grundlegendes Verständnis davon haben, wie Sie mit Oracle JET Webanwendungen entwickeln können, ist es an der Zeit, die speziellen Anforderungen von fast 10 bis 20 Prozent Ihrer Zielgruppe - also von Menschen mit Behinderungen - zu erfüllen. Laut einem Artikel aus dem Jahr 2014, der von der Weltgesundheitsorganisation veröffentlicht wurde, haben etwa 15 Prozent der Weltbevölkerung irgendeine Form von Behinderung, und diese Zahl wächst mit einer ständig alternden Bevölkerung.

Historie

Das moderne Konzept der Barrierefreiheit entstand Ende 1960s als Basisbewegung auf Universitätsgeländen und in lokalen Gemeinden, um die Rechte behinderter Menschen zu adressieren, die physischen Zugang zu öffentlichen Gebäuden suchen. Dieser Zugang umfasste Rampen entlang öffentlicher Gehwege, Eingänge, automatische Türen und Brailleetiketten in Aufzügen zu öffentlichen, staatlichen und College-Gebäuden.

Gleichberechtigung

Heute umfasst "Zugang" sowohl physischen Zugang zu Strukturen als auch Zugang zu der aktuellen technologischen Landschaft von PCs, Laptops, Tablets, Smartphones und sprachgesteuerten Geräten wie Amazon Alexa. Die Gleichbehandlungsgesetzgebung befasst sich weiterhin mit den Fragen des physischen Zugangs und der Technologie, auf die wir angewiesen sind.

Software-Zugänglichkeit wird durch Zivilgesetze in vielen Ländern auf der ganzen Welt vorgeschrieben. Beispiel:

• The Americans with Disabilities Act in den Vereinigten Staaten
• The Accessibility for Ontarians with Disabilities Act in Ontario, Kanada
• The Equality Act of 2010 im Vereinigten Königreich

Herausforderungen für den Zugang - Arten von Hindernissen

Als Webanwendungsdesigner und Entwickler müssen wir uns bewusst sein, dass behinderte Kunden beim Zugriff auf Technologie mit Hindernissen konfrontiert sind. Beachten Sie Folgendes:

• Ein Benutzer kann die Maus aufgrund einer eingeschränkten Mobilität nicht manipulieren (kongenitaler Geburtsfehler, Lou Gehrig-Krankheit, Parkinson-Krankheit, rheumatoide Arthritis, Verletzung oder ein altersbedingtes Defizit). Wie würde ein solcher Benutzer Text aktivieren, an den ein On-Click-Event gebunden ist?
• Ein Benutzer ist sehbehindert und kann nicht sehen, dass die Anweisungen zur Verwendung einer Seite oder eines Formulars nach dem Inhalt folgen. Wie würde der Benutzer wissen, die gesamte Seite zu lesen, um die Anweisungen zu finden?
• Ein Benutzer hat ein geringes Sehvermögen und verwendet eine Bildschirmlupe, die nur einen kleinen Teil des Bildschirms gleichzeitig fokussiert und vergrößert. Wie würde der Benutzer angesichts der Einschränkungen der Lupe wissen, ob eine Nachricht an anderer Stelle auf dem Bildschirm erscheint?
• Ein Benutzer ist farbenblind und kann nicht zwischen bestimmten Farben unterscheiden. Wie würde der Benutzer wissen, welche rote, blaue oder grüne Schaltfläche im Text der Seite referenziert wird?

Dies sind nur einige Illustrationen der Bedenken, die ein Entwickler bei der Erstellung einer zugänglichen Webanwendung berücksichtigen muss. Dieser Lernpfad bietet klare Methoden zur Codierung und zum Testen der Barrierefreiheit, um die aktuellen Standards zu erfüllen, die von den Web Content Accessibility Guidelines (WCAG) Version 2.2 festgelegt wurden.

Es ist ratsam, die oben genannten Leitlinien genau zu betrachten, da sie die Grundlage unserer Arbeit in der Barrierefreiheit bilden.

Die Web Content Accessibility Guidelines (WCAG)

Das World Wide Web Consortium (W3C) hat eine Reihe von Standards erstellt, die als Web Content Accessibility Guidelines (WCAG) bezeichnet werden und sehr spezifische Regeln für den Zugriff auf Websites und Webanwendungen enthalten. Diese Leitlinien bilden die Grundlage für diesen Lernpfad.

Die WCAG-Normen konzentrieren sich auf vier Bereiche einer Webanwendung oder Website:

1. Wahrnehmbarkeit: Kann die Schnittstelle von einer großen Mehrheit der Menschen unabhängig von Behinderungen wahrgenommen werden?

   • Farbkontrastverhältnisse, die gut für sehbehinderte Menschen funktionieren
   • Einfachheit des Layouts, das gut für diejenigen mit kognitiven Defiziten funktioniert

2. Bedienbarkeit: Können Personen unabhängig von Behinderungen mit der Schnittstelle interagieren?

   • Nur-Tastatur-Zugriff: Navigation und Bedienung der Oberfläche ohne Maus
   • Nur-Sprachzugriff: Bedienung der Schnittstelle nur durch Spracheingabe

3. Verständlichkeit: Ist die Schnittstelle für Menschen unabhängig von Behinderungen leicht verständlich?

   • Der Inhalt ist für Personen mit kognitiven Beeinträchtigungen geschrieben.
   • Die Benutzeroberfläche wird von einer Person mit einer Sprachausgabe verstanden

4. Robustheit: Unterstützt die Schnittstelle eine Vielzahl von User Agents (Browser, Geräte und Hilfstechnologien)?

Wenn die WCAG-Kriterien erfüllt sind, sollten auch Webanwendungen und Websites alle gesetzlichen Anforderungen erfüllen.

Kosten der Barrierefreiheit

Es sollte beachtet werden, dass Barrierefreiheit beim Schreiben von Code niemals ein Nachdenken sein sollte. Obwohl der Entwicklungsprozess länger ist, ist es kostengünstiger, Barrierefreiheitsfunktionen während der Entwicklungsphase in den Code zu schreiben, als eine vorhandene Anwendung zu ändern.

Die Entwickler beklagen sich oft über die Notwendigkeit, die besonderen Anforderungen einer wohl kleinen Bevölkerung zu erfüllen. Bei richtiger Implementierung erleichtert der barrierefreie Code eine Anwendung für alle – nicht nur für die Behinderten. Durch die Vereinfachung der Benutzeroberfläche und durch die Auswahl von Farben mit höheren Kontrastverhältnissen sind Anwendungen auf mobilen Geräten oder älteren Browsern einfacher zu verwenden.

1, 2, 3 Schritte zum Erfolg

Die Barrierefreiheit beginnt in der Designphase. Designer erstellen eine Blaupause dessen, was das Programm tut. Sie sollten die Zugänglichkeit während des gesamten Designs weben, um sicherzustellen, dass der Plan effektive Mechaniken für den Nur-Tastatur-Zugriff enthält. Diese Art des Zugangs ermöglicht alternative Eingabegeräte für diejenigen mit begrenzten oder ohne Verwendung ihrer Hände.

Entwickler müssen sowohl über fundierte Kenntnisse im Umgang mit Code für Barrierefreiheit (Front-End) als auch über ein technisches Bewusstsein für das Testen der Barrierefreiheit (Back-End) verfügen.

Qualitätssicherungsingenieure (QA) müssen die Sprache der Zugänglichkeit sprechen. Sie müssen, wie Entwickler, Barrierefreiheitstests verstehen und durchführen sowie normale Tests auf Funktionalität und Sicherheit durchführen. Qualitätssicherungsfachleute sind der Puffer zwischen der freigegebenen Software und dem Potenzial für Rechtsstreitigkeiten, wenn die Richtlinien zur Barrierefreiheit nicht erfüllt werden.

Hinweise

Oracle JET steht der Öffentlichkeit für die Verwendung in Anwendungen und Websites außerhalb von Oracle zur Verfügung. Daher muss WCAG Version 2.2 beim Schreiben von Oracle JET-Anwendungen eingehalten werden.

Dieser Lernpfad konzentriert sich hauptsächlich auf die Aspekte der Barrierefreiheit, die für den Tastaturzugriff und die Verwendung durch das Bildschirmlesegerät gelten. Dieser Pfad konzentriert sich nicht auf die kognitiven Aspekte beim Entwerfen oder Erstellen einer Oracle JET-Anwendung.