Screen Layout Mode with display: inline-block fails to distinguish between interactive controls

[majornista]

Steps to reproduce:

1. Open CodePen - NVDA Screen Layout bug with display: inline-block
2. Read through the page using browse mode.

Actual behavior:

Here is a line-by-line transcript copied from the NVDA Speech Viewer, as an ordered list with each item being a line read by NVDA following a press of the ArrowDown key.

1. CodePen - NVDA Screen Layout bug with display: inline-block
2. main landmark heading level 1 NVDA Screen Layout bug with display: inline-block
3. When navigating the following div with display: inline-block in browse mode, the individual
4. interactive controls are not treated separately. All the contained interactive elements are read as
5. a single block of text.
6. button Test button Another Button button Yet Another Button link a link check box not checked How about a checkbox , or maybe an input edit ?
7. In browse mode, the interactive controls in the div above are read as a single entity, the next
8. ArrowDown key press advances to the next block of text, skipping all interactive controls within
9. the element with display: inline-block.

This relates to how Screen Layout Mode interprets display: inline-block, and the workaround is to turn off Screen Layout Mode using NVDA+V, as described in the closed issue #5020 (comment) and #1378, but our feeling is that a user should not be expected to work around this with a shortcut key.

Expected behavior:

Interactive controls within an element that has display: inline-block, should be read independently in browse mode, so that the user can understand the purpose of each control and decide whether to interact with it.

The following line:
"button Test button Another Button button Yet Another Button link a link check box not checked How about a checkbox , or maybe an input edit ?"

Should be navigated in browse mode using the ArrowDown key as:
"button Test "
"button Another Button"
"button Yet Another Button"
"link a link"
"check box not checked How about a checkbox"
", or maybe"
"an input edit"
"?"

System configuration

NVDA installed from source:

https://www.nvaccess.org/files/nvda/releases/2020.1/nvda_2020.1.exe

NVDA version:

2020.1

Windows version:

Windows 10 Enterprise
Version 10.0.18363 Build 18363

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

Chrome Version 81.0.4044.138 (Official Build) (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.

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.

[Adriani90]

This is expected behavior. Low visiion users or blind users who would need to understand the visible structure of the page, need to use screen layout. There are also many blind users working together with sighted people, so the screen layout feature is useful to understand the visible structure of a document or web page at the same level as a sighted person. So this is expected behavior . NVDA+v is not a workaround, it is just the feature that can be turned on and off.

Closing as works for me.

[Adriani90]

Note also that NVDA users can use quick navigation keys to navigate between specific elements (i.e. b for buttons, x for checkboxes, r for radio buttons, g for graphics ans so on). So there is not always a need for navigating with arrow keys through a website.

[Brian1Gaff]

Sometimes though using cursor keys can give the user an idea of the page layout.

[majornista]

@Brian1Gaff and @Adriani90 I kindly ask you to reconsider this issue. The way NVDA groups inline interactive controls as blocks of content in screen layout mode can create situations where interactive elements, like elements controlled using the roving tabindex technique, cannot be accessed without toggling out of browse mode or screen layout mode.

I've updated the CodePen example for this bug to use a longer list of interactive controls with display: inline-block, which demonstrates how NVDA breaks the content, splitting the list into two parts: https://codepen.io/mijordan/pen/YzygzxY. I think a better behavior would be to announce each interactive item within the list as a separate element, regardless of whether it is displayed inline or not.

I think relying on CSS fixes is fragile, because it puts the onus on Web developers and designers to understand this peculiarity of how NVDA reads content in its default mode.

[lukaszgo1]

@Brian1Gaff and @Adriani90 I kindly ask you to reconsider this issue.

There is Nothing to reconsider here - these controls are visually displayed in one line and blind users (especially those of us who work as a web programmers) need to be able to tell how the given website is lay out visually as much as possible.

The way NVDA groups inline interactive controls as blocks of content in screen layout mode can create situations where interactive elements, like elements controlled using the roving tabindex technique, cannot be accessed without toggling out of browse mode or screen layout mode.

This problem demonstrates the real issue i.e. you're not aware about navigation techniques other than arrow keys with NVDA in browse mode. There are several ways in which I can move from one item of this list to the next without turning off browse mode or screen layout:

• I can press tab to navigate from one item to the next.
• I can press quick letter "i" which moves from one list item to the next.
• Finally after hearing what controls are in this list I can press quick nav key assigned to the particular type of control for example if I want to move to the checkbox which is second to last item I can just press "x" and move where I want to be.

[awkawk]

@lukaszgo1

There is Nothing to reconsider here - these controls are visually displayed in one line and blind users (especially those of us who work as a web programmers) need to be able to tell how the given website is lay out visually as much as possible.

Can you help us understand how information being omitted helps understand how the website is laid out? edit: I get that it reads a certain amount of the current line. If the line is short enough that the whole line is read, but when lines are longer you do lose the connection between lines.

The issue that we are having here is that we are hearing from users and testers that items are being skipped in Browse mode. We are using straightforward semantic HTML and modifying the presentation with CSS, and while I agree that there are ways to reach the individual content items using NVDA (quick keys, NVDA-v) we are trying to make this work in as straightforward a way as possible.

It sounds from the previous comments on this issue that the NVAccess team would say that we shouldn't worry about how NVDA is reading this particular structure because the tools are available for an NVDA user to fully access the content. If that is the case, that's fine, but it seems that is may be making the discoverability of the full content more difficult.

Interested in your thoughts on this - we don't want to spend time thinking about a workaround if you all think that this works great...

[majornista]

Here is an updated example that is closer to the use case where the issue has been raised:

• CodePen example
• CodePen example in Debug mode for simplified testing

[feerrenrut]

Thanks for the test cases @majornista this illuminates the issue you are facing well.

Generally, I think the bug here is that with screen layout on, looking at the display: inline-flex case the horizontal arrangement is not being picked up by NVDA. But I understand this is not the core of the complaint.

If I understand correctly, the core issue is: For regular users using a default config (screen layout on), it is possible (or easy) to miss certain controls.

It sounds like the concerns raised here would be resolved (@majornista and @awkawk please confirm) by one or both of the following:

• Making screen layout off by default.
  • Screen layout is certainly important for some users.
  • I suspect turning it off is more intuitive for the majority.
  • Off by default might be a controversial change.
• Removing the limit for line length when screen layout is on.
  • I suspect that the limit for line length was introduced initially as a performance protection mechanism.
  • Given the changes to NVDA for how speech is collected, I suspect we could experiment with removing this.

If this is a good summary, then I propose that this be split into two different issues:

• Look at the usability of the defaults for line length and screen layout.
• Look at display: inline-flex not being understood by screen layout correctly.

[majornista]

@feerrenrut

• The default for line length is useful, but I don't think it should ever break in the middle of an interactive control, like a button, link, or input. In the step list test case I provided, screen layout breaks the last link in the step list in two, announcing it as "link not" and "link completed: View Switcher", when it should be announced as a single link, "link not completed: View Switcher."
• I'd prefer not changing the behavior of display: inline-flex to conform with screen layout behavior of display: inline-block, but instead consider treating list items differently from other types of content in screen layout mode, announcing them separately regardless of whether they are inline or not.

[feerrenrut]

@majornista

Can you confirm if I have understood the core problem you are facing? Then we can consider the best solution for NVDA users.

I'd prefer not changing the behavior of display: inline-flex to conform with screen layout behavior of display: inline-block, but instead consider treating list items differently from other types of content in screen layout mode, announcing them separately regardless of whether they are inline or not.

But in this case, functionality is lost for people who rely on it. The intent of the feature is to convey screen layout.

You missed the suggestion of "making screen layout off by default". I assume this will resolve the concerns?

[majornista]

@feerrenrut I confirm you understand most of the core problem we are facing, and I perhaps incorrectly assume you might want to avoid changing the default behavior, because it may be a controversial change.

My Step List example is a unique situation, because we are using roving tabIndex to restrict Tab focus to the link for the current Step, similar to how a tab list behaves. This takes away one of the mechanisms a user expects to be able to use to navigate to the links identified in the screen layout announcement, the Tab key, but the other mechanisms, pressing quick letter "i" for list items or "k" for links, still work.

The other, more important problem that the Step List example demonstrates is how screen layout mode arbitrarily breaking the accessibility name for interactive controls based on line length can actually alter meaning.

In the step list test case I provided, screen layout breaks the last link in the step list in two, announcing it as "link not" and "link completed: View Switcher", when it should be announced as a single link, "link not completed: View Switcher."

While this would be more work than simply changing the default setting, keeping the accessibility label for interactive controls together, without breaking the string, would be a significant improvement.

[feerrenrut]

Thanks @majornista

I think changing the default is sensible, we will certainly aim to do it. I have created a new issue for this: #11716

I also agree that the character limit should become a bit smarter, and not break arbitrarily. While certainly a more difficult thing to achieve (and test effectively!), it would be a good improvement. I have created: #11717

While it's not core to your concern, I believe it is a bug that inline-flex is not being understood by screen layout correctly in this particular case. I think we should investigate it at least: I have created: #11718