|
From: Kevin W. <kw...@co...> - 2025-10-27 20:31:58
|
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 > > > |