|
From: Kevin W. <kw...@co...> - 2025-10-18 21:07:18
|
Hello all, This is a CFV warning for TIP 733, screen reader/accessibility support for Tk. I consider the project feature complete and as stable as I can make it at this point. I'd appreciate final reviews/comments, and then I will call for a formal vote in the next couple of weeks. My goal is to include TIP 733 in 9.1.a1, which I understand is by the end of November. I've received detailed feedback from Ashok, Jan, and Nico. I'd like to address each point: 1. Nico reported a crash on startup. I am not able to reproduce this crash. 2. Jan noted that the test suite failed on all three platforms during automated Github runs. I added code to accessibility.tcl to return an empty namespace if a screen reader isn't running. That way there will be no unintended side effects from the accessibility commands conflicting with the test suite, which now runs normally on all three platforms. Note: I am NOT including automated testing of accessibility within the test suite itself. Accessibility is best tested through interactive use of a screen reader. 3. Toggleswitch - Added and made accessible on all platforms. This implementation may be refined in the future as the widget is brand new, but for now I just wanted to ensure the widget's inclusion in accessibility. 4. "Set/get" balance in commands - complete. 5. Language issues/macOS - I have not received further feedback on my fix. This is not a showstopper for approving the TIP, in any case, but can be addressed later through bug reporting if needed. 6. Progress bars - I have opted for a simple implementation that returns a verbalized "busy" if the widget is running. This means that if a progress bar is visible, it will report "busy" even if it is not running - the best solution here would be to hide the widget when not active. (That's what I do in my apps.) There is no easy way to track the animation state of a running progress bar in real time, and I judged the complexity of supporting this to be not worth the effort. If anyone disagrees, they are welcome to submit a patch after the TIP is finalized. 7. Echoing keypresses and the prior word in text and entry widgets - done, on all three platforms. I think that is the most significant addition based on the prior feedback and brings Tk accessibility much more in line with expectations - thanks for that suggestion, Ashok. 8. Microsoft Narrator support - rudimentary. Ashok, I have been able to implement all your suggestions - but they only work well with NVDA. (I also assume they work with JAWS, but as it is an expensive proprietary product with a subscription licensing model similar to Adobe, I have not attempted to use it.) UI Automation is a significantly more complex API than Microsoft Active Accessibility, which is no lightweight API in itself. I have spent a great deal of time trying to make UIA and MSAA work together, but have not made any progress. The LegacyIAccessible pattern that I've implemented for UIA support does not do much, and attempting to develop a complete UIA implementation has risked turning the Windows portion of this project into a mess. Unfortunately, the accessibility environment on Windows is quite fragmented, and requires the developer to make some choices. My choice has been to focus on MSAA, which lines up very well with Tk's widget set and overall UI design, and NVDA, which is an extremely robust, FOSS screen reader. Ashok, if you install NVDA and run the widget demo, you will see a significant difference. My decisions here also mean that we have to document that Narrator is not well-supported, which I have noted in the TIP. I am not happy with this, but those are the choices Windows presents. A proper UIA implementation is a project for another day, and given I have spent 18 months on just this, I may opt to leave that for someone else to implement. Looking forward to any further comments. Thanks to all. --Kevin |