Span tags in EPUB are causing NVDA to pause after each word

[CircularKen]

Purely positional or stylistic span tags in an EPUB are causing NVDA to break up the speech by pausing after each word.

See the example in the video from 20-40 seconds:

LanguageDemo.mov

Steps to reproduce:

Opening the attached EPUB in Thorium https://thorium.edrlab.org/en/ and reading in NVDA

Actual behavior:

Each span tag is and announced with a pause between each word.
Note that after 40 seconds in the video the voice is correct again because NVDA is reading an image alt tag which has no spans.

Expected behavior:

Span tags are ignored like the JAWS example in the video from the 0-20 seconds

NVDA logs, crash dumps and other attachments:

n/a

System configuration

NVDA installed/portable/running from source:

unknown

NVDA version:

unknown

Windows version:

Windows 11

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

Opening the attached EPUB in Thorium https://thorium.edrlab.org/en/ and reading in NVDA

Other information about your system:

This is a fixed layout EPUB that has span tags. The English text uses span tags only for position and these should not affect the speech.
I personally don't have access to NVDA (Mac user) so am relying on others to test and report the issues.

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 NVDA add-ons are disabled, is your problem still occurring?

unknown

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

unknown

Sample EPUB attached here Dual_language_test.epub.zip happy to supply more!

Thanks

Ken Jones
Director
Circular Software Limited
circularsoftware.com

ken at circularsoftware.com
@CircularKen
linkedin.com/in/kenjones

[nvdaes]

Thanks for reporting this.
I think that this issue should be closed as invalid, since the scope may be extended to the behavior of spam elements for different browsers when screen layout is disabled, not just for EPUB files opened with Thorium.
Alternatively, this may be converted to a discussion. I have tested this EPUB in Thorium, and also the xhtml file removing the style attribute for some span elements, and I'd request that span elements could be ignored when screen layout is disabled.
cc: @jcsteh

[jcsteh]

Note that this doesn't happen for a simple span:
data:text/html,<span>1</span> <span>2</span>
Even with screen layout off, this gets read as "1 2" on the same line.
I don't have time to test this with Thorium, but my guess is that the spans have semantics which cause them to become relevant in the accessibility tree. For example:
data:text/html,<span role="group">1</span> <span role="group">2</span>
These will appear on separate lines with screen layout off. But the whole point of disabling screen layout is that inline elements should appear on separate lines. If they didn't, links would appear on the same line, which is precisely what users don't want.
Making an exception for span tags specifically doesn't make sense because this could just as well occur for <b>, etc. if they had relevant semantics. We also can't do the reverse - only push links onto separate lines - because there are many other elements that users want on separate lines: <input>, etc. There needs to be a clear rule here: we can't just pick HTML tags arbitrarily.

[CircularKen]

@jcsteh said "my guess is that the spans have semantics"
They don't, that is why I made the point that they are "purely positional or stylistic span tags." in the first line of the issue description.

[CircularKen]

@jcsteh said "There needs to be a clear rule here: we can't just pick HTML tags arbitrarily."

Not picking arbitrarily. The span and div tags should be ignored as they hold no inherent semantic value.

The HTML element is a generic inline container for phrasing content, which does not inherently represent anything.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span

[jcsteh]

I read your point, but the symptoms you're seeing suggest otherwise. As my test case above demonstrates, span elements alone do not create separate elements in the accessibility tree and thus do not cause line breaks when screen layout is disabled. I think the only way we're going to make progress here is to see the exact code for the span element in question. It should be possible to extract this using DevTools.

<span> is an inline element with no semantic value by default, but styling (e.g. display: block) or ARIA can change that. Also, see my note above regarding <b>, etc. Checking for <span> alone is not a sufficient heuristic.

In any case, I was CCed to provide information or guidance to help diagnose this, which I have now done.