Articles

Chapter 11: Software

May 21, 2019



Willkommen zu dieser Videoserie über Barrierefreiheitsanforderungen für die öffentliche Auftragsvergabe für IKT-Produkte und -Dienstleistungen in Europa der Norm EN 301 549. Das ist Video 11. Es wird von Microsoft gesponsert und von Funka produziert. Mein Name ist Susanna Laurin und ich bin eine Accessibility-Expertin mit langjähriger Erfahrung in der Standardisierung. In diesem Video schauen wir uns Kapitel 11 der Norm EN 301 549 an. Dieses Kapitel behandelt Software. Kapitel 11 basiert teilweise auf Web Content Accessibility Guidelines oder WCAG 2.0, die in Kapitel 9 der Norm erwähnt werden. In Video 9: 1 und 9: 2 haben wir WCAG detaillierter beschrieben. Wenn Sie diese Videos nicht gesehen haben, sollten Sie dies tun, bevor Sie sich dieses Video ansehen. Wenn Sie wissen, wie die Erfolgskriterien in WCAG aussehen, können Sie mit diesem Video fortfahren. Also, was bedeutet Software? Software bedeutet in diesem Zusammenhang: Plattformsoftware, Software, die eine Benutzeroberfläche bereitstellt, einschließlich Inhalte, die in der Software enthalten sind, Autorenwerkzeuge, und Software, die als assistierende Technologie arbeitet. Der erste Unterabschnitt in diesem Kapitel ist ein informativer, allgemeiner Abschnitt und definiert den Umfang des Kapitels. Es enthält keine Anforderungen an sich. Der zweite Unterabschnitt enthält Verweise darauf, wie WCAG 2.0 auf Software angewendet werden sollte. Der dritte Unterabschnitt behandelt die Interoperabilität mit assistiver Technologie. 11.4 ist eine dokumentierte Barrierefreiheitsnutzung, Und in Unterabschnitt fünf finden wir Benutzerpräferenzen. Der letzte Unterabschnitt von Kapitel 11 behandelt spezifische Anforderungen an Autorenwerkzeuge. 11.2 Nicht-Web-Software-Erfolgskriterien Dies ist ein großer Unterabschnitt. Es gibt Verweise auf alle Erfolgskriterien in der WCAG. Einige von ihnen gelten nicht für Nicht-Web-Software und enthalten daher keine Anforderungen. Die meisten Erfolgskriterien der WCAG sind jedoch für Nicht-Web-Software relevant. Für jedes dieser Erfolgskriterien gibt es einen kurzen Text mit Kommentaren zu den Unterschieden, wie man das Kriterium verwendet, wenn es um Nicht-Web-Software im Vergleich zu Webseiten geht. Wir werden hier nicht über einzelne Erfolgskriterien sprechen. Im EN-Standard gibt es Kommentare zu einigen der Erfolgskriterien, wie sie interpretiert werden sollten, wenn es um Nicht-Web-Software geht. Sie sollten diese Kommentare lesen. In diesem Video werden wir uns darauf konzentrieren, warum es einen Unterschied in allgemeineren Begriffen gibt. Web Content Accessibility Guidelines (WCAG) wurden für Webinhalte entwickelt, mit dem Ziel, technologieunabhängig zu sein. Dies macht die Richtlinien im Laufe der Zeit robuster, da neue Technologien durch die gleichen Richtlinien abgedeckt werden können. Und es bedeutet, dass sie für Technologie verwendet werden können, die kein Webinhalt ist. Da die WCAG nur angeben, wie die Schnittstelle funktionieren soll, nicht wie die Anforderungen erfüllt werden sollten, können Sie es für Nicht-Web-bezogene Anwendungen verwendet werden, wie Nicht-Web-Software. Schauen wir uns ein Beispiel an. In WCAG gibt es ein Erfolgskriterium: 1.4.1 Verwendung von Farbe. Dieses Kriterium besagt, dass "Farbe nicht das einzige visuelle Mittel ist, um Informationen zu übermitteln, eine Aktion anzeigen, eine Antwort einleiten oder ein visuelles Element zu unterscheiden." Das ist natürlich wichtig, wenn Sie eine Webseite haben, aber es ist ebenso wichtig für Nicht-Web-Software. Oder in Dokumenten oder ebenso bei gedruckten Informationen. Dies ist ein Beispiel für ein Erfolgskriterium in WCAG, das für Nicht-Websoftware ebenso relevant ist wie für Webinhalte. Wie wir die Anforderung erfüllen, kann je nach Situation, Lösung und Technologie variieren. In Video 5 sprachen wir über das Konzept der in-sich-geschlossenen Funktionalität. Wenn es um Nicht-Web-Software geht, gibt es einen wichtigen Unterschied, ob Ihre Software offene oder in-sich-geschlossene Funktionalität hat. In-sich-geschlossene Funktionalität bedeutet Software, bei der es nicht möglich ist, assistierende Technologie zu verwenden, zum Beispiel Software in Ticketautomaten. Wenn die Software keine in-sich-geschlossene Funktionalität hat, sollten Sie Unterabschnitt 11.2.1 verwenden. Wenn sie in-sich-geschlossen ist, sollten Sie stattdessen 11.2.2 verwenden. Der Hauptunterschied ist, dass Software mit offener Funktionalität eher mit Webinhalten verglichen werden kann als Software mit in-sich-geschlossenen Funktionen. Daher bezieht sich Software mit offener Funktionalität in Abschnitt 11.2.1 auf Kapitel 9 der EN-Norm, die auf den WCAG basiert, und die In-sich-geschlossene Funktionalität in 11.2.2 bezieht sich hauptsächlich auf Kapitel 5 der EN-Norm. Wenn Sie eine offene Funktionalität haben, müssen Sie die Schnittstelle so implementieren, dass es assistierende Technologien möglich ist, die Inhalte zu interpretieren und die Information dem Benutzer auszugeben. Wenn Sie die In-sich-geschlossene Funktionalität haben, müssen Sie auch die Funktionalität der assistierenden Technologie bereitstellen, was bedeutet, dass Sie mehr Möglichkeiten haben, wie Sie sicherstellen, dass Benutzer die relevanten Informationen erhalten. 11.2.1 Nicht-Web-Software-Erfolgskriterien (ohne in-sich-geschlossener Funktionalität). Wenn Sie Software ohne in-sich-geschlossener Funktionalität haben, sind die Anforderungen im Wesentlichen die gleichen wie für Webinhalte und Nicht-Webdokumente. Es gibt eine Handvoll von Erfolgskriterien, die für Nicht-Websoftware nicht relevant sind. Die meisten Anforderungen sind jedoch relevant. Wie Sie sie einhalten, mag sich unterscheiden, aber sie sollten sie einhalten. Manchmal können Sie ein höheres Niveau an Barrierefreiheit erreichen, wenn Sie Dienste verwenden, die von Plattformsoftware bereitgestellt werden. Es gibt Beispiele für Schnittstellen, bei denen assistive Technologie, das Betriebssystem und die Software miteinander interagieren und Informationen austauschen können. Eine Strategie, die oft recht gut funktioniert, ist die Verwendung standardisierter Komponenten in der Plattform, anstatt sie von Grund auf neu zu erfinden. Normalerweise hat jemand schon an Barrierefreiheit gedacht. Wenn Sie etwas völlig Neues machen wollen, können Sie das tun, aber Sie müssen sicherstellen, dass es durch assistierende Technologie gehandhabt werden kann. Und das erfordert eine Menge Tests und Entwicklung. 11.2.2 Nicht-Web-Softwareanforderungen (in-sich-geschlossene Funktionalität) Um die Nummerierung der Anforderungen in der EN 301 549 mit der WCAG 2.0 in Einklang zu bringen, enthält die EN 301 549 leere Teile, bei denen ein Erfolgskriterium vorliegt, für Punkte in Kapitel 9, das für Nicht-Web-Software nicht relevant ist. Zum Beispiel sind Anforderungen an Überschriften und Labels, Linkzweck und Fokusreihenfolge sehr spezifische Anforderungen an Webinterfaces. Insgesamt gibt es hier 26 leere Teile. Das mag seltsam erscheinen, aber in Wirklichkeit gibt es mehr Anforderungen für diese Art von Software, da die Nutzerbedürfnisse auf andere als die in der WCAG genannten Weise abgedeckt werden müssen. In Unterabschnitt 5.1 der EN-Norm gibt es eine Reihe von Anforderungen für IKT mit in-sich-geschlossener Funktionalität. In vielen Fällen kann ein Teil der Lösung für Software mit in-scih-geschlossener Funktionalität eher mit Hardware als mit Software erfüllt werden. Es gibt 13 Anforderungen in EN 301 549 in diesem Unterabschnitt, sie verweisen auf Anforderungen, die Sie in Kapitel 5 der Norm finden. Bitte werfen Sie einen Blick auf Video 5 dieser Serie für weitere Details. Es gibt zwei Anforderungen, die erwähnenswert sind, da es schwierig sein kann zu sehen, wie sie zusammenspielen. Diese beiden Anforderungen können zusammen betrachtet werden, weil sie interagieren. 11.2.2.7 Informationen und Beziehungen, die auf WCAG 2.0 Erfolgskriterium 1.3.1 basieren (Info und Beziehungen), und 11.2.2.8 Bedeutungstragende Reihenfolge, die auf WCAG 2.0 Erfolgskriterium 1.3.2 Bedeutungstragende Reihenfolge basiert. Wenn die IKT für Screenreader keine Informationen bereitsstellt und es visuelle Informationen auf dem Bildschirm gibt, sollte sie Informationen über Audio bereitstellen, die es dem Nutzer ermöglichen, die Beziehung zwischen den Audioinformationen und den auf dem Bildschirm angezeigten Informationen zu verstehen. Beispiele für akustische Informationen, die es dem Benutzer ermöglichen, die Audioinformationen mit den Informationen auf dem Bildschirm in Verbindung zu bringen, enthalten Informationen Struktur, Navigation und dergleichen. Das Ziel dieser Anforderungen ist es, sicherzustellen, dass die Benutzer alle relevanten Informationen in einer sinnvollen Reihenfolge erhalten, aber auch, dass es eine Verbindung zwischen den visuellen und auditiven Informationen geben soll. Das visuelle Objekt, das mit Sound beschrieben wird, sollte auch visuell hervorgehoben werden und Benutzer sollten Informationen über visuelle Beziehungen erhalten, z.B. "Wählen Sie Ja oder Nein, indem Sie eine der beiden folgenden Tasten drücken". 11.3 Interoperabilität mit assistiver Technologie Dieser Unterabschnitt umfasst Anforderungen, um sicherzustellen, dass Software mit assistierenden Technologien gut zusammenarbeitet. Beachten Sie, dass ICT mit in-sich-geschlossener Funktionalität von Software, die mit Unterabschnitt 5.1 konform ist, (In-sich-geschlossene Funktionalität) nicht den Anforderungen in 11.3 entsprechen muss. Für andere Software enthält Unterabschnitt 11.3 17 Anforderungen. Wir werden nicht detailliert auf diese 17 Anforderungen eingehen, aber wenn Sie Software haben, müssen Sie diesen Unterabschnitt durschauen, um die Anforderungen zu identifizieren, die für Ihre Situation relevant sind. Sie finden zum Beispiel Anforderungen für Plattform-Software, wie Betriebssysteme, und Anforderungen an assistierende Technologie. Der EN-Standard bietet die gängigen Anforderungen für Betriebssysteme, alle Mainstream-Betriebssysteme haben jedoch spezifischere API-Anforderungen für die Barrierefreiheit. Wir empfehlen Ihnen, sich zu informieren, wie Sie diese APIs direkt von den Entwicklern des Betriebssystems verwenden können. "11.4 Dokumentierte Barrierefreiheitsnutzung" ist ein kleiner Unterabschnitt, der nur aus 2 Anforderungen besteht. 11.4.1 Benutzersteuerung von Eingabehilfen. Wenn die Software eine Plattform ist (wie ein mobiles Betriebssystem), müssen Sie sicherstellen, dass der Benutzer die Barrierefreiheitsfunktionen Ihrer Plattform steuern kann. 11.4.2 Keine Störung von Eingabehilfen. Wenn die Software über eine Benutzeroberfläche verfügt, darf sie die Eingabehilfsfunktionen nicht beeinträchtigen, es sei denn, der Benutzer möchte dies. 11.5 Benutzereinstellungen Wenn die Software über eine Benutzeroberfläche verfügt, muss der Benutzer in der Lage sein, individuelle Einstellungen für Farbe, Kontrast, Schriftart, Schriftgröße und Cursor einzustellen. Wenn die Software von der zugrunde liegenden Plattform unabhängig ist, hat sie keinen Zugriff auf Benutzereinstellungen auf der Plattform. In diesem Fall kann diese Anforderung nicht erfüllt werden. Der letzte Unterabschnitt, 11.6 Autorenwerkzeuge, richtet sich an Software, die Funktionen zum Erstellen, Bearbeiten und Verwalten von Inhalten enthält. Ein Content-Management-System ist also ein Authoring-Tool. Ein Texteditor ist ein anderes Beispiel. Dieser Unterabschnitt besteht aus 5 Anforderungen. 11.6.1 Inhaltsbezogene Technologie Autorenwerkzeuge müssen die Anforderungen der Unterabschnitte 11.6.2 bis 11.6.5 erfüllen, wenn es um die Ausgabe geht. Dies sind Mindestanforderungen. Versuchen Sie es dem Benutzer leicht zu machen, zugänglichen Inhalt zu erstellen. 11.6.2 Zugängliche Inhaltserstellung Autorenwerkzeuge müssen es ermöglichen, Inhalte zu produzieren, die den Klauseln 9 (Webinhalt) oder 10 (Nicht-Webinhalt) entsprechen. Autorentools können manchmal zusätzliche Tools für bestimmte Aufgaben verwenden. Beispielsweise kann ein Videobearbeitungstool die Erstellung von Videodateien für die Verbreitung über TV und das Internet ermöglichen, aber die Untertiteldateien für mehrere Formate können jedoch von einem anderen Tool bereitgestellt werden. 11.6.3 Erhalt von Barrierefreiheitsinformationen in Umwandlungen Wenn das Authoring-Tool es ermöglicht, den Inhalt neu zu strukturieren oder umzuwandeln, z.B. durch das Erstellen von Tabellen in lineare Informationen oder das Aufteilen von Dokumenten auf Seiten, sollen die Barrierefreiheitsinformationen erhalten bleiben. 11.6.4 Reparaturhilfe Wenn das Authoring-Tool eine Funktion zum Überprüfen der Barrierefreiheit hat, und diese Funktion erkennen kann, dass der Inhalt eine Anforderung von Kapitel 9 (Webinhalt) oder 10 (Dokumente), nicht erfüllt, sollte das Tool eine Lösung bieten. Bei einigen rein technischen Barrierefreiheitsproblemen kann das Werkzeug automatische oder halbautomatische Reparaturen durchführen. 11.6.5 Vorlagen Wenn das Authoring-Tool Vorlagen bereitstellt, die die Erstellung von Inhalten unterstützen, muss es mindestens einer der Anforderungen des Kapitels 9 (Webinhalt) oder 10 (Dokumente) entsprechen. Die Vorlage sollte als barrierefrei gekennzeichnet sein. Denken Sie daran, Software ist wichtig! Kapitel 11 ist groß und ziemlich komplex. Dies liegt daran, dass es sehr unterschiedliche Bedingungen für Software geben kann, und der Standard versucht, sicherzustellen, dass, was auch immer die Bedingungen sind, die Entwickler ihr Bestes tun, um Benutzern mit oder ohne Behinderungen zu helfen. Wenn Sie mehr wissen möchten, schauen Sie sich unsere anderen Videos an. Es gibt ein Video für jedes Kapitel in der Norm. Danke fürs Zuschauen! Deutsche Untertitel bereitgestellt durch die Hilfsgemeinschaft der Blinden und Sehschwachen Österreichs. Lokaler Partner in Deutschland ist die Bundesfachstelle Barrierefreiheit.

You Might Also Like

No Comments

Leave a Reply