This section is important to our presenting a comparable and equitable user experience. Hiding content from the DOM is perhaps the worst accessibility crime committed, and it’s committed constantly by immature production teams.
We hide content to reduce our visual users’ cognitive or motor overload. We believe it meets our learning theories of clumping and clumping can be achieved on the DOM with HTML and other landmarks. (Our departments also compete for publishing space).
Non-visual users and their alternative browsing methods don’t need ‘show and hide’ techniques at all. They navigate by skipping through all of the links or selected semantic HTML elements on a page such as Headings and Paragraphs. A content menu can be useful.
Hiding content is an ableist design strategy. Making our hide and show contents accessible is not the same as offering a comparable or equivalent experience.
Where our experienced and visually impaired users may recognise some patterns they may not recognise them across all applications. There is no standard.
Hiding content may not be great for our visual users, either. The additional cognitive load in determining what to reveal and motor load to interact and reveal content may be more overwhelming than only seeing all the content that is available.
An alternative to hiding content is to landmark it with visually discernable headings, white space, and other landmarks. And that’s another story.
These are the most popular methods of hiding content.
HTML attribute, “hidden”, which removes the element from the DOM. (Mostly bad and sometimes useful. It relies on JS to reveal the content or it is forever hidden).
CSS style declaration of, “display:none;”, which removes the element from the DOM. (Bad if CSS enabled in the browser)
JS function hide(), which removes the content from the DOM. (Bad if JS enabled in the browser. Almost the worst.)
CSS style to visually displace content to out of view. (Good. Content remains in the DOM).
CSS style to update an element’s height and prevent the content overflowing from it. (Good. Content remains in the DOM).
JS function toggleClass(), which adds and, or removes a Class attribute from an HTML element. (Good if CSS and JS both enabled in the browser).
Example Hide Methods
The following are demonstrations of the effects of the Show and Hide techniques. They are styled on the page with CSS <style> tags.
This first demo explores the HTML native attribute of, hidden="hidden".
The hidden="hidden" technique leaves the content available in the DOM, which is useful. At the same time, if we do want to display the content, we need a script to remove the attribute. For example, in jQuery: $(".hideMe").removeAttr("hidden");. And that is not ideal if JS is disabled in the browser, or has other issues that prevent showing the content.
In this second demo, we relocate or displace the copy text within the <span class="hideMe"> tags. The content remains available on the DOM.
Note: engineers will tell us this method imposes a small performance cost on the browser, which needs to process the displaced element off the screen, whether we can see it, or not. It’s a tiny price to pay to provide a comparable and equitable experience!
In this third and last demo, we can see that the experience of the paragraph changes in the DOM. Content is entirely removed from the DOM. In Demo 2, the content is removed from the visual experience and remains available to the DOM.
Caution: Use display:none; sparingly, if at all.
Example using scripts
In this demo, we introduce the advantages and pitfalls of using scripts.
We can do this and more without removing content from the DOM or making less able users jump through hoops when accessing our content. Only take care not to disadvantage your visual users by omitting content key to them.
With only simple CSS and easy JS techniques, we can all experience our content in a comparable and equitable way. Universally. Inclusively.
Unless you use a Content Management System. They are only crazy crap at delivering an accessible experience. And then, if a novice like me can add CSS and jQuery to this WordPress nonsense, then why shouldn’t our corporate CMS developer do the same?