Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" <askutt at gmail.com>
On Jan 20, 2:22 am, "Octavian Rasnita" <orasn... at gmail.com> wrote:
> Where do you got the conclusion that the accessibility is so poor?

By an examination of the facts.  MSAA is universally hated and all
screen readers actively have to work around it and its many
limitations (meaning that as an application programmer, you can do the
"right" thing and still get undesired behavior through no fault of
your own).  I have no clue if it's replacement is better, but I do
know few programs use it, so it's little comfort.


The Windows applications are not accessible only if they use MSAA. The 
screen readers know how to get the necessary information for making the 
interfaces accessible in other ways, but of course, it is harder for the 
screen reader manufacturers if the GUIs don't respect a standard.
And if MSAA is hated it doesn't mean that the accessibility is so poor as 
you might think.


The situation on Linux is still an outright disaster.  Neither Qt4 nor
GTK enable accessibility functionality automatically and support from
the various distribution vendors is pretty limited.  It is improving,
however.


It might be true, I don't know, because I use Linux only in command line 
mode.


Accessibility still requires special effort "over and above" the norm
by the programmer whether you believe this to be the case or not.


I don't understand how I need to "believe" this, while I made perfectly 
accessible applications without doing special efforts for making them to be 
accessible.
Of course, I don't consider something special to put a text label on a 
button, or radio button or check box.


Most programmers aren't even aware of the fact they must consider it
(a point you've made yourself before!) and hence commit various
accessibility sins.  This is mostly a cultural problem, not a
technical one, but it's still a real problem.


Yes, that's a problem but we divagate. The programmers need to take care 
about those details, like putting text labels on buttons, or tooltips for 
images, but these things are relevant only for accessible widgets. It 
*doesn't matter* if they put those labels if they use GUIS like Tk because 
they won't be accessible at all anyway.


Plus, out of the stuff I run daily on Windows: two of the applications
are entirely inaccessible: the Adobe AIR one and the Gtk one.
Songbird, the XUL based music player, has some accessibility, but none
of the navigation controls seem to be enabled, which would make it
very difficult to actually use, I imagine.  It's also not particularly
keyboard friendly: you don't even get a visual focus indicator most of
the time, even though the focus is moving.


Yes of course, Adobe's products are at most very hard accessible or not 
accessible at all and I already said that Gtk is not accessible under 
Windows, just like Tk.


> But You keep telling me that it is hard to create accessible programs, 
> which
> is false, but you don't know and don't want to try to see.
> Try to create a WxPython app that doesn't do anything but only displays 
> some
> menus, buttons, combo boxes, list boxes, list views, tree views, text
> fields, check boxes, radio buttons... and you will see that they are very
> accessible with that screen reader I told you about, without requiring you
> to do anything special that you wouldn't do otherwise.

Applications that only display these things aren't very interesting.
And no, they still require additional effort.  Most developers can't
even be assed to get a sane tab focus order set,


Well, I haven't used WxPython until now, but only WxPerl, however the WxPerl 
programmers don't need to set the tab focus because by default the tab focus 
is set in the order of the controls on the form and I thought it should be 
the same in WxPython.
So no special effort would be necessary.

Are you sure you are not confusing accessibility with usability?
Of course that an application which respects more usability rules is easier 
to use, and this means that it should have the controls with a right tab 
order, with clear text labels and so on, but we can talk about usability 
only for an accessible GUI.

JAWS screen reader has its own programming language and it can be used for 
improving the usability of a program. It can do very many things and it has 
more than 1000 functions, but it can't do anything in the case of 
inaccessible interfaces like Tk.


> to say nothing of keyboard shortcuts, accessibility descriptions / proper 
> label
associations for buttons and other controls.
It gets even more complicated when you get away from controls only
meant to display text.  How many web pages have you visited where
images are missing alt tags?  Do you really thing those same people
are going to bother trying to do the right thing if asked to create a
desktop GUI application?  No, they're not, and you're going to get
whatever happens automatically.  Which isn't nothing (in some
toolkits), but it's also not what one really wants, either.


Yes, that's true, but as I said, some GUIS like WxPython offer the 
accessibility, so those controls are visible, and it is less important if 
they are in a right tab order or if some of the controls are not labeled, 
because the screen reader can solve these things.
But the screen reader can't solve the absolute inaccessibility of GUIS like 
Tk because it can't read anything from it.


> How do you came to the conclusion that QT is accessible on all operating
> system?

By actually going out, reading, and even testing?  Qt has had
functional accessibility support on OS X and Windows since Qt3, and
functional support on Linux, OS X, and Windows since Qt4.  It even
extends to PySide, with a few limitations: you can't write custom
accessible widgets in PySide, though I'm pretty confident they'd
enable support if someone wrote a patch to enable the bindings.


A GUI which offers accessible widgets only if they are coded specially for 
beeing accessible are not accessible at all, because most programmers won't 
care to make the applications accessible so the results will be bad anyway.

> When you talk about accessibility, try it yourself and don't take the word
> of the GUI widgets developers.
>

I just did, NVDA was able to read my button text and its accessibility
description just fine, both in C++ and Python versions of my Qt
application.  I didn't bother testing Linux or OS X, but I'm sure it
would work there too.


Have you created that QT application with its default options? Without doing 
anything special to make it accessible?
And most important, have you tested it with JAWS screen reader? (Or 
WindowEyes at least) because these are the most used screen readers.
NVDA is pretty poor and it can't be used for very complex things (yet).


Octavian