Re: [TCLCORE] Update - tka11y

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

I think I’ve addressed these. 

> On Oct 27, 2025, at 4:11 AM, apn...@ya... wrote:
> 
> Confirmed the crash is fixed. Some additional anomalies between Tk and Ttk widgets noticed. Not sure if these are bugs or not. Reporting FYI
> 
> When you tab to non-ttk checkbuttons and radiobuttons , they narrate the label AND whether they are "checked/not checked". However, ttk::checkbuttons and ttk::radiobuttons narrate the label but not if they are checked/not checked.
> 
> When tabbed to get focus, ttk::spinbox narrates the current value in the entry. However, it does not narrate the new value if up/down arrow are used to cycle through the values. On the other hand, the non-ttk combobox does narrate new values when cycling using arrows.
> 
> Toggleswitch does narrate when it is toggled but the initial focus narrates as not selected when in fact it is selected.
> 
> -----Original Message-----
> From: Kevin Walzer <kw...@co...>
> Sent: Monday, October 27, 2025 3:13 AM
> To: apn...@ya...; tcl...@li...
> Subject: Re: [TCLCORE] Update - tka11y/
> 
> Hi Ashok,
> 
> Thank you so much for your additional testing. Please see my comments below:
> 
>> On 10/26/25 12:54 AM, apn...@ya... wrote:
>> - Hovering the mouse over a label or button or other text does not narrate
>> the text. Tabbing to the widget however does narrate the text. Hovering over
>> menus also does narrate the menu item. Note that with native Windows
>> applications, text does get narrated when hovering with the mouse even
>> without focus. If there is a window (of some native application) with text
>> *below* the Tk widget, the text in that window gets narrated instead (again,
>> on a mouse hover).
> 
> My design is built around keyboard navigation and syncing Tk focus
> events with accessibility focus to fire the appropriate notifications to
> the screen reader to narrate something, so mouse events have not been
> taken into consideration. Users of a screen reader are less likely to
> need mouse support. Any screen reader activity with mouse events is
> default behavior for the platform.
> 
> Here is what I observe as the native behavior on each platform:
> 
> 1. On macOS, VoiceOver does not respond to mouse events at all. It's not
> an expectation to have the widget value or text string narrated when a
> mouse passes over it. Since macOS is the first platform-specific
> implementation I worked on, that convention informed my approach to the
> other platforms.
> 
> 2. On Windows, I see the behavior you are describing - moving the mouse
> causes NVDA to say "window" without any additional detail on the widget
> (usually because that is what has focus). Keyboard navigation is
> required to get the full widget data.
> 
> 3. On Linux, Orca does narrate widgets and their text/title/description
> on mouse events. When I was developing X11 accessibility, this
> functionality was a bit misleading, because keyboard navigation
> initially did NOT trigger narration of the widget details. Keyboard
> navigation now works correctly.
> 
> Additional research shows that MSAA does not have any kind of built-in
> support for hover events; UI Automation does, and that is likely what
> you are seeing when you get a widget fully narrated after an <Enter>
> event.  I've played with a few ideas to see if we can fake this behavior
> with MSAA, and nothing has really worked.  Since MSAA lacks support for
> hover events and UIA integration is currently very limited, the
> narration with mouse events can't be supported at this time.
> 
>> - When typing into the text widget, last letter is repeated (for example,
>> typing "word" narrates w, o, r, d, d)
> This has been corrected.
>> 
>> - There is also a crash on exit for which I have submitted a ticket.
> 
> I committed a fix that appears to solve the crash-on-shutdown issue;
> please test.
> 
> Unless you or anyone else finds additional issues of substance in the
> next week, I plan to call for a vote so we can get this into Tk for the
> next alpha release of 9.1.
> 
> --Kevin
> 
> 
>