Don't use IA2TextTextInfo on the web for object review and read line.#20096
Conversation
|
@jcsteh I still have a few issues with this. Implementation.Why customize parts of NVDA to use the NVDAObject textInfo in places where it previously used the IA2TextTextInfo? Why can't we just make IAccessible._get_TextInfo return NVDAObjectTextInfo where it previously returned IA2TextTextInfo, and go over each case where IA2TextTextInfo is needed, and make those explicitly use it? Features such as move navigator object to focus, and move the review cursor to the beginning/end of the navigator object will now still use IA2TextTextInfo, unless those gets customized as well Usefulness of reading the visual text.There are times where being able to read the visual text makes the difference between being able to use a website and not. A few days ago, I was in such a situation. There were two buttons, witch according to the Accessibility information was both called "Change password", but when I read the visual text with the review cursor reading commands, I found out that one was called next and the other cancel. Could we please make a setting to toggle if NVDA should use IA2TextTextInfo or not? |
I'll look into this.
That's fair, but there are a greater number of cases where the reverse is true. Most users are not going to understand that distinction, especially because it's inconsistent with what gets reported in both browse mode and object reporting in focus mode.
The vast majority of users are not going to understand what the setting means, nor does it make any sense in the presence of embedded objects. So unless the core team insists on this, I'm not willing to do it. |
|
The setting could be put in the advanced category, though. Then people who don’t know what it is, will not mess with it, and in case it breaks something, NVDA could use IA2TextTextInfo by default for now. This current implementation has the potential to break stuff as well, as shown with the things I mentioned. The only way to fix those, is to customize, customize, customize, and further customize. This is the exact reason JAWS went down the drain. They added short term solutions to fix problems, and that eventually ended up making it into one of the most unstable screen readers out there. Most people doesn’t know what ‘use UI automation in Microsoft Word documents’ means either, but it is still very useful to be able to switch between UIA and the legacy object model. For that matter, most people doesn’t know what object navigation, OCR, screen review, etc, etc is either. Yes, I agree that how it is handled is confusing, but reading the display text in a GenericWindow object, and reading the text from the UIA text pattern in a none-editable control, is done in the exact same way, except in those cases, the content is also shown on the braille display, but users can use the display speech output mode to get the information anyway. At least, if it remains as it was, the people that complain about that behavior has other ways to access the missing information, such as by using MVDA plus numpad five instead of numpad eight.Sendt fra min iPhone12. mai 2026 kl. 23:22 skrev James Teh ***@***.***>:jcsteh left a comment (nvaccess/nvda#20096)
Why customize parts of NVDA to use the NVDAObject textInfo in places where it previously used the IA2TextTextInfo? Why can't we just make IAccessible._get_TextInfo return NVDAObjectTextInfo where it previously returned IA2TextTextInfo, and go over each case where IA2TextTextInfo is needed, and make those explicitly use it?
It is a lot riskier. I didn't even know about the details annotation case last time I tried that, so it's likely there is more usage which is also only likely to be spotted after the fact, potentially in add-ons as well.
TextInfo was never guaranteed to be purely for user consumption.
Features such as move navigator object to focus, and move the review cursor to the beginning/end of the navigator object will now still use IA2TextTextInfo, unless those gets customized as well
I'll look into this.
There are times where being able to read the visual text makes the difference between being able to use a website and not. A few days ago, I was in such a situation. There were two buttons, witch according to the Accessibility information was both called "Change password", but when I read the visual text with the review cursor reading commands, I found out that one was called next and the other cancel.
That's fair, but there are a greater number of cases where the reverse is true. Most users are not going to understand that distinction, especially because it's inconsistent with what gets reported in both browse mode and object reporting in focus mode.
Could we please make a setting to toggle if NVDA should use IA2TextTextInfo or not?
The vast majority of users are not going to understand what the setting means, nor does it make any sense in the presence of embedded objects. So unless the core team insists on this, I'm not willing to do it.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
@jcsteh Here is yet another bug. In firefox, when tabbing through controls, the review cursor still uses the IA2WebTextTextInfo, as a TextInfo is returned when calling makeTextInfo(TextInfos.POSITION_CARET). For whatever reason, when landing on an object in firefox when the navigator object was previously outside the document, when using object navigation, when switching from document to object review, or when manualy activating focus mode, it works as intended |
#20134) ### Reverts PR Reverts #20096. ### Issues fixed Fixes #20096 (comment) and #20096 (comment). ### Issues reopened Reopens #15159. ### Reason for revert The implementation in #20096 still reviewed the wrong content if you focused a control by pressing tab in focus mode or if you used the review top/bottom line commands. I submitted #20132, but given the proximity to beta, it seems safer to wait for 2026.3 instead. ### Can this PR be reimplemented? If so, what is required for the next attempt See #20132.
3 participants
Link to issue number:
Fixes #15159.
Summary of the issue:
In focus mode in web browsers, when a control specifies a label using aria-label or aria-labelledby, it is impossible to review or spell that label; e.g. using read current line or the review cursor. This is particularly annoying and detrimental to efficiency when using web apps such as Gmail and Slack, among others, where you have to switch to browse mode to work around this even though it might be more efficient to use focus mode for navigation.
Description of user facing changes:
In focus mode in web browsers, it is now possible to review and spell the labels of controls when those labels are specifically provided for accessibility; e.g. via aria-label or aria-labelledby.
Description of development approach:
When in focus mode, for non-editable controls, both speech and braille report the name, description, value, etc. of the control; they don't use the TextInfo. However, previously, the review cursor and the read line command always used the TextInfo. Since IA2TextTextInfo is used for all objects supporting IAccessibleText, this meant that if the content wasn't a flat piece of text equal to the label, the review cursor and read line command would report something different, often nothing at all.
To fix this, for IA2Web objects that aren't editors, use NVDAObjectTextInfo instead of the object's TextInfo for object review and the read line command. I first attempted to do this generically in #18271 using
_hasNavigableText, but this caused problems elsewhere. Instead, the scope of this change is very specific, introducing a new_shouldUseTextInfoForReviewNVDAObject attribute which is only set to False for Ia2Web objects.Testing strategy:
In both Firefox and Edge:
data:text/html,<textarea>abVerified that in focus mode, formatting info is still reported for the review cursor, indicating that the correct TextInfo is being used. Also verified that the review cursor tracks the caret.
Known issues with pull request:
The narrow scoping here means that this probably doesn't fix #11285 in the Chrome UI. I was never able to reproduce it, so I can't verify that. Regardless, I think that should be addressed separately, though the new property should make that much simpler.
Similarly, this may mean we can revert VS Code specific changes such as #17573 and #16248. However, I'm not willing to risk that at this stage, given the churn this caused last time and the fact that I don't use VS Code myself and am unwilling to test it. There is no conflict here and it can easily be addressed in a follow-up if this proves to be feasible.
Code Review Checklist: