However, the evolution of interfaces, variable typography, dark modes, and the need for truly perceptual accessibility have revealed an important limitation:
meeting WCAG 2 does not always mean text is genuinely readable.

This is where APCA (Accessible Perceptual Contrast Algorithm) comes in, the new approach shaping the future of visual accessibility and forming part of the transition toward WCAG 3.

The problem with contrast in WCAG 2

The current WCAG 2 model:

• Uses a fixed mathematical ratio between colors.
• Does not account for font size or font weight.
• Treats light-on-dark the same as dark-on-light.
• Can approve combinations that are difficult to read in practice.

This creates a common scenario in many digital products:

Interfaces that are “accessible on paper,” but not necessarily comfortable for real people.

What changes with APCA

APCA introduces a fundamental shift:
moving from a mathematical measurement to a perceptual measurement.

Instead of ratios like 4.5:1, APCA uses a scale called Lc (Lightness Contrast) that:

• Is based on how the human eye actually perceives contrast.
• Considers font size, font weight, and polarity.
• Enables different rules depending on the text type.
• Aligns with the future direction of WCAG 3.

The result is simple but powerful:

APCA measures real readability, not just technical compliance.

Why this is critical for Design Systems

For teams building Design Systems, the impact is immediate:

1. It redefines color tokens

It is no longer enough to “pass 4.5:1.”
Colors must now ensure comfortable reading within real typographic contexts.

2. It improves real product accessibility

Adopting APCA means:

• Less hard-to-read text.
• Better experiences in dark mode.
• More inclusive interfaces for users with low vision.

3. It prepares organizations for WCAG 3

APCA is not a passing trend.
It is the foundation of the next accessibility model coming with WCAG 3.

Adopting it early reduces:

• Technical debt
• UI rework
• Future compliance risk

WCAG 2 vs APCA in one sentence

WCAG 2 measures contrast.
APCA measures readability.

And in user experience, that difference changes everything.

Conclusion

Digital accessibility is entering a new era. We are moving from static rule-checking toward designing experiences that can truly be read.

Adopting APCA today does not mean abandoning WCAG 2 immediately, it means:

• understanding its limitations
• improving the visual quality of products
• preparing for the standard that is coming

Because in accessibility, the real goal was never to pass a test.

The real goal has always been that people can read.

The post APCA vs WCAG: why the future of visual accessibility has already changed appeared first on Roger Romero's Blog.

Understanding the Structure of Design Tokens

To structure an efficient design token system, it is useful to break tokens down into different layers of abstraction. This allows greater clarity when naming and managing styles across different components and systems. Below, we break down the structure based on the hierarchy shown in the main image, where tokens are divided into four major groups: Namespace, Object, Base, and Modifier.

Namespace: The Starting Point of the Structure

The namespace is the first layer of a design token system. Its function is to encapsulate a set of tokens under the same space, providing a clear organizational framework. In the image, three main categories are shown within Namespace:

• System: Here we find the prefix used as an acronym to identify the system “nds” (Name of the Design System).
• Theme: This focuses on design customization, allowing for theme switching. Examples of subcategories are brand (for brand-related tokens) and mode (for modes such as dark or light).
• Domain: A category aimed at dividing tokens by user type or domain, such as public, partner, consumer, internal, or business.

Each of these subcategories allows the same token system to be applied across different contexts or products without losing consistency.

Object: Defining System Elements

The next level is Object, which allows tokens to be grouped according to the type of object they affect. The main categories of this section include:

• Group: Covering generic groupings such as form or typography.
• Component: Specific elements like buttons (button) or links (link).
• Element: The smaller parts as icon or text children of the components

This organization ensures that tokens can be applied to any element of the design system in a clear and understandable way, from a complete component to a small icon or block of text.

Base: Defining Key Properties

The Base layer defines the fundamental properties that tokens control. Here, we find categories such as:

• Category: Grouping properties like color, font, spacing, sizing, border, opacity, shadow, among others.
• Concept: Referring to more abstract interaction concepts such as action, feedback, visualization, or display.
• Property: Specifies which property of the element or component the token is affecting. For instance, properties like background, foreground, border, family, size, weight, line-height, letter-spacing, text-case, and text-decoration are examples of how specific aspects of an element’s design can be fine-tuned.

This combination of Category, Concept, and Property within the Base layer provides a powerful way to describe what visual or behavioral aspects the tokens control, from basic visual properties like color and spacing to abstract concepts like action or feedback.

Modifier: Customizing Variations and States

Finally, we have the Modifier layer, which allows specifying variations, states, and modes for components. The main subcategories are:

• Variant: Tokens that control variations such as primary, secondary, tertiary, and other types like information, warning, error, and success.
• State: Describes interactive states like default, hover, focus, active, visited, or disabled.
• Scale: Includes adjustments for size and weight such as t-shirt sizes (lg,md,sm), numerical scales (1,2,3), weight (light,regular,bold), or tone (dark,medium,light).
• Mode: Tokens that define different display modes, such as on-dark or on-light.

This level allows flexibility for quickly applying modifications to components in different states or contexts, such as when a button transitions from its default state to a hover or focus state.

Practical Examples of Applied Design Tokens

In the second image we see examples of how these categories are applied to create specific token names that are functional and clear. Through the composition of different hierarchical levels, tokens are able to precisely describe aspects of any design element.

Example 1: nds-typography-display-lg

This token describes a specific font style (size) to be used in the display typography. It is designed for application to text. Let’s break it down:

• nds: Indicates the namespace, in this case, “Name of the Design System”
• typography: The object that this token affects, in this case, typography.
• display: Describes the purpose or concept for this token, referring to display text.
• lg: A scale modifier specifying that this is large-sized text.

Example 2: nds-component-button-color-background-primary-default

Another real-world token example shows how to describe the background color of a primary button in its default state:

• nds: Indicates the namespace, in this case, “Name of the Design System”
• component-button: The object it affects, in this case, a button component.
• color-background: The property it describes, which is the background color.
• primary: The button is of the primary variant.
• default: The state modifier indicating that this is the default state for the button.

Conclusion: The Importance of Organization in Design Tokens

By structuring a design token system in this way, you get a scalable, reusable, and easy-to-understand system, which is crucial for maintaining a consistent design system over time. The provided examples demonstrate how a clear hierarchy allows tokens to precisely describe all visual aspects of a system, from colors and fonts to states and modes.

This approach also facilitates collaboration between design and development teams, as everyone works under a common and understandable language, ensuring consistency across the digital ecosystem.

The post How to Structure an Effective Design Token System appeared first on Roger Romero's Blog.

Consistency: The Cornerstone of Design Systems

One of the primary goals of a design system is to establish a consistent visual language across all digital products and platforms. A naming convention for design tokens ensures that everyone involved in the development process, from designers to developers, understands and utilizes the tokens in a coherent manner. This consistency not only enhances the user experience but also streamlines the development process, reducing the time and effort required to maintain and update the design system.

Maintainability: Keeping Your Design System Future-Proof

As design systems evolve and grow more complex, maintainability becomes a critical factor. Descriptive and logically structured token names make it easier to understand their purpose and application, facilitating the maintenance of the design system over time. Developers and designers can quickly comprehend what each token represents and how it should be utilized, minimizing the risk of introducing inconsistencies or errors.

Scalability: Embracing Growth and Complexity

Design systems are meant to scale and accommodate new components, patterns, and functionalities as product requirements evolve. A well-defined naming convention helps maintain the organization and structure of tokens, enabling the design system to adapt and grow efficiently. As new elements are introduced, they can seamlessly integrate into the existing system, ensuring a cohesive and consistent experience for designers and developers alike.

Collaboration: Fostering Teamwork and Communication

In today’s collaborative development environments, clear and established naming conventions facilitate effective communication and collaboration among teams and individuals. Everyone involved can accurately and consistently refer to tokens, reducing confusion and misunderstandings. This shared understanding fosters a more productive and efficient workflow, enabling teams to focus on delivering high-quality products rather than deciphering ambiguous token names.

Automation: Streamlining Processes and Workflows

Many development and design tools and processes rely on the ability to analyze and process token names in an automated manner. A well-structured naming convention facilitates integration with these tools and processes, allowing for a more efficient and automated workflow. From generating documentation to performing automated tests, a consistent naming convention ensures that tools can accurately interpret and manipulate tokens, saving valuable time and resources.

In conclusion, establishing a clear and consistent naming structure, teams can create a robust and scalable design system that promotes consistency, maintainability, collaboration, and automation. Ultimately, this approach leads to more efficient development processes, improved user experiences, and a future-proof design system that can adapt to the ever-evolving needs of digital products and platforms.

How to Structure an Effective Design Token System

The post The Importance of Naming Conventions in Design Token Systems appeared first on Roger Romero's Blog.