Visual Hierarchy VS DOM Hierarchy: Accessibility

Learn the difference between what the user sees and what the browser reads, and how to align visual hierarchy with the DOM for flawless accessibility in your product.

info Quick Definition
Visual Hierarchy is the order in which a user sees and processes information on a screen based on size, color, position, and contrast. DOM Hierarchy (Document Object Model) is the order in which HTML code structures and reads that same information. Aligning both is the key to accessibility and SEO.

Why the Designer Should Know the DOM Hierarchy

As designers, we often “draw” elements on the Figma canvas without worrying about their internal order. However, for a Screen Reader or Keyboard user, your design is not an image; it is a sequential list of elements.

If the “Buy” button appears visually at the end of the page (bottom right) but in the code it’s at the beginning (top left), a blind user will find it long before having read the product’s price or description. This generates massive cognitive confusion.

1. Visual Hierarchy (What is seen)

It is based on Gestalt principles and design tricks to guide the eye:

  • Size: Larger elements are seen first.
  • Color and Contrast: Vibrant colors catch attention before pastel tones.
  • Position: In the West, the eye typically reads in an “F” or “Z” pattern.
  • White Space: Separates logical groups and gives room for information to breathe.

2. DOM Hierarchy (What is read)

It is the logical structure the browser uses to interpret the page. It is defined by:

  • Tag Order: Element 1, Element 2, Element 3.
  • Heading Hierarchy: H1 > H2 > H3 > H4. It is your page’s “Table of Contents” for machines.
  • Container Relationships: Which elements are inside which others (parent/child).

The Big Problem: The Disconnect (Visual vs. Code)

Often, for aesthetic or layout reasons (using CSS Flexbox or Grid), the developer may change the visual position of an element without changing its position in the original code (the DOM).

  • Example: A banner that is visually at the very top but in the code it’s at the bottom for technical reasons.
  • Consequence: A keyboard user will tab through the entire page and, suddenly, the focus will magically jump to the banner at the beginning from the end. This feels like a system error.

How to Align Both Hierarchies (Best Practices)

As a product designer, you should be responsible for making the reading order and visual order consistent:

  • Design in Order: Try to make your layer order in Figma match the reading order. This will make it easier for the developer to build the DOM correctly.
  • Use Headings as a Guide: Do not choose H2 or H3 based only on text size. Choose the heading based on the section’s importance. If it’s visually a secondary section, it should be an H3 regardless of whether you want it to look large or small.
  • Specify the Tab Order: If your layout is complex (grids or asymmetries), add annotations in the handoff to indicate the desired reading order.
  • Beware of CSS order: Ask developers to use the Flexbox/Grid order property with caution, as it changes the visual position but often leaves the DOM intact, breaking focal accessibility.

Mentor’s Tips

  • Don’t Assume Browser Intelligence: The browser reads your code from top to bottom. If you design a header that is visually at the bottom, the browser will read it first only if the code is at the top. Be aware of this lag.
  • Test Layer Order in Figma: Figma has plugins to automatically reorder layers based on their visual position. Use them before handing over the file.
  • The Proximity Principle: Elements that are visually together should be together in the DOM. This sounds obvious, but in complex designs, it is often broken.

Useful Resources and Tools

accessibility-tree focus-management screen-reader-testing heuristic-evaluations