TailNG is building its own CDK and primitives

Accessibility-aware behavior, headless building blocks, and a Bedrock + Owned strategy for scalable Angular UI systems.

In this update

Own CDK layer

TailNG uses its own reusable Angular utilities for focus, keyboard navigation, overlays, ids, and interaction behavior.
Headless primitives

Primitives provide behavior-first APIs that components can build on without forcing one visual style.
Bedrock

A stable foundation for long-term contracts, accessibility behavior, and low-level composition.
Owned

TailNG-owned components with theme tokens, slots, and practical defaults for application teams.

Why we are building our own foundation

TailNG is built for modern Angular applications that need more than styled components. Large applications need consistent keyboard behavior, predictable focus handling, reusable overlay patterns, strong form composition, and components that can be owned by the product team.

Instead of depending on a full external component system, TailNG is building its own CDK and primitives layer. This gives us a small, focused foundation that can evolve with Angular signals, Tailwind-friendly styling, and real application needs.

The problems we want to solve

Keyboard and focus behavior drifting across components over time.
Reusable interaction logic being duplicated inside each component.
Difficulty customizing third-party components without deep CSS overrides.
Component APIs that are hard to adapt for product-specific workflows.
Need for accessible defaults without losing ownership of markup and styling.

The TailNG CDK layer

The TailNG CDK is the internal utility layer used by our primitives and components. It contains reusable behavior that should not be rewritten in every component: unique ids, keyboard navigation, active item management, selection behavior, overlay helpers, focus utilities, and shared accessibility contracts.

Interaction utilities

Keyboard action resolution
Active option management
Selection models
Roving and active-descendant patterns

Component infrastructure

Unique id generation
Overlay positioning helpers
Focus and blur handling
Shared state and data attributes

The goal is not to create a huge framework. The goal is to keep the low-level behavior reusable, testable, and consistent.

Headless primitives first

TailNG primitives are behavior-first building blocks. They provide Angular directives, state handling, ARIA relationships, keyboard behavior, and composition patterns without locking teams into one visual design.

Primitive examples

Option list primitives: active item, selection, keyboard navigation, disabled item handling.
Input primitives: labels, descriptions, invalid state, required state, generated ids.
Overlay primitives: anchor-based positioning, open/close reasons, outside interaction handling.
Form primitives: predictable control contracts for higher-level form-field components.

Components such as select, autocomplete, menu, listbox, form-field, and date controls can then build on these primitives instead of implementing behavior from scratch.

Accessibility is part of the foundation

TailNG is not currently using @angular/aria. Instead, we are building our own accessibility-aware CDK and primitives layer, shaped by the components we need in real Angular applications.

This means accessibility behavior is treated as a core contract, not as styling or a late-stage checklist. Keyboard handling, focus management, ARIA states, labelled-by relationships, described-by relationships, disabled states, and active item behavior are all part of the lower-level design.

Consistency

Shared keyboard behavior where patterns repeat.
Predictable focus behavior in lists, overlays, and controls.
Reusable ARIA relationship handling for form components.

Auditability

Behavior is centralized in CDK and primitives.
Each component has clearer accessibility responsibilities.
Test coverage can focus on shared interaction contracts.

Bedrock + Owned strategy

TailNG is evolving around a simple distribution idea: keep the stable foundation separate from the higher-level component layer. This helps teams adopt TailNG based on how much control they want.

Bedrock

Bedrock is the long-term foundation: CDK utilities, headless primitives, accessibility contracts, and minimal building blocks. It is designed to be stable, composable, and safe to build on.

Own CDK utilities
Headless primitives
Keyboard and focus contracts
Minimal styling assumptions
Composition-first APIs

Owned

Owned is the TailNG component layer: practical UI components, theme defaults, slots-based micro styling, and application-ready patterns. It can move faster while staying built on Bedrock.

Ready-to-use components
Theme-token based styling
Slots for local customization
Product-friendly defaults
Higher-level page patterns

What this means for teams

Use Bedrock when you want headless behavior and maximum control.
Use Owned when you want ready-made TailNG components with strong defaults.
Mix both when your application needs custom components beside standard TailNG components.

What changes for app developers

App developers should see more consistent behavior across TailNG components, especially in complex areas such as forms, tables, overlays, option lists, and keyboard navigation.

Expected improvements

More consistent keyboard navigation across related components.
Reusable behavior shared through primitives instead of duplicated per component.
Cleaner component APIs for forms, options, overlays, and selection.
Better local customization through slots and token-based styling.

Developer experience

Use high-level components for common product screens.
Drop down to primitives when building custom UI.
Keep styling close to the component with slot overrides.
Avoid deep CSS overrides and framework-specific styling workarounds.

Rollout approach

This foundation is being built incrementally. We are using real TailNG components and real application screens to validate the CDK and primitives layer before expanding it across the full library.

Focus areas

List navigation and option selection
Form-field and input behavior
Overlay positioning and close behavior
Autocomplete, select, listbox, menu, and date-related controls
Table and data component interaction patterns

The goal is a practical Angular UI system: small enough to understand, strong enough for enterprise screens, and flexible enough for product teams to own.

Links

Open docs View repo Back to updates

TailNG is evolving through real usage. If you find a behavior gap, accessibility issue, or styling limitation, please report it with steps to reproduce and expected behavior.