- Einleitung
- Übersicht über darauf folgende Themen/ Konzepte
- Wer wird adressiert mit diesem Artikel
- Focus Traversal (basics)
- Zusammenspiel der JVM Klassen beschreiben
- Traversal Klassen
- Focusable setzen
- Java mittel
- a11y property
- verweis auf externe Ressources/Tutorials und Demo (von Andre)
- Zusammenspiel der JVM Klassen beschreiben
- Konzept in jadice viewer
- Übersicht
- standard jadice API
- weg über TreeTraversal
- TreeTraversal
- Beispiel für TreeTraversal
- ( Identifier
- action.properties
- verweis auf jadice Doku (Action & Command Framework)
- mapping (accessibleName - Accessibility Support)
- zusammen Spiel mit Annotationen/Annotation Toolbar
- verweis auf Anno Profil
- action.properties
- FokusTraversal
- Integrationsmöglichkeiten
- In Anwendung
- Weitere Anpassungen durch FocusTraversalKey setzen
- Integrationsmöglichkeiten
- Möglichkeiten und Grenzen des Konzepts
- statische vs dynamische Komponenten
- Overlays
- ThumbnailView
- Anno Editoren
- Externe Frames
- Übersicht
Inhaltsverzeichnis
Einleitung
Dieser Artikel zum jadice viewer® wird ein Überblick darüber gegeben, wie man die Reihenfolge definiert, in der die Bedienelemente des Viewers fokussiert werden.
Der Artikel richtet sich an Integratoren, die aufgefordert sind, bestehende wie auch neue Anwendungen barrierefrei zu gestalten.
Nachfolgend werden Ihnen dafür erforderliche Konzepte und Code Beispiele erklärt.
Focus Traversal Policy
In Swing gibt es die Möglichkeit, mittels der Tastatur mit einzelnen Bedienelementen zu interagieren. Damit die Interaktion mit dem gewünschten Bedienelement erfolgen kann, muss dieses den Fokus haben. Dabei kann immer nur ein Bedienelement der GUI den Fokus erhalten.
Eine Focus Traversal Policy bestimmt die Reihenfolge, in welcher die Bedienelemente den Focus erhalten. Jede Swing-Komponente besitzt eine Default Focus Traversal Policy. Je nach Lokation der Swing Komponente in der Swing-Komponenten-Hierarchie ergibt sich daraus die Fokus Reihenfolge der Anwendung. Dieses Standardverhalten kann durch das Implementieren einer eigenen FocusTraversalPolicy
verändert werden.
Bei einer FocusTraversalPolicy werden nur Bedienelemente berücksichtigt, die einen Fokus erhalten können. Bedienelemente müssen somit zunächst fokussierbar gemacht werden.
Swing sieht für Komponenten die .setFocusable(true)
Methode vor.
jadice® bietet mittels des Action & Command Framework die Möglichkeit, alle Menubar-Komponenten auf einmal fokussierbar zu machen. Dazu muss in der menucomponents.properties, folgender Boolean gesetzt werden:
enable.focussability.for.nonfocussable.components=true
Nachfolgend eine kleine Beispielanwendung für eine eigene FocusTraversalPolicy
(siehe im Abschnitt „Beispiele“).
Weitere Informationen zum Thema FocusTraversalPolicy finden siehe hier: https://docs.oracle.com/javase/tutorial/uiswing/misc/focus.html#customFocusTraversal
Focus Traversal Policy in jadice®
Es gibt grundsätzlich zwei Vorgehensweisen, über die der Zugriff auf die Swing-Komponenten erfolgen kann.
- Zum einen kann die Referenz für die Komponenten vorgehalten werden, wie es auch in der „Beispielimplementierung für eine FocusTraversalPolicy“ der Fall ist. Hierbei muss die Sichtbarkeit Komponenten gegeben sein.
- Zum anderen gibt es die Möglichkeit über das Traversieren der Swing Komponenten Hierarchie mittels Identifier auf die Komponenten zuzugreifen.
In den nachfolgenden Abschnitten wird die zweite Vorgehensweise näher erläutert.
Identifizierung der Swing-Komponenten
Ist der Zugriff auf Swing-Komponenten aufgrund ihrer Sichtbarkeit nicht möglich, machen wir uns eine Eigenschaft der jadice Implementation zunutze. Wir verwenden Informationen, die uns über den AccessibleContext der jeweiligen Komponente bereitgestellt werden. Im Besonderen nutzen wir die über die jadice Implementation sichergestellte Eindeutigkeit des AccessibleName
(In Sonderfällen kann der Accessible Context auch integrationsseitig überschrieben werden). Zu beachten ist dabei, dass der AccessibleName
abhängig vom verwendeten Locale ist.
AccessibleName aus den Action & Command Framework Dateien
Für die nachfolgend beschriebene Identifizierung der Swing-Komponenten, kann der verwendete AccessibleName aus den Property Dateien des Action & Command Framework ausgelesen werden. In der actions.properties
Datei wird der Name einer Action spezifiziert. Der dort verwendete Name der Action wird über die jadice implementation zu einem AccessibleName überführt. Anhand des Action Name bzw. des AccessibleName kann bei der Traversierung der Swing-Komponenten-Hierarchie die gesuchte Komponente identifiziert werden.
Nachfolgend ein ein auschnitt einer actions.properties
Datei, bei der der Action Name "Document drucken"(Zeile: 2) ausgelesen werden kann.
Der Action Name, bzw. Accessible Name kann wiederum im nachfolgend Dargestellten "Erstellung der Policy anhand der Action Names" verwendet werden.
Im Beispiel "Erstellung der Policy anhand der Action Names" wird gezeigt wie durch das hinzufügen der Accessible Names in das String Array, die Fokusreihenfolge definiert werden kann. Die dort definierte Reihenfolge wird entspricht der Reihenfolge mit der die Swing-Komponenten den Fokus erhalten.
AccessibleName aus dem Annotation Profil
Im falle der AnnotationsToolbar, die dynamisch anhand des verwendeten annotation profile erstellt wird, kann der AccessibleName aus dem annoprofil ausgelesen werden (siehe Codebock "Auszug aus dem default-annotation-profile.xml"). Hierfür muss der Wert des attributes name (@name="Line") als AccessibleName verwendet werden (siehe Zeile 1).
Notiz an uns selbst, man muss sich noch das Kontext-Menü genauer anschauen, da dort dynamisch anhand des anno-profils das Menü erstellt wird.
Swing Komponenten Hierarchie Traversal
In Swing sind die einzelnen Komponenten in einer Hierarchie, die einer Baumstruktur entspricht, enthalten. Wenn man beispielsweise angefangen beim Wurzelelement der Swing Hierarchie beginnt durch die Elemente zu traversieren, kann man mittels des zuvor erwähnten AccessibleNames alle Elemente in dieser Baumstruktur wiederfinden. Ein Beispiel, wie so etwas angegangen werden kann, wird im Abschnitt "Beispiele" gezeigt. Wir verwenden im Beispiel dabei AtomicReferences (siehe https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicReference.html), um später Zugriff auf das Originalobjekt zu erhalten.
Integrationsmöglichkeit der eigenen Focus Traversal Policy
Nachfolgend wird beschrieben wie die erstellte Focus Traversal Policy Integriert werden kann. Es wird auch auf das verändern des Standard FocusTraversalKey eingegangen.
Setzen einer Focus Traversal Policy
Um eine FocusTraversalPolicy zu setzen muss man nur die Policy auf der gewünschten Komponente setzen. Werden in der selben Hierarchie mehrere Komponenten mit einer Policy besetzt, so werden bei einem FocusTraversal diese Policies zunächst ignoriert. Wenn man die Beachtung dieser Policies wünscht so kann man wie in dem gezeigten Beispiel es als PolicyProvider markieren. Dann wird bei einer Suche dessen Policy ebenfalls zur Anwendung kommen, falls diese Komponente zurückgegeben wird bei einer Suche (Next/First/Last Component).
Eigene FocusTraversalKeys verwenden
Standardmäßig wird TAB
verwendet, um bei der Komponente einen Fokuswechsel zur nächsten zu bewirken. Dies kann man durch das Setzen eigener Keys überschreiben. Über ein flag kann dabei gesteuert werden, ob die Komponente die Events des gesetzten Keys normal verarbeiten soll oder nur einen Fokuswechsel bewirken soll.
Möglichkeiten und Grenzen
Zuvor wurde die Vorgehensweise beschrieben, bei der Anhand des AccessibleNames Komponenten, während der Traversierung der Swing-Komponenten-Hierarchie, aufgefunden und für eine FocusTraversalPolicy verwendet werden können. Diese Vorgehensweise ist nicht inn allen Fällen anwendbar, weshalb nachfolgen Besonderheiten und Grenzen aufgezeigt werden.
Dynamische Komponenten
Bei der Konstruktion einer Focus Traversal Policy muss man bestimmten dynamischen Komponenten besondere Beachtung schenken. Mit dynamischen Komponenten sind hier Komponenten gemeint, die dynamisch anhand von äußeren Faktoren wie beispielsweise einem gesetztem Annotationsprofil erzeugt werden. Ebenfalls können bestimmte Eigenschaften von Komponenten wie beispielsweise visuelle Sichtbarkeit oder ob die Komponente deaktiviert ist eine Relevanz bei der Reihenfolge des Fokus haben. Diese müssen bei einer Policy je nach gewünschtem Verhalten gesondert beachtet werden.
Overlays
Zum Beispiel die Annotationseditoren, das GalleryNavigationTool und die RolloutSearch unterstützen die in diesem Artikel Konzepte für die Tastaturbedienbarkeit momentan nicht. Wenn Sie diese dennoch in Ihrer Integration mit dem hier beschriebenen Konzept Verwenden wollen, stehen wir Ihnen gerne beraten zurseite.
Fehlende AccessibleNames
Wenn eine Swing/AWT Komponente keinen AccesibleContext oder AccessibleName vergeben hat, kann dies die Identifizierung eines entsprechenden Elements, in dem Ansatz mit der Traversierung erschweren. In diesem Fall müssen wahlweise andere Eigenschaften (AccessibleContext) einer Komponente vergeben werden, die diese in dem Hierarchiebaum eindeutig identifizierbar machen oder aber auf den Ansatz mit dem Halten von Referenzen auf die Objekte ohne Traversierung ausgewichen werden.
Externe Frames
Bei einer komplexen Anwendung kommt es häufig dazu, dass ein sekundärer Dialog oder Frame zum Einsatz kommt. Da dieses Frame oder dieser Dialog nicht Teil der Hierarche des Hauptfensters ist, muss dieses ebenfalls eine eigene Policy mitbringen, die den Fokus steuert. Wichtig ist dabei auch den Übergang zwischen den Frames zu beachten. Soll beispielsweise dem neuen Fenster Focus gegeben werden muss man mit requestFocus()
und gegebenenfalls toFront()
im Voraus aufgerufen werden um das Fenster in den Vordergrund zu rücken. Ob ein Fenster den Fokus bekommt, kann jedoch je nach Betriebssystem anders gehandhabt werden und die Priorität des Fensters spielt ebenfalls eine Rolle.
Hierarchie Listener
Bei manchen Swing/AWT basierten Anwendungen kann es zu einer Änderung der Swing-Hierarchie kommen. Wird eine FocusTraversalPolicy verwendet, muss diese auf derartige Änderungen eventuell reagieren müssen, je nach Anwendungsfall. Diesem Effekt kann mit einem HierarchyListener (siehe https://docs.oracle.com/javase/8/docs/api/java/awt/event/HierarchyListener.html) begegnet werden.