Replies: 7 comments 1 reply
-
Have you looked at the SPL add-on?
It is not integrated in NVDA core, and I believe it is no longer being actively
maintained after earlier this year, but it is potentially good to suggest to
your customers.
https://addons.nvda-project.org/./addons/stationPlaylist.en.html
CC @josephsl
|
Beta Was this translation helpful? Give feedback.
-
Hi, yes, we advertise it on our website and people are using it, but it doesn’t help with every option in all our software modules. It seems a small change in NVDA itself should resolve this issue since it is reading one field title correctly. |
Beta Was this translation helpful? Give feedback.
-
Hi @rosslevis, I'm now the new maintainer of this add-on. The repo linked on the site will now redirect to my repo (which is this link. Yes, this add-on is not currently in active maintenance, mostly because, admittingly, I do not currently have enough knowledge of Python and NVDA source code, as well as other life commitments outside of this adventure, for me being able to actively maintain it, as well as another one I will be maintaining (much smaller than this add-on). The next update that I may release this month will just be a manifest update to update add-on maintainer information. If you'd like, I can give you what exactly NVDA is calling this edit control via Iaccessible from NVDA's Log Viewer. |
Beta Was this translation helpful? Give feedback.
-
Also, as far as I understand it (both from dabbling with scripting myself and also what @josephsl said in an issue about it on the repo, it uses screen scraping to be able to determine what the edit field is and announce it to JAWS users. NVDA does not use this mechanism (if at all) and relies on accessibility information to be able to determine what the name, role, etc of a control would be. |
Beta Was this translation helpful? Give feedback.
-
Hi, It is more likely that we need to get a conversation going between us (NVDA community), Ross and SPL users, and Delphi/framework developers about what to do. NVDA does use screen review functionality to look at screen labels for some controls (namely, Options screen in SPL Studio), but it would be great to have label information exposed via MSAA/IAccessible, or better yet, UI Automation (look at appModules/splstudio/init.py's event_NVDAObject_init for info on how this was done for some controls). Adding Delphi's "tnt" window class name will require editing IAccessible objects support facility (NVDAObjects/IAccessible package) inside NVDA source code provided that Delphi folks says something about these controls. At a personal level, telling NVDA to look around the screen for control labels is perhaps one of the most requested bug fix I have received over the years while maintaining SPL add-on (alongside support for encoders), and I realized not long ago that fixing it will require talking to framework developers so other apps can benefit from Delphi changes (I believe GoldWave's interface is also written in Delphi as evidenced by window class names). I have let go of SPL add-on earlier this year to reduce NVDA community workload. Thanks. |
Beta Was this translation helpful? Give feedback.
-
It would be a really good opportunity to rethink #10058. This PR has been abandoned but it is open to be taken by someone who wants to improve things on this level. cc: @LeonarddeR |
Beta Was this translation helpful? Give feedback.
-
See my reply to Joseph above. |
Beta Was this translation helpful? Give feedback.
-
I’m the main developer of software which a large number of blind users are using. I strive to make the software it as accessible as possible, however, it is written in an old development system Delphi 7 which doesn’t support the Windows accessibility interfaces, and a lot of blind people are struggling to read the labels associated with some components. The labels are implemented as STATIC text usually just to the left of the field. JAWS users have no issues so there must be a simple solution.
It has come to our attention that NVDA is able to read labels in our software for some standard Delphi components. An advanced user has determined that a Delphi TEdit control, which relates to the standard Windows Edit control, can have the associated static text read correctly by NVDA, yet just below that on the same window, we have another static text and a TTntEdit control which cannot be read. We use some 3rd party components such as TTntEdit which enable Unicode characters to be entered. This is derived from a TEdit and looks and works identically, yet NVDA cannot read the associated label. I suspect NVDA knows about Delphi programs and reads the standard component types supplied with Delphi but ignores all others.
Could you please look into adding support for components that prefix the standard controls with “Tnt”. eg. TTntEdit, TTntComboBox, TTntMemo, etc. I suspect it will be a quick change in your software and will help many hundreds of users.
Thank you for the consideration.
Beta Was this translation helpful? Give feedback.
All reactions