Rahmen der Verwendung

Die hier aufgeführten Empfehlungen sind über Programmgrenzen hinweg gültig. Für Programme, die strukturell ähnlich sind wie beook, sind sie natürlich einfacher zu befolgen. Für andersartige Applikationen können sie aber trotzdem beherzt und abgeleitet werden. Das jeweils dazu aufgeführte Beispiel von beook soll die Empfehlung in einem konkreten Kontext zeigen. Daher soll dieser Empfehlungskatalog nicht eine reine Aufzählung von möglichen Tastenbefehlen sein, sondern das Konzept hinter der Bedienung beleuchten. Die technische Umsetzung, die je nach Programmiersprache unterschiedlich aussehen kann, wird nicht beschrieben.

Die Empfehlungen versuchen, existierende Konventionen zu berücksichtigen und spiegeln die Resultate der vorhergehenden Analyse. Ein Anspruch auf Vollständigkeit für alle erdenklichen Programmtypen und -strukturen existiert nicht, aber die Bedürfnisse für die bereits bestehende Applikation beook werden abgedeckt.

Empfehlungen

Laden der Applikation

Ladezeiten können kürzer oder länger sein – je nach Gerät und Applikation. Während dieser Zeit sollte trotz optisch sichtbarem Ladebildschirm ein akustisches Signal oder eine Sprachnachricht diesen Zustand mitteilen. Dies kann eine Prozentangabe sein, es kann aber auch eine Tonfolge oder ein anhaltendes Geräusch sein. Der einfachste Weg dazu ist, die Windows-­System­töne zu unterstützen, damit die Tongebung dem Benutzer bereits bekannt ist – und automatisch bereits ein- beziehungsweise ausgeschaltet ist.

Der Eintritt in das Programm wird in der Regel vom Screenreader angekündet, in dem die Titelleiste des geöffneten Programms gelesen wird. Somit ist das Ende des Ladeprozess auch erkennbar.

Startbildschirm von beook: Akustisch sollte mitgeteilt werden, dass der Ladeprozess in Gang ist.

Umsetzung in beook

Für beook ist die Sprachausgabe des angezeigten Textes geplant. So wird der Benutzer informiert, was passiert. Zusätzlich wird beim Programmstart die Windows-Systemsound-Ausgabe unterstützt. Dadurch ist sichergestellt, dass bereits beim ersten Programmstart die Einstellungen für blinde und visuell eingeschränkte Personen stimmen und auch der «normal» sehende Benutzer nicht gestört wird.

Grundstellung

Um sich immer wieder zurechtfinden zu können, ist eine immer gleiche Grundstellung nötig. Wie ein Desktop mit geschlossenem Start-Menü oder Microsoft Word mit dem blinkenden Cursor im Text. Diese Grundstellung muss zu jeder Zeit über [esc] erreicht werden können. [esc]-Befehle nach dem Erreichen der Grundposition haben keine navigierende Wirkung mehr. Ein akustisches Signal kann aber melden, dass man die Grundposition erreicht hat.

Grundsätzlich soll nach dem Programmstart diese Grundstellung eingenommen sein.

Die Frage, welches bei einem vielseitigen Programm die Grundstellung ist, kann etwas schwieriger sein. Denken Sie dabei an Ihre Benutzer und was sie erwarten, wo deren «Landmark» in Ihrem Programm sein kann – und nicht unbedingt an das, was in erster Linie logisch ist.

Umsetzung in beook
Bei beook ist die Empfehlung für die Grundstellung folgendes: Fokus auf dem Portal-Button in der Seitenleiste. Dabei kann der angezeigte Inhalt unterschiedlich sein:

Wenn man sich aus einer Anbieter-Ansicht des Portals «escapen» will, dann wird rechts in der Grundstellung immer noch die Anbieter-Ansicht angezeigt, der Fokus wird aber auf den Portal-Button gelegt.

Der [esc]-Sprung von einem fokussierten Register in der Anbieter-Detail-Ansicht führt den Fokus direkt auf den Portal-Button der Seitenleiste.

Der Wechsel von einer Anbieter-Ansicht auf die Anbieter-Übersicht stellt keinen Niveau-Sprung dar, sondern einen Funktionsaufruf. Dies wurde mit dem Ansatz konzipiert, dass ein Benutzer in der Regel seinen «Hauptanbieter» hat.

Wenn man sich aus einem Dialog zum Bearbeiten von Markierungen im Leseteil «escapen» will, dann wird rechts in der Grundstellung noch das offene Buch im zuletzt besuchten Kapitel angezeigt.

Die [esc]-Sprünge von einem fokussierten Dialogfenster, in diesem Fall die Farbauswahl für die Markierung, zurück auf die Schaltfläche des Werkzeugs in der Lesebereich-Toolbar und zuletzt auf den Portal-Button der Seitenleiste.

Warum diese Wahl? Der Portal-Button ist ein konstanter Ort, von dem aus man sich neu orientieren kann. Im gleichen Bereich befindet sich zudem auch die Buchauswahl. Eine zusätzliche Information via Sprachausgabe wäre auch noch möglich, um den Benutzer aufzuklären, ob er nun das Portal  oder den Lesebereich vor sich hat.

Tab-Navigation von Element zu Element

Eine zweistufige Tab-Navigation kann für Klarheit und Komfort in der Navigation sorgen.

Generell was die Navigation angeht: Bloss nicht das Rad neu erfinden! In Anlehnung an aria-Regions im Web und die Bereichswechsel in Microsoft Word kann man die Navigation in einer Applikation von Bereich zu Bereich mit [ctrl + tab] regeln. So springt man von Zone zu Zone. Beim Landen in einem neuen Bereich informiert die Sprachausgabe, in welchem man sich befindet.

Innerhalb jedes Bereiches wird dann mit [tab] von Element zu Element gesprungen – ohne Gefahr zu laufen, aus der gewünschten Zone unbemerkt wieder heraus zu springen. Dies gilt auch für Symbolleisten und Registerkarten, bei denen nebst mit [tab] auch eine Navigation mit den Pfeiltasten möglich sein sollte.

Das Auswählen eines Elements, das Aktivieren einer Schaltfläche, wird mit [enter] gemacht. Alternativ die [leertaste] für die identische Funktion anzubieten stiftet mehr Verwirrung als es Komfort schafft.

Umsetzung Navigation in beook
In beook sieht eine zweistufige Navigation so aus, dass mit [ctrl + tab] in der Lesereihenfolge von Bereich zu Bereich gesprungen wird. Im Inhaltsbereich ergibt sich daraus folgende Reihenfolge: 1) Seitenleiste, 2) Übersichtsspalten, 3) Inhaltsverzeichnis, 4) Lesebereich-Toolbar, 5) Lesebereich

Die Tab-Reihenfolge über die Bereiche des Inhalts und des Lesebereichs, über die mit [ctrl + tab] navigiert wird: 1) Seitenleiste, 2) Übersichtsspalten, 3) Inhaltsverzeichnis, 4) Lesebereich-Toolbar, 5) Lesebereich

Jetzt könnte man bemängeln, dass der Lesebereich, der ja das Hauptelement des e-book-Readers von beook ist, erst als letzter Bereich in der Tab-Reihenfolge den Fokus bekommt. Dem können drei Elemente entgegengehalten werden: Über die Kombination [shift + ctrl + tab] kann die Richtung des Durchlaufs geändert werden. Also ist der Lesebereich nur einen Shortcut von der Grundstellung entfernt. Zudem entspricht die Reihenfolge für die Konsultation einer neuen, bestimmten Stelle bis auf den in diesem Fall überflüssigen Sprung zur Lesebereich-Toolbar sehr gut. Und drittens ist die Reihenfolge aufgrund der Programmstruktur für jemand Sehenden logisch, also so zu erwarten.

Die Tab-Reihenfolge für den Portal-Bereich ist sehr ähnlich.

Die Tab-Reihenfolge über die Bereiche des Potrals, über die mit [ctrl + tab] navigiert wird: 1) Seitenleiste, 2) Portal-Toolbar, 3) Produktverzeichnis, 4) Produkttitel, 5) Produktdetails 

Menüleiste

Die Menüleiste bietet für Benutzer die Möglichkeit, sich einen raschen Überblick über die Funktionen des Programms zu verschaffen – ähnlich einer Sitemap einer Webseite. Es ist eine gewohnte Art, über die Menüleiste an alle Befehle zu kommen. Für Power-User ist die Menüleiste auch der Ort, an dem Shortcuts nachgeschlagen werden können.

Umsetzung in beook

beook ist grundsätzlich auf die Touch-Bedienung ausgelegt. Dadurch wurden nur eine kleine Anzahl Funktionen in der Menüleiste platziert, was für die Barrierefreiheit wie auch menü-gewohnte Benutzer kein Vorteil ist. Eine generelle Ansteuerung von Funktionen, Ansichten und Einstellungen über die Menüleiste ist in betracht zu ziehen – auch wenn dies nicht unbedingt notwendig ist. Die Menüleiste sollte aber, sodenn diese Strategie gewählt wird, die Möglichkeiten sinnvoll und komplett abbilden.

Benennen von Buttons und Bereichen

Die grösste Schwierigkeit haben Screenreader mit Schaltern, die nur ein Bild aufweisen aber keinen Textinhalt haben. Bei denen ist es für Screenreader unmöglich, die eigentliche Funktion zu kennen, die durch das Drücken des Buttons aufgerufen wird.

Buttons müssen unbedingt via Tooltip oder andere Label-Möglichkeiten beschrieben werden, selbst wenn sie Text enthalten. Möglichst klare und eindeutige Beschreibungen sind wichtig. Im beschreibenden Text sollte zudem ein allfälliger Accesskey oder Shortcut erwähnt werden.

Auch Bereiche und Dropdownlisten sollten Labels oder Namen tragen, damit beim Durchtabben klar ist, wo man sich befindet. Geben Sie in der Beschreibung eines Bereichs auch an, wie man darin navigiert (ob mit [tab], den Pfeiltasten, etc.).

Umsetzung für beook

Als Bereichsbezeichnungen werden die unter «Tab-Navigation von Element zu Element» aufgeführten Bezeichnungen verwendet. Zusätzlich sollte vom Screenreader gelesen werden können, ob es sich beim Bereich um eine Schalter-Liste, einen Listeninhalt oder einen Textbereich handelt und wie darin navigiert werden kann.

Listen

Für Listen mit mehreren Hierarchiestufen ist eine Funktionsweise wie bei den Listen vom Windows Explorer anzustreben. Diese sind sehr gut für Screenreader zugänglich.

Windows-Explorer-Liste mit mehreren Hierarchien

Die Bezeichnung der abgebildeten Liste lautet «Struktur­ansicht» und es wird bei jedem Element erwähnt, ob ein Element offen ist und wie viele Elemente es enthält.

Bei normalen Listen mit nur einer Hierarchiestufe ist es gut, wenn der Benutzer am Ende der Liste angelangt und dabei ein akustisches Signal ertönt. So weiss der Benutzer, wann er am Ende der Liste angelangt ist – was bei langen Listen sehr praktisch ist. Sollte er das gesuchte Element verpasst haben, dient es dem Benutzer, wenn der Fokus nach dem letzten Element bei einem erneuten Drücken der gleichen Taste wieder auf das Erste springt. Damit entfällt ein mühsames «Zurück-Navigieren». Und auch der generellen Orientierung ist dies zuträglich, Listen nicht gezwungenermassen vorwärts und rückwärts durchlaufen zu müssen.

Durch die Listen wird mit den Pfeiltasten navigiert.

Umsetzung in beook

Die Strukturansicht im Inhaltsverzeichnis bringt beste Voraussetzungen mit: Die Funktionsweise ist bereits analog dem beschriebenen Verhalten von Windows-Explorer Listen mit mehreren Hierarchien. Zusätzlich muss von der Sprachausgabe mitgeteilt werden, ob es sich beim Inhalt um eine eigene Seite oder um eine bestehende Seite handelt. Diese Unterscheidung ist derzeit nur optisch – durch eine Blaufärbung des Textes – vorhanden.

Für Listen, wie sie als Resultat in den Übersichtsspalten «Lesezeichen», «Markierungen/Notizen» und «Suche» vorkommen, soll ein «Rundlauf» implementiert werden, damit der Fokus vom letzten Element in der Liste mit erneutem Drücken der Pfeiltaste wieder zum ersten springt. Mit einem akustischen Signal sollte das Angelangen am Ende der Liste angegeben werden. Dies kann ein «Bing» sein oder eine Sprachausgabe «Ende der Liste». Um das akustische Signal besser vom Gelesenen abzuheben, wäre einem textlosen Ton den Vorzug zu geben. Optimal wäre die Einbindung eines Windows-Systemsounds.

Übersichtsspalte «Notizen» im Inhaltsverzeichnis-Bereich: Eine Auflistung der gelben Notizzettel, der aktuelle Fokus liegt auf dem zweiten Eintrag.

Textlicher Inhalt

Bei dem in der Analyse behandelten Programm beook ist der textliche Inhalt zentral. Die Hauptfunktion ist schliesslich das bequeme Lesen von digitalen Lehrmitteln. Daneben gibt es natürlich allerlei Applikationen, deren Kern aus Formularfeldern, Listen, Menüs und generell aus wenig Text bestehen. Doch auch diese Programme haben textliche Inhalte, zu Beispiel bei Hilfe-Texten, Anleitungen und Dokumentationen oder auch bei Texteditoren, die für grössere Textmengen gedacht sind.

Bei all diesen Elementen empfiehlt es sich, eine Navigationsfähigkeit ähnlich einem Browser zu schaffen: Das Springen von Titel zu Titel, Listen zu Listen, Grafik zu Grafik etc. sollte über konventionelle Accesskeys möglich sein. Optimal ist es, wenn Screenreader die semantische Struktur des Textinhalts erfassen können und nicht nur mit optischen Auszeichnungen wie zum Beispiel «fett», «grösser» oder «kleiner» gearbeitet wird.

Gerade für Hilfe-Texte und Anleitungen, die oft nicht direkt im Layout der eigentlichen Applikation angezeigt werden, eignen sich html-basierte Dokumente gut. Mit einem einfachen, geöffneten HTML-Dokument mit dem Standard-Browser des Benutzers kann vermieden werden, auf eine nicht barrierefreie Webseite weitergeleitet zu werden, wo sich ein Benutzer verlieren kann.

Umsetzung in beook

Der Inhalt im Textbereich hat eine komplette html-Struktur, die in einem integrierten Browser angezeigt wird. Dadurch kann mit dem Screenreader wie gewohnt mit den Accesskeys im Inhalt navigiert werden.

Bei weiteren Textinhalten sollen die derzeit verschiedenen Typen von Textinhalten vereinheitlicht werden. So sollen die Informationen des Menüs «Über» genau gleich wie der lokal vorhandene «Hilfe-Text» und andere Erklärungen als strukturell sauberes HTML im integrierten Browser angezeigt werden.

Der Link zum vorhandenen Online-Support-Portal soll ein möglichst direkter Link sein – und nicht auf der Willkommensseite von beook.ch landen.

Texteditor

Verwendete Texteditoren für längere Texte, die eine Struktur haben müssen, sollten grundsätzlich das Verwenden von Stilvorlagen fördern. Dank sauber erstellten Stilvorlagen kann direkt eine korrekte semantische Struktur entstehen. Dabei trägt schon nur das korrekte Auszeichnen von Titelhierarchien, Listen und Links viel zur Barrierefreiheit bei.

Umsetzung in beook

In beook wäre eine Anpassung des derzeit vorhandenen Texteditors zum Erstellen von neuen Seiten anzustreben. Der eingebettete CK­editor kann über die Tastatur nicht bedient werden. Optimal wäre eine barrierefreie Bedienung des Programms im Programm. Realistischer ist wohl eine über Shortcuts definierte Bedienung, die während dem Bearbeiten im Eingabefeld die wichtigsten Menüs aufrufen kann (u.a. Formatvorlagen, Liste, Symbole einfügen).

Der geöffnete CK­editor zum Erstellen einer eigenen Seite, mit geöffneter Formatvorlagen-Dropdownliste

Bei implementierten, externen Opensource-Produkten ist die Abhängigkeit von deren Entwicklung stets ein Knackpunkt.

Bei einer Anpassung der eigenen Seite-Funktionalität wäre zusätzlich Folgendes in Betracht zu ziehen: Ist eine eigene Seite erst einmal geschrieben, sollte diese als «flaches» HTML gezeigt werden, ohne in einem Eingabefeld integriert zu sein. Nur so kann gewohnt – wie in bestehenden Seiten im Leseteil auch – in den eigenen Seiten mit Browser-Accesskeys navigiert werden, ohne Gefahr den Inhalt ungewollt zu verändern.

Die eigene Seite mit geschlossenem Editor und dem Inhaltstext, der sich in einem riesigen Eingabefeld befindet.

Shortcuts

Tastenkombinationen erlauben es zwar, dass Power-User schnell an Ihre Menüs kommen. Betreffend «Barrierefreiheit» spielen sie aber eine sekundäre Rolle: Als oberstes Gebot gilt: Alle Funktionen müssen mit der normalen Tastaturnavigation erreichbar sein. Es gilt nicht zu vergessen, dass blinde und sehbehinderte Benutzer bereits eine gewisse Anzahl an Shortcuts kennen müssen, um den jeweiligen Screenreader zu bedienen. Bekannte Shortcuts wie [ctrl + c], [ctrl + v] und [ctrl + o] zu implementieren ist gängig, die dann auch die erwarteten Befehle Kopieren, Einfügen und Öffnen ausführen.

Sollten dennoch «neue» Shortcuts gesetzt werden, muss sichergestellt sein, dass ein Menü-Punkt oder Button zum Aufrufen der gleichen Funktion existiert, am besten mit Sprachausgabe der zugewiesenen Tastenkombination. Eine Funktion darf nicht exklusiv über den Shortcut erreicht werden. Es wird abgeraten, die Beschreibung der definierten Tastenkombinationen einfach in ein «Hilfe-Menü» oder in ein «Manual» auszulagern. Sie müssen dort beschrieben sein, wo sie gebraucht werden!

Umsetzung in beook

Um die Benutzerfreundlichkeit zu erhöhen, sind für die Navigation in den Übersichtsspalten Shortcuts vorgesehen. Wechsel zwischen den Übersichtsspalten sind bei der intensiven Nutzung von beook eine häufige Handlung. So kann ein ständiges Navigieren zum Bereich der Übersichtsspalten umgangen werden.

Ansonsten sind keine weiteren programmspezifischen Shortcuts vorgesehen, ausser sie sind bereits klare Konvention, wie zum Beispiel [alt + F4] zum Beenden des Programms.

Accesskeys

Accesskeys dienen erfahrenen Benutzern zum effizienteren Arbeiten und können in einer geschlossenen Umgebung eines Programms verwendet werden. Wie Shortcuts dürfen auch Accesskeys nie der einzige Weg sein, um eine Funktion auszuführen oder ein Menü zu wählen. Accesskeys werden ergänzend eingesetzt. Bei Menü-Punkten, Schaltflächen und Registerkarten sollten vorhandene Access­keys beim Darübernavigieren von der Sprachausgabe erwähnt werden.

Bei der Programmkonzeption sollte die Internationalisierung dieser Accesskeys berücksichtigt werden, damit diese auch möglichst Eingängig sind für die Beutzer: So macht zum Beispiel [l] für «Lesezeichen» auf Deutsch Sinn, ist aber für die englische Version unpassend, da Lesezeichen «bookmarks» heisst.

Wenn lange, textliche Inhalte in der Applikation vorkommen, kann eine Browser-Ähnliche Accesskey-Implementation in Erwägung gezogen werden – so denn dieser Textinhalt nicht bereits in einem implementierten Browser angezeigt wird. Doch Achtung: gerade wenn dies der Fall ist, sind eigene Accesskeys im Kontext der textlichen Inhalte fast nicht mehr möglich, ohne Konflikte zu schaffen.

Umsetzung in beook

Für alle Menü-Punkte in der Menü-Leiste werden klare, sprachangepasste Accesskeys gesetzt. Ebenso für die Register der Übersichtsspalten, die Schaltflächen der Lesebereich-Toolbar, die Schaltflächen in der Portal-Toolbar und die Register der Produktdetails. Zusätzlich sind zwei Accesskeys für die konstanten Elemente der Seitenleiste vorgesehen: [p] für Portal, [b] für Browser.

Funktionstasten

Als globale Art von Accesskeys werden oft die Funktionstasten verwendet – dies ist der Grund, warum sie hier ein separates Unterkapitel erhalten. Folgende Belegung ist empfohlen:

• [F1] Hilfe aufrufen
• [F3] Suche
• [F4] Fenster schliessen (nicht Programm)
• [F6] zwischen Unterfenstern beziehungsweise Tabs wechseln

Umsetzung in beook

Die Taste [F1] führt direkt zum Hilfetext, der auch über das Menü «Hilfe» aufgerufen werden kann. [F3] setzt den Cursor direkt in der Übersichtsspalte «Suche» in das Suchfeld. Die Suche ist somit auf die globalst-mögliche Suche eingeschränkt, welches die Suche in einem einzelnen Buch ist.

Kontextmenü

Kontextmenüs werden in der Regel über einen Rechtsklick der Maus aufgerufen und stehen immer in Bezug mit dem Ort des Klicks. Um der Tastatur-Navigation ebenfalls diese Möglichkeiten zu bieten, ist ein Weg über Menü-Punkte in der Menü-Leiste der logische Weg. So bleibt zum Beispiel ein selektierter Text ausgewählt, während man über [alt] in die Menü-Leiste einsteigt und dort die gewünschte Funktion aufruft.

Umsetzung in beook

Für das Kontextmenü des Lesebereichs wird in der Menü-Leiste ein neues Menü geschaffen und nimmt all die im Kontextmenü vorhandenen Punkte auf. Zusätzlich wird dieses mit der Funktion «Notiz einfügen» ergänzt.

Beenden der Applikation

Das Beenden der Applikation muss in jedem Fall über [alt + F4] möglich sein. Ein Menü-Punkt in der Menü-Leiste kann auch dazu dienen, ist jedoch nicht unbedingt nötig.

Umsetzung in beook

Die beook-Applikation hat diesen Standard-Befehl implementiert. Die Applikation schliesst sich über [alt + F4].

Accessibility-Feature: On/Off

Grundsätzlich sollte versucht werden Accessibility-Features so zu implementieren, dass sie für den normal sehenden Benutzer nicht auffallen. Wer sie aber sucht, soll sie auch finden. Denn auch ein «Normal-Benutzer» kann zum Beispiel von Shortcuts und Accesskeys profitieren.

Elemente, die zusätzlich zur Screenreader-Ausgabe hinzukommen, sollten in den Einstellungen an prominenter Stelle ein- beziehungsweise ausgeschaltet werden können. Dies weil zum Beispiel die Ausgabe von akustischen Signalen, die zusätzlich eingebaut werden, für «Normal-Benutzer» schnell störend wirken. Auch für den Wechsel von «sehr ausführlichen» auf «normale» Tool-Tipps oder Hilfs-Labels kann eine Einstellungsmöglichkeit sorgen.

Umsetzung in beook

Zweistufige Labels und Tooltips sind nicht vorgesehen. Dafür können im Einstellungsmenü die zusätzlichen, akustischen Hinweise ein- beziehungsweise ausgeschaltet werden – so denn diese nicht komplett über die Standard Windows-Systemsounds gelöst werden können.

Das Wichtigste: Selber ausprobieren!

Bevor Sie mit der Umsetzung einer barrierefreien Applikation beginnen, begeben Sie sich selbst in die Situation, ausschliesslich mit der Tastatur zu navigieren. Und dann steigern Sie das Erlebnis, in dem Sie einen Screenreader installieren und sich anschliessend eine Schlafmaske aufsetzen. Ausser natürlich, Sie gehören zu der beeindruckend hohen Anzahl blinder und visuell eingeschränkter Programmiererinnen und Programmierer, die es auf dieser Welt gibt – dann kennen Sie dies ja schon.

Erleben Sie selbst, was es heisst, wenn plötzlich kein Feedback kommt, wenn ein Programm für den Screenreader ein weisses Blatt ist. Oder wie Ihnen ein einfaches Interface plötzlich als «langer Text auf einer einzigen Zeile» doch kompliziert scheint. Und stellen Sie bald einmal fest, was stört.

Dabei ist klar, dass man durch eine stündige «Blind-Session» noch nicht zum Profi wird. Aber es hilft, Verständnis zu entwickeln um letztendlich ein (noch) besseres Resultat zu erschaffen.

Diese öffentliche Publikation ist im Rahmen der Bachelor-Arbeit von Christian Heimann entstanden. Anregungen, Feedbacks und Kritik zur Verbesserung dieses Empfehlungskatalogs sind sehr willkommen. Diese werden für den weiteren Verlauf der Bachelor-Arbeit auch bestmöglichst berücksichtigt. Bei Interesse an der vorangeganenen Analyse können Sie sich ebenfalls beim Autor melden: christian.heimann@ionesoft.ch

Die erwähnte Applikation beook kann kostenlos in der aktuellen, noch nicht barrierefreien Version heruntergeladen werden unter:
http://beook.ch