BEST PRACTICE

Is there a best practice for how to store data for org charts? Is there best practice for how org charts are presented? Gemini said Managing organizational chart data is a classic “graph problem” disguised as a business requirement. Because people have bosses, who have bosses, who have bosses, you’re dealing with hierarchical data that can become a performance nightmare if stored incorrectly.

Here is the breakdown of industry best practices for both storage and presentation.

1. Data Storage: How to Structure the Backend There are three common ways to store this in a relational database (SQL), each with its own trade-offs.

The Adjacency List (The “Simple” Way)

Each employee record has a manager_id column that points to their supervisor.

Pros: Very easy to update (just change one ID if someone moves teams).

Cons: Hard to query. To find an entire department, you have to run “recursive” queries, which can be slow as the company grows.

Nested Sets (The “Read-Heavy” Way)

Employees are stored with left and right values that define their place in a hierarchy.

Pros: Lightning-fast for fetching an entire tree or branch in a single query.

Cons: High “write” cost. If you add a new person at the top, you might have to update the left/right values for every other row in the table.

Path Enumeration / Materialized Path (The “Best of Both Worlds”)

Each employee record stores their full “ancestry” as a string (e.g., CEO/VP_Sales/Manager_Bob/Employee_Jane).

Pros: You can find all subordinates using a simple string search (LIKE ‘CEO/VP_Sales/%’). It’s intuitive and scales well.

Cons: You have to manage string updates if a manager’s name or ID changes.

2. Presentation: How to Visualize the Data A massive wall of boxes is where org charts go to die. To make them usable, follow these UI/UX best practices:

The “Hybrid” Layout

Don’t just go strictly horizontal or vertical.

Top Levels: Use Horizontal layouts for the C-suite and VPs to show breadth of responsibility.

Lower Levels: Use Vertical (Stacked) layouts for individual contributors. This prevents the chart from becoming 50 feet wide.

Essential Interaction Features

Progressive Disclosure: Start with the top level and let users click a + icon to expand specific branches. Never show the whole company at once.

Search and Center: Users should be able to search for a name, and the chart should automatically fly to that person and expand their management chain.

The “Me” View: Always provide a button that centers the chart on the user’s own profile.

Visual Cues

Dotted vs. Solid Lines: Use solid lines for direct reporting and dotted lines for “Matrix” or functional reporting (e.g., a Project Manager who reports to a Head of PM but works daily with a Dev Lead).

Card Design: Keep cards minimal. Name, Title, and Photo are the “Big Three.” Save details like “Hire Date” or “Bio” for a slide-out panel when the card is clicked.

Summary Table Feature Best Practice Database Use Path Enumeration or a Graph Database (like Neo4j) for scale. Logic Implement Recursive Common Table Expressions (CTEs) for SQL queries. Layout Hybrid (Horizontal for leaders, Vertical for teams). Performance Use Lazy Loading (fetch child nodes only when a branch is expanded). Would you like me to write a sample SQL schema or a JSON structure for a Path Enumeration model?

You said If an org chart has to be clicked on to expand items, can they be migrated to HTML and pass a wcag audit? Gemini said The short answer is yes, but it is a significant engineering challenge. Most interactive org charts fail WCAG audits because they rely on “drag-and-drop” or “canvas-based” rendering (like an image) that screen readers can’t parse.

To pass a WCAG 2.1/2.2 audit, your HTML org chart must treat the hierarchy like a nested tree widget.

1. The Semantic Structure The foundation must be a nested list (
   and
   • ). Even if you use CSS to make it look like a series of boxes and lines, the underlying “skeleton” needs to be a list so a screen reader can say, “Level 2, 1 of 5 items.”

Avoid or

The “Tree” Role: Use ARIA roles to tell the browser this isn’t just a list, but a functional tree:

• 2. Passing the “Keyboard Test” (2.1.1) This is where most org charts fail. A user must be able to navigate the entire chart without a mouse.

  Sequential Navigation: A user should be able to Tab to a person’s card and press Enter or Space to expand their direct reports.

  Arrow Key Support: For a “AAA” level experience, you should implement arrow key navigation (Up/Down to move through siblings, Right to expand/enter a level, Left to collapse/exit a level).

  Focus Visible: There must be a clear, high-contrast outline around the currently selected “card.”

  3. Accessible Expansion (4.1.2) When a user clicks a node to expand it, a screen reader user needs to know that something happened.

  aria-expanded: The button that toggles a branch must dynamically switch between aria-expanded=“true” and aria-expanded=“false”.

  aria-controls: The toggle button should point to the ID of the sub-list it opens.

  Announcing Changes: If the chart “re-centers” or moves after a click, use an aria-live region to announce, “Expanded Marketing Team, 12 new members shown.”

  4. Visual Contrast and Scaling (1.4.3 & 1.4.4) Contrast: Many org charts use pastel colors to differentiate departments. You must ensure the text-to-background contrast ratio is at least 4.5:1.

  Text Resizing: The chart must remain functional even if the user zooms their browser to 200%. This is hard with “fixed-width” box layouts, so your CSS should be flexible (using em or rem units).

  Checklist for your Audit Requirement Implementation Keyboard Operable Can I reach every “expand” button using only the Tab key? Expansion State Does the code change from aria-expanded=“false” to true on click? Meaningful Sequence If CSS is disabled, does the list still make sense logically? Color Independence If I remove color, can I still tell who reports to whom? (Use lines/labels). Pro-Tip: If the org chart is extremely complex, WCAG often suggests providing an alternative view, such as a searchable, flat directory or a standard “nested list” view that isn’t styled as a chart. This acts as a “fail-safe” for accessibility.