Barrierefreie Softwareentwicklung nach der europäischen Norm EN 301 549

In diesem Artikel erkläre dass nach der europäischen Norm EN 301 549 auch Software barrierefrei entwickelt werden kann und warum ich von der EN 301 549 nicht begeistert bin, wenn es um barrierefreie Softwareentwicklung geht.

Barrierefreie Softwareentwicklung: Definition

Barrierefreie Softwareentwicklung bedeutet, dass eine Software so gestaltet ist, dass sie von allen Menschen, auch Menschen mit Behinderungen und anderen körperlichen Einschränkungen, wahrgenommen und bedient werden kann.

Barrierefreie Softwareentwicklung – Wer ist die Zielgruppe?

Der Hauptgrund warum es barrierefreie Softwareentwicklung gibt, sind Menschen mit Behinderungen. Senioren profitieren ebenso von barrierefreie Softwareentwicklung. Es gibt auch Menschen die vorübergehend körperlich eingeschränkt sind. Zum Beispiel, wenn jemand die rechte Hand im Gips hat, auch dieses Menschen profitieren von barrierefreie Softwareentwicklung.

Harmonisierter europäischer Standard Zugänglichkeitsanforderungen für ICT-Produkte und -Dienstleistungen


ETSI – Harmonisierter europäischer Standard Zugänglichkeitsanforderungen für ICT-Produkte und -Dienstleistungen

Wer oder was ist BIK?

Das Zeichen BIK steht für ‚barrierefrei informieren und kommunizieren‘. Ziel der unter dem BIK-Zeichen tätigen Initiativen und Projekte ist, durch die Entwicklung, Verbreitung und Anwendung von Testverfahren zu barrierefreiem Webdesign beizutragen. Der BIK BITV-Test ist ein Verfahren für die umfassende und zuverlässige Prüfung der Barrierefreiheit von Websites und Webanwendungen. Der BITV-Softwaretest von BIT inklusiv.

Der BIK BITV-Test

Der BIK-BITV-Test ist ein Name. Unter diesem Namen wurde jetzt ein Prüfverfahren für die Accessibility requirements for ICT products and services bei Software veröffentlicht. Dieses Prüfverfahren hat den Vorteil, dass es die einzelnen Prüfschritte des Standards EN 301 549 in deutscher Sprache erklärt werden.
Um mein Anliegen nochmal deutlich auf den Punkt zu bringen:
Wenn Sie eine Software nach BIK BITV-Test auf Barrierefreiheit überprüfen, hat das nichts mit der deutschen Richtlinie BITV 2.0 zu tun, sondern es ist ein Name. BIT inklusiv hat jetzt die europäische Norm in deutscher Sprache veröffentlicht. Sie können eine Software mit BIK BITV-Test auf Barrierefreiheit nach der europäischen Norm EN 301 549 überprüfen.

Ich habe mich so gefreut …

Als ich erfahren habe, dass es in absehbarer Zeit für barrierefreie Softwareentwicklung eine europäische Norm gibt, habe ich mich riesig gefreut.
Leider haben die „Erfinder“ dieser europäischen Norm den maximalen Unsinn gemacht. Sie haben die Richtlinien für barrierefreies Webdesign auf barrierefreie Softwareentwicklung umgebogen. Die Gleichung Webseite = Software ist einfach Unsinn.

Software-Entwickler die mit Java, C# und Python barrierefreie Software entwickeln möchten bekommen keine Anleitung

Der Sinn von Richtlinien ist nicht dem Informatiker einfach Vorschriften zu machen, sondern ihm die Richtlinien zu erklären und konkrete Handlungshinweise geben, wie die einzelnen Prüfschritte umgesetzt werden sollen. Software-Entwickler die mit den Programmiersprachen Java, C# und Python barrierefreie Software entwickeln möchten, bekommen mit der europäischen Norm EN 301 549 keine Anleitung wie die Prüfschritte mit der jeweiligen Programmiersprache umzusetzen sind.

Die europäische Norm EN 301 549 ist nur für Web-Anwendungen

Folgende Prüfschritte machen es offensichtlich, dass die europäische Norm nur für Web-Anwendungen ist:
4.1.1 Korrekte Syntax
Java-, C#-und Python-Entwickler reiben sich verwundert die Augen!
Bei allen 3 Programmiersprachen ist es so, dass wenn der Programmcode Syntax-Fehler hat,  der Compiler meckert und das Programm nicht startet. Deswegen macht dieser Prüfschritt für Desktop-Anwendungen überhaupt kein Sinn.

Ein zweites Beispiel:
3.1.1 Hauptsprache angegeben
Ist bei der Entwicklung von Desktop-Anwendungen Unsinn. Habe ich bei Java-, C# und Python-Programmen noch nie gemacht und meine Programmoberflächen wurden immer richtig von Screenreader vorgelesen.

Ein drittes Beispiel:
1.4.4 Textgröße ändern
Zunächst klingt das für Menschen mit Sehbehinderung sehr sinnvoll. Aber, wie meine Blogleser wissen, können Menschen mit einer Sehbehinderung die Schriftgröße im Betriebssystem ändern. Somit ist nicht notwendig, dass die Textgröße in der Software anpassbar ist.
Ein Prüfschritt Farbe ändern fehlt. Menschen mit einer Farbfehlsichtigkeit haben als nicht das Recht eine Software auf Ihre Bedürfnisse anzupassen.
Bei einer Web-Anwendung im Browser die Textgröße anpassen, macht jedoch Sinn!
Des Weiteren fehlt die Übernahme von Einstellungen im Betriebssystem, wie zum Beispiel Schriftgröße oder hoher Farbkontrast.

Weitere Probleme mit barrierefreier Softwareentwicklung nach der EN 301 549

Weltunternehmen wie Oracle und Microsoft, die Entwickler von Programmiersprachen sind, haben Richtlinien zur barrierefreien Softwareentwicklung erstellt:

Mein Problem:
Warum richtet sich eine europäische Norm nicht nach Richtlinien von Weltunternehmen in Sachen barrierefreie Softwareentwicklung?
Das, was hier gemacht wurde, ist einfach weit weg von der beruflichen Praxis der Software-Entwickler. Deswegen mache ich hier nur eine Auflistung der Prüfschritte der europäischen Norm für barrierefreie Softwareentwicklung ohne Erklärung.

Barrierefreie Softwareentwicklung: Alle Prüfungsschritte der europäischen Norm EN 301 549

Hier liste ich alle Prüfungsschritte der europäischen Norm EN 301 549 auf.

Wahrnehmbarkeit

  • 1.1.1 Nicht-Text-Inhalte
  • 1.2.1 Alternativen für Audiodateien und stumme Videos (aufgezeichnet)
  • 1.2.2 Untertitel für Videos (aufgezeichnet)
  • 1.2.3 Audiodeskription oder Volltext-Alternative für Videos
  • 1.2.4 Videos (live) mit Untertiteln
  • 1.2.5 Audiodeskription für Videos (aufgezeichnet)
  • 1.3.1 Info und Beziehungen
  • 1.3.2 Sinnvolle Reihenfolge
  • 1.3.3 Sensorische Merkmale
  • 1.3.4 Ausrichtung
  • 1.3.5 Eingabezweck bestimmen
  • 1.4.1 Nutzung von Farbe
  • 1.4.2 Audio-Steuerung
  • 1.4.3 Kontraste von Texten
  • 1.4.4 Textgröße ändern
  • 1.4.5 Schriftgrafiken
  • 1.4.10 Umbruch der Inhalte
  • 1.4.11 Nicht-Text Kontrast
  • 1.4.12 Textabstand anpassbar
  • 1.4.13 Eingeblendete Inhalte

Bedienbarkeit

  • 2.1.1 Ohne Maus nutzbar
  • 2.1.2 Keine Tastaturfalle
  • 2.1.4 Tastatur-Kurzbefehle abschaltbar oder anpassbar
  • 2.2.1 Zeitbegrenzungen anpassbar
  • 2.2.2 Bewegte Inhalte abschaltbar
  • 2.3.1 Verzicht auf Flackern
  • 2.4.3 Schlüssige Reihenfolge bei der Tastaturbedienung
  • 2.4.4 Aussagekräftige Linktexte
  • 2.4.6 Aussagekräftige Überschriften und Beschriftungen
  • 2.4.7 Fokus sichtbar
  • 2.5.1 Zeigergesten (Alternativen für komplexe Zeiger-Gesten)
  • 2.5.2 Zeigerabbruch
  • 2.5.3 Sichtbare Beschriftung Teil des zugänglichen Namens
  • 2.5.4 Alternativen für Bewegungsaktivierung

Verständlichkeit

  • 3.1.1 Hauptsprache angegeben
  • 3.2.1 Kontextänderung bei Fokus
  • 3.2.2 Kontextänderung bei Eingabe
  • 3.3.1 Fehlererkennung
  • 3.3.2 Beschriftungen oder Anweisungen
  • 3.3.3 Fehlerbehebung
  • 3.3.4 Fehlervermeidung (rechtlich, finanziell, Daten)

Robustheit

  • 4.1.1 Korrekte Syntax
  • 4.1.2 Name, Rolle, Wert verfügbar
  • 4.1.3 Statusmeldungen programmatisch verfügbar

Interoperabilität mit assistiven Technologien

  • 5.1 Assistenztechnologien (geschlossene Funktionalität)
  • 5.2.1 Plattformunterstützung von Barrierefreiheitsdiensten für Software mit einer Benutzungsschnittstelle
  • 5.2.2 Plattformunterstützung von Barrierefreiheitsdiensten für Assistenztechnologien
  • 5.2.3 Verwendung von Barrierefreiheitsdiensten
  • 5.2.4 Assistenztechnologie
  • 5.2.5 Objektinformationen
  • 5.2.6 Zeile, Spalte und Kopfzeilen
  • 5.2.7 Werte
  • 5.2.8 Label-Beziehungen
  • 5.2.9 Eltern-Kind-Beziehungen
  • 5.2.10 Text
  • 5.2.11 Liste der verfügbaren Handlungen
  • 5.2.12 Ausführung verfügbarer Handlungen
  • 5.2.13 Verfolgung von Fokus- und Auswahlattributen
  • 5.2.14 Änderung der Fokus- und Auswahlattribute
  • 5.2.15 Änderungsbenachrichtigung
  • 5.2.16 Änderungen von Zuständen und Eigenschaften
  • 5.2.17 Änderungen von Werten und Text

Dokumentierte Nutzung

  • 6.1 Benutzersteuerung der Barrierefunktionen
  • 6.2 Keine Unterbrechung der Barrierefunktionen

Benutzerpräferenzen

  • 7. Benutzerpräferenzen

Autorenwerkzeuge

    • 8.1 Inhaltstechnologie
    • 8.2 Erstellung barrierefreier Inhalte
    • 8.3 Aufbewahrung von Informationen zur Barrierefreiheit bei Transformationen
    • 8.4 Reparaturhilfe
    • 8.5 Vorlagen

Web-Anwendungen können nach EN 301 549 barrierefrei entwickelt werden, Desktop-Anwendungen NICHT!

Die Richtlinien sind für Web-Anwendungen geeignet.
Die Richtlinien sind für Desktop-Anwendungen mangelhaft , weil bestimmte Kriterien fehlen.
Die Richtlinien erklären viel zu wenig für Software-Entwickler,  die keine Erfahrung mit behinderten Menschen haben.

Die Europäische Norm EN 301 549 als PDF-Datei: barrierefreies Webdesign, barrierefreie Softwareentwicklung, Barrierefreiheit bei Hardware

Die ganzen Richtlinien, barrierefreies Webdesign, Barrierefreiheit bei Software und Hardware finden Sie in englischer Sprache in dieser PDF-Datei:
EN 301 549 V3.1.1 (2019-11) HARMONISED EUROPEAN STANDARD Accessibility requirements for ICT products and services

Ausblick

Die barrierefreie Softwareentwicklung für Desktop-Anwendungen ist der Schwerpunkt meines Unternehmens. Deswegen habe ich beschlossen, dass Marlem-Software jetzt Richtlinien für barrierefreie Softwareentwicklung für Desktop-Anwendungen erstellen wird. Die Richtlinien werden eine Art BestOf Oracle, Microsoft, EN 301 549 und Markus Lemcke werden.

Schlussbemerkung

Meine große Hoffnung, dass es für barrierefreie Softwareentwicklung eine europäische Norm gibt, nach der Desktop-Anwendungen barrierefrei entwickelt werden können, wurde nicht erfüllt. Was aber für mich noch viel Schlimmer ist, dass mir bei der ganzen europäischen Norm EN 301 549 ein durchgängiges, schlüssiges Konzept fehlt.

Wenn Sie fragen zu obige Themen haben, schreiben Sie mir eine Mail an info@marlem-software.de oder rufen Sie mich an unter 07072/1278463 .


Autor: Markus Lemcke

Ich bin Markus Lemcke, Softwareentwickler, Webentwickler, Appentwickler, Berater und Dozent für barrierefreies Webdesign, barrierefreie Softwareentwicklung mit Java, C# und Python, Barrierefreiheit bei den Betriebssystemen Windows, Android, IOS, Ubuntu und MacOS.

Schreibe einen Kommentar