In Drupal 8 some content is being visually hidden (and exposed to screen reader users) using the "visually-hidden" class, which is styled as follows in system.module.css:

.visually-hidden {
  clip: rect(1px, 1px, 1px, 1px);
  position: absolute !important;
  overflow: hidden;
  height: 1px;
  width: 1px;

This works as intended, with one exception: width: 1px causes major problems in Firefox if the hidden content inherits word-wrap:break-word. With this combination of properties, Firefox seems to eliminate all spaces from text before exposing the content to assistive technologies. Screen readers attempt to read the content without spaces which sounds like gobbledy-gook.

This problem has been observed in Firefox 22 using JAWS 14, Window-Eyes 7.5, NVDA 2013.1.1.
Here's a test page:

This is not a problem in Internet Explorer 10 or Chrome 28.

Proposed resolution

Remove width: 1px from the style definition for .visually-hidden.

In Drupal 7, there was a similar class "element-invisible" defined in system.base.css which did not include a width property. Otherwise Drupal 7's "element-invisible" class was identical to Drupal 8's "visually-hidden" class. The symptoms of this problem have not been observed in Drupal 7.

#15 Screen Shot 2013-07-21 at 9.15.56 PM.png170.39 KBmparker17
#13 drupal8-FirefoxScreenreader-2045151-13.patch368 bytesbowersox
PASSED: [[SimpleTest]]: [MySQL] 57,152 pass(es). View
#1 fix_visually-hidden_css.patch381 bytesfalcon03
PASSED: [[SimpleTest]]: [MySQL] 57,178 pass(es). View


falcon03’s picture

Status: Needs work » Needs review
381 bytes
PASSED: [[SimpleTest]]: [MySQL] 57,178 pass(es). View

@terrill: thanks for posting (and, most of all, uncovering) this issue. Here's a patch to remove the width property usage from the visually-hidden CSS class. Can you test this patch and confirm that it solves the issue?

At this point, I'm wondering whether it would make sense or not to remove the "height" property usage as well...

Also, let's make sure that this patch does not change anything for sighted users (when "visually-hidden" content is shown in the page), which is something that I can't do (I'm blind ! :D).

echoz’s picture

Status: Needs review » Needs work

Sorry, I don't currently have a fix for this screen reader issue, but the width: 1px; part of .visually-hidden is needed for .visually-hidden on an element near the right edge of the viewport (for example, the span inside Bartik's Read more link) causes a horizontal scrollbar in webkit. On an iPhone, you don't see the scrollbar, you see the overflow as if scrolled to the right, showing a space on the right.

This part of .visually-hidden (formerly named .element-invisible) is is built from

The width: 1px; had been added, lost and re-added, most recently in #1973456: .element-invisible on element at right causes horizontal scrollbar on desktop or right gap on phone on webkit browsers. See comments #18 and #22 for explanations.

bowersox’s picture

Instead, can we solve this bug by applying a "word-wrap: normal" style into .visually-hidden?

@terrill, can you check whether that might work?

jessebeach’s picture

Issue tags: +TwinCities
mparker17’s picture

Assigned: Unassigned » mparker17

Assigning to myself.

mgifford’s picture

Assigned: mparker17 » Unassigned

Thanks for finding this problem. We should be able to fix it for D8.

There were some other proposed changes to this in

Fascinating to see this issue evolve #58941: 'display: none' causes problems for screenreaders

mparker17’s picture

Assigned: Unassigned » mparker17

Steps to test:

  1. Download a testing Windows 8 / IE10 image from and set it up.
  2. On the VM, download the latest version of Firefox and install it.
  3. On the VM, download the latest version of JAWS and install it.
  4. On the VM, visit and verify it works as reported.
  5. Download and install a fresh copy of D8. Create a page with the following HTML:

    Test before

    This is a test paragraph.

    Test after

  6. On the VM, verify the page works as reported.
  7. Patch D8 with the patch from #1.
  8. On the VM, verify the page works correctly.
echoz’s picture

#7, why ask to test patch from #1 when info in comment #2 explains that removing width: 1px; will cause breakage in another circumstance?

mparker17’s picture

Status: Needs work » Needs review

I've confirmed that @falcon03's patch from #1 fixes the problem with JAWS+Firefox. And, it does not appear to cause a horizontal scrollbar in Safari 6.0.5, Safari on iOS 6.1, or Chrome 28.

As suggested by @bowersox, I tried restoring the width: 1px; and adding the style word-wrap: normal;. This also appeared to fix the JAWS+Firefox problem, and it didn't cause any problems in any of the aforementioned browsers either.


bowersox’s picture

@mparker, I think the next step is to roll a patch for that second approach, restoring the width: 1px and adding the word-wrap: normal.

echoz’s picture

Great on #10 suggestion, and that word-wrap: normal; resolves problem!
The horizontal scrollbar bug only appears when an element with this class is near the right edge of the viewport (and width: 1px; is omitted). You can see this in Bartik by creating content that has a read more link.

echoz’s picture

Status: Needs review » Needs work
bowersox’s picture

368 bytes
PASSED: [[SimpleTest]]: [MySQL] 57,152 pass(es). View

Here's a patch with this word-wrap: normal approach.

This needs testing in Firefox with JAWS and other screenreaders.

@terrill or @falcon03, can you check in screenreaders?

bowersox’s picture

Status: Needs work » Needs review
mparker17’s picture

Assigned: mparker17 » Unassigned
Status: Needs review » Needs work
170.39 KB

I can verify that the patch in #13 fixes the problem in JAWS+Firefox.

However, when I follow @echoz's suggestion in #11, I do see a funky margin in iOS 6.1. See attached screenshot.

Sorry :(

echoz’s picture

@ mparker17 is there a misunderstanding?
There is no problem I can see if the only fix in the patch is word-wrap: normal; and does NOT delete any other css (like width: 1px;).

Why are you giving the patch in #13 a status of needs work, after saying it fixes the problem in JAWS+Firefox?

Adding word-wrap: normal; is the only change in patch #13. Why "needs work"?

mparker17’s picture

Status: Needs work » Reviewed & tested by the community

Sorry @echoz, I should have been more clear: I marked the patch as "needs work" because, when I tested the patch from #13, I saw a large border on the right side of the screen in iOS 6, as shown in the screenshot attached to #15.

However, while writing this reply, I decided to try to test again, and discovered that the broken margin was actually due to assigning a really long default site name, which pushed out past the edge of the page. When I shortened this string, the page worked correctly.

Therefore, I am marking the patch from #13 as RTBC.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 5b847ea and pushed to 8.x. Thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.