How to Hide Any Text from Sighted User and Search Engine But Not from Screen Reader

How to hide any text from sighted user and search engine but not from screen reader?

The jQuery UI CSS framework does this by positioning elements far off-screen, e.g.

.ui-helper-hidden-accessible { position: absolute; left: -99999999px; }

display:none vs visibility:hidden vs text-indent:9999 How screen reader behave with each one?

refer: http://css-discuss.incutio.com/?page=ScreenreaderVisibility

display:none: will not be seen nor heard. *

visibility: hidden: will not be seen nor heard. *

text-indent: 9999: will not be seen but it will be heard.

• Most of the screen reader will not 'speak' display:none and visibility: hidden , but there are few screen readers like pwWebSpeak and HtReader which will read even these too.

Hide all elements from screen readers except one div?

Implementing accessible modal dialogs correctly has got to be one of the trickier aspects of web accessibility, since there's just so many things to watch out for, on top of the usual issues of screenreader and browser compat and adherence to spec. Here's a summary(!), somewhat based on personal experience, this article from Smashing Magazine on accessible Modal dialogs, WAI-ARIA 1.0 Authoring Best Practices and this slideshow on the same topic.

(Note that you'll find some conflicting advice between these; this is somewhat due to differences in behavior between screenreaders/browsers and spec, and different authors having different positions on whether to stick to spec vs work with the screenreaders that real users actually use.)

• Tell screenreaders it's a dialog: Add role="dialog" to the parent DIV, and set aria-labelledby to point to the ID of the title.

  This causes the screenreader to recognize the piece of UI as a dialog in the first place; when the user navigates into it, either by navigating or because focus moves into it, the screenreader will announce that the user is now in a dialog, and will likely also announce the title. (On some screenreader/browser combinations - notably VoiceOver+Safari, it may also affect how screenreader navigation works.) This alone does not 'hide' any of the other UI on the page, however.

• Add basic keyboard support

  There's a bunch of things to do here that are important for both screenreader users and non-screenreader using keyboard users. Two key issues here are to move focus to somewhere appropriate in the the dialog when it initially appears, and when the dialog is dismissed, restore focus back to where it was when the dialog originally appeared.

• Make it modal for screenreader users and keyboard users

  Dialogs come in two flavors: modal, which don't let the user interact with any other UI while present, and modeless, which do let the user leave the dialog and return later - examples might be the "Find Text" dialogs in some text editors. role="dialog" doesn't distinguish between these two cases, and also using ARIA doesn't have any affect on browser behavior, so if your dialog is modal, you have to do extra work yourself to make it behave as modal. There's two aspects to this:

  • Just as modal dialogs use a gray scrim or blur effect to visually hide the inactive background from sighted users, we also want to hide this content from screenreader users: otherwise they will still be able to navigate out of the dialog to the background, or use other hotkeys to list links or headings or other controls from the page and will see both items from the background part of the page and the dialog. In the past, putting aria-hidden="true" on all other top-level DIVs was the best tool to use to do this (and a bit fiddly - remember to remove it when done!), but as of 2020, aria-modal="true" appears to be decently supported and is much easier to implement.

  • For both screenreader users and non-screenreader-using keyboard users, you also need to make the keyboard behavior modal: hitting tab from the last item in the dialog should wrap to the top of the dialog, and the inverse behavior for shift-tab. If you don't do this, keyboard - and screenreader - users can simply tab right out of your dialog into the background of the page. There's different approaches for doing this, most involve tracking focusin or similar at the body level, and forcing focus back into the dialog if it "escapes".

• Other tweaks/fixes/hacks

  Windows-based screenreaders such as NVDA and JAWS go into "application mode" when they enter a dialog: their web navigation hotkeys no longer work, and they treat the content of the dialog as a form rather than a rich web page. This is fine is the dialog content is a classic form with just fields, labels and buttons, but isn't a good fit if the dialog contains web content with text, hyperlinks, and the like. In that case, you might want to place a <div role="document">...</div> within your role="dialog" but wrapping the main content.

• Ensure dialog content is itself accessible

  Should go without saying, but all of the above counts for nothing unless the content within the dialog is itself accessible.

• Most importantly: understand why you are making the dialog accessible in the first place, and test appropriately.

  Unfortunately, at the moment (Jan 2015!) there's still a lot of variation in behavior between different screenreaders (also depending in browser used); it's almost like how browsers were with CSS a decade(!) or so ago. It's worth understanding why you want to make your UI accessible, figure out where most of your users are going to be, and test appropriately given the screenreaders they'll be using. From the most recent (Jan 2014) WebAim Screenreader survey, Windows readers - notably JAWS and NVDA - have the majority of the market, with VoiceOver coming third.

  Here's one possible strategy to consider:

  • If you just want to do a basic 'due diligence', then testing with just VoiceOver may be fine. The experience may not be as good on the other screenreaders, but if something works with VO, it's likely not going to be completely broken on the others.

  • Next level up is to get a copy of (free, but feel free to donate) NVDA windows-based screenreader and run it in a VM on a Mac (assuming you're using a Mac here). NVDA and JAWS tend to be pretty close behavior-wise.

  • If accessibility is part of your job description, then likely you or your company will need to get a copy of JAWS ($800+!), since that appears to be the screenreader of choice for government and educational institutions. (This is perhaps the accessibility analog of testing with downlevel versions of IE!)

In HTML, how can I have text that is only accessible for screen readers (i.e. for blind people)?

As far as alt text, you are correct, that only works for images.. But you can use aria-label in place of the alt attribute for non-image elements like so:

Solutions that work

ARIA Labels ★ ★ ★ ★ ★ ★

aria-label (not to be confused with aria-labelledby, a related tag that instead pulls the accessible name from the text of another element) is used to add off-screen descriptive content to an element much in the way an alt= attribute adds off-screen descriptive content to images to be used when the images are not displayable.

The difference is, aria-label can be used on non-image elements.

<div aria-label="test A"><p aria-hidden="true">test B</p></div>
<!--
     result (screenreaders):  test A
     result (regular):        test B
-->

The addition of the aria-hidden attribute hides the inner text.

Position + Clip + Collapse ★ ★ ★ ★

.screenreader {
    position: absolute !important; /* Outside the DOM flow */
    height: 1px; width: 1px; /* Nearly collapsed */
    overflow: hidden;
    clip: rect(1px 1px 1px 1px); /* IE 7+ only support clip without commas */
    clip: rect(1px, 1px, 1px, 1px); /* All other browsers */
}

The clip is used to hide the 1px x 1px element completely, otherwise it will still be visible on the screen.

Position ★ ★ ★

.screenreader {
    position: absolute;
    left:-9999px;
}

<div>Wed<span class="screenreader">nesday</span>, Sept<span class="screenreader">ember</span> 24, 2014</div>

Indent ★

.screenreader {
    text-indent: -5000px;
}

The actual indent value is not important as long as it's outside of the range of your pages layout. The example will move the content to the left 5,000 pixels.

This solution only works for full blocks of text. It won't work well on anchors or forms, or right-to-left languages, or specific inline-text intermixed with other text.

Will not work

visibility: hidden; and/or display:none;

These styles will hide text from all users. The text is removed from the visual flow of the page and is ignored by screen readers. Do not use this CSS if you want the content to be read by a screen reader. But DO use it for content you don't want read by screen readers.

width:0px;height:0px

As above, because an element with no height or width is removed from the flow of the page, most screen readers will ignore this content. HTML width and height may give the same result. Do not size content to 0 pixels if you want the content to be read by a screen reader.

Further:

• WebAIM Center for Persons with Disabilities
• Fangs Screen Reader Emulator for Mozilla

Set screen reader text (and meta-information text) to a different value than visible text

aria-label on a heading will not help because the heading is not focusable with a keyboard.

The design you have is fine. Having ascii art is creative, albeit only readable to a subset of the population. I have decent eyesight but still have to think about what I'm looking at to find the word.

But, be that as it may be, if that's what the client wants, then go with it. It's easy to make it accessible.

<div aria-hidden="true">
  <!-- ascii art here -->
</div>

<h2 class="sr-only">Sandwich</h2>

So the ascii art is visible to sighted users but hidden from screen readers.
The heading is visible to screen readers (and SEO) but hidden from sighted users.

You can search for the "sr-only" class (sometimes called the "visually-hidden" class). Here's one example. It basically pushes the text off the screen or makes it one pixel tall.

If you're talking about food, just make sure "sandwich" is spelled correctly in the ascii art :-)

Will the CSS property opacity only hide content from screen readers if exactly 0?

In general, CSS does not affect screen readers. The only exceptions are:

• display:none
• visibility:hidden
• :before and :after pseudo elements
• (edit) height:0 or width:0 (some screen reader / browser combinations ignore elements with a 0 size, but not all of them)

The first two will hide the elements from the screen reader. The last one can potentially add text to the "accessible name". See step 2.F.ii in "Accessible Name and Description Computation 1.1".

Opacity is ignored by screen readers. It's only changing the appearance of the element and does not remove it from the DOM. You can set it to 0 and a screen reader will still read the element.

Most Screen Readers will skip content with opacity: 0

I'm not sure where you got that from. I have never seen an element with opacity:0 skipped by a screen reader.

Hide Text with CSS, Best Practice?

Actually, a new technique came out recently. This article will answer your questions: http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement

.hide-text {
  text-indent: 100%;
  white-space: nowrap;
  overflow: hidden;
}

It is accessible, an has better performance than -99999px.

Update: As @deathlock mentions in the comment area, the author of the fix above (Scott Kellum), has suggested using a transparent font: http://scottkellum.com/2013/10/25/the-new-kellum-method.html.

---

Related Topics