OP
BlindHedgehogStew
New Member
Now, here's to all the lazy Linux desktop app developers that care exclusively about eye candy ...
Youre very tactics alone will Never Allow a visually-impaired person to Use Your app lest someone else either makes a TUI of that app, or worse for you, a low-ball GUI that actually performs - better - for the V.I. than the 'normal' one!
So let me clear my throat, put the needle on the record and knock down a word of developmental warning for those of you sighties - who still silently insist (with your code development practices) - that even blind people Should Not Be Using Linux!
So hereth goeth nada...
Orca handles most 'standard' programs well, but do watch out for dodgy apps with strange-looking interfaces; Orca's most important pair of requirements are that an application Can Only Use Standard Controls in a GTK+QT toolkit; (anything else will more than likely throw it off course, or worse, get stuck in a focus trap you can't get out of , say, like PavuControl. Next - and the definite biggy, - the application Should Have been coded with the correct names, or mostly decent names, for all controls in the main area, menus+menu items and dialog boxes. (This certainly includes the static text of an error message being able to be located and read independently
more often than not, I'm sadly seeing apps with OK or Close buttons, but no reason why an app crashed! Your choice of a desktop environment is surprisingly more important than you think, only because this choice now becomes the rendering 'law of the land' where GUI apps are concerned. In my case, I'm on #Mint + the #Mate desktop, which may appear bland and unwelcoming to most of the modern (or , is that, post-modern) audience, but read me here very carefully on this; The simpler a desktop layer is drawn, the less fluff and eye-candy Orca ultimately will have to deal with later! You'll thank me later and not know you actually needed to 'see' this; Consider this a public service announcement To All Linux App Developers! Shalt you fail to do what I outlined above
and Orca's done gonna be one perfect player at the silent game, when in fact, you really need a 'chatty Cathy"! Also, make sure you use the Right Kind of Control(s) per the pieces of information/choices to make. Drop-Down combo boxes Always Take Up Less Space than RadioButtons! If a checkbox Can Be Partially Checked, have a button nearby to spawn a smaller dialog to make choices Only Related to that checkbox! And don't let me find out you used a custom canvas in place of a general control that provides necessary info, say, songs in a playlist. DeadBeeF (by StarryHope) has a nasty not-so-little rendering secret where the list renders, but upon Tabbing to/object navigating to it, it only says "drawing area' - then nothing more! So now you'll never know what item in a playlist you're about to play by tapping the Enter key!
Youre very tactics alone will Never Allow a visually-impaired person to Use Your app lest someone else either makes a TUI of that app, or worse for you, a low-ball GUI that actually performs - better - for the V.I. than the 'normal' one!
So let me clear my throat, put the needle on the record and knock down a word of developmental warning for those of you sighties - who still silently insist (with your code development practices) - that even blind people Should Not Be Using Linux!
So hereth goeth nada...
Orca handles most 'standard' programs well, but do watch out for dodgy apps with strange-looking interfaces; Orca's most important pair of requirements are that an application Can Only Use Standard Controls in a GTK+QT toolkit; (anything else will more than likely throw it off course, or worse, get stuck in a focus trap you can't get out of , say, like PavuControl. Next - and the definite biggy, - the application Should Have been coded with the correct names, or mostly decent names, for all controls in the main area, menus+menu items and dialog boxes. (This certainly includes the static text of an error message being able to be located and read independently
more often than not, I'm sadly seeing apps with OK or Close buttons, but no reason why an app crashed! Your choice of a desktop environment is surprisingly more important than you think, only because this choice now becomes the rendering 'law of the land' where GUI apps are concerned. In my case, I'm on #Mint + the #Mate desktop, which may appear bland and unwelcoming to most of the modern (or , is that, post-modern) audience, but read me here very carefully on this; The simpler a desktop layer is drawn, the less fluff and eye-candy Orca ultimately will have to deal with later! You'll thank me later and not know you actually needed to 'see' this; Consider this a public service announcement To All Linux App Developers! Shalt you fail to do what I outlined above
and Orca's done gonna be one perfect player at the silent game, when in fact, you really need a 'chatty Cathy"! Also, make sure you use the Right Kind of Control(s) per the pieces of information/choices to make. Drop-Down combo boxes Always Take Up Less Space than RadioButtons! If a checkbox Can Be Partially Checked, have a button nearby to spawn a smaller dialog to make choices Only Related to that checkbox! And don't let me find out you used a custom canvas in place of a general control that provides necessary info, say, songs in a playlist. DeadBeeF (by StarryHope) has a nasty not-so-little rendering secret where the list renders, but upon Tabbing to/object navigating to it, it only says "drawing area' - then nothing more! So now you'll never know what item in a playlist you're about to play by tapping the Enter key!
Last edited by a moderator:
