[TCLCORE] CFV Warning - TIP 733

[Kevin W. <kw...@co...>]

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