New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 710485 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

no line breaks when rendering code blocks with a screen reader

Reported by jfa...@gmail.com, Apr 11 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Example URL:
https://home-assistant.io/cookbook/automation_for_rainy_days/

Steps to reproduce the problem:
1. Open the referred URL in Chrome while using JAWS or NVDA.
2. Try to read the code block using the screen reader.
3. 

What is the expected behavior?
Each line of the code should be spoken as a sepperate line

What went wrong?
The code is rendered with no line breaks. On some sites, all white space is removed. This works in Firefox and IE.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 57.0.2987.133  Channel: stable
OS Version: 10.0
Flash Version:
 

Comment 1 by junov@chromium.org, Apr 11 2017

Components: -Blink UI>Accessibility
Labels: Needs-Triage-M57

Comment 3 by ja...@nvaccess.org, Apr 12 2017

Cc: nek...@chromium.org
Status: Untriaged (was: Unconfirmed)
Minimal test case: data:text/html,<pre><span>l1</span>&#10;<span>l2</span></pre>
In this case, a line feed character is not exposed via IAccessibleText. NVDA needs this in order to render the lines as intended.
In addition, line offsets are incorrect. For offsets 0 and 1, the line offsets returned are (0, 4); they should be (0, 2). Interestingly, for offsets 2 and 3, the line offsets returned are (2, 4), which is correct.

If you remove the span tags or move the line feed inside one of the span tags, the line feed character is exposed via IAccessibleText as expected.

Related NVDA issue: https://github.com/nvaccess/nvda/issues/7057293563219

Comment 4 by ja...@nvaccess.org, Apr 12 2017

Also occurs in Version 59.0.3069.0 (Official Build) canary (64-bit).
Labels: triage-dominic
Cc: -nek...@chromium.org
Labels: -Arch-x86_64 -Via-Wizard-Content -Needs-Triage-M57 -triage-dominic
Owner: nek...@chromium.org
Status: Assigned (was: Untriaged)

Comment 7 by lynnkate@google.com, Oct 17 2017

This was also reported in v. 61. 
Labels: Hotlist-Accessibility Hotlist-ConOps

Comment 9 by nek...@chromium.org, Dec 10 2017

Status: Fixed (was: Assigned)

Sign in to add a comment