OP
BlindHedgehogStew
New Member
Now, here's to all the lazy Linuxians desktop app developers that care exclusively about eye candy
(did I - really write that, rofl) - ..?.
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 when the drum beat goes like this 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 Right Now!
So here 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 First 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 seemingly small choice now becomes the massive official 'law of the land' where GUI/TUI 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 'kids incorporated', lol) 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
(wait, see - this - in a world of post-modern development, does inclusion matter anymore, lol);
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"!
Although, there is definitely a such thing as 'too' chatty;
If this is a web-based application and you have to keep telling me about an unnecessary progress bar/other random info that has to be repeated every time keyboard focus changes (That for you is doing something, but for me does nothing,
you may have just lost a potential user).
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 use 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 truly know what item in a playlist you're about to play by tapping the Enter key!
(did I - really write that, rofl) - ..?.
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 when the drum beat goes like this 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 Right Now!
So here 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 First 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 seemingly small choice now becomes the massive official 'law of the land' where GUI/TUI 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 'kids incorporated', lol) 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
(wait, see - this - in a world of post-modern development, does inclusion matter anymore, lol);
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"!
Although, there is definitely a such thing as 'too' chatty;
If this is a web-based application and you have to keep telling me about an unnecessary progress bar/other random info that has to be repeated every time keyboard focus changes (That for you is doing something, but for me does nothing,
you may have just lost a potential user).
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 use 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 truly know what item in a playlist you're about to play by tapping the Enter key!
Last edited:
