Jaws screenreader does not read selected text

RESOLVED INCOMPLETE

Status

()

Core
Disability Access APIs
P3
normal
RESOLVED INCOMPLETE
3 years ago
4 months ago

People

(Reporter: sang.park, Unassigned)

Tracking

(Blocks: 2 bugs, {multiprocess})

54 Branch
x86
All
multiprocess
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: aes+)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:

I'm building an EmberJs app and trying to get Jaws to work on my page. We have following structure

<table>
    <thead></thead>
    <tbody>
        <tr>
            <td>
                {{{textBinding}}}
            </td>
        </tr>
    </tbody>
</table>

When this gets rendered by ember, it becomes 

<table>
    <thead></thead>
    <tbody>
        <tr>
            <td>
                <script id="metamorph-99-start" type="text/x-placeholder"></script>
                    text
                <script id="metamorph-99-end" type="text/x-placeholder"></script>
            </td>
        </tr>
    </tbody>
</table>




Actual results:

Jaws screen reader cannot read the text in the <td> tag.



Expected results:

Jaws screen reader should be able to read the text. 
Interestingly, it's able to read the text in Firefox on running on Windows VM.
Component: Untriaged → Disability Access

Comment 1

3 years ago
CC'ing MarcoZ with is his aware of that.
Flags: needinfo?(mzehe)

Comment 2

3 years ago
I am not. An actual sample page would be helpful. I do not have an amberjs setup, nor do I have time to do so, so a live page that demonstrates the problem would be much appreciated.
Flags: needinfo?(mzehe)

Updated

3 years ago
Flags: needinfo?(sang.park)
Keywords: testcase-wanted
@Reporter: Is this still a concern? If yes please provide current OS and Firefox Version, a screenshot and simple test case will also be beneficial.
Closing this as incomplete due to inactivity and lack of response from the reporter. 
Feel free to reopen the bug and provide a test case and or links if the issue still reproduces on a current build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
Reopening - Encountering similar issue with testing Jaws for a11y/e10s

Steps to Reproduce:
1. Navigate to any wikipedia article (in this case, I am using a touch screen Surface Pro)
2. Highlight a block of text in the article
3. Observe the lack of acknowledgement of selected text by Jaws screenreader

Expected Result:
Jaws screenreader reads the selected text highlighted.

Actual Result:
Jaws screenreader does not read the highlighted text.
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(sang.park)
Keywords: testcase-wanted
OS: Mac OS X → All
Resolution: INCOMPLETE → ---
Version: 32 Branch → 54 Branch

Comment 6

11 months ago
(In reply to Grover Wimberly IV [:Grover-QA] from comment #5)
> Reopening - Encountering similar issue with testing Jaws for a11y/e10s
> 
> Steps to Reproduce:
> 1. Navigate to any wikipedia article (in this case, I am using a touch
> screen Surface Pro)
> 2. Highlight a block of text in the article
> 3. Observe the lack of acknowledgement of selected text by Jaws screenreader
> 
> Expected Result:
> Jaws screenreader reads the selected text highlighted.
> 
> Actual Result:
> Jaws screenreader does not read the highlighted text.

Which version of JAWS? Surkov, can you reproduce / comment?
Component: Disability Access → Disability Access APIs
Flags: needinfo?(surkov.alexander)
Flags: needinfo?(gwimberly)
Product: Firefox → Core
Jaws Version 18.0.2324
Flags: needinfo?(gwimberly)

Comment 8

11 months ago
I suspect this has to do with the fact that the JAWS screen text interception mechanism is incompatible with Firefox graphics rendering. We render text in a way that the JAWS cursor, AKA mouse pointer, is not compatible with, and hasn't been since Firefox version 4 in Windows 8 and higher or so.

I suspect the text selection is done via the mouse? If so, that's not a use case blind people will actually use anyway, we don't use the mouse normally. We select text in the JAWS virtual buffer using shift plus the arrow keys. For that, the buffer must be filled, which in E10S builds is still being worked on for JAWS, see bug 1206711. So I am not even sure this bug is valid as is.

Comment 9

11 months ago
Jaws is not yet working in e10s mode, Yura and me track the issue. Let's make sure to revisit this one, when a11y e10s is claimed being jaws-ready.
Flags: needinfo?(surkov.alexander)

Updated

11 months ago
Blocks: 617918

Updated

10 months ago
Whiteboard: [JAWS][aes?]

Comment 10

10 months ago
Does this happen in non-e10s mode?
Flags: needinfo?(gwimberly)
It functions as intended in non-e10s mode. Pressing up/down reads the next several words. Pressing left/right reads the preceding/following letter in the article.
Flags: needinfo?(gwimberly)

Updated

10 months ago
Whiteboard: [JAWS][aes?] → [JAWS][aes+]

Updated

10 months ago
Blocks: 1350984

Updated

10 months ago
Whiteboard: [JAWS][aes+] → [JAWS]
This issue is still reproducible after updating JAWS (and corresponding Nightly) to today's date when e10s is enabled. It still works as intended when e10s is disabled.

JAWS Version - 18.0.2945

Updated

7 months ago
No longer blocks: 1258839
This issue is still reproducible after updating JAWS (and corresponding Nightly) to today's date when e10s is enabled. The behavior works as intended when e10s is disabled.

Firefox Nightly - 57.0a1 
JAWS Version - 18.0.4938

Updated

5 months ago
Keywords: multiprocess

Updated

5 months ago
Priority: -- → P2

Updated

5 months ago
Summary: Jaws screenreader cannot read some texts from the webpage → Jaws screenreader does not read selected text

Updated

5 months ago
Priority: P2 → P3
Marco made a good point today: We should determine whether this is a problem with selection events or if it is an issue with screen scraping.


ni? marco to determine whether this is a problem with NVDA.
Flags: needinfo?(mzehe)

Comment 15

5 months ago
As far as I can tell, this bug is a mix of three different issues, which may visually look the same, but are totally different issues on the screen reader side.

For comment #0, we still need a test page. I don't know how to use Angular, so if the reporter could please put a sample somewhere that demonstrates their problem, that would be appreciated. It sounds to me from that description that the problem is that the text doesn't appear in JAWS virtual buffer. This has NOTHING to do with on-screen text selection, but is a RENDERING problem. And that is what we should be concerned with.

Comment #5 talks about something different entirely. Yes, it may visually look similar, but is something totally different, and my analysis of this from comment #8 stands and has nothing to do with the initial description of this bug.

Comment #11 again gives totally divfferent indication, saying that left and right read previous/next character, and up and down arrows read the previous and next lines. You are now dealing with the virtual buffer, NOT with the on-screen text selection.

So in theory, everything below my request for a sample page in comment #2, and the closure of the bug in comment #4, is bogus and has nothing to do with this bug, although it may VISUALLY look similar. So if we didn't get a sample from the reporter until now, we should request it again, and if no reaction comes in, possibly close this bug again as INCOMPLETE as was done in comment #4.
Flags: needinfo?(mzehe)
status-firefox57: --- → affected
status-firefox56: --- → affected

Updated

4 months ago
Flags: needinfo?(dbolter)
Whiteboard: [JAWS] → aes+
Closing. If anyone feels the need to reopen please consider filing a new bug after carefully reading comment 15 thanks!
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago4 months ago
Flags: needinfo?(dbolter)
Resolution: --- → INCOMPLETE

Updated

4 months ago
status-firefox56: affected → ---
status-firefox57: affected → ---
You need to log in before you can comment on or make changes to this bug.