Should off-screen elements be accessible prior to being toggled?

Question

Reading around the web on accessibility is like trying to comprehend the cloud.

Too much information, too many opinions, too few real world test cases. Which brings me to my question:

Should off-screen/hidden content be rendered in the DOM prior to it being initiated by the user if not relevant prior?

Hiding content, visually, is frowned upon (I say this loosely because it depends), yet in some cases is still necessary; on smaller screens or where the desired expand/collapse/tab functionality is preferred (off-screen menus, etc). If the content being hidden is still viable while hidden, I see a reason for it to be only "visually hidden" yet still remain in the DOM. Now, take for example you have a context menu that pops up on right click, or even a widget for changing font size with a button "change font size" that expands when clicked. Is the content to be displayed necessary from an accessibility standpoint until the user actually interacts with the toggleable element?

I'm speaking in terms of accessibility, not SEO. (or... maybe the two are one and the same these days, who knows, I've been too buried in work to stay up to date).

Answer 1

If it comes to accessibility you should always ask yourself for the benefits and if it makes sense.

For example: Why should you tell the braille browser or screen reader for blind people that they can change the font size here or have a context menu there? In the best case it's just useless information, in the worst case you're triggering someone with their handicap(s).

Another example: If you have an off-screen sidebar with additional information for the content, then yes, you should make it accessibile (rendered in the DOM, marked for accessibility). Alternative you can hide it behind a link with self-explanatory description. Something like "Load additional content for this article".

BTW: I would say that your examples (context menu, font size widget) are not really SEO-relevant.

Answer 2

Maybe what you're looking for is a way to make it clear what your interactive element will lead to, so your user can decide whether to enter/click it or not.

In case you haven't seen this page yet, it may be helpful: Providing link text that describes the purpose of a link for anchor elements

Answer 3

I was wondering the same a while ago, so I’d like to clarify two misconceptions here and try to help with an accessible pattern.

Long story short: No, they should not be accessible prior to being toggled visible (in most cases).

Attention, a moral statement:

As user experience professionals, we know that we are not the users. We shouldn’t get lost in checklists, but without working with our users, in this case screen reader users, our judgement to what makes sense to them will be based on our biases. Either we include them in our UX process, or we rely on best-practices.

Visually hidden blocks of content shouldn’t be accessible to assistive technology either

About 20 % of screen reader users (one assistive technology) are not completely blind, according to WebAIM’s screen reader users survey #9. Many have low vision, and still look at the website.

So for this group of people it’s actually quite helpful to treat visually hidden content the same for screen readers, and also to increase font size. Often, a magnifier is used alongside a screen reader, as well.

There is a small exception to this rule where text is added solely for the benefit of screen reader users, for example if all links read “Read more”, to render the name for assistive technology “Read more about dolphins”.

There is a basic (level A) accessibility requirement regarding this detail. It requires the text that is presented visually (“Read more”) to be included in the accessible name of the element, which is read f.e. by screen readers.

I think this small detail illustrates nicely that coherence between visible content and that accessible to assistive technology is important. See Understanding Success Criterion 2.5.3: Label in Name

Learn more on real world accessibility issues

W3’s Web Accessibility Initiative did a great job in the recent years to accumulate user stories and personas, to make accessibility more accessible (;

Read more on visual disabilities on WAI

Content can be in the DOM, but still hidden from assistive technology

Should off-screen/hidden content be rendered in the DOM prior to it being initiated by the user if not relevant prior?

Let me rephrase this question to should that content be available to assistive technology (e.g. a screen reader) if not relevant prior?

Because DOM nodes often get hidden from screen readers AND visually by means of CSS properties like display: hidden.

Whether this part of the DOM should be there or not is therefore left to judgements about loading performance.

Best practice for accessibly hiding/revealing content

The established pattern is documented in detail by Disclosure in the ARIA Authoring Practices, where you can find a lot more.

Applied to your question, the important parts are:

• to have the button accessible that will toggle additional content
• That the content is hidden, for example by the hidden attribute
• That the aria-expanded attribute is present on that button, which tells the user that they can reveal more content by activating it.
• That users can easily find the content that got revealed. The common practice is to have that content right after the button in the DOM. An alternative might be to set focus to the beginning of that content.

Answer 4

Imho, I think you shall only render items in the DOME when these items shall be used/when the user asks for them. One exception might be skip-links.

From the accessible point of view, a screen reader won't se these items until they are rendered.

From the performance point of view, if you render the items when they are required the page will load faster and less data has to be transfererad.