nvaccess
Screen layout is not consistent to its description in the documentation
Steps to reproduce:
- Open this wikipedia article.
- If it is not already off, turn screen layout off.
- Search for "from wikipedia", then arrow down several times.
Actual behavior:
down arrow
This is a list of historical and living
down arrow
link Bosniaks (of
down arrow
link Bosnia or the Bosnian diaspora) who are famous or notable sportspeople.
down arrow
heading level 2 Basketball[
down arrow
heading level 2 link edit ]
Expected behavior:
According to the documentation:
This option allows you to specify whether browse mode should place clickable content (links, buttons and fields) on its own line, or if it should keep it in the flow of text as it is visually shown. Note that this option doesn't apply to Microsoft Office apps such as Outlook and Word, which always use screen layout. When screen layout is enabled, page elements will stay as they are visually shown. For example, a visual line of multiple links will be presented in speech and braille as multiple links on the same line. If it is disabled, then page elements will be placed on their own lines. This may be easier to understand during line by line page navigation and make items easier to interact with for some users.
Currently these are not in its own line. So either change the documentation, or the page should look like this:
down arrow
This is a list of historical and living
down arrow
link Bosniaks
down arrow
(of
down arrow
link Bosnia
down arrow
or the Bosnian diaspora) who are famous or notable sportspeople.
down arrow
heading level 2 Basketball[
down arrow
heading level 2 link edit
down arrow
]
(I would usually be able to notice if a link has ended because I have report colors on, but not in this case. Also, at least JAWS does put links in its own line).
NVDA logs, crash dumps and other attachments:
System configuration
NVDA installed/portable/running from source:
NVDA version:
2023.3.3
Windows version:
Edición: Windows 10 Home
Versión: 22H2
Compilación del sistema operativo: 19045.3930
Experiencia: Windows Feature Experience Pack 1000.19053.1000.0
Name and version of other software in use when reproducing the issue:
Firefox 122.0.1 (64-bit)
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
No, but I'm sure this has happened for a long time.
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes
Does this only happen with this Wikipedia page or with other pages or websites? Have you tried this page with other browsers?
Yes to both. It also happens in Chrome and Edge, and in this page too (turn screen layout off, and navigate between comments).
You really need to try it in Firefox and its derivatives. I've seen this sort of thing before when a page has a lot of links on it embedded in the text.
Brian
-- @.*** Sent via blueyonder.(Virgin media) Please address personal E-mail to:- @.***, putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: Sukil Etxenike To: nvaccess/nvda Cc: Subscribed Sent: Friday, February 16, 2024 8:19 AM Subject: Re: [nvaccess/nvda] Screen layout is not consistent to its description in the documentation (Issue #16182)
Yes to both. It also happens in Chrome and Edge, and in this page too (turn screen layout off, and navigate between comments).
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
cc: @jcsteh tagging you since the knowhow regarding this feature is very old and quite important. Maybe you can help in getting to a solution here. Jaws seems to place the links on their own lines as expected. NVDA does not create a field node at the end of the link AS INDICATED BY the child element in the object navigation. So the document review is not in sync with the object hierarchy. At the links position, document review spans until the character before the next link. So the new line in the virtual document is triggered before the second link. This needs to be solved in the NVDA helper I guess by redefining field nodes and where the child elements should begin and end in the virtual document. Maybe when screen layout is off, every direct child element of the main page should be placed on its own line. In this case, the word "of" between both links is a separate child element of the wikipedia page.
When screen layout is disabled, NVDA always places links at the start of a new line, which we assumed is why most people want this functionality: to make it easier to get to links, rather than having links start in the middle of a line. A long time ago, lines did end at the ends of links too, but users complained because this caused spaces, punctuation, etc. to end up on their own lines, effectively resulting in blank lines between links in some cases. For example, consider something like this:
This is a link, another link and finally another link.
If we do as you're requesting (and as we did previously), you'd get this:
This is
link a link
,
link another link
link and finally another link
.
Note the comma, the space and the full stop on their own lines. The space is particularly annoying because it effectively causes a blank line, but by this rule, it has to be on its own line because there's a space between the two links and links must be on their own lines. To avoid this, this was changed to the current behaviour in 7638c331a0e2.
I agree that at the very least, the User Guide is inconsistent with this behaviour and should be updated. Whether we want to revert to the old behaviour is not a question I can answer, but be aware if that if we do, the above annoyance will occur.
Ah, I understand the reasoning then. No idea what users would prefer (I use screen layout myself but heard complaints about the inconsistency between NVDA and JAWS in this regard).
@jcsteh I see, so indeed placing each child element on a separate line might not make sense unless we have an option to exclude blank lines in browse mode. Actually that seems to be the way Jaws tackles this problem. In the virtual document blank lines between texts or elements can be optionally suppressed. I remember there was a PR trying to add this option in NVDA but don't remember why it has not been implemented.
to be more precise, it seems Jaws ignores blank line in all navigation paterns in browse mode except for character by character navigation with left and arrow keys or when selecting with shift+left and right arrow keys.
What about punctuation; e.g. the comma and full stop in my earlier example? They don't count as blank lines, but they still effectively cause the same annoyance.
Jaws seems to only render punctuation on the same line as the link or other element in the virtual document, but plain text is separated and blank lines are ignored. If there is plain text after an element such as link or button, the next line in the virtual document begins with the space character followed by the first character of the plain text.
@seanbudd the initial author writes:
(I would usually be able to notice if a link has ended because I have report colors on, but not in this case. Also, at least JAWS does put links in its own line).
I interpret this as a wish to display links or elements on their own line as far as possible like Jaws does. I don't think this is a quick fix here.
I personally use screen layout. I've heard complaints about this behaviour (about links not being separated from the text in both sides), and when I realised that the documentation was inconsistent with the actual behaviour, I thought of reporting it. I don't know which would be the right course of action: on one hand, we have peoople who are used to other how JAWS does things, and on the other, people who are used to how things are right now. If I hadn't got used to screen layout, I would indeed be in the first group (influenced by previous JAWS usage).
I interpret this as a wish to display links or elements on their own line as far as possible like Jaws does. I don't think this is a quick fix here.
We triaged this as we would accept a documentation change to more accurately reflect the current intended design. This is a quick fix.
