Make WordPress Core

Opened 23 months ago

Closed 23 months ago

Last modified 11 months ago

#26107 closed defect (bug) (fixed)

CSS Usability Error with .screen-reader-text

Reported by: jhned Owned by: helen
Milestone: 3.8 Priority: normal
Severity: normal Version: 3.8
Component: Accessibility Keywords: has-patch needs-testing
Focuses: Cc:

Description (last modified by SergeyBiryukov)

This ticket is similar to #23684, but there's a CSS error occurring when using search on page (cmd/ctrl + F in browser): when searching in browser for a page title, the browser picks up the title text twice.


This is because of this CSS in wp-admin.css:

/* Hide visually but not from screen readers */
.screen-reader-text span,
.ui-helper-hidden-accessible {
	position: absolute;
	left: -1000em;
	top: -1000em;
	height: 1px;
	width: 1px;
	overflow: hidden;

So if you have a long list of pages and a lot of them have a word in common, like "Product," every other time that you hit enter or hit the next arrow in the browser's search box, it'll bring you back to the top of the page, because it's picking up on the (supposably) hidden screen reader text.

Naturally, we can't change that to display:none because that would defeat the whole point. But I think we can change like this:

/* Still hide visually but not from screen readers */
.screen-reader-text span,
.ui-helper-hidden-accessible {
	display: block;
	line-height: 0;
	font-size: 0;
	overflow: hidden;

And as you can see, that fixes the problem:


I've done a good bit of research, but haven't found anything against using font-size: 0 and line-height: 0 to hide text except from screen readers, so it needs some testing, but I think this will allow us to fix the problem and keep things accessible.

Attachments (1)

screen-reader-text.patch (552 bytes) - added by jhned 23 months ago.
Patch for .screen-reader-text fix

Download all attachments as: .zip

Change History (12)

23 months ago

Patch for .screen-reader-text fix

#1 @SergeyBiryukov
23 months ago

  • Description modified (diff)

#2 @grahamarmfield
23 months ago

I have done some testing of this patch on a Windows 7 laptop using NVDA 2013.2 and JAWS 14 (screen readers) and the hidden labels etc with the revised CSS do seem to be accessed by the screen readers as you'd expect.

I also created a test page outside of WordPress and tested this with Voiceover on an iOS7 iPad. As before the revised CSS did not prevent the screen reader from accessing and voicing the text.

#3 @grahamarmfield
23 months ago

  • Cc graham.armfield@… added

#4 @SergeyBiryukov
23 months ago

Should be handled along with #23684.

#5 @helen
23 months ago

Firefox still searches in text masked by overflow: hidden, so there's nothing we can do to make this perfect cross-browser. Will handle with #23684 momentarily.

#6 @joedolson
23 months ago

The characteristic causing the jump to top is the negative top positioning; because the element is off the top of the screen, the focus jumps to as high as it can go. Simply removing the negative top positioning should be sufficient - that was a "once upon a time" recommended technique for accessibility, until this bug was observed. top: auto or omitting a declaration for top should be reliable. No time to test right now, but I'll check in again tomorrow.

In my opinion, having this text show up in an in-page search is expected: the text is present, and is part of the page. Since screen readers use a completely standard browser interface, they don't get the luxury of a separate set of search results.

#7 @helen
23 months ago

Been experimenting some more - haven't found a reliable way to remove from the results entirely, especially cross-browser. This particular patch doesn't account for when things get really wide, which unfortunately can (and I'm sure does) happen, so horizontal scrolling can ensue. If I set a width, it appears in search results again. If I set overflow: hidden, VoiceOver doesn't pick it up.

Tested the method in use by jQuery UI and HTML5 Boilerplate - those get picked up in search results, too. I get that this is super annoying - does not jumping to the top at least solve the annoying part?

Would love to hear if there's a super awesome method that fixes everything, and I bet other projects would love that, too.

#8 @helen
23 months ago

  • Owner set to helen
  • Resolution set to fixed
  • Status changed from new to closed

In 26602:

Utilize a more widely-adopted CSS method for hiding screen reader text, as seen in projects like jQuery UI and HTML5 Boilerplate. props codebykat for the initial patch. fixes #23684, #26107.

#9 @helen
23 months ago

New ticket if a super awesome method makes itself known, please.

#10 @markoheijnen
23 months ago

  • Milestone changed from Awaiting Review to 3.8

#11 @afercia
11 months ago

Thinking about a little crazy alternate method, what about to remove the title from the label, then hide the label text from screen readers and provide the information in a aria-hidden attribute?
Something like:

<label class="screen-reader-text" for="cb-select-2" aria-label="Select Sample Page">
<span aria-hidden="true">Select</span>

  • browsers don't search for text in attributes
  • the relevant information would still be conveyed to screen readers

I know it's not so orthodox :) and I've tested just with NVDA + Firefox, would definitely need feedback from the accessibility team.

Note: See TracTickets for help on using tickets.