From: "Adam Skutt" <ask...@gmail.com> > Yet, for some unfathomable reason, you keep promoting wxWidgets even though it is plainly the inferior solution.
Inferior to what? I would be glad if you could tell me about a portable solution which is accessible with JAWS and Window Eyes, the most used screen readers under Windows (real glad). > Yes of course they can do that if they use the wrong tool. They can't do the > right thing if they believe that Tk or Silverlight or Flash is accessible no > matter if they follow the recommendations for accessibility, because the > screen readers don't support those interfaces. No, even using the right tools: http://doc.qt.nokia.com/qq/qq24-accessibility.html#dealingwithquirks (a few years old, but AFAIK still relevant). It's a crap shoot even if I use tools that support accessibility, because the APIs aren't very good. Some of the new APIs improve the problem, but some reading suggests there will still be the need for a lot of special case handling on both sides of the table. Exactly. When you will read that thing on a GUI creator site it means that that GUI is not accessible because the screen readers don't support it yet. The GUI libs manufacturers will say that the screen readers are bad because they don't offer support for their GUI, although that GUI offers accessibility features. Well, I don't care that the screen readers are bad and don't support some libs. I care only if the interfaces created with a certain GUI lib is accessible out of the box as WxPython is under Windows. > Nope, the cultural problem exists because the programmers use the wrong > interface, not because they just don't make the efforts for making that > interface more accessible. No, they don't think about it, they don't test, they don't make the necessary calls to enable accessible applications. Plenty of applications with poor to non-existent accessibility support are written with toolkits that support accessibility. You confuse again the accessibility with the usability or you think that if a GUI lib offers accessibility features it is accessible. Well, a GUI lib is accessible only if JAWS and Window Eyes offer support for it because those are the screen readers used by the majority and this is because they have the most features. > To be more clear and not to include in the discussion many interfaces, we are > comparing Tkinter and WxPython. No, we're not comparing just them, because they're hardly the only solutions. We were starting from the idea that Tkinter is worse than WxPython so let's come to that idea and not divagate. > I am not excluding anything. I said that all the Tk-based programs are > inaccessible no matter what the programmer does to make it accessible, > because the screen readers can't work with that interface. > And I have also said which are the accessible interfaces: wxWIDGETS (which > use Win32 GUI under Windows and Gtk under Linux), SWT (which I think it does > exactly the same thing as wxWIDGETS), WindowsForms (DotNet) and SWING (if the > user installs Java Access Bridge). This is not a complete list, or even a correct list, which was my point. My point was that Tkinter shouldn't be promoted by Python because it doesn't create accessible GUI out of the box at least for Windows as WxPython does. > It depends if there is a JAWS script defined. Stop. You've insisted many times that I need to not do anything special for making accessible applications. Yet, JAWS has an API entirely for the purpose of enhancing accessibility for specific applications! So, which is it? If I don't need to do anything special, then why does the API exist? Oh right, it exists so people can compensate for developers shortcomings. I've told you a lot of times that you confuse accessibility with usability. And I told you that the JAWS scripts can't make an absolutely inaccessible application made with Tk to be accessible. And that's why Tkinter is bad. The JAWS scripts can only improve the usability, can make the application be much friendly, but if it is not accessible, it can't make it accessible, because if it could do it, there would be no accessibility issues anymore. It's very hard to take anything you say seriously when you repeatedly get basic facts wrong and when you make claims that aren't consistent with the facts. Which are those facts? > If the user doesn't want or don't know how to create that script for > improving the usability, he/she might need to learn how to use the > application by trial and error, but what I want to show is that the user is > *able* to use that application, even if the interface is not very friendly, > but it would be absolutely impossible to use an application created with > Tkinter. He / she might be able to use the application. It's a "maybe", not a "for sure", yet you consistently imply it's the latter. Yes, but there is a chance to be able to use that application while if the application is done with Tk, she/he would have absolutely no chance to use it. > I am not talking about custom controls. Those things are the worst thing > possible from the perspective of accessibility, because usually nobody cares > about providing accessibility features. Yet I was talking about custom controls, and plenty of applications use custom controls, so you cannot ignore them even if you'd wish to do so. If the application uses custom controls and the programmer adds custom accessibility features for them (which usually never happends), that application might be accessible if it uses an accessible GUI lib. But if the programmer adds accessibility features to a Tk GUI, that GUI won't be accessible because the screen readers don't offer the necessary support for Tk. > My point was that Tkinter which uses Tk is bad, and I didn't tried too many > QT-based applications. No, you explicitly stated that Qt has zero accessibility support, which is simply false. You didn't say, "The ones I tried haven't worked", which is certainly possible depending on version and how Qt was compiled (since Qt is normally shipped with the application on Windows). You said, "But the interfaces created with Tk, Gtk and QT are completely inaccessible." If QT is not consistent and some versions can be accessible and other versions not, it means that QT should be avoided just because it is not consistent. A sane GUI should offer accessibility by default in all its versions without needing to activate anything in order to make the application accessible. Octavian -- http://mail.python.org/mailman/listinfo/python-list
