He said that he is currently working on integrating AccessKit into GTK, which would make GTK applications accessible on Windows and macOS for the first time.
Finally! GTK advocates like to say GTK is a professional toolkit that is cross platform and accessible, but they never mention, unlike Qt, it is not (so far) cross platform accessible. It was not possible to choose GTK over Qt if you wanted cross platform accessibility for, say, PDF reader.
I think we should do UI/UX testing with the a11y toolkits, that gives developers a reason to care about a11y. Someday, when I have time, I want to work on this, but that probably won’t be for a good long while, hopefully someone beats me to it.
The accessibility APIs are in fact used for automated testing in both Windows and GNOME, though perhaps not enough. In theory, if an application has comprehensive automated UI tests, then it should also be fully usable with an assistive technology. But, of course, the tests aren’t necessarily comprehensive, and the test authors may be depending on implicit knowledge of the application that a blind user (for example) doesn’t have. So in other words, the tests may test the application’s functionality without fully testing its accessibility.
I think it’s possible that the push model of Newton (the new accessibility architecture I described in my talk) will have the side effect of also making automated tests more robust and efficient.
I found that the current architecture is extremely likely lead to bugs where some info gets stuck in some library along the ipc path. These problems simply don’t exist in browser implementations.
Having one super robust owner of accessible metadata would be huge.
I’m the one that gave the presentation. I’m happy to answer questions here. Also, the presentation is available on YouTube.
Finally! GTK advocates like to say GTK is a professional toolkit that is cross platform and accessible, but they never mention, unlike Qt, it is not (so far) cross platform accessible. It was not possible to choose GTK over Qt if you wanted cross platform accessibility for, say, PDF reader.
I think we should do UI/UX testing with the a11y toolkits, that gives developers a reason to care about a11y. Someday, when I have time, I want to work on this, but that probably won’t be for a good long while, hopefully someone beats me to it.
The accessibility APIs are in fact used for automated testing in both Windows and GNOME, though perhaps not enough. In theory, if an application has comprehensive automated UI tests, then it should also be fully usable with an assistive technology. But, of course, the tests aren’t necessarily comprehensive, and the test authors may be depending on implicit knowledge of the application that a blind user (for example) doesn’t have. So in other words, the tests may test the application’s functionality without fully testing its accessibility.
I think it’s possible that the push model of Newton (the new accessibility architecture I described in my talk) will have the side effect of also making automated tests more robust and efficient.
That’s how Cocoa does it.
Yay Cocoa!
I found that the current architecture is extremely likely lead to bugs where some info gets stuck in some library along the ipc path. These problems simply don’t exist in browser implementations.
Having one super robust owner of accessible metadata would be huge.