4.2. The DOM, Styles, and Functions of digital experience


Typically, a comparable and equitable experience is obstructed the ableist approach of production teams. On accessibility Berg (2019) finds they often:

  • Do not have trained employees.
  • Don’t understand their target market.
  • Feel it is too expensive or it drags out the timeline
  • Are simply unaware of the various needs of their users.

We can address that very easily. It’s not difficult. And we should expect digital product designers and producers to understand the following features of the Document Object Model (DOM), visual style and presentation, and functionality.

Timeline from project start to closure and from a small cost for accessibility work to a huge one bigger than a red dwarf star
The myth of accessibility being too expensive is perpetuated by organisations who failed to implement accessible design from the outset. The dark shadow is over the product owner 🙂

Introducing the DOM

The DOM (think of it as a map) is the structure of our content. Pieces of content are arranged linearly. Semantic information architecture and the arrangement of the content is vital to our users’  understanding. The order of our content in the DOM is the order in which content is encountered by browsing technologies.

Semantic segments of content are surrounded by opening and closing tags, which define what type of content they contain. For example, a heading (and its level), a paragraph, and a bulleted list. This is the language of HTML.

The DOM can be hard-coded (typed into the document file) or loaded dynamically into the document from external files when predefined conditions are met. For example, on our users’ interaction, depending on their device or browser type, and if our domain and their browser settings allow it.

Content placed in the DOM is accessible to all browsing technologies unless we remove or hide it.

Web and Platform Design Lore

All lore may be broken. In general, these code definition lores will keep you and your team in good stead:

For content.
For visual styling.
Adds function.
Three layers with the DOM and contents at the base, covered with Styles, and then with Function
Web and Platform Lore. The layers of experience. (Illustration by the author).

Native HTML Visual Style and Interaction

HTML’s visual presentation is limited by our browsers’ default design patterns. Over time and as ableist fashions and web design skills evolved, displaying native HTML is perceived to be unprofessional.

HTML’s default design patterns and presentation is inherently accessible and usable straight out of the box. We can add attributes too, which can natively update the presentation, change the keyboard tabbing order, or target styles defined elsewhere by CSS or acted on by functions in scripts.

Caution: It’s not all good for HTML. Many attributes have been devalued while some that should have been have not. Pointy finger at you, hidden="hidden". That said, it can be useful to hide pre-filled form inputs (shrug).

Updating Visual Styles

We can add CSS code to the DOM. CSS addresses visual style definitions to target HTML classes and ID attributes. Content can be hidden, displaced, and animated on our screens without using functions in scripts. And here we observe caution as CSS can remove content from the DOM or only visually from a display. Remove content from the DOM with CSS and no one can access it while using that CSS.

The best practice is to separate visual styling from the DOM. CSS can be placed on the page, and the best practice is to place it in one or more CSS files, which is the most efficient strategy when globally updating visual styles.

CSS styles that are ‘hard coded’ into the HTML elements (called inline CSS) must be updated in situ. Blocks of CSS can be added to each page and usually in the document’s head section. Again, global updates then require adjusting each page CSS block individually.

CSS is targeted to the special HTML attributes of Class and ID, which also enable the specific targetting of functions in scripts. More than one instance of the same class can live happily on the same page. IDs must be unique to each document

CSS can target the child (or nested) elements of the parent given a Class or ID. It can also create new pseudo-elements before and after each HTML element. Pseudo-elements can be configured in the CSS to display content, which does not exist in the DOM

Note: CSS is only active in a browser on our users’ choice. This doubles the importance of designing a well-structured HTML content in the DOM.

Scripted Functions

Scripts add function and depth of experience. Script functions are min-programs that define and capture our interactions with the DOM, and respond as programmed. JavaScript (JS) is the parent language used by popular web services and platforms using ASP, PHP, JSON, RESTful API, AJAX, etc.

JS is difficult to learn. Pre-programmed JS libraries are available that enable mere mortals to access the functionality of JS with minimal learning. An example is jQuery.

Scripts are often used to update the visual style of HTML elements using Classes and IDs to target where updates occur. Novice developers tend to write CSS styles directly into DOM elements, which can have disastrous consequences when it comes to a global update of the HTML, CSS, or JS. (CSS definitions must live in a CSS file or block).

To update visual styles using JS, it is best practice to add or remove Classes or IDs to and from the HTML in the DOM, which are styled by the CSS file or block.

Note: Usefully, scripts can add HTML to the DOM. It can include content from other files or manufacture the content on-the-fly. We exercise caution here as the execution of scripts in a browser is our users’ choice. This triples the importance of designing a well-structured HTML content in the DOM.


By using HTML, CSS, and scripts together, we can visually update the presentation without changing the DOM. If the DOM content and its information architecture is semantic and follows our users’ expectations, and it allows them to scan programmatically, then any visual changes we make must not frustrate that processing.

Common practices of websites and platform design appear to discriminate our less able users and in particular those who are blind.

As UX designers, we can and must penetrate the presentation layer and envelop our less able users within a delightful experience. Getting our Show and Hide methods right is one step in the right direction.


Berg, K., (2019, January 9). Law: Why Your Website Must Be Compliant. Retrieved from https://www.searchenginejournal.com/website-accessibility-law/285199/