Barrierefreies Webdesign – Richtlinien und Gesetze in der Schweiz

In Zukunft möchte ich als Unternehmer auch barrierefreies Webdesign für die Schweiz anbieten. Deswegen beschäftige ich mich in diesem Blogartikel mit den Gesetzen und Richtlinien für barrierefreies Webdesign für die Schweiz.

Barrierefreies Webdesign – Was ist das?

Barrierefreiheit bedeutet ohne Hindernisse. Barrierefreiheit gibt es bei Gebäuden, auf der Straße oder in der EDV. Barrierefreiheit in der EDV bedeutet, dass Websites und Software barrierefreier gestaltet sind, dass Menschen mit unterschiedlichen Einschränkungen die Webseite / Software bedienen können.

„Barrierefreies Webdesign – Richtlinien und Gesetze in der Schweiz“ weiterlesen

Barrierefreies Webdesign – Richtlinien und Gesetze in Österreich

Weil ich auch schon einen Kunden aus Österreich hatte für den ich eine barrierefreie Webseite mit WordPress erstellte, schreibe ich heute über barrierefreies Webdesign aus bzw. in Österreich. Außerdem würde ich mich über noch mehr Aufträge aus Österreich freuen.

Barrierefreies Webdesign – Was ist das?

Barrierefreiheit bedeutet ohne Hindernisse. Barrierefreiheit gibt es bei Gebäuden, auf der Straße oder in der EDV. Barrierefreiheit in der EDV bedeutet, dass Websites und Software barrierefreier gestaltet sind, dass Menschen mit unterschiedlichen Einschränkungen die Webseite / Software bedienen können.

„Barrierefreies Webdesign – Richtlinien und Gesetze in Österreich“ weiterlesen

Richtlinien für barrierefreies Webdesign

In diesem Artikel möchte ich erklären warum es Richtlinien zu barrierefreies Webdesign gibt und welche!

Barrierefreies Webdesign bedeutet, dass Webseiten keine Barrieren enthalten für Menschen mit unterschiedlichen Einschränkungen oder Behinderungen.

Warum gibt es Richtlinien für barrierefreies Webdesign?

Damit eine Webseite barrierefrei ist, muss sie bestimmte Kriterien erfüllen. Diese Kriterien richten sich danach, welche Behinderungsart welche Probleme im Umgang mit Internetseiten hat. Ziel der Richtlinien ist es, dass möglichst viele Behinderungsarten und andere Einschränkungen berücksichtigt werden. Das Internet soll für alle Mensche zugänglich und wahrnehmbar sein. Deswegen gibt es Richtlinien für barrierefreies Webdesign. Es gibt Internationale und nationale Richtlinien für barrierefreies Webdesign.

Barrierefreies Webdesign – Internationale Richtlinien – WCAG 2.0

Die WCAG 2.0 sind die Internationalen Richtlinien für barrierefreies Webdesign.
Somit wurde barrierefreies Webdesign internationaler Standard. WCAG 2.0 Richtlinien wurden am 11. Dezember 2008 veröffentlicht.
Die Richtlinien sind in 4 Prinzipien gruppiert:

  • Wahrnehmbar (z.B. visuelle Inhalten brauchen eine Textalternative)
  • Bedienbar (insbesondere Tastaturbedienung)
  • Verständlich
  • Robust (Kompatibilität)

Hier der Link: Barrierefreies Webdesign mit der Richtlinie WCAG 2.0

Barrierefreies Webdesign – deutsche Richtlinien – die BITV 2.0

Die BITV 2.0 sind die nationalen Richtlinien für barrierefreies Webdesign. Die Richtlinien der BITV 2.0 wurden abgeleitet von den Richtlinien der WCAG 2.0 für barrierefreies Webdesign. Somit gibt es auch hier die oben genannten Prinzipien.
Hier der Link: Barrierefreies Webdesign mit der BITV 2.0

Welche Richtlinie kommt wann zur Anwendung?

Nun stellt sich vielleicht der Leser die Frage: Welche Richtlinie benötige ich wann?
Wenn Sie eine deutsche Webseite barrierefrei machen möchten, verwenden Sie die deutsche Richtlinien der BITV 2.0. Möchten Sie eine Webseite aus dem Ausland barrierefrei machen in dem es keine nationalen Richtlinien gibt, dann verwenden Sie die WCAG 2.0.

Richtlinien zur barrierefreien Software-Entwicklung für Java von IBM

In diesem Blogartikel werden die Richtlinien zur barrierefreien Software-Entwicklung für Java von IBM wiedergeben. Und erklärt. Es handelt sich hierbei um die Version 3.6 .
 

1. Tastaturbedienbarkeit

1.1 Alle Softwarefunktionen müssen auch ohne Maus, also nur per Tastatur ausführbar sein

Erklärung:
Blinde und einige Sehbehinderte können keine Maus bedienen, weil zum positionieren des Mauszeigers die Fähigkeit zu sehen unbedingt notwendig ist. Deswegen bedienen diese Menschen den kompletten Computer mit der Tastatur. Dies kann nur geschehen, wenn auch die Software komplett per Tastatur bedienbar ist.
Ein zweiter Grund ist, dass es Menschen mit einer starken Einschränkung an der Hand gibt, für die es nicht möglich ist eine Computermaus zu bedienen, sehr wohl aber eine Tastatur.

1.2 Es darf keine Konflikte geben zwischen Ihrer Software und der Tastatureingabehilfen des Betriebssystems

Erklärung:
Im Betriebssystem Windows gibt es Eingabehilfen für behinderte Menschen. Diese helfen zum Beispiel mehrere Tasten gleichzeitig mit einer Hand zu drücken oder die Drucksensibilität von Tasten zu verändern. Zwischen diesen Eingabehilfen und Ihrer Software darf es keine Konflikte geben. Sie dürfen in Ihrer Software keine Tastenkürzel verwenden die vom Betriebssystem für Eingabehilfen (http://www.marlem-software.de/marlemblog/2010/12/28/was-sind-eingabehilfen/ ) reserviert sind.

 

2. Informationen über Objekte

2.1 Bieten Sie eine optische Fokusanzeige an, die den Änderungen des Eingabefokus zwischen den interaktiven Objekten folgt. Diese Fokusanzeige muß programmtechnisch für die assistive Technik zugänglich sein.

Erklärung:
Sehbehinderte haben oft Probleme zu erkennen welches Bedienelement gerade den Fokus hat. Deswegen sollten Sie dafür sorgen, dass der Fokus gut sichtbar ist. Desweiteren muss gewährleistet sein, dass der Screenreader ( http://www.marlem-software.de/marlemblog/2010/02/09/was-ist-ein-screenreader/ ) die Position des Fokus kennt.

2.2 Liefern Sie semantische Informationen über Objekte der Benutzerschnittstelle. Wenn ein Programmelement aus einem Bild besteht, dann muss die Information, die durch das Bild transportiert wird, auch als Text verfügbar sein.

Erklärung:
Der Screenreader von Blinden benötigt Informationen welches Objekt den Fokus hat und welche „Rolle“ das Objekt hat. Der Screenreader muss zum Beispiel wissen, dass ein Optionsfeld aktiv ist und welche „Option“ ausgewählt ist.

2.3 Beschriften Sie Bedienelemente, Objekte, Icons und Bilder. Wenn ein Bild zur Kennzeichnung von Programmelementen benutzt wird, muss die Bedeutung des Bildes in der gesamten Applikation einheitlich sein.

Erklärung:
Für Screenreader ist es wichtig, dass Objekte wie z. B. Icon-Name, Fenstertitel oder Eingabefelder Beschriftungen haben. Damit diese Beschriftungen für Screenreader und andere Eingabehilfen verfügbar sind, müssen Sie programmtechnisch mit einem Objekt verbunden sein. Ansonsten bekommt der Screenreader Probleme bei der Zuordnung von Objekten und Beschriftungen.

2.4 Wenn elektronische Formulare in der Software benutzt werden, sollten die Formulare den Menschen, die assistive Technik benutzen, erlauben, auf die Informationen, Feldelemente und Funktionen zuzugreifen, die zum Ausfüllen und zur Abgabe des Formulars, einschließlich aller Anweisungen und Hinweise, notwendig sind.

Erklärung:
Elektronische Formulare müssen für Screenreader zugänglich sein. Hierfür ist es wichtig, dass die Formulare und Bedienelemente sachgerecht Kodiert werden.

 

3. Sound und Multimedia

3.1 Bieten Sie eine Option, um Audio-Warnmeldungen visuell anzuzeigen.

Erklärung:
Gehörlose Menschen können Töne gar nicht wahrnehmen und schwerhörige Menschen nur sehr begrenzt. Damit diese Personen Töne(Informations- oder Warnsignale) wahrnehmen können müssen diese visuell durch ein Meldungsfenster oder einer Statusinformation angezeigt werden.

3.2 Bieten Sie zugängliche Alternativen für wichtige Audio- und Videosequenzen.

Erklärung:
Für Gehörlose und Schwerhörige sind Hörbeiträge (=Audio) oder Videos mit Ton nicht wahrnehmbar. Deswegen sollte in einer Software immer eine Alternative zur Audio oder Videowiedergabe geben. Am besten eignet sich hierfür Text der bei Videos auch in Form eines Untertitels bereitgestellt werden.

3.3 Bieten Sie eine Option zum Einstellen der Lautstärke

Erklärung:
Schwerhörige müssen den Ton lauter stellen wie nicht Schwerhörige. Blinde und Sehbehinderte sind auf Audiowiedergabe angewiesen und müssen deswegen die Lautstärke regulieren können um andere Geräusche im Umfeld übertönen zu können.

 

4 Anzeige

4.1 Erzeugen Sie Text durch normale Systemfunktionsaufrufe oder einer API (Schnittstelle für Anwendungsprogrammierung), die die Interaktion mit assistiver Technik unterstützen.

Erklärung:
Screenreader können nur systemgestützte Zeichenoperationen wahrnehmen. Wenn Text nicht standardmäßig dargestellt wird, kann der Screenreader diese Informationen nicht an den Benutzer weitergeben.

4.2 Benutzen Sie Farbe als eine Ergänzung und nicht ausschließlich, um Informationen zu übermitteln oder Aktionen anzuzeigen.

Erklärung:
Grundsätzlich kann Farbe ein wichtiges Hilfsmittel sein um Informationen besser darzustellen. Sie sollten es vermeiden Farbe als wesentliches Merkmal einzusetzen. Menschen mit einer Farbfehlsichtigkeit ( http://de.wikipedia.org/wiki/Farbfehlsichtigkeit )haben große Probleme Farben zu erkennen und zu unterscheiden. Es ist zum Beispiel nicht sinnvoll einen Benutzer dazu aufzufordern einen „grünen“ Schalter anzuklicken wenn dieser grün und braun nicht unterscheiden kann. Deswegen sollten Sie den Schalter beschriften mit „Übernehmen“.

4.3 Unterstützen Sie Einstellungen für starken Kontrast für alle Bedienelemente des Benutzerinterfaces und Client-Bereiches.

Erklärung:
Die Verwendung von bestimmten Farben ist oft kritisch. Farbfehlsichtige und Sehbehinderte können damit ein Problem haben. Sie benötigen einen hohen Kontrast zwischen Hintergrundfarbe und Schriftfarbe. Im Betriebssystem Windows in der Systemsteurung kann der Farbkontrast eingestellt werden. Deswegen muss eine Software in der Lage sein, diese Farbeinstellungen zu übernehmen, sonst hilft es der oben genannten Personengruppe nicht, dass der Kontrast im Betriebssystem anpasspar ist.

4.4 Wenn kundenspezifische Farbanpassung durch das Programm unterstützt wird, bieten Sie vielfältige Farbeinstellungsmöglichkeiten, damit mehrere Kontrastniveaus erzeugt werden können.

Erklärung:
Farbfehlsichtigkeit und Sehbinderungen können sich sehr unterschiedlich auswirken. Deswegen sollten die Möglichkeiten der Farbeinstellungen sehr individuell gehalten werden.

4.5 Übernehmen Sie die Systemeinstellungen für Schriftart, Größe und Farbe für alle Steuerelemente der Benutzerschnittstelle.

Erklärung:
Menschen mit einer Sehbehinderung benötigen eine größere Schrift. Im Betriebssystem Windows kann die Systemschriftgröße eingestellt werden. Deswegen sollten Beschriftungen von Eingabefelder und Schalter und die Eingabefelder selbst diese Schriftgröße übernehmen.

4.6 Bieten Sie eine Option an, die Animationen in einer nicht animierten Form darstellt.

Erklärung:
Animierte Informationen sind für Blinde nicht wahrnehmbar. Stellen Sie sicher, dass Animationen angehalten werden können. Desweiteren sollten Sie die in der Animation übermitteten Informationen alternativ, zum Beispiel als Text, bereitstellen.

 

5 Timing

5.1 Bieten Sie die Möglichkeit, die Reaktionszeit auf zeitlich begrenzte Hinweise einzustellen oder ermöglichen Sie den Verbleib des Hinweises.

Erklärung:
Menschen die eine Einschränkung in der Bewegung der Arme oder Hände haben, können oft nur sehr langsam auf Ereignisse oder Hinweise reagieren. Deswegen sollte die Zeitspanne, wie lange ein Hinweis angezeigt wird, einstellbar sein.

5.2 Verwenden Sie keine leuchtende oder blinkende Texte, Objekte oder andere Elemente mit einem Blitz oder blink Frequenz größer als 2 Hz und kleiner als 55 Hz.

Erklärung:
Anzeigen, die flackern oder blinken, können bei empfänglichen Menschen epileptische Anfälle auslösen, besonders wenn das Blinken eine hohe Intensität in einem Frequenzbereich zwischen 2 Hz und 55 Hz hat. Das schließt blinkenden Text, das Ein- und Ausschalten von Grafik oder das Wechseln zwischen unterschiedlichen Bildern ein.

Das sind die Richtlinien zur barrierefreien Software-Entwicklung für Java von IBM.

Richtlinien barrierefreie Software-Entwicklung für Java von Oracle

Da ich gerade einen großen Auftrag habe bei dem ich eine Java-Software barrierefrei machen darf, werde ich heute die Richtlinien von Oracle, die ich ins deutsche übersetzt habe wiedergeben.

Um barrierefreie Software-Entwicklung mit Java zu machen bedarf es Richtlinien. Diese Richtlinien orientieren sich an den Bedürfnissen von Menschen mit Behinderungen. Das Unternehmen Oracle hat die Programmiersprache Java entwickelt. Da Java die Voraussetzungen hat für barrierefreie Software-Entwicklung hat Oracle hierfür Richtlinien herausgegeben. Diese Richtlinien werde ich hier wiedergeben mit Erklärung:

1. Kriterium:
Wenn eine Komponente keinen ‘short string’ anzeigt, dann legen Sie einen Namen mit der setAccessibleName Methode fest. Sie können das auf ‚image-only buttons’, ‚panels’ mit logischer Gruppierung, Text Felder usw. Anwenden.

Erklärung:
Es kann grundsätzlich nichts schaden jeder Komponente einen AccessibleName zu geben. Der AccessibleName soll den Zweck der Komponente kurz beschreiben.
Zum Beispiel „Beenden-Schalter“. Auf jeden Fall sollte man, wann immer es geht und Sinn macht, Tooltips bei Komponenten angeben. Wie oben beschrieben werden die Tooltips auch in die Eigenschaft AccessibleDescription eingetragen.

2. Kriterium:
Wenn Sie eine Komponente nicht mit einem ‘tooltip’ versehen wollen, dann benutzen Sie die setAccessibleDescription Methode um eine Beschreibung über die Unterstützungstechnologie an den Benutzer weiter zu geben. Zum Beispiel: aJComponent.getAccessibleContext(). setAccessibleDescription(„Clicking this component causes XYZ to happen.“);

Erklärung:
In der Eigenschaft AccessibleDescription kann man einen längeren Text angeben, der den Sinn und Zweck der Komponente beschreibt. Dieser Text wird z.B. von Screenreadern gelesen und dem blinden oder sehbehinderten Menschen mitgeteilt.

3. Kriterium:
Sehen Sie, wo immer möglich, alternative Tastatureingaben vor. Sie sollten sicher stellen, das Ihr Programm nur mit der Tastatur bedient werden kann. Denken Sie daran das Sie aus einem editierbaren Feld mit ‚Shift-Tab’ den Fokus auf die nächste Text Komponente setzen können.

Erklärung:
Blinde und sehbehinderte Menschen arbeiten oft mit der Tastatur, weil das arbeiten mit der Maus nur dann funktioniert, wenn man genau sehen kann wo der
Mauszeiger ist. Deswegen ist es für beide Personengruppen wichtig, dass die Software auch per Tastatur bedienbar ist.

4. Kriterium:
Weisen Sie allen ImageIcon Objekten in Ihrem Programm eine textuelle Beschreibung zu. Sie können diese Eigenschaft festlegen, indem Sie entweder die setDescription Methode oder eines der String Formulare der ImageIcon Konstruktoren verwenden.

Erklärung:
Nicht nur auf Internetseiten, sondern auch bei Software haben blinde Menschen erhebliche Probleme mit Bildern/Grafiken. Stellen an den Bildern platziert sind, werden von Blinden als leere Fläche wahrgenommen. Deswegen ist es auch bei Software wichtig, dass man Bildern eine Textbeschreibung mit gibt, damit die Screenreader-Software dem Blinden was vorlesen kann.

5. Kriterium:
Wenn eine Gruppe von Komponenten eine logische Gruppe bilden, versuchen Sie diese in einen Container zu setzen. Verwenden Sie zum Beispiel ein JPanel das alle Radio-Buttons enthält die zu einer Radio-Button-Gruppe gehören.

Erklärung:
Das Gruppieren von Komponenten macht die Programmoberfläche übersichtlicher. Wenn die Container-Komponente noch einen sprechenden AccessibleName hat, kann das für einen Blinden eine enorme Erleichterung sein, um sich schneller auf der Programmoberfläche zu orientieren. Zum Beispiel könnte man Eingabefelder zum erfassen von einer Adresse in einen Container mit dem AccessibleName „Adressdaten“ gruppieren.

6. Kriterium:
Wann immer Sie ein Label verwenden welches eine andere Komponente beschreibt, verwenden Sie die setLabelFor Methode damit die Unterstützungstechnologie die Komponente finden kann die zu dem Label gehört. Dies ist besonders wichtig, wenn das Label eine Gedächtnisstütze für eine andere Komponente (z.B. ein Text Eingabefeld) ist.

Erklärung:
Dies hängt unmittelbar mit Punkt 3 zusammen. Hier geht es wieder u.a. darum, dass die Software auch per Tastatur bedienbar sein sollte. Außerdem können aber
auch Screenreader die Zusammenhänge zwischen Label und Eingabefeld so besser erkennen.

7. Kriterium:
Wenn Sie eine benutzerdefinierte Komponente erstellen, stellen Sie die Zugänglichkeit sicher. Insbesondere beachten Sie, dass Unterklassen von JComponent nicht automatisch zugänglich sind. Benutzerdefinierte Komponenten, die Nachkommen anderer Swing-Komponenten sind, sollten, wenn notwendig, die geerbten barrierefreie Informationen überschreiben.

Erklärung:
Wenn man Java-Komponenten selber entwickelt, sollte man darauf achten, dass diese auch barrierefrei sind.

8. Kriterium:
Verwenden Sie die Beispiele die Sie bei den Dienstprogrammen für Barrierefreiheit finden um Ihre Programm zu testen. Obwohl der primäre Zweck dieser Beispiele dafür gedacht ist den Umgang mit der Accessibility-API zu zeigen, sind sie auch sehr nützlich um Anwendungsprogramme auf Barrierefreiheit zu testen. Eine Prüfung auf Barrierefreiheit zeigt ScrollDemo die mit Monkey läuft. Monkey zeigt den Baum der zugänglichen Komponenten in einem Programm und ermöglicht es Ihnen mit diesen Komponenten interagieren.

Erklärung:
Es gibt Beispiele von Sun/Oracle zum Thema Accessibility

9. Kriterium:
Wenn Ihre GUI(=Programmoberfläche) einen Container hat der nicht zugänglich ist, zum Beispiel, Ihre eigene Container Unterklasse, eine JComponente oder einen anderen Behälter, die von dem Zugänglichkeitsdienstprogramm nicht erreicht wird, sind alle Komponenten in dem Container nicht erreichbar.

Erklärung:
Komponenten die in einem nicht barrierefreien Container sich befinden, sind für Eingabehilfen und andere unterstützende Software nicht erreichbar.

10. Kriterium:
Alle wichtigen Funktionen der Software sollten über Tastenkürzel(engl. Shortcuts) ansteuerbar sein.

Erklärung:
Sehbehinderte und Blinde, welche die Software nur per Tastatur bedienen profitieren von Tastenkürzel für wichtige Funktionen.

11. Kriterium:
Vermeiden Sie es Farb-und Schrifteigenschaften unveränderlich zu machen Die Software benötigt einen Einstellungsdialog für Farben und Schriftgrößen.
Wenn der Anwender in der Systemsteuerung die Schriftgröße verändert, muss die Software diese übernehmen!

Erklärung:
Menschen die Farbenblind sind, können eventuell mit den von Ihnen gewählten Farben Probleme haben. Deswegen sollte es in der Java-Anwendung ein Menü geben, in welchem der Anwender die Farben individuell einstellen kann.

12. Kriterium:
Vermeiden der Übermittlung wichtiger Informationen allein per Audioausgabe

Erklärung:
Stellen Sie sich vor, ein Mailprogramm würde das ankommen einer Mail nur akustisch signalisieren und die neue Mail wäre optisch nicht hervorgehoben. Gehörlose Menschen hätten keine Chance das eingehen von neuen Mails war zu nehmen. Deswegen ist es wichtig, dass man sich nicht nur auf Audioausgabe verlässt.

Barrierefreies Webdesign nach BITV 2.0: Alternativen für CAPTCHAs

CAPTCHA bedeutet Completely Automated Public Turing test to tell Computers and Humans Apart. Das bedeutet wörtlich: „Vollautomatischer öffentlicher Turing-Test zur Unterscheidung zwischen Computern und Menschen“. Was da genau bedeutet und warum Captchas für barrierefreies Webdesign ein Problem sind und wie Sie dieses Problem lösen, dass erfahren Sie in diesem Artikel.

Leider gibt es heutzutage viele Programme, sie heißen Bots, die völlig ungefragt Formulare mit unsinnigen Texten ausfüllen und dann den Formular-Inhalt abschicken. Der Formular-Inhalt wird per Mail an einen „armen“ Menschen geschickt, der mit diesem Inhalt nichts anfangen kann.

Um sich vor solch unliebsamen Formular-Inhalten und Mails zu schützen wurden die Captchas erfunden. Ein Captcha ist ein Bild auf dem eine Folge von Buchstaben und Zahlen zu sehen ist. Die Zeichen werden mit Absicht etwas verzerrt dargestellt und/oder mit einem komplizierten Hintergrund schwer lesbar gemacht. Sie müssen dann diese Zeichen in ein Eingabefeld eingeben und mit einem Schalter die Eingabe bestätigen.  Nur wenn die dargestellten Zeichen richtig ins Eingabefeld eingegeben wurde, werden die zuvor eingegebenen Formulardaten abgeschickt. 

Grundsätzlich ist die Idee der Captchas ja nicht schlecht, allerdings haben blinde und sehbehinderte Menschen die mit einem Screenreader arbeiten keine Chance das Captcha zu erkennen, weil der Screenreader Bilder nicht „lesen“ kann. Deswegen ist es unabdingbar dass dieses Captcha-Bild einen Alternativtext bekommt, damit das Captcha-Bild barrierefrei ist.

Allerdings steht in der BITV 2.0 folgendes:
„Mindestens eine nicht bildbasierte CAPTCHA-Alternative muss vorhanden sein.“

Also muss noch eine andere Lösung her. Es gibt die Möglichkeit textuelle Aufgaben zu stellen:

Welcher der vier Begriffe passt nicht zu den anderen drei?

Zweig Trapez Kreis Dreieck
Hose schreien sprechen reden
Auto Kugelschreiber Füller Bleistift

Unter den Auswahlbegriffen befindet sich jeweils ein Eingabefeld für die Antwort und ein Schalter zum Abschicken der Antwort. Wenn die Eingaben richtig sind, werden z. B. Die Formulardaten übermittelt.

Eine andere Möglichkeit ist, das einfache Rechenaufgaben gestellt werden und die Zahlen in Buchstaben dargestellt werden.

Beispiel:

Wieviel ist eins plus drei?

Eine weitere Idee ist, dass Sie eine Blacklist(=schwarze Liste) erstellen. Hier stehen Begriffe drin, die einfach in einem Formular nichts zu suchen haben wie z. B. „Sex“, „Kondom“ usw. Bevor das Formular abgeschickt wird, überprüfen Sie ob Begriffe vorkommen, die in Ihrer Backlist vorhanden sind. Wenn ja, wird das Formular nicht abgeschickt.

Was bei den Alternativen zu Captchas wichtig ist: Sie sollten leicht zu lösen sein. Es geht nicht darum einen barrierefreien Intelligenztest durchzuführen, sondern unnötige Mails mit unsinnigen Formulardaten zu verhindern. Sie sollten bei der „Erfindung“ von Captchas bedenken, dass es auch Menschen mit Lernbehinderungen gibt, funktionale Analphabeten oder Menschen mit Migrationshintergrund . Diese Menschen sollten ebenfalls in der Lage sein, Ihre Captchas korrekt auszufüllen.


Barrierefreies Webdesign mit der BITV 2.0 – Artikelreihe

Accessibility: Richtlinien zur barrierefreier Software-Entwicklung mit .net bzw. C#

In diesem Blogartikel möchte ich die Richtlinien von Microsoft für .net bzw. C# zur barrierefreier Software-Entwicklung besprechen. Wenn eine Software barrierefrei ist, dann ist Sie für Menschen mit Behinderung verwendbar.

Im Artikel „Was ist eine barrierefreie Software“ habe ich erklärt welche Kriterien erfüllt werden müssen, damit eine Software barrierefrei ist. Microsoft hat in ihrer Dokumentation, die MSDN, Richtlinien veröffentlicht wie eine Standardsoftware barrierefrei bzw. behindertengerecht gemacht werden kann. Ich werde hier die Richtlinien wiedergeben und erklären.


Punkt 1: Unterstützung der Systemsteuerungseinstellungen für Größe, Farbe, Schriftart und Eingabe

Unterstützung der Systemsteuerungseinstellungen für Größe, Farbe, Schriftart und Eingabe. Wenn die Benutzer die Einstellungen der Systemsteuerung ändern, wird die Größe der Menüleiste, der Titelleiste, der Ränder und der Statusleiste automatisch geändert. In dieser Anwendung müssen keine weiteren Änderungen an den Steuerelementen oder dem Code vorgenommen werden

Erklärung:
Microsoft hat in jedem Windows, wie oben erwähnt, in der Systemsteuerung einige Einstellungsmöglichkeiten die Menschen mit Behinderung zu gute kommen. Deswegen ist es unabdingbar, dass eine entwickelte Software diese Einstellungen übernimmt und nicht ignoriert. Es wäre zum Beispiel kontraproduktiv, wenn ein Mensch mit einer Sehbehinderung sich in der Systemsteuerung große Schriftarten einstellt und in der Software erscheinen alle Zeichen in der Schriftgröße 10.


Punkt 2: Unterstützung des Kontrastmodus

Erklärung:
In der Eingabehilfe, die man in der Systemsteuerung findet, gibt es einen Reiter „Anzeige“. Hier findet man ein Kontrollkästchen mit der Beschriftung „Kontrast aktivieren“. Klickt man es an und aktiviert rechts unten den Schalter „Übernehmen“ wird der Kontrastmodus aktiviert. Die Aktivierung dauert ein bisschen. Nach und nach wird der Hintergrund Pech schwarz und überall erscheint eine weiße Schrift.Dieser Kontrastmodus darf durch eine Software nicht verändert oder verhindert werden.


Punkt 3: Bereitstellen eines dokumentierten Tastaturzugriffs auf alle Features

Erklärung:
Wie oben schon erwähnt, benutzen Menschen die blind oder sehbehindert sind, eher die Tastatur wie die Maus. Deswegen sollten alle Programmfunktionen auch über Tastatur erreichbar sein und die entsprechenden Tastenkürzel sollten in der Programmhilfe dokumentiert sein.


Punkt 4: Visuelle und programmgesteuerte Anzeige der Position des Tastaturfokus

Erklärung:
Für Menschen die hauptsächlich oder ausschließlich mit der Tastatur arbeiten ist es wichtig, schnell zu erkennen wo der Tastaturfokus ist. Aus diesem Grund muss der Tastaturfokus visuell angezeigt und erkennbar sein.


Punkt 5: Vermeiden der Übermittlung wichtiger Informationen allein per Audioausgabe

Erklärung:
Im Artikel weiter oben wurde es erwähnt, dass es Menschen gibt die gehörlos sind. Wenn wichtige Informationen nur per Audioausgabe zur Verfügung stehen, bekommen gehörlose Menschen die Informationen nicht mit. Deswegen sollten Informationen die per Audioausgabe zur Verfügung stehen auch in visueller Form angeboten werden. Ein Mail-Programm, welches dem Anwender nur über Sprache mitteilt, dass er neue Mails hat, wäre für gehörlose Menschen unbrauchbar.

Wenn diese 5 Punkte bei einer Standardsoftware erfüllt sind ist, laut Microsoft, eine Software barrierefrei.