Barrierefreiheit mit Dotnet: Barrierefreie Softwareentwicklung mit Microsoft .net 4.5 für Windows-Anwendungen

In diesem Blogartikel möchte ich erklären, wie Sie mit dem Mircosoft .net Framework 4.5 und 4.6 barrierefreie Softwareentwicklung für Windows-Anwendungen verwirklichen können.

Was ist Microsoft Dotnet 4.5 / .net 4.5

.NET ist eine von Microsoft entwickelte Software-Plattform zur Entwicklung und Ausführung von Anwendungsprogrammen(=Software). Dotnet besteht aus einer Laufzeitumgebung (Common Language Runtime), in der die Programme ausgeführt werden. Ebenfalls in .NET ist eine Sammlung von Klassenbibliotheken, Programmierschnittstellen und Dienstprogrammen die auch Services genannt werden.

Für alle diejenigen die lieber Video schauen statt zu lesen, gibt es hier ein Video:

Was ist barrierefreie Softwareentwicklung?

Software die für Menschen mit unterschiedlichen körperlichen Einschränkungen(=Behinderungen) bedienbar ist, wird barrierefreie Software genannt. Die Entstehungsprozess von barrierefreier Software nennt sich barrierefreie Softwareentwicklung.
Durch barrierefreie Softwareentwicklung entsteht eine Software die für Menschen mit unterschiedlichen Behinderungen gut zu bedienen ist.

Warum ist barrierefreie Softwareentwicklung wichtig?

In Deutschland leben über 10 Millionen Menschen mit Behinderung . Viele von diesen behinderten Menschen sind potentielle Anwender von Software und somit auf Barrierefreiheit angewiesen.
Auf einer deutschsprachigen Microsoft Webseite ist folgendes zu lesen:
Diese exemplarische Vorgehensweise beschäftigt sich mit den fünf Anforderungen an Barrierefreiheit, die Anwendungen erfüllen müssen, um das „Certified for Windows“-Logo zu erhalten.
Quelle: Exemplarische Vorgehensweise: Erstellen von behindertengerechten Windows-basierten Anwendungen
Das ist doch eine coole Aussage liebe deutsche Microsoft Dotnet-Entwickler! Wenn Ihre Software „Certified for Windows“ sein soll, MUSS sie barrierefrei sein! Ja, Barrierefreiheit als Qualitätsmerkmal! Davon habe ich schon lange nachts geträumt! Danke Microsoft!

Wer mit dem Thema so gar nichts anfangen kann sollte meinen Blogartikel über
Barrierefreie Softwareenwicklung lesen.

Anforderungen von Microsoft an eine Barrierefreie Software

In diesem Abschnitt möchte ich die Anforderungen an eine barrierefreie Software wiedergeben und diese erklären:

Anforderung 1:
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:
Sehbehinderte können in der Systemsteuerung eine große Systemschrift einstellen oder Menschen mit einer Farbsehschwäche können in der Systemsteuerung ein Design mit hohem Kontrast wählen. Eine Microsoft Dotnet-Anwendung übernimmt diese Systemeinstellungen ohne dass sie als Software-Entwickler zusätzlichen Programmcode einfügen müssen in Ihre Software. Allerdings sollten Sie überprüfen ob Ihre Software nach Übernahme dieser barrierefreien Systemeinstellungen weiterhin gut bedienbar ist.

Windows 10 - Systemschrift anpassen für Menschen mit Sehbehinderung
Windows 10 – Systemschrift anpassen für Menschen mit Sehbehinderung

Anforderung 2:
Unterstützung des Kontrastmodus
Erklärung:
Sehbehinderte oder Menschen mit einer Farbsehschwäche können bei Windows in der Systemsteuerung einen Kontrastmodus einstellen. Dies machen Sie in der Systemsteuerung ? Darstellung und Anpassung ? Anpassung ? Basisdesigns und Designs mit hohem Kontrast. Dieser Kontrastmodus muss von Ihrer Microsoft Dotnet-Anwendung übernommen werden. Im obigen Link „ Exemplarische Vorgehensweise: Erstellen von behindertengerechten Windows-basierten Anwendungen“ finden Sie ein Codebeispiel wie der Kontrastmodus in Ihre Software übernommen werden kann.

Anforderung 3:
Bereitstellen eines dokumentierten Tastaturzugriffs auf alle Features.
Erklärung:
Blinde und Sehbehinderte können mit einer Computermaus nicht arbeiten. Ohne Sehvermögen ist es nicht möglich den Mauszeiger zu einer bestimmten Stelle auf dem Bildschirm zu bewegen. Deswegen sind Blinde und Sehbehinderte darauf angewiesen, den ganzen Computer(Betriebssystem und Software) per Tastatur bedienen zu können. Sie müssen als Software-Entwickler dafür Sorgen, dass Ihre ganze Software per Tastatur zu bedienen ist. Ausserdem muss es eine Dokumetation geben für die Bedienung per Tastatur.

Anforderung 4:
Visuelle und programmgesteuerte Anzeige der Position des Tastaturfokus
Erklärung:
Für Sehbehinderte Menschen ist es oft nicht einfach zur erkennen, welches Bedienelement den Fokus hat, d.h. aktiv ist. Deswegen sollten Sie bei der barrierefreie Softwareentwicklung mit Microsoft Dotnet darauf achten, dass der Tastaturfokus gut erkennbar ist. Mein Tipp ist: Verändern Sie die Hintergrundfarbe des aktiven Bedienelements. Ich verwende hierfür immer die Farbe Gelb.

Anforderung 5:
Vermeiden der Übermittlung wichtiger Informationen allein per Audioausgabe.
Erklärung:
Wenn Sie Informationen per Audioausgabe übermitteln muss Ihnen klar sein, dass gehörlose Menschen diese nicht wahrnehmen können. Deswegen sollten Sie unbedingt wichtige Informationen auch Visuell darstellen. Entweder durch eine Textmeldung oder ein Programmfenster. Sie können auch die Titelleiste Ihres Programmfensters blinken lassen um den Gehörlosen auf eine bestimmte Meldung hinzuweisen. Allerdings halte ich persönlich von Blinkenden Elementen nicht viel, weil Sie bei Epilepsie in bestimmten Fällen Anfälle auslösen können.

Anforderung 6:
Weisen Sie den Eigenschaften AccessibleDescription und AccessibleName Texte zu.
Erklärung:
Ja, Sie haben recht, diese Anforderung steht im Microsoft-Link nicht. Aber im aufgeführten Link wird es im Programmbeispiel umgesetzt! Blinde Menschen arbeiten mit einer Software die den Bildschirminhalt vorliest. Diese Software heißt Screenreader . Diese Software kann nur lesen.
Damit diese Software dem Blinden mitteilen kann, wie die Oberfläche Ihrer Software aussieht, müssen Sie als Software-Entwickler in den Oberflächen-Komponenten Texte hinterlegen. Diese Texte müssen die Oberfläche Ihrer Software beschreiben.

Barrierefreheit mit Dotnet: Welche Programmiersprache ist die richtige?

Das besondere an .NET ist, dass es mehrere Programmiersprachen gibt mit denen Sie barrierefreie Anwendungen entwickeln können. Die eigentliche Programmiersprache von .NET ist C#. Sie können aber auch mit Visual Basic.NET oder anderen Programmiersprachen barrierefreie Anwendungen entwickeln.

Ansicht Visual Studio 2015 mit geöffneten Projekt
Ansicht Visual Studio 2015 mit geöffneten Projekt

Programmcodebeispiele für Barrierefreiheit mit Dotnet-Anwendungen

Die hier aufgeführten Programmcodebeispiele sind von diesem Link:
Exemplarische Vorgehensweise: Erstellen von behindertengerechten Windows-basierten Anwendungen

1. Kontrasmodus aktivieren

Visual Basic
Private Sub SetColorScheme()
If SystemInformation.HighContrast Then
companyLabel.BackColor = SystemColors.Window
companyLabel.ForeColor = SystemColors.WindowText
Else
companyLabel.BackColor = Color.Blue
companyLabel.ForeColor = Color.Yellow
End If
End Sub

// C#
private void SetColorScheme()
{
if (SystemInformation.HighContrast)
{
companyLabel.BackColor = SystemColors.Window;
companyLabel.ForeColor = SystemColors.WindowText;
}
else
{
companyLabel.BackColor = Color.Blue;
companyLabel.ForeColor = Color.Yellow;
}
}

2. Accessibility-Eigenschaften setzen

So setzen Sie die Accessibility-Eigenschaften:

// C#
myEdit.AccessibleName = "Webadresse";
myEdit.AccessibleDescription = "Web-Adresse bitte eingeben";

// Visual Basic.NET
myEdit.AccessibleName = „Webadresse“
myEdit.AccessibleDescription = _ „Web-Adresse bitte eingeben“

Barrierefreheit bei Microsoft Dotnet-Anwendung Testen

Ich bin kein Freund davon Barrierefreiheit mit Tools zu Testen. Microsoft bietet allerdings eine Reihe von Tools zum Testen von Barrierefreheit an:
Tools zum Testen der Barrierefreiheit
Diese Tools können selbstverständlich eine große Hilfe sein beim Testen auf Barrierefreheit bei einer Microsoft Dotnet-Anwendung.
Ich empfehle allerdings eine Überprüfung der Barrierefreiheit von „Hand“ nach oben genannten Richtlinien.
Der Vollständigkeit halber möchte ich hier die Microsoft Testmetoden wiedergeben, die sie ebenso auf obigen Link finden:
Um den Tastaturzugriff zu testen, ziehen Sie den Mausstecker aus dem Computer heraus und greifen auf alle Features der Benutzeroberfläche nur mithilfe der Tastatur zu. Stellen Sie sicher, dass sich sämtliche Aufgaben auch ausschließlich über die Tastatur ausführen lassen.

Wählen Sie zum Testen der Kontrastunterstützung in der Systemsteuerung das Symbol Barrierefreiheit. Klicken Sie auf die Registerkarte Anzeige, und aktivieren Sie das Kontrollkästchen Kontrast aktivieren. Überprüfen Sie in den einzelnen Elementen der Benutzeroberfläche, ob die Farben und die Schriftart entsprechend geändert wurden. Darüber hinaus muss die Anzeige von Symbolen und Mustern hinter dem Text unterdrückt sein.

Die Barrierefreiheit einer Anwendung können darüber hinaus direkt mithilfe spezieller Tools getestet werden.

Um die Kennzeichnung des Tastaturfokus zu testen, verwenden Sie die Bildschirmlupe. (Zeigen Sie zum Öffnen der Bildschirmlupe im Startmenü auf Programme, dann auf Zubehör, anschließend auf Barrierefreiheit, und klicken Sie auf Bildschirmlupe.) Navigieren Sie durch die Benutzeroberfläche. Verwenden Sie dazu sowohl die TAB-Taste als auch die Maus. Stellen Sie sicher, dass sämtliche Aktionen ordnungsgemäß in der Bildschirmlupe wiedergegeben werden.

Um die Kennzeichnung der Bildschirmelemente zu testen, führen Sie Inspect aus, und testen Sie die einzelnen Elemente sowohl mit der Maus als auch mit der TAB-TASTE. Stellen Sie sicher, dass die in den Feldern Name, State, Role, Location und Value des Fensters Inspect angezeigten Informationen für die Benutzer der einzelnen Objekte der Benutzeroberfläche aussagekräftig sind.

Zum Schluss noch ein Video von mir welches barrierefreie Softwareentwicklung mit Microsoft Dotnet erklärt:

Schlussbemerkung:

Sie können mit allen Programmiersprachen die Microsoft Dotnet unterstützt barrierefreie Softwareentwicklung durchführen. Für Microsoft ist Barrierefreiheit inzwischen ein MUSS. Um das „Certified for Windows“-Logo zu erhalten muss Ihre Dotnet-Anwendung barrierefrei sein!!!
Ich berate und gebe Schulungen in Sachen Barrierefreie Softwareentwicklung mit Microsoft Dotnet. Wenn Sie fragen haben, dürfen Sie mich gerne anrufen unter 07121/504458 oder eine Mail schreiben an info@marlem-software.de .

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.