1758616 - Screen reader reads highlighted text separately

Status: RESOLVED DUPLICATE of bug 1550644

(Firefox :: Address Bar, defect, P3)

Description

[Daisuke Akatsuka (:daisuke)]

Attachment: read-separately.mp4

STR:

1. Enable VoiceOver
2. Type any char in URL bar.
3. Select roww by keydown.

Actual:
VoiceOver reads highlighted text separately.
Expect:
It should be read with the correct delimitation.

I attach a video. In this example, I input “exa” in URL bar. Then, select the results by order. As we can see the text of VoiceOver, “example” separates to “exa” and “mple” (we can see white space between “exa” and “mple”), then it will be read out separately. Screen reader should read out “example”, I think.

It seems that this issue happens on not only OSX but Windows with NVDA as well.

Comment 1

[Morgan Reschenberg [:morgan]]

:Jamie sounds like this isn't VO specific -- is this the expected behaviour?

Comment 2

[James Teh [:Jamie]]

It's not intentional, no. I suspect fixing it may be non-trivial, though.

Comment 3

[Daisuke Akatsuka (:daisuke)]

It seems that this may be fixed if we set aria-label etc explicitly without modifying a11y engine.
I will take a look at this.

Comment 4

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1758616: Read out highlighted text without separating.

Comment 5

[Daisuke Akatsuka (:daisuke)]

I have looked at the behavior of normal web content as well, including other browsers.
The following is a result that Screen Reader read out after reloading the content or selecting.
For Firefox, VO does not read out when selecting the body.
For Safari, VO does not read out when reloading.

HTML	Firefox (reloading)	Chrome (reloading)	Chrome (selecting)	Safari (selecting)
<strong>exa</strong>mple	"exa" "mple"	"example" "examp"	"example"	"example"
<span>exa</span>mple	"exa" "mple"	"example" "examp"	"example"	"example"
<span style="display: inline-block;">exa</span>mple	"exa" "mple"	"example" "examp"	"example"	"example"
<span style="margin: 12px; padding: 12px;">exa</span>mple	"exa" "mple"	"example" "examp"	"example"	"example"
<span style="display: block;">exa</span>mple	"exa" "mple"	"exa" "mple"	"exa" "mple"	"exa" "mple"
<div style="display: inline;">exa</div>mple	"exa" "mple"	"example" "examp"	"example"	"example"
<div style="display: inline-block;">exa</div>mple	"exa" "mple"	"exa" "example"	"example"	"example"

When looking at the result, other browsers also seem to be different behavior depending on reloading and selecting.
We need to discuss what we should choose, but IMO we may better handle it as similar as Safari and Chrome (selecting).
That is, how about that Screen Reader reads out without dividing text when the style of element is inline?
What do you think?
If we choose this way, I want to try to fix this issue in a11y engine instead of URL bar.

Comment 6

[Morgan Reschenberg [:morgan]]

The fix here seems good to me :) I'm not sure how widespread this type of formatting is on the web, or if making a broader change in the a11y engine makes sense. :Jamie do you have thoughts here?

One note: With VoiceOver, I think there's some remnants of the issue in bug 1758614. If I type "ex" into my url bar, and hit down arrow, the result that gets focus is "expedia". Instead of reading that entire string, VO says "pedia text inserted". If I focus the next entry "experian", VO reads it correctly, and if I arrow back up "expedia" gets read in full.

I don't think this is an issue with your patch, just pointing out an odd pre-existing behaviour. Pretty sure this is the same notification race condition issue we saw before.

Comment 7

[James Teh [:Jamie]]

I'm not really sure what is meant by "reloading" in comment 5. What I can say is that navigating with the VO cursor or selecting is a little different to what is happening with the address bar.

For the address bar, what we're dealing with is the a11y engine's name computation code. That is best demonstrated by tabbing to the focusable div in this distilled test case:
data:text/html,<div role="listbox"><div role="option" tabindex="0"><strong>exa</strong>mple</div></div>
We do indeed return "exa mple" for Accessible::Name in that case, which is wrong.

This problem suggests that we're adding white space, but that is only supposed to happen if the parent is a block level element.

Which leads to the crux of the problem. The "mple" text's parent is a block level element, even though the strong's parent isn't. If you ensure both nodes don't have a block level parent:
data:text/html,<div role="listbox"><div role="option" tabindex="0"><strong>exa</strong><strong>mple</strong></div></div>
everything works as expected.

I'm not quite sure how we're going to fix this, but it's clear it's definitely an a11y engine bug.

Comment 8

[James Teh [:Jamie]]

Oh. We had a mid-air collision while I was writing this comment... and I somehow completely forgot I ever filed bug 1550644, so I've clearly done this investigation more than once. Fun!

Comment 9

[Daisuke Akatsuka (:daisuke)]

Hi James! Thank you very much for your advice!

I commented out the line you pointed, VO read data:text/html,<div role="listbox"><div role="option" tabindex="0"><strong>exa</strong>mple</div></div> correctly, but still there was a white space in the URL bar results.
Instead, if commented out this line, the white space was gone from the results as well!
So, I want to try to resolve the issue here, instead of the URL bar as I posted.

One question:
If I tried data:text/html,<strong>exa</strong>mple, it still had a white space.
I tried to comment out all other 5 places where append white space in nsTextEquivUtils as well. But, it had no change.
Do you know where we append the white space for that case? It would be ideal if we could solve it too, right?

Comment 10

[James Teh [:Jamie]]

(In reply to Daisuke Akatsuka (:daisuke) from comment #9)

still there was a white space in the URL bar results.
Instead, if commented out this line, the white space was gone from the results as well!

Oh. Sorry about that.

If I tried data:text/html,<strong>exa</strong>mple, it still had a white space.
Do you know where we append the white space for that case? It would be ideal if we could solve it too, right?

Can you explain how you were reproducing that? As I noted, navigating with the VO cursor is a bit different to reading the name. When you're just dealing with text (outside of a control like a list box option, a button, etc.), VO just sees the individual nodes, which is necessary in order to show formatting, etc. So, you will definitely get three separate nodes in this case, which is not ideal, but is also how VO works for content; text nodes are navigated separately.

Comment 11

[James Teh [:Jamie]]

I believe I have a patch for this. I'll deal with it over in bug 1550644.

Comment 12

[Daisuke Akatsuka (:daisuke)]

Attachment: reloading.mp4

(In reply to James Teh [:Jamie] from comment #10)

(In reply to Daisuke Akatsuka (:daisuke) from comment #9)

If I tried data:text/html,<strong>exa</strong>mple, it still had a white space.
Do you know where we append the white space for that case? It would be ideal if we could solve it too, right?

Can you explain how you were reproducing that?

I am sorry that I have not explained about “reloading".
This behavior reproduces when reloading the browser in my env at least.
Let me attach the video.

Comment 13

[James Teh [:Jamie]]

I can't see the video, as I'm totally blind, and it doesn't appear to have audio. My guess is that you're seeing VO auto read the page when it loads, where it effectively just reads all the content, element by element. In this case, you would see separate text nodes, just as you do with navigation.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Daisuke Akatsuka (:daisuke)]

(In reply to James Teh [:Jamie] from comment #13)

My guess is that you're seeing VO auto read the page when it loads, where it effectively just reads all the content, element by element. In this case, you would see separate text nodes, just as you do with navigation.

Yeah, I have been turning on the auto read switch.
And I see, I understand that reading element by element is the expected result.
Do you think we should solve the auto reading issue as well?
If no, I will close this bug.

Comment 16

[James Teh [:Jamie]]

If you're referring to text elements being read separately with auto read, I'm not sure how we can solve it. In any case, that would be a bug for the a11y engine rather than this one.

Thanks for your work on this.

Comment 17

[Daisuke Akatsuka (:daisuke)]

Okay, thanks!