![]() |
Barrierefreiheit mit Delphi
Ich muss zu meiner Schande gestehen das ich mich mit dem Thema Barrierefreiheit und Delphi noch nie auseinandersetzt habe. Jetzt hat es mich aber eingeholt. Bei einem Kunden arbeitet seit kurzem ein Blinder. Jetzt ist die Frage von Seiten des Kunden aufgetaucht ob wir zumindest Teile der Software Barrierefrei anbieten können.
Tja deshalb hier die Frage ob sich jemand damit ernsthaft auseinandergesetzt hat und eventuell mit Links oder Tips dienen kann. Der Mitarbeiter des Kunden hat mir auch angeboten mitzuwirken, ist auch echt um die Ecke so dass wir uns öfter treffen könnten. Vielen Dank für allen Input |
AW: Barrierefreiheit mit Delphi
|
AW: Barrierefreiheit mit Delphi
Nja, zu diesem Thema könnte man auch grundsätzlich erstmal einfache (übersichtlich und nicht übefüllt) und verständliche/intuitive GUIs zählen.
Keine extrem unleserlichen Farbkombinationen/-muster, vor allem in/hinter/um Text. (speziell an jene, welche es mit Skins/Styles/Theming übertreiben müssen) Screen-Reader für Sehbehinderte. VCL ist per se oft dafür geeignet, auch wenn dennoch softwareseitig für solche Programme weitere Informationen bereitgestellt werden können. Aber grundsätzlich kann dort die Oberfläche extern zerlegt und ausgelesen werden. (ACHTUNG) PS: Mach mal Strg+C in den Messageboxen und schon hast du den Inhalt als Text im Zwischenspeicher. (ein Beispiel für Zusatzinfos) Der Screenreader weiß aber ohne Zusatzinfos ala MSAA nicht unbedingt in welcher Reihenfolge die Texte/Komponenten zu lesen sind oder wie die Betonung des Vorgelesenen zu sein hat (Listboxen, Grids und "besonders" gefärbter Text) und speziell was der wichtige Inhalt ist oder was davon z.B. Menüstrukturen oder zusätzliche/unwichtigere Informationen sind. zu ACHTUNG: Das stimmt nur bedingt, denn in Delphi wird TLabel selbstgemalt, auf den Canvas dessen Parents, während das Text-Control im Windows eigentlich "STATIC" ist, welches ein eigenständiges WinControl darstellt und sich in Delphi als ![]() Thema ![]() ![]() ![]() Schwerer wird es bei selbstmalenden Komponenten oder gar sowas wie FMX, wo alles selbstgemalt ist. Dort sollte die API dem Screenreader sagen was wo zu lesen ist, denn ORC funktioniert nunmal nicht immer so gut. Ich weiß nicht ob das jetzt im FMX schon direkt drin ist, aber vor 'ner Weile gab es im CC noch ein Modul, welches man nachrüsten konnte. [add] ![]() ![]() PS: Auch für Nichtblinde gibt es ein paar Dinge, die sich manchmal besser machen lassen. Nimm dir z.B. mal die Dateieigenschaften des Explorers und versuche dort die Zahlen und Texte zu markieren/kopieren. (Abschreiben ist fehleranfällig) Auch/vorallem für Webseiten gibt es da ebenfalls etwas. Dort kann man auch Werbung bzw. den "wichtigen" Inhalt markieren. ![]() |
AW: Barrierefreiheit mit Delphi
Eventuell gar keine Themes nehmen, dann kann er die Windows eigene kontrastreiche Theme für Sehbehinderte auswählen, was dem Screenreader eventuell zu gute kommt.
|
AW: Barrierefreiheit mit Delphi
Ich hatte vor Jahren auch mal das Thema. Auch da hatte ich jemand der sich dafür eingesetzt hatte. Beteiligt war auch ein Verein der da eine Ahnung von den Anforderungen hatte.
Barrierefreiheit ist ein weites Feld. Ich empfehle nicht gleich mal die große Keule rauszuholen und auf Verdacht alles mögliche anzugehen. Stattdessen nimm die Hilfe des Mitarbeiters in Anspruch und erledige erst mal was ihn konkret stört. (Farbkombinationen sind da mal zuerst kein Thema da er wohl komplett blind ist.) |
AW: Barrierefreiheit mit Delphi
Zitat:
Zitat:
Für total Blinde gibt es passende Tastaturen und Screenreader mit Braille-Ausgabe. Gerade da wäre es gut, wenn der Screenreader besser filtern kann. Die Braille-Ausgabe könnte man entweder direkt ansprechen und geziehlt Text anzeigen, oder der Screen-Reader nutzt eine API, wo er dann dort nur das "Wichtigste" anzeigt. Ist ja meist nur eine ein-/zweizeilige Ausgabe, wo niemand sämtlichen Text des Fensters lesen will. |
AW: Barrierefreiheit mit Delphi
Zitat:
Wenn er gar nichts sehen kann, wird es etwas schwierig. Dann wäre es besser etwas eigenes zu erstellen, was die Arbeit erleichtert. Wenn es für jemand ist der schwer sehen kann, kann man alles etwas leichter machen, z. B. durch Elemente die wie Magnete wirken, also zb Buttons oder Felder die den Mauszeiger anziehen und mittig platzieren. Erst wenn man den Mauszeiger weit wegzieht, löst er sich vom Element. Das hilft ungemein, da man so sehr grobmotorisch arbeiten kann. Auch kann man den Text eines Buttons, Labels, Editfeldes, usw. vorlesen. Zumindest sollte man da schon eine Schnittstelle schaffen, so dass man später entscheiden kann was zu tun ist. Geht die Maus über einen Schalter, kann man sich den Text vorlesen lasen. Windows 7 (evtl. sogar früher) kann Texte vorlesen. |
AW: Barrierefreiheit mit Delphi
Ein weiteres Stichwort hier wäre TTS (Text to speach). Mit solchen Engines kann man dann einfach z.B. bei onHint den Hinttext zusätzlich akkustisch ausgeben.
|
AW: Barrierefreiheit mit Delphi
"Barrierefreiheit" ist ein technischer Begriff + als solcher definiert + gesetzlich verankert.
Hier findet sich eine gute Zusammenfassung (Focus Österreich, aber grundsätzlich ist das in D nicht anders): ![]() Das finde ich auch gut: ![]() |
AW: Barrierefreiheit mit Delphi
Mit der gleichen Thematik beschäftigt sich ein Team bei uns, soweit ich mitbekommen habe ist dieses Thema von der VCL unabhängig, die Interaktion mit einen Screenreader und der Braille-Zeile erfolgt eine Ebene höher.
Die Screenreader arbeiten sehr oft mit der UI Automation API ( ![]() ![]() Ein weiterer Punkt betrifft den Gesamtaufbau der Oberfläche, die muss für die Barrierefreiheit überdacht werden. Beispielsweise kann man sich die Frage stellen woran erkenne ich eigentlich wo ich mich befinde? Ist in der Navigationsleiste der aktuelle Eintrag einfach nur andersfarbig? Mit solchen Informationen kann ein Bilder garnichts anfangen, selbst wenn der Screenreader die Farbe vorliest, weitaus besser wäre ein Label aktuelle Position. Natürlich sollte sich das Programm auch vollständig über die Tastatur bedienen lassen, was eigentlich selbstverständlich sein müsste. Die Hersteller und Vertreiber von Screenreadern sind selbstverständlich auch daran interessiert das immer mehr Produkte Barrierefrei auf den Markt kommen, entsprechend sind die oft dazu bereit bei diesen Thema zu helfen. |
AW: Barrierefreiheit mit Delphi
Danke schon mal an alle. Einiges zum nachdenken und lesen.
Es geht tatsächlich um "Blind", nix teilweise oder so. Werde mich jetzt morgen nachmittag mal mit dem Mitarbeiter treffen. Ich denke er kann mir am besten erklären was er braucht. Ich nehme aber schwer an, dass in diesem Zusammenhang schon noch die ein oder andere Frage auftaucht. |
AW: Barrierefreiheit mit Delphi
Eine kurze Rückmeldung zu diesem Thema
Ich habe mich am Freitag mit dem Mitarbeiter getroffen und wir haben uns die Probleme "angeschaut". Habe dabei einiges gelernt über das Thema Barrierefreiheit. Die Lösung die wir im Moment anstreben ist erst mal sehr pragmatisch. Da die GUI und Funktionalität bei uns sehr sauber getrennt ist, wird es erst mal einen Speziellen Modus in den Betroffenen Programmen geben, die auf "einfache" Fenster aufbaut. Einfach in dem Sinne das die Benutzerführung verstärkt auf Tastaturfunktionalität aufgebaut wird, z.B in komplexeren Fenstern mit PageControls etc. die Auswahl von Tabs auf Funktionstasten gelegt wird. Wobei dann im Tab selber die FN Taste mit angezeigt wird etc. Dies erst mal als ersten Schritt um Ihm die Arbeit zu erleichtern. Der nächste Schritt ist dann, MSAA einzubauen. Als erstes in Grids, damit die Erkennung von Spalten und Zeilen besser wird. Ich habe auch einiges gelernt über die Unterschiede der am Markt erhältlichen Screenreadern. Die Unterschiede sind gewaltig, auch im Preis....... Alles in allem ein spannendes Thema und ich schäme mich immer noch, dies in all den Jahren die ich jetzt in der Entwicklung bin so sträflich vernachlässigt zu haben. |
AW: Barrierefreiheit mit Delphi
Im Grunde würde ich lieber die ursprünglichen Fenster anpassen, anstatt Zusätzliche einzubauen (außer als "vorübergehende" schnelle Hilfe, bis das Andere fertig ist),
Zumindestens sollten die beiden/mehreren Varianten schon ähnlich sein. (abgesehn von bissl was aus-/einblenden, Schriftgröße usw.) Denn das erleichtert erstmal euch die Arbeit (nur eine Form pro Modul pflegen) und vor allem die Arbeit der Mitarbeiter untereinander (Blinder mit Nicht-Blindem). Und vergiss nicht die Rollstuhlrampen im Spashscreen! |
AW: Barrierefreiheit mit Delphi
Zitat:
Es geht im Moment darum das der Mitarbeiter erst mal arbeiten kann. Danke für den Hinweis an die Rampen.... Die hätte ich glatt vergessen |
AW: Barrierefreiheit mit Delphi
Bei DevExpress lassen sich die Menüs/Ribbons zumindestens fast überall per Tastatur-Shortcuts ansprechen. (oft sogar automatisch generiert, wenn du die vergessen hast ... macht Spaß, wenn das dann Shortcuts von dir überdeckt)
Nur die Massen an verschiedenen Kontextmenüs (Header, Cell, Column, Row, View, Grid, ...), welche man an die Grids überall ranhängen kann, da hört es dann mit der einen Kontextmenütaste auf. |
AW: Barrierefreiheit mit Delphi
Ja da wird schon einiges auf uns zukommen,
aber es gibt auch einen neuen Blick auf die Usability. |
AW: Barrierefreiheit mit Delphi
Da bin ich von DevExpress nun doch enttäuscht. Gibts dazu ein Request bei dem man voten kann?
Edit: da z.B.: ![]() |
AW: Barrierefreiheit mit Delphi
Zitat:
es gibt aber eine Unit cxAccessibility, ich untersuche mal ob das irgendwo schon verwendet wird. Lustigerweise ist der Virtual Tree voll MSAA fähig. Ich schaue mir das mal an, wie es gelöst ist und werde versuchen auf dieser Basis eine Lösung zu bauen, für meinen aktuellen Bedarf. Ich habe nicht das Gefühl als ob Devexpress da was unternehmen wird. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:26 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz