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

[Octavian Rasnita]

From: "Adam Skutt" <askutt at gmail.com>On Jan 19, 11:09 am, "Octavian Rasnita" <orasn... at gmail.com> wrote:
> From: "Adam Skutt" <ask... at gmail.com>
> > Accessibility always requires special effort, and I don't see how
> > changing toolkits gets away from this.

>
> This is the most false thing I ever heard and the most dangerous.

O RLY?  http://www.wxwidgets.org/docs/technote/wxaccesstips.htm sure
looks like there's a whole host of things that I, the application
programmer, must do manually to enable an accessible application[1].
I can't just plop down controls and have an accessible application.


Well, to be sincere, I thought that you don't care, or even worse, and I am sorry because I was thinking that way, but I see that you don't understand what accessible means.

A GUI can be more or less accessible and the most accessible is the standard Win32 GUI / MFC. wxWIDGETS is not perfect because it has some controls that steal the focus and don't allow moving it to another control by using the tab key, or it has the HTML widget which is not accessible at all, but the most used controls like the buttons, list boxes, list views, text fields, radio buttons, check boxes... are perfectly accessible out of the box.

Those rules for creating an accessible application are obvious; like the fact that a button need to contain a text label and not only an image, or that an image needs to have a tooltip defined, or that a radio button needs to have a label attached to it, but all those things can be solved by the programmer and usually the programmer create those text labels.

If the programmer doesn't create those labels, the application won't be totally inaccessible. The users will tab around and they will hear that there is a button without name, or a radio button without name, but the user can use the application and by trial and error he/she might learn that the second button does this and the third button does that.

But the interfaces created with Tk, Gtk and QT are completely inaccessible.
This means that no object confirms that it got the focus, no text field returns the text it contains, and so on. Those applications are like an opened notepad.exe program with an empty file in which you try to tab around to move the cursor, but of course, nothing happends and you can't find any button, or list box in it.
In the Tk applications only the menus are accessible but that's the entire accessibility it offers.

> The programmer doesn't even know that the application will also offer accessibility features.

No, accessibility requires consideration in the design and
implementation of the GUIs, in all of those toolkits.  It is not
transparent, nor can it be transparent.  It requires both
consideration when laying out the widgets, but also ensuring that the
widgets have specific properties set.  How many applications have you
ever used that had focus order bugs?  That's an accessibility issue
that requires programmer intervention to get right.

Adam


Yes, those things should be followed for creating a better app, but what I wanted to say is that no matter if you do those things or not in a Tk, Gtk or QT GUI, they will be useless, because the screen readers can't understand those GUIS even they have text labels, and even if you will see a focus rectangle around buttons. They don't report that those objects have the focus so the screen readers won't speak anything.

Octavian