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
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
- 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.