Inconsistent presentation of `aria-invalid` with screen layout disabled

[lukaszgo1]

Discovered as part of #11906

Steps to reproduce:

1. In either Firefox or Chrome open data:text/html,<p>Big <span aria-invalid="spelling">caat</span> meos</p>
2. Navigate through the text with screen layout both enabled and disabled.

   Actual behavior:

   With screen layout disabled the document is presented as follows:

   Big
   spelling error caat meos

Expected behavior:

Spelling error should not be presented in the separate line regardless of the screen layout being enabled or disabled. Alternatively spelling error should be presented in a separate line though I don't like this very much.

System configuration

NVDA installed/portable/running from source:

From sources

NVDA version:

Latest master as of 12-th of February.

Windows version:

Windows 7 localy and whatever version of Windows 10 is currently in use on AppVeyor

Name and version of other software in use when reproducing the issue:

Firefox, Chrome

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.

The same problem can be reproduced in NVDA 2019.2

If addons are disabled, is your problem still occuring?

Yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

No

[JulienCochuyt]

@lukaszgo1 wrote:

Expected behavior:

Spelling error should not be presented in the separate line regardless of the screen layout being enabled or disabled.

Isn't it precisely what screen layout is all about? Please do correct me if I'm wrong, but the way I understand it:

• screen layout on: Present as much as possible on one line what fits on one line on screen
• screen layout off: Split on logical boundaries, to allow for more granular review and interaction.

The spelling error being presented on a line on its own, it is then easier to determine where it begins and where it ends.

[lukaszgo1]

The spelling error being presented on a line on its own, it is then easier to determine where it begins and where it ends.

I was looking at this from the perspective of a word processor user where spelling errors are just a part of the text but I'm happy either way as long as this is consistent. I've mentioned what you've proposed as an alternative implementation in my first comment i.e.

Alternatively spelling error should be presented in a separate line...

[JulienCochuyt]

Sorry for the misunderstanding. Do you complain about aria-invalid on a web page not presented the exact same way as a spelling error in a word processor depending on the "screen layout" setting? As pointed out by @leonardder in https://github.com/nvaccess/nvda/pull/11906#issuecomment-739800931

Note that screen layout of is a virtual buffer specific thing. It doesn't work in browse mode in Word, Excel, Outlook, Kindle, etc.

Hence, I'd say that IMHO aria-invalid presentation with screen layout on is coherent with spelling error presentation in a word processor and there is no point in comparing with screen layout off.

I agree this is not obvious from the preference dialog nor from the user guide.

[CyrilleB79]

Hello

I agree that consistency should be respected. Maybe it is just a matter of habit but personally, I would prefer not to have the spelling error alone on its line even with screen layout off mode (mode that I am usually using). For a real life example, I am regularly writing e-mail in an edit field of a browser page (webmail). My messages contain spelling errors due to unknown technical terms or invented terms such as variable names. I like to re-read the message line by line with down arrow because the granularity is adapted to make potential corrections. I am interested in having spelling error reported in case I have made a real error but I do not want my line to be split in many parts. Of course, it is just my personal experience and some may want to have a different result.

Some additional points to note for this issue:

• Font formatting reporting (e.g. bold, italic) fortunately do not lead to line splitting when enabled
• If reporting of spelling error is disabled in document formatting settings, it seems to me that the line should not be split in any case, i.e. even with screen layout off.
• the same issue occurs for text revisions (<ins> and <del> tags) and thus should be handled at the same time.

[JulienCochuyt]

I agree with both of you that consistency is of most importance. When it's not the case, the documentation / UI should probably make it more clear.

We've made a quick internal consultation on the matter here at @Accessolutions and unanimously settled on supporting all the points raised by @CyrilleB79 in https://github.com/nvaccess/nvda/issues/12067#issuecomment-826883032.

The only short lived controversial point was about <ins> and <del>, as there are actually two main use cases regarding these: consultation and validation.

Screen layout off is a feature mostly easing interaction with content, especially for non-advanced users This is why we support #11716. As the validation use case is less prominent than the consultation one, we feel it's important to provide the smoothest reading experience by default. If interaction is needed for corner cases, there are other means to achieve it (eg. WebAccess)

[Adriani90]

I agree from an user perspective it feels like <ins> and <del> elements make sense to be displayed on one line each. They appear i.e. when changing a title of something like a github issue etc. So it is convenient to see the old title on one line and the new one on the next line.

As far as I understand NVDA's behavior in browse mode with screen layout off, the line separator applies at the end of each fieldnode, and fieldnodes are defined in the NVDA Helper. So it should be somehow possible to stop spelling errors from being treated as fieldnodes.

[Adriani90]

Actually, after looking in more detail to the user guide, screen layout off means that only interactive elements are displayed on their own line. So spelling errors via aria invalid, <ins> or <del> are not interactive elements. So unless the web author explicitely added new line character, we should not display them on their own line and we should not treat them as separate child objects.

This issue becomes more annoying now that e.g. the user guide uses monospace inline markdown formating for key commands. Monospace inline fomating ìndicated by "`" is showing the characters in the same line as the text surounding them, but the virtual document always begins a new line for every inline monospaced expression, because it is handled in the helper as being a separate child object, same as the aria invalid, <ins>, or <del>.

The navigation through the text becomes very inefficient when lots of inline monospaced expressions are added.

@seanbudd, @SaschaCowley could you have a look at the fieldnodes in the helper to see if this can be improved in NVDA?