# index
---
title: FAQs
side_nav_title: FAQs
side_nav_order: 1
description: Find answers to frequently asked questions about the Visa Product Design System.
meta_description: Find answers to frequently asked questions about the Visa Product Design System.
---
## About Nova
### What is Nova?
Nova is the latest version of the Visa Product Design System (VPDS). It embodies the team’s commitment to creating the next wave of Visa products and experiences, marked by enhanced cohesion and consistency.
To learn more about Nova and VPDS, visit [What is VPDS?](https://design.visa.com/about-VPDS)
### What is the difference between Nova and Vault Key+?
Nova and Vault Key+ are major versions of VPDS. Vault Key+ is the third and final iteration of the Vault design system. All the code libraries provide low-level accessible [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) components to help build experiences that follow Visa’s brand and product guidelines. Nova components are built following [Visa Global Accessibility Requirements (VGAR)](https://developer.visa.com/pages/accessibility), meeting VGAR, WCAG 2.2, A, and AA standards.
Nova is the current supported version of VPDS and will continue to receive support for the foreseeable future. Since many stable products use Vault Key+, it will continue to receive security and framework upgrades, as well as bug fixes for the foreseeable future. However, all future expansion efforts are now directed toward Nova.
To learn more about VPDS versions, visit [Releases](https://design.visa.com/what's-new/releases).
### Why is Nova recommended over Vault Key+?
Nova is the latest version of VPDS and will continue to receive support for the foreseeable future. It includes new design tokens for easy theming, updated visuals, and new libraries for icons and mobile components. Nova components are available in [Angular](https://design.visa.com/developing/angular), [Flutter](https://design.visa.com/developing/flutter), [React](https://design.visa.com/developing/react), or [Styles (CSS)](https://design.visa.com/developing/styles-css).
As with any version of our design system, always follow [VGAR Test Procedures](https://developer.visa.com/pages/accessibility/test-procedures) to ensure experiences meet accessibility requirements.
### Does Nova have a stable release?
Yes. For more information, visit [Releases](https://design.visa.com/what's-new/releases).
### Is Nova compatible with Vault Key+?
Nova is the latest version of VPDS and is recommended for all new projects. Its [Angular](https://design.visa.com/developing/angular), [Flutter](https://design.visa.com/developing/flutter), [React](https://design.visa.com/developing/react), or [Styles (CSS)](https://design.visa.com/developing/styles-css) components can be used along with Vault Key+ components in stable Vault Key+ applications.
Nova and Vault Key+ are separate libraries with different scopes and names, so Nova isn't backwards compatible with Vault Key+. This means you can't use Nova as a drop-in replacement for Vault Key+ because they are designed independently. However, both libraries can coexist in the same application using the same Styles (CSS), React, or Angular library versions.
### Can I use both Nova and Vault Key+ in the same project?
Yes, you can swap older, Vault Key+ components for Nova versions or add new features in Nova without upgrading the rest of your application.
### What is the process and support available for transitioning from Vault Key+ to Nova?
Nova and Vault Key+ can coexist to support a gradual transition to Nova. In addition, Nova is built with first-class theming capabilities to help make this transition smoother. Our team is available to provide help for migration plans as needed.
To get help or join our office hours, visit [Support](https://design.visa.com/support).
### Are there any plans to sunset Vault Key+ ?
Currently, there are no plans to sunset Vault Key+. However, as technical specifications evolve and we notice reduced Vault Key+ usage from our analytics, the team may reconsider.
### When do I need to upgrade to Nova?
We recommend designing all new Visa products using Nova assets, but there's no mandated deadline for teams to upgrade to Nova.
### What if Nova doesn't have a component I need?
The VPDS team is continuously adding new assets to the system, including components. If there’s a component you need that’s not in our system, Visa employees can contact the VPDS team by visiting [Support](https://design.visa.com/support).
### How do I report a bug or request a feature in Nova?
Reach out to the team for help by visiting [Support](https://design.visa.com/support).
## Design
### Can I customize or detach Nova components?
Yes, you can detach components. Many components, such as the Dynamic table, include subcomponents that are easier to manipulate once detached. However, remember that design software has limitations on customizing components, especially if you're creating a variant that isn’t in the design system yet. Ensure you communicate any customizations to your development team early and again during handoff.
## Development
### Can I use the latest Angular, React, or Flutter versions with Nova?
We regularly update to the latest library and framework versions to add new features, improvements, and security updates to our system while keeping our components stable and compliant.
To learn more, visit the changelogs for [Angular](https://design.visa.com/developing/angular/changelog), [Flutter](https://design.visa.com/developing/flutter/changelog), [React](https://design.visa.com/developing/react/changelog), or [Styles (CSS)](https://design.visa.com/developing/styles-css/changelog).
### Can I use Nova with other design systems, like Bootstrap?
Nova's class names are unique, but other libraries might have CSS resets that can change the box model, root font size, or layout. We recommend moving away from any outdated libraries and embracing Nova to experience all its capabilities, along with modern Styles (CSS) features like Flexbox and Grid.
### Vault used to have a Grid component, but that's not available in Nova. What should I do?
The Grid component within Vault was a layout utility that was created to support old browsers. VPDS encourages teams to embrace modern CSS features like Flexbox and CSS Grid within Nova, which offer more powerful and flexible layout options.
For more information, reference [Grid resources (internal only)](https://bookmarks.visa.com/vpds-angular-foundations-grid).
## Accessibility
### Does VPDS provide accessibility guidance?
Yes, VPDS provides accessibility guidance for components and patterns to help designers and developers create inclusive digital products. We also provide Visa’s Global accessibility requirements, which ensure that Visa’s digital products meet global accessibility standards. These requirements help in planning, design, and development to prevent costly rework.
To learn more, visit [Global accessibility requirements](https://design.visa.com/global-accessibility-requirements).
### Have VPDS components been accessibility reviewed and tested?
Yes. Nova components are built following VGAR, meeting VGAR, WCAG 2.2, A, and AA standards.
### Are VPDS components and assets routinely regression tested?
Yes, VPDS components are regression tested annually.
## Content
### Does VPDS provide guidance for writing content?
Yes. To learn more about crafting thoughtful and concise content, visit [Content](https://design.visa.com/content).
### Have VPDS assets been content reviewed?
The Content Design team has partnered with Accessibility to review all available VPDS components for descriptive headings, labels, and more. Additionally, all assets have been reviewed ensuring they follow content guidance for [Placeholder text](https://design.visa.com/content/placeholder-text). This means when you use a VPDS component, medium fidelity placeholder content has been added to help your team further edit and customize components.
## Data visualization
### What are Visa Chart Components?
Visa Chart Components (VCC) are a library of accessible web chart components with robust accessibility configurations to enhance your workflow and ensure your product meets the latest accessibility standards. The VCC library is maintained to provide charts that work alongside VPDS components. VCC can be used with React, Angular, and Vanilla JavaScript.
To learn more, visit [Visa Chart Components](https://design.visa.com/data-visualization).
### What if I need a chart that's not in Visa Chart Components?
Visa employees can contact the Data Experience team to discuss needs for any charts that aren’t available in Visa Chart Components (VCC).
To get connected with the Data Experience team, visit [Support](https://design.visa.com/support).
---
# index
---
title: Inclusive design
description: Gain insight into the use of inclusive design to ensure Visa products include everyone, everywhere.
meta_description: Learn how to implement inclusive design to ensure Visa products include everyone, everywhere.
thumbnail: assets/about-vpds/inclusive-design/inclusive-design-graphic.svg
header_image: assets/about-vpds/inclusive-design/inclusive-design-overview.svg
related:
content:
- index
---
Inclusive Design considers the full range of human uniqueness and the diversity of perspectives, abilities, and backgrounds throughout the product design and development process. The intent is to fulfill as many needs as possible and drive innovation that unlocks equitable, accessible, and ethical experiences. This guidance provides an overview of key concepts and their impacts, such as how Design@Visa infuses Inclusive Design throughout its practices and embodies an equity-driven approach.
## Best practices
### Embody an equity-based approach
Strive for an equity-based approach. When designing, we start by addressing the needs of underrepresented groups, ensuring fair treatment and opportunity, and then design outward. This approach helps us create digital experiences that are truly inclusive and beneficial to all users.
This is the counterpart to an equality-based approach, in which resources are allocated equally regardless of barriers that may prevent some groups from accessing or utilizing them. In an equity-based approach, fair treatment and opportunity are afforded while striving to deconstruct barriers that prevent the all groups from participating equally.
### Embrace the complexity of human uniqueness
Human identities are complex intersections of various factors such as class, gender, ethnicity, and more. These elements interplay and can’t be singled out to determine how inequity impacts an individual. During your product design process, respect this complexity to build digital experiences that enhance access and reduce barriers for all users, especially those from underrepresented groups.
### Avoid centering on dominant culture
Consciously avoid designing from the perspective of a dominant culture, which often becomes the default lens for design decisions. Recognizing dominant defaults allows us to disrupt these norms, creating more inclusive designs.
One way to accomplish this is by using the term “misrepresented” instead of “marginalized,” “underserved,” “unserved,” “vulnerable,” or similar terms. Misrepresented identities are those that have been defined by the dominant culture and denied the ability to define themselves on their own terms. They are falsely or narrowly represented. In terms of financial terminology, avoid phrases like "underbanked" or "unbanked," as they don’t fully encompass financial inclusion. Instead, use "underinvested".
### Strive for greater financial inclusion
As a global leader in digital payments, Visa is committed to fostering inclusion, particularly financial inclusion, as a part of our corporate responsibility. Our mission is to uplift all individuals, everywhere, by providing the best payment solutions. Strive to dismantle barriers to financial access, such as expanding account accessibility to include more participants in the global economy.
## Inclusive design process
The design process is the way in which product teams approach meeting a user need and is imperative to bringing a product to market. The core group of cross-functional team members, or Triad, is responsible for product delivery and are responsible for proactively addressing inclusion at every step of the process. The Triad includes a product lead, a design lead, and a technology lead (engineering). All three are involved in all the conversations of end-to-end product delivery.
### The design process at Visa
Our design process is an iterative approach in which:
- Design is an end-to end partner to product, technology, and beyond
- Designers work iteratively to discover, define, develop, and deliver great experiences and outcomes
- Design teams are structured across three pillars: Opportunity, Experience, and Solution
#### Human-centered design and inclusive design
Inclusive Design is a part of human-centered design, where both put real humans and the problems they face at the center of the design and development process. At its core, human-centered design is based on a philosophy made to ensure products and services are tailored to the needs of as many users within an audience as possible.
Inclusive design is more focused and considers the full range of human diversity, including physical and mental abilities, language, race, gender, age, and other forms of human differences. It aims to drive innovation that unlocks equitable, accessible, and ethical experiences for all backgrounds and abilities. When practicing human-centered design, inclusive design should be considered a part of your process.
#### Universal design and accessible design
Universal and accessible design are often confused for one another. While the two concepts are closely related to inclusive design, accessibility is focused on ensuring that people of all abilities can use digital products and tools equally, where universal design aims to create one experience that can be accessed, understood, and used to the greatest extent possible by all users with a wide range of abilities, disabilities, and other characteristics.
Universal design differs from human-centered design as universal design is more conceptual and philosophical, while user-centered design process-focused. When using human-centered design processes, keep inclusive, universal, and accessible design philosophies and methodologies in mind to help reduce barriers between humans and technology.
## Inclusive research
Design research is heavily involved in the Discover and Define phases of the design process. These phases focus on deep discovery of a user need (getting the right need) and definition of the need (getting the need right), while surfacing recommendations for when a solution gets designed. Research is user-driven, as it is directed at generating new ideas or evaluating what’s been built to provide the best experience possible for users. Design research should be performed by design researchers, and in the absence of design researchers, designers, developers, and product managers should partner to ensure inclusion is incorporated in the design process. Teams should consult with the design research organization to ensure they are measuring their product team inclusion (using the Inclusion score), and incorporating inclusion into their process in the recommended manner.
### Examples of how design research can boost inclusion:
- Validate that the need actually exists with users (don’t design for something they don’t need)
- Include the right data by ensuring there’s a proper sample size to provide useful feedback and including secondary and tertiary personas in addition to primary personas..
- Enlist co-design, a participatory approach in which the community of users is treated as an equal collaborator
- Ensure diversity of collaborators, and involve them early in the design process
## Impact
Companies are expected to be transparent around their business approach now more than ever. Consumers have become more conscious as they desire to align themselves with brands, companies, and products that share their social, political, and moral values.
### Financial inclusion
As a global leader in digital commerce and finance, Visa processes billions of transactions daily and drives economies worldwide with its vast payment network. This positions us uniquely to foster global financial inclusion. It's our responsibility to ensure our services are designed for all individuals and businesses, regardless of their demographic or business attributes. We also have the capacity to create opportunities for those previously unable to partake in local and global economies.
To achieve this, we apply inclusive design practices in our focused areas. Throughout the design and development lifecycle, the cost of change can escalate considerably. However, this can be mitigated by understanding the real needs of users and businesses and translating these needs into appropriate specifications from the beginning of the design process.
### Opportunities within payment
Within the payments space there are many emerging B2C and B2B business cases to build more inclusive products. Below are a few examples of how Visa is working to create inclusive experiences.
Enabling digitally inclusive government-to-citizen paymentsDesigning with government beneficiaries and financial institutions to increase cards used as a payment tool instead of a cash-access tool in government disbursement programs.Increasing affordability with installmentsDesigning with consumers to help manage cash flow and budget based on their current financial position.Ensuring global mobility with Tap to PhoneDesigning with consumers and small- and mid-sized businesses may to help increase the types of phones that work with Tap to Phone (TTP).Allowing chosen name on credit cardsDesigning with LGBTQIA+ consumers and financial institutions to reduce false positives on credit applications, or help issuers avoid deadnaming LGBTQIA+ community members.
#### ESG reports
- Explore Visa’s current and past [Environmental, Social and Governance Reports](https://usa.visa.com/about-visa/esg/resources.html) to learn how we’re delivering our purpose to uplift everyone, everywhere by being the best way to pay and be paid.
#### Case studies
- Learn how Visa is [collaborating with Fintech partners](https://usa.visa.com/audiences/fintech.html) to help pioneer new modes of commerce and new ways to pay.
#### White papers
- Explore the [Visa Economic Empowerment Institute’s white papers](https://usa.visa.com/sites/visa-economic-empowerment-institute/digital-financial-inclusion.html) on fostering digital inclusion.
## Resources (internal only)
- [VGAR SharePoint](https://bookmarks.visa.com/va11y-sharepoint)
- [Inclusion & Diversity Hub](https://bookmarks.visa.com/vpds-inclusion-diversity-hub)
---
# index
---
title: What is VPDS?
side_nav_title: What is VPDS?
description: Learn more about the Visa Product Design System.
---
The Visa Product Design System (VPDS) is an all-encompassing toolkit designed to revolutionize the product design and development process. Recognized across Visa’s product ecosystem, VPDS:
- Enhances collaboration among teams.
- Ensures brand consistency throughout products.
- Accelerates time to market across various platforms.
This robust system unifies design and development, offering a cohesive approach to creating digital products. Utilizing VPDS helps your product:
- Seamlessly integrate with other Visa offerings.
- Facilitate the creation of intuitive user experiences.
- Resonate with Visa's brand values.
## What are the benefits of VPDS?
VPDS simplifies the product development lifecycle, empowering your team to innovate and deliver high-quality products that go to market faster. The key benefits include:
- **Efficiency:** Accelerate design and development with pre-built components, reducing repetitive tasks and rework.
- **Accessibility:** Create accessible experiences using libraries pre-tested for global accessibility standards.
- **Consistency:** Use standardized guidelines, components, and patterns to uphold brand trust and user satisfaction.
- **Collaboration:** Follow best practices and principles embedded in the system to enable effective teamwork.
- **Scalability:** Keep products forefront with regular updates based on user feedback and industry standards.
- **Innovation:** Drive innovation by allowing your team to focus on creative solutions while VPDS covers the basics.
## What is a design system?
Design systems provide a centralized library of assets and guidelines to ensure consistency and efficiency. This includes extensive libraries of pre-built components, design patterns, and comprehensive content guidelines, all tailored to meet the highest standards of accessibility, usability, and aesthetic excellence. VPDS supports [design kits](https://design.visa.com/designing/design-kits) in Figma and code libraries for [Angular](https://design.visa.com/developing/angular), [React](https://design.visa.com/developing/react), [Styles (CSS)](https://design.visa.com/developing/styles-css), and [Flutter](https://design.visa.com/developing/flutter). These resources are continuously updated based on user feedback and the latest technological advancements. By leveraging these assets, teams can streamline their workflows, foster innovation, and create cohesive user experiences across all Visa products.
## What's the history of VPDS?
VPDS has undergone several releases since Hamlet launched in 2018. Each release has brought improvements in scale, usability, and accessibility based on community feedback. Support for Hamlet ended in 2022, followed by its successors Vault and Vault Key. The third and final version of the Vault system, Vault Key+, continues to receive support and fixes for the foreseeable future.
The latest version of the design system is called Nova. Inspired by the astronomical phenomenon, Nova symbolizes a burst of energy and innovation. This version embodies the VPDS team’s commitment to creating the next wave of Visa products and experiences, marked by enhanced cohesion and consistency. Just as a Nova signifies a powerful transformation in the cosmos, this release represents a significant leap forward in Visa’s design system.
Product teams are encouraged to begin migrating to this version as it will continue to receive new additions and support moving forward. For more information on current and past versions, visit [Releases](https://design.visa.com/what's-new/releases).
## Who manages VPDS?
The Visa Product Design System is managed by a collaborative team of designers, developers, content designers, accessibility partners, researchers, and ops. Collectively, the team ensures the system remains current and effective by continuously updating resources based on cross-discipline reviews, user feedback, and industry best practices. To connect with the VPDS team or learn more about office hours or quarterly updates, visit [Support](https://design.visa.com/support).
## Ready to get started?
Transform your product design and development process by choosing one of the paths below.
---
# Usage
---
title: Color
description: Learn how to use Visa brand colors to create and maintain consistent and engaging experiences.
tab_title: Usage
tab_order: 1
keywords: ["color", "brand colors", "color contrast", "color palette", "contrast"]
tags:
- colors
- brand
- accessibility
---
Colors used within the Visa Product Design System were adapted from Visa brand colors for digital products and experiences. These colors were designed to provide flexibility to designers and developers, including themes for Visa-branded products and generic colors which serve as a starting point for representing clients and fictitious brands.
Reference Visa brand guidance for more information on color use outside product design.
## Best practices
## Active colors
Active colors are the primary color used to indicate interactivity. Active subtle is used for interactive pieces that need less emphasis but sufficient contrast.
## Surface colors
Surface colors are used for the largest background areas of an application. They are also used as backgrounds on subtler interactive elements in combination with active colors, such as in the secondary button.
## Text colors
Text colors are used to ensure readability and accessibility. They are applied to various text elements such as headings, body text, and labels, and are chosen to provide sufficient contrast against background colors.
## Decorative colors
Decorative colors are only applied to elements that don’t have color contrast requirements, such as disabled components or container borders. They add visual interest and enhance the aesthetic appeal without impacting functionality or readability.
## Messaging colors
Messaging colors are used for components like [Section messages](https://design.visa.com/components/section-message/usage), [Flags](https://design.visa.com/components/flag/usage), [Banners](https://design.visa.com/components/banner/usage), and [Dialogs](https://design.visa.com/components/dialog/usage), to communicate the urgency of a message or alert. These colors are used sparingly to ensure they don’t overwhelm the primary content.
## Color for Visa-branded products
All Visa-branded products should use the Visa theme palette along with the alternate palette to achieve a consistent experience that accurately represents the Visa brand.
## Theme background colors
The Visa theme contains two background colors that allow you to change between a default and alternate color treatments. These were designed for navigation headers and bold splash screens. Changing the theme background color will automatically adjust the design tokens to ensure accessibility contrast ratios are met.
- Use the alternate palette sparingly and intentionally. Too much color variation can disorient or overwhelm users.
## Visa light and Visa dark modes
The Visa light theme serves as the default mode for most use cases, providing a clean and consistent user experience. The Visa dark theme offers an alternative mode for Visa-branded applications, reducing eye strain in low-light environments with its darker colors. Learn more about themes and modes in [Design tokens](https://design.visa.com/base-elements/design-tokens/overview).
## Color for data visualization
Color can be used as a tool to communicate meaning in data visualizations. To learn how to select the most effective type of color palette for your data visualization, reference the Data Experience team’s design guide for [Color (internal only)](https://bookmarks.visa.com/vpds-vcc-color-guidelines).
---
# accessibility
---
title: Color
description: Learn how to use Visa brand colors to create and maintain consistent and engaging experiences.
meta_description: Learn how to use Visa brand colors to create and maintain consistent and accessible experiences.
tab_title: Accessibility
tab_order: 2
tags:
- colors
- brand
- accessibility
---
## Using color for meaning
While color is an important, it should never be used alone to convey meaning. Always pair color with another communication method, such as text or icons, to ensure everyone can understand and interact with Visa products.
## Color contrast for accessibility
Color is measured by the visual contrast between an element and the surface it appears on. Ensuring colors pass contrast requirements means combining them intentionally. When creating your own theme or custom designs, follow the patterns in the Visa theme palette to make sure your product is accessible.
If you make changes to Visa theme colors, there are many free browser extensions and other tools which test contrast on a page.
**Note:** Disabled controls are not subject to color contrast ratios.
- Ensure text uses foreground colors with a contrast ratio above 4:5:1.
- Ensure user interface elements, graphics, and text that are 14 point bold or larger, use foreground colors with a ratio above 3:1.
### High contrast
Users can select settings in their operating system to increase color contrast because of visual impairment, to reduce eye strain, to reduce distractions, or personal preference. VPDS components and themes handle high contrast modes out of the box. However, please note the following, especially if you use custom themes, icons, or logos. For more, reference [Horizontal navigation](https://design.visa.com/components/horizontal-navigation/accessibility) or [Vertical navigation](https://design.visa.com/components/vertical-navigation/accessibility).
CSS media queries are used to target OS high contrast settings. There’s also a media query to determine whether a page has a light or dark background. Automated testing doesn’t test page appearance or meaning in high contrast modes. For this reason, manual testing is especially important for Windows high contrast mode.
### Windows high contrast mode
Windows high contrast mode completely removes background colors and background images with limited exceptions. It also sets text colors, form control colors, borders and outlines according to the theme chosen by the user.
- Replace box shadows with borders or outlines as the shadows will be automatically removed.
- Ensure outlines don’t conflict with focus styles.
- Consider using a border or outline in HC mode if background colors are used to demarcate a section of the page.
- `img` elements are not changed.
## Data visualization
There are additional color requirements for visualizing data. Reference [Data visualization](https://design.visa.com/data-visualization).
---
# index
---
title: Color
description: Learn how to use Visa brand colors to create and maintain consistent and engaging experiences.
meta_description: Get code for Visa brand colors to create and maintain consistent and engaging experiences.
thumbnail: assets/base-elements/color/color-graphic.svg
tab_title: Code
tab_order: 0
tags:
- colors
- brand
- accessibility
---
---
# index
---
title: About design tokens
side_nav_title: Overview
side_nav_additional_screenreader_title: for Design tokens
description: Explore guidance for using design tokens or variables to customize themes and experiences.
meta_description: Use design tokens and themes to customize your product experiences, ensuring consistency, scalability, and accessibility.
thumbnail: assets/base-elements/design-tokens/design-tokens-graphic.svg
related:
baseElements:
- color
- typography
---
## What are design tokens?
Design tokens are name-value pairs that define small, repeatable design decisions. Tokens can represent colors, typography, spacing, or even icons tailored to specific needs. Designers can use Visa Product Design System (VPDS) design tokens in Figma to easily adjust visual properties, while developers can modify a set of global variables to achieve the same effect in code.
## What is theming?
Theming is the practice of using a collection of token values to achieve a specific look or style. A theme is essentially a predefined set of tokens designed to work together harmoniously. Examples of themes include Visa light and dark. Theming can also extend beyond colors to include elevation, spacing, and shape and size.
### Theming terms
Definitions of theme, design token, and value
- Term: A collection of visual attributes assigned to the tokens in order to create a specific aesthetic.
- Term: A role-based identifier that assigns a value to a theme. Design tokens are universal and never change across themes. These are sometimes referred to as variables although not all variables are design tokens.
- Term: The actual style (such as a hex code) assigned to a token.
## Themes in our system
### Visa
The Visa theme supports light and dark modes. This theme automatically defaults to your system's preferences unless you override this behavior. Learn more about [switching between light and dark modes](https://design.visa.com/base-elements/design-tokens/tokens-for-developers#switching-between-light-and-dark-modes).
### Default
The Default theme uses the VPDS color theming system for non-Visa branded products. It supports light and dark modes and automatically defaults to your system's preferences unless you override this behavior. Learn more about [switching between light and dark modes](https://design.visa.com/base-elements/design-tokens/tokens-for-developers#switching-between-light-and-dark-modes).
## Theme elements
VPDS supports theming at various levels, from broad adjustments to component-specific changes. Both CSS and Figma can be used to override system values for color, typography, icons, elevation, shape and size, and spacing.
### Color
Colors can be adjusted to represent Visa, our clients, or fictitious companies. Each theme is assigned universal color variables based on common roles and usage, ensuring uniform color application across themes while maintaining full styling flexibility. Always consider contrast requirements to ensure designs are accessible to all users.
For more information, visit [Color.](https://design.visa.com/base-elements/color)
### Typography
Visa Dialect UI is the standard font for Visa-branded digital interfaces. For non-Visa branded experiences, you can adjust the font choice as needed, but avoid using Visa Dialect or Visa Dialect UI. Mobile applications may benefit from using native fonts based on the platform to take advantage of built-in features. For browser-based applications, we recommend Open Sans. Maintain the size ratios shown in the type ramp to ensure consistent text hierarchy across experiences.
For more information, including our type ramp, visit [Typography.](https://design.visa.com/base-elements/typography)
### Icons
VPDS currently supports two sets of icons: Visa-branded and generic, to represent ideas, actions, and entities. Products using the Visa theme should use the Visa icon set, while all non-Visa themes should use the generic set.
To learn more about the icons available for use, visit [Icons and illustrations.](https://design.visa.com/components/icons-illustrations)
### Elevation
Elevation tokens define the perceived surface level and shadow, creating depth and hierarchy in your designs. These help simulate realistic lighting and layering effects, ensuring a cohesive and polished visual experience.
For more information, including how to layer elements in CSS, React, and Angular, visit [Elevation.](https://design.visa.com/base-elements/elevation)
### Size and shape
Size and shape define the corner rounding and dimensions of components within the system. Use the Figma assets panel to apply preset rounding options, such as Square, Less rounded, More rounded, or Full rounded. Similarly, the size of individual design elements or entire layouts can be scaled up or down to fit your use case.
For more information, visit [Size and shape.](https://design.visa.com/base-elements/size-and-shape)
### Spacing
Spacing refers to the blank space inside and around elements to achieve various levels of visual density. Use the Figma assets panel to apply preset spacing options, including Dense, Default, or Spacious layouts.
For more information, visit [Spacing.](https://design.visa.com/base-elements/spacing)
## Customizing a theme
Designers and developers can customize their components and styles to deviate from the default Visa light theme. Within Figma, designers can modify one, some, or all of the default token values to create a new theme. Developers can configure these new values in the appropriate files, either replacing the default values or adding new custom tokens.
---
# index
---
title: Design tokens for designers
description: Learn how to leverage design tokens to customize components effortlessly while maintaining a cohesive visual identity and experience.
side_nav_title: Tokens for designers
show_on_overview: false
---
## Before you begin
Make sure you understand the basics by visiting [Design tokens and theming](https://design.visa.com/base-elements/design-tokens/overview).
### Common use for design tokens and theming
- **White labeling for non-Visa products:** Easily adapt your designs for external brands.
- **Mockups using fictitious brands:** Create realistic prototypes for presentations and pitches.
### Common ways to theme in Figma
- **Batch adjust components with presets:** Use variable modes to change multiple components simultaneously.
- **Create custom themes:** Modify one, some, or all of the default token values (variables) to create a new theme.
## Using variable mode presets
Design tokens are represented by variables within Figma. These variables can be changed to alternate preset values through the Figma user interface. Using variable modes helps to ensure that customizations are within the design system’s rules and capabilities. For example, the color themes have been tested to ensure proper contrast when applied to VPDS components.
### Step 1: Select a page, frame, or component
Add or select a component within your workspace to activate the properties panel on the right. Select the **Apply variable mode** button, represented by an icon of two hexagons with a dot in the middle, to explore the presets.
### Step 2: Start customizing
Once you’ve explored the presets provided by VPDS, use the variable modes to swap the theme background, typography, shape, and more. You can also select multiple components or the entire frame to apply consistent styles.
The table below includes the names of the base elements, along with their corresponding variable mode in Figma, and preset values. These will help you navigate the system and customize your designs effectively.
Base elements mode, presets and tokens
- Base element: Color theme
- Variable mode: Visa light, Visa dark, Gray blue light, Gray blue dark, Purple light, Purple dark, Green light, Green dark, Black and white light, Black and white dark
- Preset values: [Color](https://design.visa.com/base-elements/color)
- Base element: Platform
- Variable mode: Web, mobile
- Preset values: N/A
- Base element: N/A
- Variable mode: N/A
- Preset values: [Elevation](https://design.visa.com/base-elements/elevation)
- Base element: N/A
- Variable mode: Visa, Generic (modified through properties)
- Preset values: N/A
- Base element: N/A
- Variable mode: Use Figma scale tool
- Preset values: [Size and shape](https://design.visa.com/base-elements/size-and-shape)
- Base element: Shape
- Variable mode: Rounded (default), Less rounded, Full rounded, square
- Preset values: [Size and shape](https://design.visa.com/base-elements/size-and-shape)
- Base element: Padding
- Variable mode: Default, Spacious, Dense
- Preset values: [Spacing](https://design.visa.com/base-elements/spacing)
- Base element: Typography
- Variable mode: Visa Dialect UI, Open Sans, Noto Sans, SF Pro, Roboto
- Preset values: [Typography](https://design.visa.com/base-elements/typography)
## Create custom themes
Customizing beyond the provided properties can create additional development work. For maximum efficiency, continue the application of system rules throughout your customizations whenever possible. To make implementation of custom themes easier for your team:
- Edit the values of the existing design tokens (linked in the table above).
- Define values for a custom color theme by understanding how colors are applied to components to ensure proper contrast. Visit [Color accessibility](https://design.visa.com/base-elements/color/accessibility) to learn more.
- Create custom components using existing design system components as building blocks whenever possible. Follow system rules for communicating [States](https://design.visa.com/base-elements/states).
---
# index
---
title: Design tokens for developers
description: Use design tokens to customize your applications with consistent, scalable theming.
meta_description: Learn how to leverage design tokens to customize your applications with consistent, scalable theming.
side_nav_title: Tokens for developers
show_on_overview: false
---
## Before you begin
Make sure you understand the basics by visiting [Design tokens and theming](https://design.visa.com/base-elements/design-tokens/overview) or reference the following overview.
## Understanding base elements
The base elements of our system represent visual aspects that can be themed at various levels, from broad adjustments to component-specific changes. These elements include accessibility styles, color, elevation, icons, shape and size, spacing, and typography.
This page provides an introduction to app-level and component-level theming for web and mobile. To find tables containing the variables of each element and their default values, reference the Code tabs of each of the following:
- [Accessibility styles](https://design.visa.com/developing/styles-css/accessibility-styles)
- [Color](https://design.visa.com/base-elements/color)
- [Elevation](https://design.visa.com/base-elements/elevation)
- [Icons and illustrations](https://design.visa.com/components/icons-illustrations/code)
- [Size and shape](https://design.visa.com/base-elements/size-and-shape)
- [Spacing](https://design.visa.com/base-elements/spacing)
- [Typography](https://design.visa.com/base-elements/typography)
## Theming for mobile (Flutter)
There are two types of theming that can be performed using our library: App-level theming and widget-level theming.
### App-level theming
The following provides an example of how to apply light and dark mode as an app-level theme.
#### Step 1: Add light and dark theme
Under your MaterialApp(), add both light and dark theme:
#### Step 2: Add the provider package
Next, add provider package in your pubspec.yaml. In your main .dart file, create a ThemeProvider, provide your themeData, and wrap your app with it:
#### Step 3: Switch the theme
Then, anywhere in your code, call and to switch the theme. In the code example above, you'll notice that the font is now customizable. But don't forget to add your fonts in your pubspec.yaml.
### Widget-level theming
Theming can also be performed at the widget level. This example shows how to change the theme of a button to VButtonSecondary.
## Theming for web
Theming for web can be performed at the app-level or component-level using CSS variable overrides.
### App-level theming
The following theming configuration allows you to modify a small set of variables for maximum impact across components.
- controls how components and sizes adapt on smaller screens, below the mobile breakpoint.
- controls how much space appears between elements, making the UI feel more compact with smaller values or more relaxed with larger values.
### Switching between light and dark modes
Learn how to switch between light and dark modes using our Nova web libraries.
#### Step 1: Import your chosen theme
The Visa and Default themes support light and dark modes. Reference the Get Started guides for [Angular](https://design.visa.com/developing/angular), [React](https://design.visa.com/developing/react), or [Styles(CSS)](https://design.visa.com/developing/styles-css) for instructions on how to import themes into your application.
#### Step 2: Set the theme attribute
Apply a data-theme attribute to your tag. The possible values are light or dark.
**Note:** The Visa and Default themes automatically default to your system's light or dark mode preference. To override this behavior and use your desired mode, set the data-theme attribute to light or dark.
#### Step 3: Switch the mode
To switch between light and dark modes, change the value of the data-theme attribute. This example uses plain Javascript, but you can also use React or Angular to manage the theme state and switching logic.
#### Best practices for switching modes
- For accessbility purposes, consider defaulting to the user's system preferences for light or dark mode. This can be done by checking the prefers-color-scheme media query.
- Use local storage or cookies to save the user's preferences if you want the theme to persist across page reloads.
### Color
The simplest way to customize your application colors is by adjusting the palette.
### Typography
To override the typography value, you can use CSS variables or utilities.
### Padding
To override the padding value, you can use CSS variables or utilities.
### Shape
The simplest way to customize the shape is by adjusting the corners.
### Margin
To override the margin value, you can use CSS variables or utilities.
### Component-level theming
When overriding only one component or one instance of a component without customizing the whole theme, you can redefine the component variables directly. The following example shows this using a checkbox component.
### Variants
For some customization efforts, you may need to update the markup structure or the display properties of the component. To make this easier, we provide examples of some basic variants you can extend to create custom components. Learn more in our [Abstract examples](https://design.visa.com/developing/styles-css/abstracts/action-primary).
You can also find utility classes that can help you shape your components with [Typography](https://design.visa.com/base-elements/typography), [Flex](https://design.visa.com/base-elements/responsive-grid-system/flex), and [Spacing](https://design.visa.com/base-elements/spacing) examples.
---
# index
---
title: Elevation
tab_title: Code
thumbnail: assets/base-elements/elevation/spatial-model.svg
description: Discover how to use elevation to layer elements and surfaces to create more intuitive and visually appealing interfaces.
meta_description: Discover how to use elevation to layer elements and surfaces to create more intuitive and visually appealing interfaces.
---
## Component Code Examples: elevation
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the elevation component
const component = parsed.components.find(c => c.name === 'elevation');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `elevation`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Elevation
tab_title: Usage
tab_order: 1
description: Discover how to use elevation to layer elements and surfaces to create more intuitive and visually appealing interfaces.
---
Elevation shows the relationships between different surfaces within an application. Consistently mapping elevation levels helps to create an application that mirrors the physical world and feels comfortable and understandable for users.
## Component elevation
Components within each surface layer are mapped to a corresponding elevation level. The diagram below displays the relationship between components and their elevation levels.
## Shadow specs
Proper use of shadows enhances the visual hierarchy and depth in an application. The chart below lists the shadow values to apply for each elevation level, ensuring consistent and realistic visual effects throughout the application.
Table showing shadow specs
- Layer name: -1
- Elevation: **Shadow 1:** 0, 0, 2 px, 0 rgba(0,0,0,0.10)
**Shadow 2:** 0, 2 px, 5 px, 1 px rgba(0,0,0,0.10)
- Layer name: 6
- Elevation: **Shadow 1:** 0, 12.5 px, 25 px, -6 px rgba(0,0,0,0.25)
## Applied in practice
The following is an example page layout with a top navigation, side panel, and dialog box with an accompanying diagram of component elevations (right).
---
# index
---
title: Base elements
meta_description: Discover our system’s visual and architectural standards used to ensure consistent digital experiences.
page_size: large
description: Discover our system's visual and architectural standards used to ensure consistent digital experiences.
show_table_of_contents: false
---
---
# breakpoints
---
title: Responsive grid system
description: Use the responsive grid system to organize design elements for visual consistency across pages.
---
## Component Code Examples: breakpoints
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the breakpoints component
const component = parsed.components.find(c => c.name === 'breakpoints');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `breakpoints`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# flex
---
title: Responsive grid system
description: Use the responsive grid system to organize design elements for visual consistency across pages.
---
---
# index
---
title: Responsive grid system
tab_title: Usage
description: Use the responsive grid system to organize design elements for visual consistency across pages.
thumbnail: assets/base-elements/responsive-grid-system/responsive-grid-system-graphic.svg
header_image: assets/base-elements/responsive-grid-system/platform-scale-overview.svg
related:
patterns:
- application-layouts
---
A responsive grid system is a framework enabling apps and website to adapt their layouts to fit different screen sizes or orientations. This helps ensure visual consistency throughout a product experience while still allowing for flexibility in design.
VPDS grids guide element placement on a page, working with VPDS components, spacing, and typography. They adjust sizing based on the platform to ensure designs are consistent, usable, and appealing on any screen or device.
## Anatomy
**A. Margin:** The empty space on the two outer edges of the grid. **B. Column:** Vertical guides spanning the width of the screen. **C. Gutter:** Empty space between columns with fixed widths based on the defined breakpoints. **D. Content area:** Area containing page content or components that can span any number of columns.
## Fixed vs. fluid grids
### Fixed grids
Fixed grids have a set maximum width with fixed columns and gutters. As the screen size changes, the content areas maintain a fixed width and the margins grow or shrink. They’re ideal for text-heavy designs, enhancing readability.
### Fluid grids
Fluid grids scale with screen width, using all the available space. Columns expand as the screen grows, while gutters and margins remain fixed. They’re ideal for dashboards or data-heavy designs.
## Breakpoints
Breakpoints are specific points where the layout changes to match different screen sizes. The grid system was designed around the different [Application layouts](https://design.visa.com/patterns/application-layouts) that VPDS offers. Each grid adapts to both the screen width as well as the navigational structure for each layout.
### Horizontal and advanced layouts
The grid designed for horizontal and advanced layouts is simple and flexible. Its variants are fluid by design with one option for a fixed grid at larger screen sizes.
Breakpoints for horizontal navs, which lists the number of columns, margins, and gutters
- Breakpoint: 4
- Number of columns: 16px
- Margins: 16px
- Breakpoint: 8
- Number of columns: 16px
- Margins: 24px
- Breakpoint: 12
- Number of columns: 24px
- Margins: 24px
- Breakpoint: 12
- Number of columns: 80px min
- Margins: 24px
### Vertical and mixed layouts
The grid designed for vertical and mixed layouts adapts to accommodate the left navigation panel. The grid begins to the right of the left navigation, with the space between the navigation panel and the first column serving as the left margin. While the grid system is fixed in Figma, it can also be built as fluid.
Breakpoints for vertical and mixed layouts, which lists the number of columns, margins, and gutters
- Breakpoint: 12
- # columns: 24px
- Margins: 24px
- Breakpoint: 12
- # columns: 24px
- Margins: 24px
- Breakpoint: 12
- # columns: 32px
- Margins: 24px
- Breakpoint: 12
- # columns: 32px
- Margins: 24px
- Breakpoint: 12
- # columns: 32px
- Margins: 24px
- Breakpoint: 12
- # columns: 32px
- Margins: 24px
- Breakpoint: 12
- # columns: 32px
- Margins: 24px
- Breakpoint: 12
- # columns: 32px
- Margins: 24px
## System baseline
A baseline grid ensures consistency within content areas across platforms. It guides the design of foundational elements like typography and iconography, as well as main components.
### Factors of four
The VPDS grid system is based on factors of four as the base unit. For example, for vertical spacing, it is suggested to use spacing blocks of 16px, 24px, 32px, 48px, etc.
**Note:** Aligning to half pixels and using odd numbers may disrupt clean pixel alignment.
## Content reflow
As screen width changes, consider how your content areas will shift or reflow. It's crucial to communicate this reflow to the development team, ensuring they understand how the design should adapt at each breakpoint. Reflow can be defined in terms of percentages or column spanning. For instance, if a content area occupies 50% (6 columns) at 1600px, it might occupy 25% (4 columns) at 1280px. Define your reflow patterns based on the components within your content areas.
## Screen size
The VPDS grid system is designed to scale across multiple platforms, from mobile to ultra-wide screens. Each view is designed for seamless content scaling. Note the grid dimension changes from mobile to desktop: Margins increase from 16px to 24px, and the number of columns changes with screen width. Mobile components fit easily into the predefined mobile grid.
### Example layouts
The following is an example of a form designed in both web and mobile.
### Web
### Mobile
## Component size
### Web scale
Web components have a base height of 38 dp. The default component size is determined across the system by the base height.
{/* no alt because the image doesn't give info not in paragraph */}
### Mobile scale
The mobile scale is 1.25 times larger than web, with a base height of 46 dp. It’s applied for native mobile and responsive web views when a touch device is detected.
{/* no alt because the image doesn't give info not in paragraph */}
## Typography size
Typography also scales up for mobile platforms. Body 2 is the base body copy size for the design system. Body 2 is defined as 14 px for web platforms and 16 px for mobile platforms. Get more detailed specifications in [Typography.](https://design.visa.com/base-elements/typography/usage)
## Units
Not all screens and platforms have the same pixel density, which is the number of pixels in a given area. This results in elements appearing larger on screens with lower pixel density and smaller on screens with higher density.
To address this, iOS uses points (pts) to determine the pixel density of Apple devices. Android uses density-independent pixels (dps) to scale designs uniformly across all screens. A density-independent pixel uses a physical pixel on a screen with a density of 160 pixels per inch as the base.
Unit usage and operating system
- Unit: Android
- Unit: Image resolution
- Unit: iOS
- Unit: Web
- Unit: Type scaling
---
# index
---
title: Size and shape
side_nav_title: Size and shape
thumbnail: assets/base-elements/size-and-shape/size-and-shape-graphic.svg
description: Find examples and classes for defining the dimensions and shape of elements in your designs.
---
## Component Code Examples: sizes
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the sizes component
const component = parsed.components.find(c => c.name === 'sizes');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `sizes`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Spacing
side_nav_title: Spacing
thumbnail: assets/base-elements/spacing/spacing-graphic.svg
description: Access resources to ensure consistent spacing between, outside, and within digital elements.
meta_description: Access resources to ensure consistent spacing between, outside, and within digital elements.
---
## Component Code Examples: spacing
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the spacing component
const component = parsed.components.find(c => c.name === 'spacing');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `spacing`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: States
tab_title: Code
description: Consistently apply visual cues and design patterns to communicate a component’s interaction state.
thumbnail: assets/base-elements/states/states-graphic.svg
header_image: assets/base-elements/states/states-overview.svg
---
## Flutter widget state
Flutter Widget State is used to manage the state of a widget and its lifecycle. For more details, refer to the official [WidgetState Documentation](https://api.flutter.dev/flutter/widgets/WidgetState.html).
### Additional widget state resources
[Widget Lifecycle](https://docs.flutter.dev/ui/interactivity#the-widget-lifecycle)
[Stateful and Stateless Widgets](https://docs.flutter.dev/ui/interactivity#stateful-and-stateless-widgets)
## State management
State management is the process of handling the state of an application to ensure it behaves as expected and remains responsive to user interactions. It's crucial in Flutter to ensure the UI updates correctly when the state changes.
### Additional state management resources
[Managing State in Flutter](https://docs.flutter.dev/data-and-backend/state-mgmt/intro)
[Flutter State Management Options](https://docs.flutter.dev/data-and-backend/state-mgmt/options)
[Flutter State Management Guide](https://docs.flutter.dev/data-and-backend/state-mgmt)
---
# usage
---
title: States
tab_title: Usage
description: Consistently apply visual cues and design patterns to communicate a component’s interaction state.
thumbnail: assets/base-elements/states/states.svg
header_image: assets/base-elements/states/states-overview.svg
---
States are visual cues and design patterns that are consistently applied to components to help the user better understand the interaction. States include default, hover, focus, and more.
## Anatomy
Three sections showing states. Section A shows a default button state is blue, active hover is brighter, focused with a keyboard is brighter and has an extra dotted border, pressed is dark blue, and disabled is gray. The same states are shown again with a white or transparent button, with hover, keyboard focus, and pressed all having a light blue fill. Section B shows a selected chip is blue with a white checkmark. Section C shows three tabs with the first tab active. The active tab has a light gray background and blue line underneath the text.
**A. Color:** Value of the active and surface color that adjusts based on the component state.
**B. Icon:** Visual indicator communicating the selected state.
**C. Active indicator line and text:** Line used to indicate the selected view, with text changing to bold when active.
## Component states
Component states support user interactions and guide visual design expectations. Not all components will have all of the following states.
### Default
The default, enabled state for all interactive elements and components.
### Hover
The state when the mouse pointer is placed over the component. Not used on touch devices.
### Pressed
The temporary state indicating a component is being tapped, clicked with a mouse, or triggered with a keyboard.
### Focus (keyboard)
The state indicating an interactive component is in-focus during keyboard or voice-activated navigation.
### Focus (mouse)
The state indicating an input field has been clicked into and is currently in-focus. This isn’t used for any other components.
### Active
The state indicating the currently selected item out of a set, menu, or list.
### Selected (on/off)
The state showing the user’s selection, usually from a list of options, a checkbox, or a setting.
### Disabled
The inactive state of a component, indicating the action is not available and can’t be interacted with.
### Read-only
An inactive state which may show possible or past interactions, or the absence of editing rights.
### Expanded
State indicating that a component is expanded, with the menu arrow pointing up.
### Error
State that uses color and an icon with text to indicate an error and provide user guidance.
## Interactive target areas
Ensuring sufficient space around interactive areas is vital as it facilitates easier interaction, particularly for users who may struggle with precise movements. When using components with smaller visual footprints, it's important to design with ample touch area in mind and avoid placing elements too closely together.
### Touch targets
Use the minimum size of 44 x 44 dps for touch areas across all interactive components.
For additional context, learn more about challenges faced by [users with a limited ability to use a mouse](https://www.w3.org/WAI/people-use-web/user-stories/#reporter).
### Non-touch targets
- Use the minimum size of 24 x 24 dps for touch areas across all interactive components.
- Rounded corners detract from 24 x 24 target.
- To learn more about accessibility minimum targets, refer to [WCAG guidance](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html).
---
# index
---
title: Surface
description: Use these generic styles to define the layout and visual hierarchy of your app with surface components, or customize and create your own components.
thumbnail: assets/base-elements/surface/surfaces-graphic.svg
---
## Component Code Examples: surface
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the surface component
const component = parsed.components.find(c => c.name === 'surface');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `surface`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# accessibility
---
title: Typography
tab_title: Accessibility
tab_order: 2
description: Get guidance, examples, and code to enhance readability through consistent text styles and hierarchy.
meta_description: Get code to enhance accessibility through consistent text styles and hierarchy.
thumbnail: assets/base-elements/typography/typography.svg
header_image: assets/base-elements/typography/typography-overview.svg
---
Creating access for everyone, everywhere requires attention to accessibility attributes, best practices, and requirements. Find accessibility guidance below.
## Best practices
- Avoid using pure visual styles to convey structural knowledge or indicate relative importance.
- Ensure a color contrast ratio of at least 4.5:1 for text, informational images, and images of text to their backgrounds. For text that is 18 point or 14 point bold or larger, maintain a ratio of 3:1.
### Text spacing
In content implemented using markup languages that support the following text style properties (user agent default styles, author styles, user styles), ensure no loss of content or functionality by setting all of the following without changing any other style property:
- Set line height (line spacing) to at least 1.5 times the font size.
- Set spacing following paragraphs to at least 2 times the font size.
- Set letter spacing (tracking) to at least 0.12 times the font size.
- Set word spacing to at least 0.16 times the font size.
**Note**: For human languages and scripts that do not use one or more of these text style properties, conform using only the properties available for that language and script combination.
### All capitals
There are no specific WCAG guidelines on the use of ALL CAPS. Opinions vary on their use among users with cognitive disabilities, non-sighted, and low vision. The style guide in the content foundation recommends using sentence case (capitalizing the first letter of each title, label, phrase, or sentence, while still capitalizing proper nouns).
#### Cognitive disabilities
Users with cognitive disabilities might find it difficult to read due to indistinct word shapes instead of distinctive word shapes. For instance, compare the word shape of "CONTACT US" to "Contact Us."
#### Non-sighted
Screen readers announce text letter-by-letter only when a word cannot be formed from the combinations of letters. For example, a screen reader may read the uppercase text "CONTACT US" as "Contact U. S." because it interprets the uppercase "US" as an acronym for "United States."
#### Low-vision
Users with visual impairments might find words in all capitals more legible when zoomed in or viewed from a distance, as ALL CAPS appears relatively larger in font size than normal text.
---
# index
---
title: Typography
tab_title: Code
description: Get guidance, examples, and code to enhance readability through consistent text styles and hierarchy.
meta_description: Get code to enhance readability through consistent text styles and hierarchy.
thumbnail: assets/base-elements/typography/typography.svg
header_image: assets/base-elements/typography/typography-overview.svg
---
## Component Code Examples: typography
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the typography component
const component = parsed.components.find(c => c.name === 'typography');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `typography`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Typography
tab_title: Usage
tab_order: 1
description: Get guidance, examples, and code to enhance readability through consistent text styles and hierarchy.
meta_description: Learn how to enhance readability through consistent text styles and hierarchy.
thumbnail: assets/base-elements/typography/typography.svg
header_image: assets/base-elements/typography/typography-overview.svg
related:
content:
- readability
baseElements:
- design-tokens/overview
---
We created a new humanistic typeface, Visa Dialect, designed specifically for our brand. Its foundation is built on our core brand attributes: accessible, inclusive, and approachable. It's modern, but still feels like it has been crafted by the human hand. It has been designed to be approachable, unique, and easily read on any device.
Visa branded digital experiences use Visa Dialect UI. Visa Dialect UI has been created specifically for user interfaces. It has narrower forms than Visa Dialect and has been designed to be highly efficient for small typographic settings.
Internal users can access Visa Dialect UI on [Sharepoint (internal only)](https://bookmarks.visa.com/vpds-sharepoint).
For digital experiences that are not Visa branded, font choice can vary as needed, but should not be Visa Dialect. Mobile applications may be best suited to use native fonts based on platform, to take advantage of built in features. For browser based applications, we recommend Open Sans, which is from Google's Open Fonts Directory.
## Type ramp
For this ramp, there are type categories built in to support and simplify usage. While applying the styles, keep in mind the typographic hierarchy set in place and the intended use for each type style.
### Headlines
The headline category is meant for page and section titles. Display 1 and 2 are intended for banner areas and landing pages, and may not be suitable for use across a whole application.
- Start most page designs with Headline 1 as your largest headline size.
- Use typography with a line height about 1.3x the size of the text, referred to as 'line-height-short' in the system.
- Use sentence case.
- Avoid adding punctuation such as periods, commas, colons, or semicolons unless completing sentences or for impact.
Heading measurements, font, and levels
- Label: **Size/line height:** 60 px/78 px
**Paragraph spacing:** 0px
- Mobile: 1px
- Letter spacing: Semibold/ 600
- Weight: H2-H6
### Overline
- Pair overline headlines with display, headline, or subtitle content. These are sometimes called an eyebrow or category.
- Use all caps for overline headlines, containing no periods, commas, colons, or semicolons after sentence fragments, and limit to 1–3 words.
### Body
The body category is meant for paragraph styling for the main content areas of your page. Most applications will use Body 2 as the default body copy styling, and doing so will ensure proper relationship between the content of your page and the design system components.
- To increase readability, typography in this category uses a line height about 1.5x the size of the text. We define this is ‘line-height-default’ in the system.
- Body 1, 2, and 3 should always use sentence case and all standard punctuation.
Body text measurements, weight, and tags
- Label: **Size/line height:** 16 px/24 px
Item 1 - with enough words to make a text wrap, so paragraph spacing is apparent.
Item 2
Item 3
Use ordered lists when the sequence of the items is important, such as step-by-step instructions.
#### Unordered lists
Item 1 - with enough words to make a text wrap, so paragraph spacing is apparent.
Item 2
Item 3
Use unordered lists when the sequence is not important.
### Detail
Typography in the detail category is applied to the interactive components in the design system.
- Use typography with a line height about 1.3x the size of the text, defined as "line-height-short" in the system.
- Use UI label large for tables, tabs, and navigation; it matches Body 2.
- Use UI label for labels on input fields and form elements.
- Use UI label small for labels on icon buttons.
Button and label measurements, spacing, and weight
- Label: **Size/line height:** 14px/ 18px
**Paragraph spacing:** 0px
- Mobile: 0px
- Letter spacing: Regular/ 400
## Applying the type ramp
When using the type ramp to build an interface, it is recommended not to modify or change properties such as weight, size, and color for any type style. Each type style has been selected with consideration for user needs and systemization within the overall design system.
## Hierarchy
Effective typographic hierarchy makes content easy to consume and understand. It enhances scan-ability and guides users on what information to focus on first. Use it as a tool to direct the reader’s attention to the content in the desired order.
Headline 2 <h2>Financial inclusion
Headline 3 <h3>What is Financial inclusion?
Body 2No barriers between you and the financial services you need to survive and thrive.
Subtitle 1 <h4>Where we focus our efforts
Body 2We’re using the power of our network to create new solutions, stimulate investment and innovation, promote usage, and encourage strong enabling environments, from China to Colombia, Africa to America.
### Consistent appearance
Maintain a consistent appearance for text within the same category.
### Sentence case
Use sentence case, as Visa adopts this in nearly all scenarios.
## Text alignment
There are three options for text alignment: right-aligned, center-aligned, and left-aligned.
### Right-aligned
Right-align text for side notes or visual grouping.
### Center-aligned
Center-align text for copy in UI elements such as buttons.
### Left-aligned
Left-align text for product copy. This is most common in left-to-right-languages.
## Paragraph spacing
Spacing between paragraphs can affect how users perceive relationships between information. Keep paragraph spacing between 0.75 and 1.25 times your font size. In Microsoft Word, this equates to a full line of spacing between paragraphs.
## Line height
Line height, also known as leading, is the space between baselines in a block of text. It measures the distance from the bottom of one line of text to the bottom of the next.
We recommend a line height approximately 1.5 times the font size, translating to 1.5 line spacing in Microsoft Word. On iOS, this is measured in pixels (px), and on Android, in density-independent pixels (dp).
## Line length
The ideal line length is around 50-75 characters, including spaces, or 12-14 words per line. Longer lines of text can feel intimidating and overwhelming to users, potentially leading them to avoid reading. Conversely, lines that are too short disrupt the reader’s rhythm by requiring frequent eye movements.
Table adapted from the [Baymard Institute](https://baymard.com/blog/line-length-readability).
## Language considerations
Visa Dialect has a vast Latin and Cyrillic character set, making it suitable for many languages. For languages not supported by Visa Dialect, we use [Noto Sans](https://fonts.google.com/noto), a free font available from Google.
Languages vary in average word lengths and heights, which can affect typography layout. When internationalizing our typeface, consider the differences in word length, alignment, height, and language categories. Reference [Material’s guidance](https://m2.material.io/design/typography/language-support.html#language-considerations) regarding language support for more information.
---
# accessibility
---
title: Accordion
tab_order: 2
description: Sets of vertical headers that reveal or hide subsections of content.
meta_description: Find accessibility guidelines for vertically stacked headers that expand and collapse related content panels.
thumbnail: assets/components/accordion-graphic.svg
---
## Best practices
**Note:** VPDS uses native HTML `details` and `summary` elements.
- Use descriptive accordion titles that reflect the content within the associated panels.
- Check that the icons in the accordion header use the library’s right-to-left class if needed.
## Keyboard controls
Keyboard actions and their corresponding behaviors for accordion
- Key: Moves focus to the next focusable element. All focusable elements in the accordion section are included in the tab sequence.
- Key: Moves focus to previous focusable element. All focusable elements in accordion section included in tab sequence.
- Key: Expands or collapses the section panel when focus is on the accordion's header.
---
# index
---
title: Accordion
tab_title: Code
thumbnail: assets/components/accordion-graphic.svg
description: Sets of vertical headers that reveal or hide subsections of content.
meta_description: Get code for vertically stacked headers that expand and collapse related content panels.
categories:
- structure-and-layout
---
## Component Code Examples: accordion
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the accordion component
const component = parsed.components.find(c => c.name === 'accordion');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `accordion`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Accordion
tab_title: Usage
tab_order: 1
description: Sets of vertical headers that reveal or hide subsections of content.
meta_description: Learn how to use vertically stacked headers that expand and collapse related content panels.
keywords: ["Summary (html)", "expand/collapse", "hide/show"]
related:
components:
- content-card
- checkbox
- tabs
patterns:
- wizard
---
Accordions are vertically stacked sections of content that, when selected, expand or collapse to reveal or conceal related content panels. They’re a type of progressive disclosure that simplify large amounts of content and minimize scrolling.
Also known as: Summary (html), expand/collapse, hide/show.
## Anatomy
**A. Chevron (required):** Interactive element indicating that users can expand or collapse the accordion. **B. Header section (required):** Area containing the accordion title which briefly describes the content in the expanded panel. **C. Panel (required):** Area containing content that, when expanded, provides details relevant to the header.
## Usage
When to use and when not to use different types of accordions
- Component: To present users with multiple sections of content that can be expanded simultaneously. This is the most common use case.
- When to use: To organize content into clear, distinct categories where only one category should be viewed at a time. Use single-select accordion instead.
If there is not enough content to warrant condensing. Add this content to the main content area of the page instead.
To organize large volumes of content into separate, distinct categories. Use [Tabs](https://design.visa.com/components/tabs/usage) instead.
To provide a visual summary of information. Use a [Content card](https://design.visa.com/components/content-card/usage) instead.
- Component: To present users with multiple sections of content, but only one can be expanded or viewed at a time.
- When to use: If users would benefit from viewing information between multiple sections simultaneously. Use a multi-select accordion instead.
For complex, step-by-step tasks. Use a [Wizard](https://design.visa.com/patterns/wizard/usage) instead.
To provide a visual summary of information. Use a [Content card](https://design.visa.com/components/content-card/usage) instead.
## Best practices
- Use accordions carefully as they diminish content visibility and increase interaction cost.
- Never hide critical information that should be easily accessible within an accordion.
- Enhance usability by making the header section clickable for content expansion.
### Multi-select accordions
Multi-select accordions provide users with control over how they view the information by allowing them to expand multiple sections of content at once. They are typically used for FAQs, product descriptions, and event or course details.
- Allow users to reference or compare multiple sections of content at the same time.
- Place in logical locations to maintain the natural flow of the page, ensuring they’re easy to find and use.
### Single-select accordions
Single-select accordions only allow users to view one section of content at a time. They are ideal for small screen sizes as they minimize clutter and focus user attention on specific content. Learn more in [Platform considerations](https://design.visa.com/components/accordion/usage/#platform-considerations).
- Use single-select accordions sparingly as they reduce user control and can lead to frustration.
- Position single-select accordions logically to preserve page flow, ensuring easy discovery and interaction.
#### Automatic closure
Single-select accordions only allow users to expand one section at a time. The expanded section should automatically collapse when the user selects a new section.
- Ensure users also have the ability to control when they want to close a section and open another.
### Chevron direction
Visually differentiate expanded and collapsed sections using the chevron direction. In some cases, it may be appropriate to use a plus (+) or minus (-) icon instead of a chevron. Whichever method you choose, use it consistently.
#### Collapsed
Collapsed sections should use the inactive color palette.
- Use the right pointing chevron to indicate collapsed content can be expanded.
- Use the plus (+) icon to indicate that the section can be expanded.
#### Expanded
Expanded sections should use the active color palette.
- Use the downward pointing chevron to indicate expanded content can be collapsed.
- Use the minus (-) icon to indicate that the section can be collapsed.
## Behaviors
### Applying accordion functionality
In some cases, it may be appropriate to combine interactive elements to achieve accordion-like functionality. Unlike standard accordions that only reveal or conceal content, these combinations can be used to show or hide additional user options or actions. This functionality can be accomplished using a UI icon button or text button to expand or collapse the section. Keep in mind that these combinations have different accessibility considerations than single- and multi-select accordions.
#### Revealing a checkbox group
Accordion functionality can be used to expand or collapse additional options within a checkbox group. This is achieved by combining a UI icon button with checkbox group, where selecting the chevron would show or hide additional, nested options. This design requires careful consideration as it introduces a two-step process which can add confusion for users.
##### Collapsed
The user selects the chevron button to reveal the options within the checkbox group.
- Ensure the checkbox is visible when the accordion is collapsed to indicate there's an action to be taken.
- Use the right pointing chevron to indicate collapsed content.
##### Expanded
The user makes their selection from the available options within the checkbox group.
- Group related options and order them logically by either the order of importance or alphabetically.
- Use the downward pointing chevron to indicate expanded content.
#### Revealing a panel
Accordion functionality can be used to expand or collapse a panel through a button. For example, showing additional filters and fields for advanced search. A similar function is used to expand an inline help panel for [credit card security codes](https://design.visa.com/patterns/card-input/#security-code) using a tooltip button to reveal a content section beneath the input field when selected.
##### Collapsed
The user selects the “Show filters” button to reveal or hide the panel.
- Use text or context clues to indicate that the panel will expand to reveal additional actions.
- Use the plus (+) icon to indicate collapsed content will expand when selected.
##### Expanded
The user then makes their selection from the available options.
- Allow users to collapse the section by selecting the same action that expanded the section.
- Use the minus (-) to indicate expanded content will collapse when selected.
### Animation
Accordions may animate. Typically, they use a smooth, vertical sliding effect. When a user clicks on an accordion header, the associated content panel expands downward, revealing the hidden content. Conversely, when the header is clicked again, the content panel collapses upward, hiding the content.
- Ensure animations are brief, subtle, and unobtrusive.
- Implement animations consistently across accordions in your experience, either animating all or none.
## Platform considerations
### Mobile
#### Full-width accordions
Full-width accordions make it easier for users to select and expand sections on mobile devices and reduce the chance of missed selections. While there's no set limit to the number of accordions on a mobile interface, excessive use can create a cluttered and overwhelming experience.
- Use full-width accordions for screen sizes where users would benefit from extra touch space.
- Consider simplifying the interface or reevaluating the information architecture if many accordions are needed.
## Content
- Use simple language—avoid abbreviations or jargon.
- Use sentence case, except for proper nouns or acronyms.
- Use accordions to simplify the interface by hiding content, not to fit more onto the screen.
### Accordion titles
- Use short, concise content across headers or section labels. Aim for a range of five to ten words.
- Only use punctuation when labels are phrased as questions, such as “How do I edit my billing information?”
- Ensure labels accurately describe the content within the section to help users predict what they will find when expanded.
- Use parallel structure for all labels, using either questions, statements, or nouns. Learn more about parallel structure by visiting [Grammar and punctuation](https://design.visa.com/content/grammar).
### Panel content
- Use complete sentences and proper punctuation within each section or panel.
- Keep the content within each panel concise and to the point.
- Avoid unnecessary details or complex language.
- Provide users with the answers they need as quickly and efficiently as possible.
- If content within the accordion is becoming too lengthy, it may be a sign that the information should be presented in a different way, such as being broken down further, moved to a separate page, or even represented visually.
---
# accessibility
---
title: Anchor link menu
description: Link menus that navigate to sections within the current page.
meta_description: Find accessibility guidelines for link menus that navigate to sections within the current page.
thumbnail: assets/components/anchor-link-menu-graphic.svg
tab_order: 2
---
## Best practices
- Ensure all links have unique labels and destinations.
- Use `aria-current="true"` on the current link.
- Customize the list elements to fit your site's navigation and hierarchy. Provide an `aria-label` for the landmark to help users navigate to this section and see it listed in a page summary.
## Keyboard controls
Keyboard actions and their corresponding behaviors for anchor link menu
- Key: Navigates to the destination of the link in focus.
- Key: Navigates between links.
---
# index
---
title: Anchor link menu
tab_title: Code
thumbnail: assets/components/anchor-link-menu-graphic.svg
description: Link menus that navigate to sections within the current page.
meta_description: Get code for link menus that navigate to sections within the current page.
categories:
- navigation
- structure-and-layout
---
## Component Code Examples: anchor-link-menu
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the anchor-link-menu component
const component = parsed.components.find(c => c.name === 'anchor-link-menu');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `anchor-link-menu`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Anchor link menu
description: Link menus that navigate to sections within the current page.
meta_description: Learn how to use link menus that navigate to sections within the current page.
keywords: ["Jump menu", "skip navigation menu", "page jump menu", "in-page navigation menu", "table-of-contents links", "link", "links"]
related:
components:
- vertical-navigation
- link
- navigation-drawer
content:
- information-architecture
tab_order: 1
---
The anchor link menu is a set of links mapping to different sections of the same page. It provides a high-level view of the page’s structure and content, and enables users to navigate quickly without having to manually scroll.
Also known as: Jump menu, skip navigation menu, page jump menu, in-page navigation menu, table-of-contents links.
## Anatomy
**A. Section title (optional):** Label used to group or organize navigational links.
**B. Active link indicator (required):** Visual indicator showing the active menu item.
**C. Navigational link (required):** Label indicating the destination of the menu item on the page.
**D. Vertical rule (required):** Element separating the anchor link menu from page content.
## Usage
When to use and when not to use anchor link menu
- When to use: To jump to every sub-section on a page.
- When to use: For mobile experiences. Consider using a [Navigation drawer](https://design.visa.com/components/navigation-drawer) instead.
## Best practices
- Ensure the order of the menu items is consistent with the corresponding section headings throughout the application.
- Ensure text within the anchor link menu wraps to a second line instead of truncating to ensure it’s fully visible to users.
- Clearly indicate the active menu item to help users know which item corresponds to the displayed content section.
- Avoid exceeding two levels of hierarchy within menus.
- Follow [Link](https://design.visa.com/components/link) guidance when implementing anchor link menus.
### Section titles and nesting
Section titles refer to static text used to group navigation items under a common category. This text isn’t interactive and can be used with or without nested navigation items. Nesting refers to organizing navigational items according to their level of hierarchy on the page. Both methods group related content and help users navigate easily.
#### Section titles
Section titles group navigation items without nesting them. They’re helpful for providing context for the menu on a page.
- Use only one section title per menu.
#### Nesting
Nesting links group related items in a hierarchical order. They’re helpful for more content-heavy applications.
- Limit nesting to two level of hierarchy for simplicity.
## Behaviors
### Scrolling behavior
When a user clicks on a navigational link in the menu, the page will scroll to that content section. The active indicator then moves to the corresponding menu item. As the user scrolls down the page, the current location within the menu should be updated. The anchor link menu should always remain visible and in the same position.
## Content
- Write all content in sentence case, except for acronyms or proper nouns,
- Ensure menu items match section headings to enhance the user’s understanding of the site’s information hierarchy.
- Don’t use punctuation for links.
- Limit menu labels to a few brief words to prevent unnecessary reflow.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# accessibility
---
title: Avatar
description: Icons and/or text that represent users or entities.
meta_description: Find accessibility guidelines for visual or textual representations of users or entities within products.
thumbnail: assets/components/avatar-graphic.svg
tab_order: 2
---
## Best practices
- Ensure avatars always have accessible names for screen readers. As mentioned in the [usage guidelines](https://design.visa.com/components/avatar/usage) they must have accessible names such as `aria-label` or `alt` attributes. In the case of initials, the accessible name should be the full name.
- Add `role="img"` to all avatars that are not placed directly on an `img`.
- Reference examples of avatars used in [Dropdown menu](https://design.visa.com/components/dropdown-menu) and [Horizontal navigation](https://design.visa.com/components/horizontal-navigation) for more.
## Keyboard controls
Keyboard actions and their corresponding behaviors for avatar
- Key: Prompts buttons. If using `role="button"`, make sure these key commands work.
---
# index
---
title: Avatar
tab_title: Code
thumbnail: assets/components/avatar-graphic.svg
description: Icons and/or text that represent users or entities.
meta_description: Get code for visual or textual representations of users or entities within products.
---
## Component Code Examples: avatar
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the avatar component
const component = parsed.components.find(c => c.name === 'avatar');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `avatar`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Avatar
description: Icons and/or text that represent users or entities.
meta_description: Learn how to use visual or textual representations of users or entities within products.
keywords: ["User icon", "user avatar", "profile image", "profile avatar", "thumbnail", "UIImageView (iOS)", "ImageView (Android)"]
related:
components:
- vertical-navigation
- horizontal-navigation
tab_order: 1
---
Avatars are visual and/or textual representation elements of users and entities within a product. They help to personalize products and tailor experiences to the user and their preferences.
Also known as: User icon, user avatar, profile image, profile avatar, thumbnail, UIImageView (iOS), ImageView (Android).
## Anatomy
**A. Avatar element (required):** Icon, text, initials, or image representing the user or profile.
**B. Dropdown chevron (optional):** UI icon indicating the menu can expand or collapse.
## Usage
When to use and when not to use avatar
- When to use: As a visual representation of a user or entity in your application.
- When not to use: In situations where privacy is a concern, as displaying a user's avatar might not be appropriate.
- When to use: For a more personalized user experience. Can be used to indicate who is currently logged in, which is especially useful in multi-user environments.
- When not to use: If the avatar doesn't serve a clear function like leading to a user's profile or settings.
## Best practices
- Use avatars to identify users in the main part of the app navigation.
- Implement avatars to function as nav menus when used in navigation components.
- Apply proper alt text to any images such as the user’s name when icons, initials, or images are used.
- Enable users to change the avatar style of their experience.
- Reference [Fictitious brand and user aliases (internal only)](https://bookmarks.visa.com/vpds-fictitious-brands) guidelines for placeholder names.
- Follow all guidance for implementing [badges](https://design.visa.com/components/badge/usage) on avatars.
### Avatar styles
There are four styles of avatars that can be used within an experience. Consider selecting a default avatar style for your application and enabling users to customize this style at a later time.
#### Icon
The icon avatar is a generic representation of a user using an icon.
#### Text
The text avatar displays the user's name in an adjustable text format.
#### Initials
The initials avatar shows the user's initials in one or two characters.
#### Image
The image avatar uses a customizable profile image to represent the user.
## Behaviors
### Avatar used in navigation
When an avatar is used in navigation components, it’s treated the same as navigation links that activate a nav menu. In the pressed state, the background color of the avatar will change to match the background color of the nav menu. To learn more, reference [Horizontal navigation](https://design.visa.com/components/horizontal-navigation) guidance.
### Profile representation
Representing a user profile, account, issuer, or brand can use the same basis without the menu button.
- Use standard icon sizes of 24x24 or 48x48. Whichever size you choose, be consistent throughout the application.
## Content
- Always use title case for names including companies or entities.
- Don’t use punctuation.
- Follow all best practices and guidelines implementing links. Reference [Link](https://design.visa.com/components/link) for more information.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing in navigation.
---
# accessibility
---
title: Badge
description: Visual indicators that communicate the status of a component.
meta_description: Find accessibility guidelines for visual indicators that communicate the status of a component.
thumbnail: assets/components/badge-graphic.svg
tab_order: 2
---
## Best practices
### Label badges
- Avoid using label badges alone to convey information.
- Always place icon badges near their associated labels to convey information through visible text.
- Avoid labeling icons individually or giving them screen reader focus, as this creates redundancy. Screen reader focus should wrap the icon and the label, reading the label information, e.g., "! Out of stock".
### Icon badges
- Use an `aria-label` to communicate an accessible name.
---
# index
---
title: Badge
tab_title: Code
thumbnail: assets/components/badge-graphic.svg
description: Visual indicators that communicate the status of a component.
meta_description: Get code for visual indicators that communicate the status of a component.
categories:
- feedback-and-status
---
## Component Code Examples: badge
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the badge component
const component = parsed.components.find(c => c.name === 'badge');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `badge`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Badge
tab_title: Usage
description: Visual indicators that communicate the status of a component.
meta_description: Learn how to use visual indicators that communicate the status of a component.
tab_order: 1
keywords: ["Info tag"]
related:
patterns:
- feedback-and-status
---
Badges provide brief information, statuses, or counts related to an item or element. They can be used to draw attention to new or important information, such as notifications, messages, or updates.
Also known as: Info tag.
## Anatomy
**A. Icon (optional):** Leading icon used to represent badges that can be used with or without a label.
**B. Label (optional):** Brief text providing information about a specific item or element.
**C. Background color (required):** Visual indicator to help convey the badge status.
## Usage
When to use and when not to use different types of badges
- Component: If text is needed to describe the status.
- When to use: If the text is too long or complex.
- Component: To indicate counts of the element it’s tied to, like notifications.
- When to use: If the count doesn’t provide meaningful information to the user.
## Best practices
- Ensure badges are static and not interactive.
- Ensure badges are easily noticeable but don’t obscure their associated element or other important information.
- Avoid using badges if they add complexity, ambiguity, or visual noise.
- Ensure the label text, icons, and background color collectively convey the badge information accurately.
### Label badges
Label badges use text to convey information. Ensure the label and background color match to accurately convey the badge information. For example, only use the yellow background color to convey warning information.
#### Label and icon badge
Use icons to indicate status or condition of an element, especially for common meanings.
#### Label badge with ellipse
Use the ellipse indicator when more visual emphasis is needed and intuitive icons aren’t available.
### Number badges
Number badges are small, circular badges that only convey a count or number. They're commonly used to indicate notifications. They can be paired with UI icons such as the notification bell or with other components such as [tab bars](https://design.visa.com/components/tab-bar). They’re tied to the element that it represents the count for.
### Placement
Badges are typically placed alongside the element they are supporting or calling attention to.
#### Section notifications
Section notifications group related messages to help organize large numbers of notifications. A number badge can be attached to different sections to show unread items. When a user navigates to a section, the notifications appear, and the badge disappears. Not all sections may need notifications, so consider whether a global notification system might work better for your application.
## Platform considerations
### Mobile
In mobile designs, badges can appear as an individual ellipse when the number badge is too large compared to the component or icon. In this scenario, the badge indicates that one or more notifications are available, but doesn't indicate how many or provide specific status updates.
## Content
- Use simple language—avoid abbreviations or jargon.
- Write all content in sentence case, except for acronyms or proper nouns.
- Don’t use punctuation for badge labels.
- Limit labels to a few short words.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# accessibility
---
title: Banner
description: Messages that indicate the global status of an application or website.
meta_description: Find accessibility guidelines for messages that indicate the global status of an application or website.
thumbnail: assets/components/banner-graphic.svg
tab_order: 2
---
## Best practices
- Don’t move focus to the banner when it opens to avoid interrupting the user’s work flow.
- Position the banner at or near the top of the page content in the DOM.
- Ensure banners remain visible even when the page is scrolled below the fold.
- Ensure banners never cover the rest of the page, even with high zoom levels and small screen sizes.
- Use roles and attributes to announce the banner content to the user.
### Screen reader
`role="alert"` is used to communicate an important and usually time-sensitive message to the user.
- Use `role="alert"` for error messages and system messages. This is equivalent to `aria-live="assertive"` paired with `aria-atomic="true"`.
`role="status"` is used to communicate information that isn’t important enough to be an alert.
- Use `role="status"` for informational or success messages. This is equivalent to `aria-live="polite"` paired with `aria-atomic="true"`.
## Keyboard controls
Banners are comprised of other elements that use standard keyboard actions.
**Note:** Activating the Escape key does not close the banner, as that might disrupt what the user is doing by closing something else.
Keyboard actions and their corresponding behaviors for banner
- Key: Moves focus to the next focusable element.
- Key: Prompts the action associated with the focused interactive element.
- Key: Moves keyboard focus backwards to the previous interactive element in the banner.
---
# index
---
title: Banner
tab_title: Code
thumbnail: assets/components/banner-graphic.svg
description: Messages that indicate the global status of an application or website.
meta_description: Get code for messages that indicate the global status of an application or website.
categories:
- feedback-and-status
---
## Component Code Examples: banner
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the banner component
const component = parsed.components.find(c => c.name === 'banner');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `banner`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Banner
tab_title: Usage
tab_order: 1
description: Messages that indicate the global status of an application or website.
meta_description: Learn how to use messages that indicate the global status of an application or website.
keywords: ["Status alert", "global status message", "informational notice", "site notice"]
related:
components:
- section-message
- flag
patterns:
- feedback-and-status
content:
- messaging
---
Banners provide global or system-level messages on the status of an application or site. They provide updates from low to critical priority and often include a follow-up action for the user.
Also known as: Status alert, global status message, informational notice, site notice.
## Anatomy
**A. Icon (required):** Visual indicator communicating the urgency of the banner. **B. Title (optional):** Brief text summarizing the purpose of the banner. **C. Message (required):** Descriptive message detailing important contextual information. **D. Close icon button (optional):** Optional action allowing users to dismiss a banner without completing a call to action. **E. Button and link (optional):** Text button or link that prompts an action or directs users to relevant resources.
## Usage
When to use different types of banners
- Component: For system-level feedback or status messages that require the user’s attention without disrupting their workflow or requiring immediate action.
- When to use: For informational messages that are of high enough priority to disrupt the user's workflow, even though they may not require immediate action. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For low-priority status updates contextually relevant to the user’s current workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
For low-priority messages that don't require user action or attention. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
- Component: Success banners are not a common use case as they require more attention than needed for low-priority messages.
- When to use: For system- or section-level success, messages including on-page event confirmations. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
If the user is taken to a success page on submit. Don’t a messaging component in this case.
- Component: For medium-priority warning messages that require the user's attention and may or may not require action immediately or in the near future.
- When to use: For medium-priority messages that are of high enough priority to disrupt the user's workflow. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For warnings contextually relevant to a section of a page or workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
For low-priority warnings that don’t require user action or attention. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
- Component: For high-priority, system-level messages alerting that errors or issues have occurred that require immediate action or attention.
- When to use: For high-priority alerts communicating that critical errors have occurred and must be fixed before continuing. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For high-priority errors contextually relevant to a section of a page or workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
## Best practices
- Visit [Button](https://design.visa.com/components/button/usage) to learn about best practices for alignment, order, and language for calls to action.
- Visit [Feedback and status](https://design.visa.com/patterns/feedback-and-status) to learn how to use messaging components, understand their level of disruption, and choose the appropriate messaging component for your context.
## Behaviors
### Dismissal
In general, users should be allowed to dismiss banners using a close icon button or text button. Banners should also dismiss when users complete an associated action, such as correcting an error. Avoid using timed auto-dismissal for banners, as they may disappear before screen readers finish announcing the text.
### Display methods
There are two primary methods for displaying banners: Scrolling with page content (recommended) or floating over page content. Floating banners are more disruptive and should only be used for high-priority messages.
#### Scrolls with page (recommended)
Banners that scroll with page content are fixed below the navigation bar and remain there as users scroll. This is the least disruptive way to implement banners.
- Place these banners within page content below the navigation bar.
- Use these banners for low and medium-priority messages without disrupting the flow of content.
#### Floats above page content
Floating banners float over page content. They remain in view when users scroll but may obstruct important interactive controls.
- Reserve floating banners for high-priority messages that require immediate attention.
- Always float banners on mobile screens for accessibility reasons. Visit [Platform considerations](https://design.visa.com/components/banner/usage/#platform-considerations) for more info.
### Animation
Banners may use animated graphics. When animated, banners appear by sliding downwards from the top of the page and reverse when dismissed.
- Ensure animations are brief, subtle, and unobtrusive.
- Use animations consistently for all banners in your experience.
## Content
- Learn how to craft content for messaging components, like banners, visit [Messaging](https://design.visa.com/content/messaging).
- Follow guidelines for [Link](https://design.visa.com/components/link/usage) and [Button](https://design.visa.com/components/button/usage) components when labeling actions and destinations within banners.
## Platform considerations
### Mobile
Banners are available in both web and mobile and should be implemented similarly across platforms.
- Always float banners on mobile screens. This ensures they remain visible if users zoom or navigate non-linearly.
---
# accessibility
---
title: Breadcrumbs
description: Supplemental navigation that indicates the user’s location in a site or app.
meta_description: Find accessibility guidelines for supplemental navigation that indicates a user’s location in a site or app.
thumbnail: assets/components/breadcrumbs-graphic.svg
tab_order: 2
---
## Best practices
- Contain all breadcrumb links in an ordered list ( `ol`) as list items, because their ordering indicates positioning in the breadcrumb.
- Ensure the containing element for the breadcrumbs is a `nav` element and give it an `aria-label` to differentiate it from other navigation regions.
- Use `aria-current="page"` to identify the current breadcrumb page. It is implemented as a span.
- Check that the separator icons use the library’s right-to-left class if needed.
## Keyboard controls
Keyboard actions and their corresponding behaviors for breadcrumbs
- Key: Activates the focused breadcrumb link to navigate to the corresponding page.
- Key: Moves focus to the breadcrumb links sequentially.
- Key: Move focus backward through the breadcrumb links.
---
# index
---
title: Breadcrumbs
tab_title: Code
thumbnail: assets/components/breadcrumbs-graphic.svg
description: Supplemental navigation that indicates the user’s location in a site or app.
meta_description: Get code for supplemental navigation that indicates a user’s location in a site or app.
---
## Component Code Examples: breadcrumbs
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the breadcrumbs component
const component = parsed.components.find(c => c.name === 'breadcrumbs');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `breadcrumbs`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Breadcrumbs
description: Supplemental navigation that indicates the user's location in a site or app.
meta_description: Learn how to use supplemental navigation that indicates a user's location in a site or app.
keywords: ["Breadcrumb trail", "cookie crumb trail"]
related:
components:
- link
tab_order: 1
---
Breadcrumbs are a supplemental navigation element that help users with wayfinding. They indicate the user's current location within a website or app and streamline navigation across multiple layers of pages, folders, or files.
Also known as: Breadcrumb trail, cookie crumb trail.
## Anatomy
**A. Link (required):** Standalone link component with an underline. **B. Separator (required):** Character appearing between each link, either a forward slash: (‘/’) or svg: (‘>’). **C. Current page (required):** Non-interactive text representing the user’s current location.
## Usage
When to use and when not to use breadcrumbs
- When to use: To help users understand their current location within the information hierarchy of an app or site.
- When not to use: For linear web pages without multiple levels of page hierarchy.
- When to use: As a secondary form of navigation.
- When not to use: In place of a site’s main navigation.
## Best practices
- Use breadcrumbs consistently across your site. If you use them on one page, use them on all pages where they're relevant.
- Always include the user's current page as the last item. The current page isn’t a link and should appear different from the other breadcrumb items, which are active links.
### Breadcrumb trails
There are generally three strategies for generating breadcrumb trails: location-based, path-based, and attribute-based breadcrumbs. These include location-based, path-based, and attribute-based breadcrumbs.
Following [design recommendations](https://www.nngroup.com/articles/breadcrumbs/) from the Nielsen Norman Group, we suggest primarily using the location-based strategy. However, there may be exceptions where path- and attribute-based breadcrumbs fit your use case.
#### Location-based breadcrumb trails (recommended)
Location-based breadcrumbs show the user’s location within a site’s hierarchy. They are the suggested form of breadcrumbs because they provide a clear route that is not repetitive or lengthy, which can happen with other types of breadcrumbs.
- Always start with the home page or base level of hierarchy. This provides a clear starting point and helps users understand the overall hierarchical structure.
#### Path-based breadcrumbs (alternative strategy)
Path-based trails show the pages a user visited to get to their current page. This strategy shows the specific path a user took but might not reflect site hierarchy.
- Include every page a user has visited to ensure the path is accurate and consistent.
#### Attribute-based breadcrumbs (alternative strategy)
Attribute-based trails show the attributes or characteristics of the items on a page. This works best when page contents can be categorized in multiple ways, not just within a single hierarchical structure, such as an e-commerce site.
- Identify both the attribute type and specific attribute in the breadcrumb trail.
## Content
- Write all content in sentence case, except for acronyms or proper nouns.
- Don’t use punctuation, except for colons in attribute-based trails.
- Ensure labels match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Follow all best practices and guidelines implementing links. Reference [Link](https://design.visa.com/components/link/usage) for more information.
## Platform considerations
### Mobile
Breadcrumbs are not common in native mobile apps. Instead, consider using a back-facing arrow UI button to let users navigate back one level in site hierarchy.
- Reference [Link](https://design.visa.com/components/link/usage) for more information on “Back to” links.
### Web
Breadcrumbs are commonly used on websites with many pages that are organized hierarchically.
- Place breadcrumbs at the top of a page between the navigation bar and page title.
- Don’t use breadcrumbs on sites where every page is accessible from a global navigation bar.
---
# accessibility
---
title: Button
tab_order: 2
description: Interactive elements that help users take actions within an interface.
meta_description: Find accessibility guidelines for interactive elements that help users take actions within an interface.
thumbnail: assets/components/button-graphic.svg
---
## Best practices
- Ensure icon-only buttons have an `aria-label` for screen readers.
- Don’t put block level elements such as divs inside buttons. Only use spans, images, svgs, and text inside buttons.
- Ensure all buttons meet touch target requirements, especially on mobile devices.
- Use attributes `type="submit"` or `type="reset"` when appropriate for buttons used inside forms.
## Keyboard controls
Keyboard actions and their corresponding behaviors for buttons
- Key: Prompts the action associated with the <button>. If you’re using `role="button"`, make sure these key commands work.
---
# index
---
title: Button
tab_title: Code
description: Interactive elements that help users take actions within an interface.
meta_description: Get code for interactive elements that help users take actions within an interface.
thumbnail: assets/components/button-graphic.svg
categories:
- actions
---
## Component Code Examples: button
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the button component
const component = parsed.components.find(c => c.name === 'button');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `button`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Button
tab_title: Usage
tab_order: 1
description: Interactive elements that help users take actions within an interface.
meta_description: Learn how to use interactive elements that help users take actions within an interface.
keywords: ["Push button", "actions drop-down", "action menu", "UI button (Native iOS)", "button (Android)", "elevated button (Flutter)"]
related:
components:
- link
patterns:
- forms
---
{/* INTRO */}
Buttons are selectable elements that allow users to take action. They typically communicate a call to action (CTA) using text, icons, or both. Buttons are utilized across a range of interfaces including dialogs, forms, and content cards.
Also known as: Push button, actions drop-down, action menu, UI button (Native iOS), button (Android), elevated button (Flutter).
{/* ANATOMY */}
## Anatomy
**A. Leading icon (optional):** Icon located before the button text used to enhance the meaning of the text.
**B. Label (required):** Text communicating what action will be performed when the user interacts with it.
**C. Trailing icon (optional):** Icon located after the button text used to enhance the meaning of the text.
{/* USAGE */}
## Usage
When to use different types of buttons
- Component: To emphasize the most important or common call to action.
- When to use: For actions of equal importance to others or another primary button.
- Component: For calls to action that are less important or the opposite of the primary.
- When to use: For the principle or most important action or without a primary button.
- Component: For the least important call to action.
For sub actions when the primary and secondary are present.
- When to use: For actions of high use or importance.
For destructive actions that might be accidentally selected.
- Component: To emphasize that an action could have a destructive or irreversible effect, such as deleting data.
- When to use: For non-destructive actions.
- Component: For displaying actions in a compact area.
To implement buttons with more visual appeal.
- When to use: When the meaning of an icon is unclear.
When icon buttons aren’t consistently used within the UI.
- Component: Within components and when the action is universally recognized.
- When to use: When the meaning of an icon is unclear.
{/* BEST PRACTICES */}
## Best practices
- Only use buttons for actions, not navigational elements. Use a [Link](https://design.visa.com/components/link) to take users to a new destination.
- Use consistent design, placement, and behavior for buttons throughout interfaces. This helps users predict interactions.
- Avoid using more than five text buttons per interface. Consider using a [Dropdown menu](https://design.visa.com/components/dropdown-menu) to group more than five actions.
- Group buttons into logically based on the relationship or tasks users are trying to accomplish with your interface.
{/* DO + DON'T */}
{/* PRIMARY BUTTONS */}
### Primary buttons
Primary buttons are high emphasis and use fill to draw attention. They can be used independently or in groups where one call to action needs to stand out more than others.
- Use them sparingly to draw attention to the most important action on a screen.
- Place primary buttons in expected locations, ensuing they are easy to find and follow the natural flow of the page.
{/* DO + DON'T */}
{/* SECONDARY BUTTONS */}
### Secondary buttons
Secondary buttons are medium emphasis and use an outline with no fill. They’re commonly paired with primary buttons to perform the opposite or negative action compared to primary buttons, for example “Next” and “Back”, or “Submit” and “Cancel”. However, they can also be used independently or in groups.
- Use secondary buttons for common actions when high emphasis isn't needed.
{/* - DO + DON'T */}
{/* TERTIARY BUTTONS */}
### Tertiary buttons
Tertiary buttons are the least prominent compared to primary and secondary buttons. They can be used independently or in groups with primary and secondary buttons for less important actions.
- Use tertiary buttons for less important, less frequently used actions. Overuse can dilute their meaning and confuse users.
- Ensure tertiary buttons are easy to locate and not so subtle that they’re easy to overlook or hard to interact with.
{/* DO + DON'T */}
{/* DESTRUCTIVE BUTTONS */}
### Destructive buttons
Destructive buttons should be used sparingly. They have three styles: primary, secondary, and tertiary.
- Alert users with a warning dialog before a destructive action happens, especially if resulting in data loss.
- Prevent data loss by placing destructive buttons where they're less likely to be selected by mistake.
- Allow users to undo destructive actions when possible to give users more control over their actions.
{/* DO + DON'T */}
{/* ICON BUTTONS */}
### Icon buttons
Icon buttons are circular, enclosed icons that represent an action. They include an optional label and are available in a medium and large size. Unlike text buttons, icon buttons offer visual appeal and stack vertically in limited horizontal space.
- Use icon buttons thoughtfully, don’t add visual appeal for the sake of visual appeal.
- Size icons consistently and use or exclude icon button labels across experiences.
{/* - DO + DON'T */}
{/* UI ICON BUTTONS */}
### UI icon buttons
UI icons buttons are visual representations of an action that don’t require labels. They exist within other components or on their own.
- Ensure icons clearly and intuitively indicate the action they represent.
- Make sure UI icons are large enough to be usable, especially on touch devices.
{/* - DO + DON'T */}
{/* Order */}
### Order
Order refers to the sequence of buttons and which action comes first in a group. Buttons should be ordered logically based on user expectations. This frequently aligns with reading order, meaning primary buttons appear on the left for left-to-right languages. However, common exceptions exist. For example, navigational buttons in a form or wizard where “Next” would be placed in the right position to indicate forward progress.
- Be consistent across your interface. If the primary action is usually on the left, avoid switching it for specific instances.
- Group related actions, for example, "Cut", "Copy", and "Paste" are often grouped together in text editing interfaces.
{/* DO + DON'T */}
{/* Alignment */}
### Alignment
Alignment refers to the position of buttons or button groups along a common edge within a container. In left-to-right languages, users typically scan content left-to-right, then top-to-bottom. Buttons should follow this pattern and align with the content within the container to match these expectations.
Buttons within components are typically left-aligned except in wizards, touring tips, or components with full-width buttons.
- Left-align buttons by default for left-to-right languages so it’s easier for users to scan content along a common edge.
- Right-align navigational buttons to reinforce that there will be forward progress.
{/* Size */}
### Size
Text and icon buttons are available in medium and large sizes. UI icon buttons are available in small, medium, and large sizes.
#### Medium buttons
Medium buttons are the default button size for most use cases, such as forms and dialogs.
- Use medium buttons to allow space for interfaces with multiple interactive elements.
#### Large buttons
Large buttons are more expressive and may balance large headings commonly found across landing or web pages.
- Use large buttons when space is available and there are few other interactive elements present.
{/* BEHAVIORS */}
## Behaviors
### Styling and coding buttons and links
In general, buttons should be used for in-page actions and links should be used as navigational tools, like leaving a page. Whenever possible, match the visual styling of these elements with their coded and user-expected behavior. However, buttons and links may be styled like one another in some cases. Learn about these exceptions below.
#### Button coded as links
Buttons may be coded as links but styled as buttons when necessary. For example, an icon button may be appropriate when linking to a shopping cart.
- Use the arrow icon whenever possible as a visual cue that selecting will navigate to another page.
#### Link coded as buttons
Links may be coded as buttons but styled as links when necessary. For example, buttons may be styled as links when information will be presented in an overlay or dialog.
- Avoid underlining links coded as buttons, as this style is reserved for links, not buttons.
{/* CONTENT */}
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use clear, actionable, language that is easy to understand without additional context or information.
- Avoid abelist verbs that focus on senses. For example, use “Play video,” instead of “Watch video” or “Explore results” instead of “See results”.
### Button formulas
- Combine action or command verbs with nouns to make buttons specific.
- \{verb\} + \{noun\} is useful for most product cases.
- \{verb\} + \{adverb\} is typically used for marketing and promotions.
- Only use single word labels for common navigational actions such as, “Next,” “Continue,” “Back,” “Close,” “Cancel,” “OK,” “Accept,” “Done,” or “Finish.”
{/* DO + DON'T x 4 */}
{/* PLATFORM CONSIDERATIONS */}
## Platform considerations
### Mobile
#### Full-width buttons
Full-width buttons make it easier for users to select options on mobile devices and reduce the chance of missed selections.
- Use full-width buttons within containers when users would benefit from extra touch space.
- Avoid using more than two full-width buttons per container to help prevent accidental selections.
#### Stacked buttons
Stacked buttons adds visual balance and provide a larger touch area on small screens.
- Arrange buttons in a vertical stack at the bottom of the screen to use the available space more effectively.
- Avoid stacking too many buttons to prevent overwhelming the user. Limit the options to the most important actions.
- Help users prioritize actions by placing the most important or expected button at the top.
#### Icon buttons as navigation
Icon buttons can be used in mobile interfaces to provide compact navigation.
- Only use icons as navigation when the icon is commonly understood.
- Use text in addition to the icon if an icon can be interpreted in multiple ways.
- Maintain consistent styles for icons. This includes the design as well as placement and behavior.
---
# accessibility
---
title: Checkbox
description: Interactive element that lets users select one or more independent choices.
meta_description: Find accessibility guidelines for interactive elements that let users select one or more independent choices.
thumbnail: assets/components/checkbox-graphic.svg
tab_order: 2
---
## Best practices
- Don’t use the aria-checked attribute for indeterminate checkboxes. Instead, set its indeterminate property to true or false using JavaScript. Reference [the coded examples.](https://design.visa.com/components/checkbox)
- `fieldset` and `legend` indicate a set of checkbox elements grouped together.
- Always use the `legend` element to indicate a set of checkbox elements are grouped together. It can be visually hidden if necessary using the library’s screen reader class.
- Use an HTML list for the checkboxes to ensure screen readers will announce how many checkboxes are in the group.
- Ensure additional instructions or error messaging are associated with the checkbox group so screen readers will read them. Reference Angular or React for examples.
- Always use the `required` attribute for legal acknowledgments.
- Ensure each checkbox input has an `id` associating it with its label. Be sure to associate additional text and error messages to its relevant checkbox input or fieldset. Reference the code for more.
- Ensure all checkboxes used in tables have accessible names for screen readers that communicate which row or column they’re associated with. For example, “Select ProjectA”.
## Keyboard controls
Keyboard actions and their corresponding behaviors for checkboxes
- Key: Moves keyboard focus to the next checkbox in a group or next interactive element.
- Key: Selects/unselects the checkbox when the component is in focus.
When the parent checkbox shows the unselected state, all nested checkboxes are unselected.
When the parent checkbox shows the indeterminate state, selecting the parent checkbox selects all nested options.
When the parent checkbox shows the selected state, all nested checkboxes are selected.
---
# index
---
title: Checkbox
tab_title: Code
description: Interactive element that lets users select one or more independent choices.
meta_description: Get code for interactive elements that let users select one or more independent choices.
thumbnail: assets/components/checkbox-graphic.svg
categories:
- selection-controls
---
## Component Code Examples: checkbox
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the checkbox component
const component = parsed.components.find(c => c.name === 'checkbox');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `checkbox`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Checkbox
description: Interactive element that lets users select one or more independent choices.
meta_description: Learn how to use interactive elements that let users select one or more independent choices.
keywords: ["Check box", "tick box", "checkBox (Android)"]
related:
components:
- dropdown-menu
- radio
- multiselect
patterns:
- forms
tab_order: 1
---
Checkboxes enable users to select one or more options from a short list. They are commonly used in forms, filter menus, or any scenario where users may want to select multiple options from a short list.
Also known as: Check box, tick box, checkBox (Android).
## Anatomy
**A. Checkbox (required):** Interactive element enabling users to select an option.
**B. Option label (required):** Brief text describing the checkbox option.
**C. Description (optional):** Brief message detailing important information about the option.
**D. Checkbox group (optional):** Two or more related checkboxes presented in a group.
**E. Group label (required):** Brief description of options available for selection.
## Usage
When to use and when not to use different types of checkboxes
- Component: To present a binary choice where the user can select or deselect a single option.
- When to use: To present multiple options the user can choose between. Use a checkbox group instead.
- Component: To present a short list of options where the user can select one or multiple.
- When to use: If users must select one option from a short list. Use a [Radio button group](https://design.visa.com/components/radio) instead.
For long lists where all options can't be viewed at once or require scrolling. Use a [Multi-select listbox](https://design.visa.com/components/listbox) instead.
For long lists where users would benefit from entering text to filter or search the list options. Use [Multiselect](https://design.visa.com/components/multiselect) instead.
To present a list of actions. Use a [Dropdown menu](https://design.visa.com/components/dropdown-menu) instead.
- Component: To present a binary choice where the user can select or deselect a single option.
To provide an increased touch area.
- When to use: To present multiple checkbox panels in a list. Use a checkbox panel group instead.
When space is limited.
- Component: To present a short list options where the user can select one or multiple.
To provide an increased touch area.
- When to use: If users can only select one option from a list. Use a [Radio panel group](https://design.visa.com/components/radio) instead.
When space in limited.
## Best practices
- Ensure checkboxes appear visually different when selected and unselected by using the fill color and “check” icon.
- Ensure users can select anywhere within the checkbox or associated option label to choose an option.
- List options in a logical order, either alphabetically or according to the most common or likely selection.
- Avoid using a horizontal layout for checkbox groups and panel groups, as vertical layouts are easier to scan and more adaptable for small screens.
- Always indicate that more than one option can be selected using phrasing like “Select one or more options”.
### Standalone checkboxes
Standalone checkboxes refer to checkboxes used alone to present a single, independent option that doesn’t relate to any others. They’re typically used to enable settings, agree to terms and conditions, or present a binary choice, where selecting the checkbox indicates agreement and not selecting indicates disagreement.
- Use the default checkbox component to present a standalone option.
- Frame options so that selecting the checkbox indicates agreement and not selecting the checkbox indicates disagreement.
### Checkbox panels
Checkbox panels are an alternative to default checkboxes. They’re available as standalone elements or in groups and can be used to draw attention to the checkbox or provide an increased touch area on small screens.
- Ensure users can select anywhere within the checkbox, label, or panel to choose an option.
### Checkbox groups
Checkbox groups and panel groups are sets of default checkboxes or checkbox panels placed under a single group label. They’re commonly used to present a short list of related options available for selection.
- Use a checkbox group or panel group for short lists where all options can be viewed without scrolling.
### Label size for panel groups
Group labels for panel groups are available in two sizes. Use whichever is appropriate depending on your use case and the overall hierarchy of your experience.
#### Default
The default option is the UI label font size and matches the text in option descriptions.
- Use the default size to reduce visual weight for users when multiple checkbox panel groups are used together.
#### Large
The large UI label size is an alternative option that can be used to draw attention to the checkbox panel group label.
- Use the large size to draw attention to a standalone checkbox panel group.
### Hidden labels
Checkbox groups and panel groups should always include a group label. However, there are some cases where hiding the group label can provide design flexibility or space for additional context. If the group label within the component build is hidden, include an alternate label elsewhere on the screen as well as within the code for accessibility.
### Nested options
In some cases it may be appropriate to format checkbox groups with nested options. Users can select all nested options by selecting the parent or top-level checkbox, or unselect all nested options to by unselecting the parent checkbox. Alternatively, users can select nested options individually when the parent option is not selected. When the parent checkbox shows the indeterminate state, selecting it causes all nested options to be selected.
- Ensure all nested options are related to the parent option.
- Use the unselected state for the parent option when all nested options are unselected.
- Use the selected state for the parent option when all nested options are selected.
- Include a chevron UI icon button to enable users to expand and collapse the nested options.
**Note:** The indeterminate state is not fully accessible for screen readers. To learn about alternative methods for nested checkbox groups, visit [Accessibility](https://design.visa.com/components/checkbox/accessibility).
#### Collapsed
The user selects the chevron UI icon button to reveal the nested options.
- Use the right pointing chevron to indicate collapsed content.
#### Expanded
The user makes their selection from the available nested options.
- Use the downward pointing chevron to indicate expanded content.
### Default selections
In general, checkboxes should be unselected by default to give users full control over their choices. The main exception is when a choice is required and the selection indicates a default or system setting.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Visit [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Descriptions
- Use full sentences with proper punctuation.
- Limit descriptions to 80 characters or 20 words including spaces.
### Labels
- Don’t include punctuation.
- Ensure group labels accurately summarize the options available for selection.
- Limit labels to three words or fewer unless referencing proper nouns, such as product names.
- Use [Parallel structure](https://design.visa.com/content/grammar/#parallel-structure) for labels across your experience, either starting with verbs such as “Select a notification preference” or nouns such as “Notification preferences”.
## Platform considerations
### Mobile
Checkboxes are available in mobile and web and should be implemented similarly on both platforms.
- Use checkbox panels to provide a larger touch area when necessary.
- Use default checkboxes to save space and prevent user overload, especially when there are many checkbox groups used together in a form.
---
# accessibility
---
title: Chips
tab_order: 2
description: Compact elements used to filter content or display user input.
meta_description: Find accessibility guidelines for compact elements that filter content or display user input.
thumbnail: assets/components/chip-graphic.svg
---
## Best practices
- Ensure all chips have an ID, which is used in the `for` attribute of the label, as selection chips are really checkboxes wrapped in labels.
- Always use an `aria-label` for removable chips, which are really buttons. Use a label such as "clear <label text>" to ensure screen reader users can predict the button’s behavior.
- Use a `fieldset` and `legend` to ensure chip groups are within HTML lists so screen readers can indicate how many options are in the group.
{/* CURSOR AND KEYBOARD */}
## Keyboard controls
Chips have the standard behavior for checkboxes (selection chips) or buttons (removable chips).
### Navigation
Keyboard actions and their corresponding behaviors for navigation chips
- Key: Moves to next chip.
- Key: Moves to previous chip.
### Selection chips
Keyboard actions and their corresponding behaviors for selection chips
- Key: Toggles beween on and off state.
---
# index
---
title: Chips
tab_title: Code
description: Compact elements used to filter content or display user input.
meta_description: Get code for compact elements that filter content or display user input.
thumbnail: assets/components/chip-graphic.svg
categories:
- selection-controls
---
## Component Code Examples: chip
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the chip component
const component = parsed.components.find(c => c.name === 'chip');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `chip`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Chips
description: Compact elements used to filter content or display user input.
meta_description: Learn how to use compact elements to filter content or display user input.
keywords: ["Pills", "tags", "lozenges", "selectable tag", "dismissible tag"]
related:
components:
- checkbox
- toggle-button
tab_order: 1
---
Chips are compact, interactive elements that represent an input or option. They often appear in groups helping users filter content, enter data, or complete tasks efficiently.
Also known as: Pills, tags, lozenges, selectable tag, dismissible tag.
## Anatomy
**A. Label (required):** Brief text describing the chip. **B. Avatar (optional):** Thumbnail image or logo representing users or entities. **C. Leading icon (optional):** Icon used to represent the chip. **D. Clear button (required):** Button used to deselect removable chips.
## Usage
When to use and when not to use different types of chips
- Component: To enable users to filter content by selecting from a set of pre-determined chips.
If there’s sufficient space to display all the available selection chips at once.
- When to use: If there is only one option. Consider using a [Default checkbox](https://design.visa.com/components/checkbox/usage) instead.
- Component: To provide a visual representation of options selected from a checkbox group or multiselect component.
For more complex filtering scenarios where only the selected options should be displayed in chips.
- When to use: If the list of options is brief or simple and it would be easier to select and deselct chips directly.
## Best practices
- Maintain consistent spacing and margins between chips to enhance readability and visual consistency. Reference [Scaling and reflow](https://design.visa.com/components/chips/usage/#scaling-and-reflow) for more guidance.
- Organize chips into logical groups to help users understand relationships between options or categories.
### Selection chips
Selection chips enable users to make choices by manually selecting a chip from a set or group. They can be used to filter content or indicate selected items. Selection chips are similar to checkboxes or toggle components, where clicking the chip selects it, and clicking it again deselects it.
- Clearly indicate when a chip is selected using color, a checkmark, or another visual indicator.
- Display all selection chips at once, including those that have been deselected.
### Removable chips
Removable chips represent selections by appearing once the user has selected an item from a checkbox group, multiselect component, or set of filters. They show brief information about each selection and provide an easy way for users to remove individual items. These chips provide a visual representation of items the user has selected, but aren’t selectable themselves.
- Always provide a clear button to remove chips.
- Always hide chip options after removal.
- Consider asking for confirmation before removal if the chip removal has significant impact.
#### Removable chip size
Removable chips come in two sizes depending on their location, standard and compact. For both sizes, selecting the clear button will remove the chip.
##### Standard
Standard-sized chips appear outside of components and display options or filters that have been applied by the user.
- Arrange chips in a logical order, such as by order of selection or alphabetically.
##### Compact
Compact chips appear inside components like input fields or comboboxes after user selection or input.
- Keep chip labels concise to maintain readability and prevent truncation.
## Behaviors
Chips have various behaviors designed to enhance user interaction and functionality. This section provides guidance on the the expected behaviors of the chip variants, selection and removable chips.
### Selection chips
Selection chips toggle between selected and deselected stated when clicked by the user.
### Removable chips
Removable chips allow the user to perform one action on the chip, usually removing the settings from the list.
### Scaling and reflow
Scaling and reflow refers to how content behaves as the container size changes, particularly when the container is too small to display all content at once. This describes the behavior of chips as their number increases and they wrap in a container and how individual chips behave when their content is too long.
- Display chip labels fully when possible.
- Maintain consistent spacing between chips during reflow.
- Keep chip labels concise to maintain readability and prevent truncation.
## Content
- Use clear, concise text to label chips.
- Use sentence case, except for proper nouns or acronyms.
- Use simple language - avoid abbreviations or jargon.
- Don’t include punctuation in chip labels.
- Limit chip labels to a 20-character maximum.
---
# accessibility
---
title: Color selector
tab_order: 2
description: Menu that allows users to select a specific color through a variety of ways.
meta_description: Find accessibility guidelines for menus that enable users to select a color using a variety of methods.
thumbnail: assets/components/color-selector-graphic.png
---
## Best practices
**Note:** A color selector is an `input type="color"`. Our libraries use this HTML native element. Browsers render those differently from each other. Color selectors are handled by the browser so developers have limited amount of control over the component display and behavior, however, most of the work is done by the browser.
- Ensure an `input type="color"` is labeled and associated with related content just as you would with other inputs.
- Consider using a tooltip with additional descriptions to accompany the color selector. Reference the [Color selector](https://design.visa.com/components/color-selector) examples and [Tooltip](https://design.visa.com/components/tooltip) for more.
## Keyboard controls
Keyboard actions and their corresponding behaviors for color selector
- Key: Moves focus to the next focusable element.
When the color selector menu is expanded, all focusable elements in the menu are included in the tab sequence. Focus goes in a circular rotation within the menu, so if the the focus was on the last element, the next focus would move to the first interactive element.
- Key: Moves focus to the previous focusable element.
When color selector menu is expanded, all focusable elements in the menu are included in the shift + tab sequence. Focus goes in a circular rotation within the menu, so if the the focus was on the first element, the next focus would move to the last interactive element.
- Key: Moves/pans the color well two-dimensional slider.
Moves/pans the eye-dropper window.
- Key: Moves left or right through the hue slider.
- Key: Spins the format toggler edit spin box channels - RGB/HSL/HEX.
- Key: Accepts the adjusted Color well/Eye dropper/Hue/RGB/HSL/HEX values and closes the Color selector menu.
Prompts the eye-dropper button.
Selects the eye-dropper window color.
- Key: Dismisses the Color selector menu if no color adjustments are made. If color adjustments are made, the first instance cancels any color adjustments, and then the second instance dismisses the Color selector menu.
- Key: RGB and HSL accepts digits or numerals. RGB and HSL have limits to their values.
For RGB input fields, each RGB value ranges between 0-255. Any numeral entry in the RGB input fields exceeding 255, accepts the first two digits numeral.
For HSL input fields, H (Hue) input field value ranges between 0-359 degrees; S (Saturation) and L (Lightness) values range between 0-100%.
- Key: For HEX input field, the format is #RRGGBB and the values range from 00 to FF for each color channel with total possible color combinations of 256 power 3 (16,777,216).
---
# index
---
title: Color selector
tab_title: Code
description: Menu that allows users to select a specific color through a variety of ways.
meta_description: Get code for menus that enable users to select a color using a variety of methods.
thumbnail: assets/components/color-selector-graphic.png
categories:
- inputs
- selection-controls
---
## Component Code Examples: color-selector
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the color-selector component
const component = parsed.components.find(c => c.name === 'color-selector');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `color-selector`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Color selector
tab_title: Usage
tab_order: 1
description: Menu that allows users to select a specific color through a variety of ways.
meta_description: Learn how to implement menus that enable users to select a color using a variety of methods.
thumbnail: assets/components/color-selector-graphic.png
related:
components:
- input
baseElements:
- color
---
Color selectors are a built-in feature provided by the operating system or browser. They combine an input field with a menu, which is prompted by a button, allowing users pick a custom color. It's important to note that the design of this component has limited customizations since it's a native component.
## Anatomy
**A. Swatch button (required):** Button that expands or collapses the color swatch menu while showing the color selected.
**B. Label (optional):** Text summarizing the purpose of the color selector.
**C. Tooltip inline message (required):** Text providing color code instructions.
**D. Accessibility tooltip button (required):** UI icon button that reveals the tooltip inline message on hover.
**E. Color range (required):** Gradient area allowing users to manually select a specific color from the range.
**F. Eyedropper (required):** Tool allowing users to sample a color from anywhere on the screen using the OS color selector.
**G. Color hue slider (required):** Area below the gradient box that allows users to adjust the hue of the selected color.
**H. Input (required):** Text field appearing in the expanded menu section that enables users to enter color codes.
**I. Toggle button (required):** Toggle button allowing users to toggle between RGB, HSL, and HEX color codes.
**J. Swatch preview (required):** Preview window showing the color selected.
## Best practices
- Follow the default appearance and interaction of the [Select](https://design.visa.com/components/select/usage) component on different browsers.
- Use this component in areas of your app where you want to allow users to customize color.
- For more information about using inputs, visit [Input](https://design.visa.com/components/input/usage) guidelines.
### Default color selector
Color selectors leverage the native appearance of different browsers and operating systems, meaning it has limited customizations available.
- Always test the color selector on multiple browsers and devices to ensure consistent user experience.
#### Collapsed
When collapsed, the color selector typically appears as a small rectangle that previews the selected color.
- Allow users to expand the menu by selecting anywhere in the swatch.
#### Expanded
When expanded, the menu displays a range of selection methods the user can use to adjust the color.
- Allow users to collapse the menu by removing focus from the menu.
### Hidden labels
Color selectors should typically include a label. However, there are some cases where hiding the label can provide design flexibility or space for additional context. If the label within the component build is hidden, include an alternate label elsewhere on the screen as well as within the code for accessibility.
- Always include a label somewhere else on the screen if you choose to omit it from the component build.
- Always include the label programmatically to ensure screen reader users have the full context.
### Accessibility tooltip
The accessibility tooltip provides visually impaired users with valuable information about the acceptable ranges for each color code format. Users can activate the tooltip by hovering over the icon button, and close it by simply shifting focus away.
## Behaviors
### Pre-selected color
In general, color selectors will have a pre-selected color of black (#000000) by default. However, this can be changed to a different default color on page load to increase usability and provide users with hint about how their selection will be applied.
- Provide users with a way to reset the color selection if they wish to revert to the default color.
- Use descriptive labels to give users context on how their selection will be applied.
### Selection method
The color selector allows users to change the color in a variety of ways including inputting a color code, adjusting the color range and hue slider, and using the eyedropper tool. The swatch preview will display the color selected currently.
#### Color code input
The color value input allows users to enter a value by editing the input text fields within the expanded menu. Users can use the arrow toggle to change between RGB, HSL, or HEX color codes.
- The color preview indicators will actively change color as the user types in their color values.
#### Hue slider and color range
The color range and hue slider allow users to select a color and are often used in combination. The hue slider is used as a macro-selector to choose a color, while the color range is a micro-selector to adjust the lightness and darkness of the selected color.
- Allow users to close the color selector menu by removing the focus from the menu.
#### Eyedropper tool
The eyedropper tool allows users to select a specific color that exists on any given page without having to enter a color value or guess what color it is on the color range.
- Allow users to close the eyedropper by either selecting a color or pressing the ESC key.
## Platform considerations
### Web
Color selector components are only available for web.
---
# accessibility
---
title: Combobox
tab_order: 2
description: Dropdown menu that helps users enter text or select items from a list.
meta_description: Find accessibility guidelines for dropdown menus that help users enter text or select an item from a list.
thumbnail: assets/components/select-combobox-graphic.svg
---
## Best practices
**Note:** Comboboxes are comprised of multiple components. Many of the attributes that comboboxes use are handled by our library components. As with other form components, use `id` values to associate additional instructions or error messaging so screen readers will read them. Reference [the coded examples.](https://design.visa.com/components/combobox)
- Consider implementing a “no results found” message similar to the Angular examples.
- Visit [Listbox](https://design.visa.com/components/listbox) for notes on its roles which include `role="listbox"`.
## Keyboard controls
### Input
Maintain common keyboard shortcuts used for editing text unless uniquely specified. Refer to [Input](https://design.visa.com/components/input/accessibility) for details.
Keyboard actions and their corresponding behaviors for input
- Key: Moves to next interactive focusable element.
- Key: Moves to previous input field.
- Key: Opens the menu.
- Key: Opens the menu.
- Key: Dismisses menu and clears any inline autocomplete while maintaining user-entered input.
### Menu (listbox pop-up)
Reference [Listbox](https://design.visa.com/components/listbox/accessibility) for detailed interactions. Focus will loop in a circular direction among the menu items.
Keyboard actions and their corresponding behaviors for menu (listbox popup)
- Key: Confirms the option in focus as the user’s selection and closes the menu.
- Key: Dismisses the menu, moves to next interactive focusable element.
- Key: Moves focus between the options in the menu.
- Key: Dismisses menu and clears any inline autocomplete while maintaining user-entered input.
---
# index
---
title: Combobox
tab_title: Code
description: Dropdown menu that helps users enter text or select items from a list.
meta_description: Get code for dropdown menus that help users enter text or select an item from a list.
thumbnail: assets/components/select-combobox-graphic.svg
categories:
- selection-controls
- inputs
---
## Component Code Examples: combobox
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the combobox component
const component = parsed.components.find(c => c.name === 'combobox');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `combobox`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Combobox
tab_title: Usage
tab_order: 1
description: Dropdown menu that helps users enter text or select items from a list.
meta_description: Learn how to use dropdown menus that help users enter text or select an item from a list.
keywords: ["Combo box", "autocomplete", "autosuggest", "UIPickerView (iOS)", "Spinner (Android)", "Menu (Android)", "MenuItem (Android)"]
related:
components:
- input
- listbox
- multiselect
patterns:
- forms
---
Comboboxes enable users to select one option from a menu or input custom text. This component combines an input field and single-select listbox to ensure users can find and select an option quickly.
Also known as: Combo box, autocomplete, autosuggest, UIPickerView (iOS), Spinner (Android), Menu (Android), MenuItem (Android).
## Anatomy
**A. Label (required):** Text summarizing the options available for selection. **B. Input (required):** Text field enabling users to enter custom text or filter menu options. **C. Inline message (optional):** Brief text describing the field label in more detail. **D. Chevron icon button (optional):** UI icon button that expands or collapses the menu. **E. Leading icon (optional):** Visual indication that the input field is interactive. **F. Clear text button (optional):** UI icon button that clears the text input or selected option. **G. Menu (required):** Container displaying the list of options that includes scrollbar as needed.
**H. Option (required):** Selectable text representing a single option.
## Usage
When to use and when not to use combobox component
- When to use: To present a list of options where users can select only one.
- When not to use: If users can select multiple options from the list. Use [Multiselect](https://design.visa.com/components/multiselect) instead.
- When to use: For long lists where all options can't be viewed at once or require scrolling.
- When not to use: For short lists where all options can be viewed without scrolling. Use a [Radio button group](https://design.visa.com/components/radio) instead.
- When to use: If users would benefit from entering text to filter or search the list options.
- When not to use: If list options are unfamiliar and users wouldn’t benefit from searching for specific terms. Use [Select (native)](https://design.visa.com/components/select) instead.
- When to use: If space is limited and displaying options in a collapsible menu would help.
- When not to use: To present a list of actions. Use a [Dropdown menu](https://design.visa.com/components/dropdown-menu) instead.
## Best practices
- Ensure the selected option appears visually different from unselected options by using an icon and selected state.
- Ensure users can select anywhere within an option label to select an option.
- List options in a logical order, either alphabetically or according to the most common or likely selection.
- Ensure comboboxes appear collapsed on page load to save space.
### Clear text button
Clear text buttons allow users to clear their input or selection from the field.
- Only display the clear text button when the user is actively inputting text to prevent confusion or accidental clearing.
### Chevron direction
The chevron UI icon button enables users to manually expand or collapse the menu. The direction it points should indicate what happens when it’s selected.
#### Collapsed
The chevron should point down when the menu is collapsed.
- Ensure the chevron icon can be used to manually expand the menu when selected.
#### Expanded
The chevron should point up when the menu is expanded.
- Ensure users can collapse the menu by removing focus from the field, not just by using the chevron icon.
### Leading icons
Leading icons are placed at the beginning of an input field and are not interactive. They visually indicate the type of information required, such as an avatar for selecting a recipient.
- Use one leading icon per input field as multiple icons can confuse users.
- Use icons that are universally understood and directly relate to expected entry.
- Use leading icons consistently across experiences to help users learn and predict behavior.
### Pre-selected options
In general, all comboboxes should appear empty by default. This ensures users have full control over their choices and prevents confusion that a selection has already been made. When possible, leave all options unselected both visually and programatically.
Some browsers require an option to be selected by default. If this occurs, the first option can be used as a placeholder that can’t be selected by the user. For required fields, leaving the placeholder option selected causes an error during submission. For optional fields, no error is shown. This ensures users must make an active choice and can’t accidentally submit the placeholder option.
- Use disabled styling so the placeholder option is visually distinct from the others.
- Ensure placeholder text is clear and helpful to avoid confusing or frustrating the user.
- Ensure placeholder text uses a font color with a 4:5:1 contrast ratio.
### Empty state
An empty state occurs when when text entered in the input field doesn't match the available options within the menu.
- Use clear language to inform users that their input doesn’t match any options, as users may misinterpret an empty state for a loading state and wait for options to appear.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
## Behaviors
Comboboxes can be implemented in a variety of ways to help users easily find and select an option. Reference the guidance below to learn about features of this component and optional behaviors you may implement based on use case.
**Note:** This section introduces features that aren’t automatically included in the component design and can be implemented in various ways. Product teams can determine how to load and filter data for their use case and should work closely with developers and designers to determine the appropriate level of complexity for their product.
### Input and menu functionality
Input fields in combobox components can be implemented with a variety of methods that help users find and select menu options. Product teams should work with their designers and developers to choose the appropriate method for their use case.
#### Manually expandable menu
Comboboxes can be implemented with menus that display all the selectable options upon expansion. In this method, the user can select an option from the menu without typing in the input field. The input field can optionally be implemented with a search or filter feature. Learn more about these below.
- Include the chevron UI icon button to enable users to expand the menu without typing.
- Implement optional user input with a search or filter behavior to help users find options.
##### Menu search
In this method, the text field is used to search the options displayed in the menu. When the user types, the menu jumps so the option that matches their input best appears at the top of the field, and focus is placed on that option.
- Only show the clear text button when the input field is in focus to prevent users from accidentally clearing their input.
- Use this method when users may want to browse options that are similar to their input but don’t match exactly.
##### Menu filter
In this method, the text field is used to filter the options displayed in the menu. When the user types, the options displayed in the menu are temporarily reduced so only those matching the entry remain.
- Include the clear text icon to enable users to remove their text input and return the menu to its original state without collapsing the menu.
- Use this method when users are likely to know exactly what option they’re looking for.
#### With custom input
Comboboxes can also be implemented to accept custom input, which means users can create a custom option that isn’t available in the menu. This method is particularly helpful for providing flexibility when you can’t predict all potential inputs.
When implementing comboboxes that accept custom input, ensure field accepts flexible formatting to avoid frustrating users with errors. If the system can’t accommodate varying formats, use a pre-defined menu without custom input. To learn more, reference [flexible input](https://design.visa.com/components/input/usage/#flexible-input).
- Pair this functionality with a filtering behavior like autosuggest or autocomplete so users can tell if their input matches a pre-defined option.
- Only show the clear text button when the input field is in focus to prevent users from accidentally clearing their selection.
#### Input-prompted menu
Comboboxes can be implemented with a menu that only appears after the user enters text in the input field. This method is generally used for complex scenarios where a large number of options are available and can’t all be displayed immediately.
It’s common to implement this type of combobox with autocomplete or autosuggest. To learn more, reference [Input](https://design.visa.com/components/input/usage).
- Consider including a leading icon to indicate the purpose of the input field.
- Only show the clear text button when the input field is in focus to prevent users from accidentally clearing their input.
- Don’t include a chevron icon, even when the menu is open. Users can collapse the menu by removing focus from the field.
### Selection method
Users can select an option using one of the following methods that aim to simplify the process and prevent accidental selections. Selection methods can be combined with search, filter, or autocomplete/autosuggest behaviors to create custom interactions. Consider your desired filtering behavior when implementing a selection method, as filtering behaviors affect how and when focus is placed on a menu option.
#### Manual selection (preferred)
Select and confirm requires users to confirm their choice before it's displayed in the field. When the user places focus on an option within the menu, it won't appear as the selected value in the field until the user selects the option they want by clicking or using the enter key. This is the preferred method as it’s the most accessible and provides users full control over their selection.
- Ensure the selected option isn't displayed until the user confirms their choice. This prevents accidental selection and gives users the opportunity to change their mind before submission.
Automatic selection
Automatic selection doesn’t require the user to confirm their choice before it’s displayed in the field. When focus is placed on an option in the menu, it automatically appears as the selected value when the user tabs out of the menu or removes focus from the combobox as a whole.
While this method can provide a streamlined selection process, it’s not as accessible as manual selection. Product teams using this method are responsible for ensuring accessibility standards and practices are met.
- Ensure the selected option isn't displayed until the user confirms their choice. This prevents accidental selection and gives users the opportunity to change their mind before submission.
### Scaling and reflow
Scaling and reflow refers to how content behaves as the container size changes, particularly when the container is small and can’t display all content at once. This is common with comboboxes, as they’re often used when screenspace is limited. While the option menu can scale vertically, the input field has a fixed height.
- Scale the option menu vertically until the maximum height is reached.
- Implement a scroll bar when the maximum height is reached to enable users to access all the options.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
- Avoid using unnecessary articles like “the” or “an”, unless they’re included in the proper name of a product or service.
### Labels
- Limit field labels to three to five words when possible.
- Be consistent when using plural language or “(s)” in field labels. For example, use “Select card type,” “Select card types,” or “Select card type(s)” consistently. If using “(s),” use the asterisk method over “(required)” to keep labels concise.
- Use parallel structure across field labels, using either nouns like "Services" or verbs like "Select a service". Learn more about parallel structure in [Grammar and punctuation](https://design.visa.com/content/grammar#parallel-structure).
### Option labels
- Limit option labels to three words or fewer unless referencing proper nouns, such as product names.
- Avoid using unnecessary articles like “the” or “an,” unless they’re included in the proper name of a product or service.
### Inline messages
- Use full sentences with proper punctuation.
- Limit descriptions to 80 characters or 20 words including spaces.
- Provide useful information such as why a field is required (if not obvious) without being technical.
- Give an example or specific syntax or values for inputs to help avoid errors.
#### Inline error message
- Use inline error messages to draw attention to errors without causing frustration.
- Provide clear, prescriptive guidance on correcting the error. Avoid redirecting users to another page to fix it.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
## Platform considerations
### Mobile
On mobile screens, the combobox opens as a full-screen and spans the width of the page. Once users make a selection, the fullscreen view closes automatically and the user is returned to their place in the form.
- Ensure users can exit the fullscreen view by selecting the close button in the top app bar.
- Remove the chevron icon button from the input field when the combobox is in fullscreen view.
---
# accessibility
---
title: Content card
description: Compact displays that summarize or direct users to more information.
meta_description: Find accessibility guidelines for compact displays that summarize or direct users to more information.
thumbnail: assets/components/content-card-graphic.svg
tab_order: 2
---
## Best practices
- Ensure buttons and links have meaningful `aria-labels` if there are multiple content cards with generic link or button labels. For example, use “close cardA” so a screen reader will announce which card the button goes to.
- Ensure clickable cards don’t have additional controls like a close button, as the whole card is a button.
- Consider using an HTML heading element for each card to help with keyboard navigation and page summaries for screen readers. Be sure to use the right heading level for the hierarchy of the page so that there aren’t skipped levels, even if you style the heading to look like a different level.
## Keyboard controls
Keyboard actions and their corresponding behaviors for content cards
- Key: Prompts the default action associated with a button.
- Key: Moves to the next focusable element.
- Key: Moves to the previous focusable element.
---
# index
---
title: Content card
tab_title: Code
description: Compact displays that summarize or direct users to more information.
meta_description: Get code for compact displays that summarize or direct users to more information.
thumbnail: assets/components/content-card-graphic.svg
categories:
- structure-and-layout
---
## Component Code Examples: content-card
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the content-card component
const component = parsed.components.find(c => c.name === 'content-card');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `content-card`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Content card
description: Compact displays that summarize or direct users to more information.
meta_description: Learn how to use compact displays that summarize or direct users to more information.
keywords: ["Tile", "card", "snapshot", "spotlight"]
related:
baseElements:
- responsive-grid-system
charts:
- charts/overview
tab_order: 1
---
Content cards are stylized containers that group elements and actions for a single, related subject. As one of the most customizable components, they can be tailored to meet specific user needs or preferences. Content cards are often displayed within a page's content area and provide a preview or summary of another page's content to encourage users to click-through for more details. They are often presented in multiples, offering various topics or aspects for users to explore.
Also known as: Tile, card, snapshot, spotlight.
## Anatomy
**A. Card (required):** Container featuring related content, icons, images, and actions. **B. Icon (optional):** Static icon enhancing or communicating the meaning of the card. **C. Card title (optional):** Brief text summarizing the subject of the content card. Can be used with or without the subtitle. **D. Subtitle (optional):** Additional text communicating more details. Can be used with or without the card title. **E. Body text (optional):** Brief message detailing important information about the content card. **F. Button or link (optional):** Text button and/or link that prompts an action or directs users to relevant resources. **G. UI icon button (optional):** Visual representation of an action that doesn’t require text to convey meaning. **H. Image (optional):** Graphic, illustration, or photography representing or communicating the meaning of the card.
## Usage
When to use and when not to use different types of content cards
- Component: To provide information and actions related to a single subject.
- When to use: To display large amounts of information or information that isn’t related.
As a [Dialog](https://design.visa.com/components/dialog/usage) or modal, as content cards do not float over the main content area of a page.
- Component: To make the entire card selectable.
- When to use: If no additional information or actions are associated with the card.
- Component: To save space on small screens.
- When to use: For detailed information that’s difficult to read in a small format.
- Component: To represent simple data visualizations.
- When to use: For complex or interactive data visualizations without customizing. While the dashboard card can serve as a starting point, it may require additional design iteration to represent more intricate data visualizations.
## Best practices
- Use consistent elements for cards within the same layout or content area to help users scan and understand information.
- Establish a clear visual hierarchy within the container to enhance scannability and readability.
- Use visuals such as icons, images, or illustrations to enhance the meaning and aid in quick comprehension of the content.
- Avoid cluttering the card with too many elements or actions. Keep the design simple and focused on the primary task.
### Icons and images
Icons and images add visual interest and enhance the meaning of content cards. By integrating relevant icons and images, you can quickly and effectively convey the essence of the content.
- Avoid overloading a card with too many elements that detract from the main message.
- Always ensure visuals align with the content and support the user's understanding.
#### Icons
Icons can be used to add visual interest or enhance the meaning of the card.
- Use universally recognized icons to ensure comprehension for all users.
- Use one icon per card to maintain simplicity and avoid confusion.
#### Category icons
Icons and labels can be used to categorize specific subjects under a broader subject.
- Use distinct and descriptive category names and icons for easy identification.
- Use one icon per category card to ensure it clearly represents and differentiates each category.
#### UI icon buttons
UI icons buttons visually represent an action without text. They’re typically used for actions related to the entire card.
- Ensure icons clearly and intuitively indicate the action they represent without accompanying text.
- Make sure UI icons are large enough to be usable, especially on touch devices.
#### Images
Images such as illustrations and photography add visual interest and meaning to content cards.
- Only use images when relevant or to enhance the understanding of the content.
- Avoid using intricate illustrations that may not be clear on smaller screens.
### Dividers and borders
Dividers and borders can be used to enhance the visual appeal and readability of content-heavy cards by breaking down dense information and improving organization.
#### Content dividers
Dividers can be added between content to break up sections or give the card a sense of hierarchy.
- Use dividers to provide a clear separation and organize information for easy consumption.
- Place dividers in consistent areas across content cards used in your experiences.
#### Card borders
Borders can be added to the bottom for emphasis or as a hover state to indicate the entire card is clickable.
- Use color to further distinguish multiple cards in a group, such as category cards.
- Use bottom borders consistently across content cards used in your experiences.
### Card collections
Content cards are typically presented as a grid or collection, reading left right, with each card the same size. For more complex grids, like the one below, reading order should follow a left to right, top to bottom pattern. The layout of these groups can influence user perception, so they should be organized for easy scanning and understanding.
- For left-to-right languages, the order should go from top left to bottom right.
- For right-to-left languages, the order should go from top right to bottom left.
## Behaviors
### Clickable card elevation
On hover, a clickable card may transition from a small to medium elevated surface. The default surface for content cards has a 1px border, small elevation, and a background of Surface 1. Surfaces are intended to be customizable to the individual needs of an application, as styling needs will change based on number of cards and desired emphasis.
## Platform considerations
### Responsive scale and reflow
Content cards scale to adapt to different screen sizes, and their position and alignment can also change. Content card layouts may be fluid or fixed width. When used in a fluid grid, a card’s width can adjust across grid columns and rows.
Content will also resize and reflow accordingly. Some content may not be appropriate to resize due to limitations or visual distortion. Learn more by visiting [Responsive grid system](https://design.visa.com/base-elements/responsive-grid-system).
#### Fixed grid
#### Fluid grid
---
# accessibility
---
title: Date and time selectors
tab_order: 2
description: Interactive calendar or time selector that allows users to choose a specific date or time.
meta_description: Find accessibility guidelines for interactive calendar or time selectors that allow users to choose a specific date or time.
thumbnail: assets/components/date-selector-graphic.svg
---
## Best practices
**Note:** Date and time selectors are inputs with `type="date"` or `type="time"`. Our libraries use these HTML elements, so different browsers will show this component differently. As a result, developers have a limited amount of control over how these elements appear and behave.
- Always label `input type="date"` and `input type="time"` elements and associate them with related content.
## Keyboard controls
VPDS date and time selectors share keyboard behavior with text inputs. The special date and time menus are controlled by the browser.
### Input field
Reference [Text field](https://design.visa.com/components/input/accessibility) and [Button specs](https://design.visa.com/components/button/accessibility) for base behavior.
Keyboard actions and their corresponding behaviors for input field
- Key: Moves between the date fields mm/dd/yyyy and adjust the entries within those fields.
- Key: Moves between the date fields mm/dd/yyyy and adjust the entries within those fields.
- Key: Accepts all valid characters.
- Key: Opens the date selector menu and places focus on the selected date displayed in the input text field.
If no date has been selected, it places the focus on the current date.
#### Date selector menu
Keyboard actions and their corresponding behaviors for date selector menu
- Key: Closes the menu and moves the focus back on menu-prompting element.
If the focus or hover was set to a different menu item, closing the menu with Esc will not update the selection.
- Key: Moves the focus to the next item of the tab sequence within the date selector menu.
**Note:** Only one button within the calendar grid is in the tab sequence. The focus will loop back to the top (Month and year label) when the focus is on the last button (Today).
- Key: Moves the focus to the previous item of the tab sequence within the date selector menu.
**Note:** Only one button within the calendar grid is in the tab sequence. Focus will loop back to the bottom (Today) when the focus is on the first button (Month and year label).
#### Date selector menu: Dates grid
Keyboard actions and their corresponding behaviors for date selector menu: dates grid
- Key: Selects the date receiving focus, places focus back on the menu-prompting element, and updates the text field to display the selected date.
- Key: Moves the focus to the next menu item. The focus moves based on the set grid. ←→ moves the focus to the previous or next day incrementally.
If the focus is on the last day of the week, pressing → moves the focus to the following day. For example, if the focus was on the end of the week, pressing → shifts the focus to the following start of the week.
↑↓ moves the focus to the previous or next week, on the same day of the week.
- Key: Home key moves the focus to the first day of the current week.
End key moves the focus to the last day of the current week.
- Key: Page Up key changes the grid of dates to the previous month.
Page Down key changes the grid of dates to next month.
Set focus to the same date. If that day does not exist, then move focus to closest available date. For example, for dates that don’t exist within all months, such as the 29, 30, and 31, move the focus to the last date of the month.
#### Date selector menu: Month and year label and navigation buttons
Keyboard actions and their corresponding behaviors for date selector menu: month and year label and navigation buttons
- Key: Changes the month and/or year displayed in the calendar grid.
#### Clear button
Keyboard actions and their corresponding behaviors for clear button
- Key: Space or enter key on the Clear button closes the date selector menu, reset the month, date, and year in the input, and return the focus to the menu-prompting element.
#### Today button
Keyboard actions and their corresponding behaviors for today button
- Key: Space or enter key on the Today button selects today’s date and close the menu.
---
# index
---
title: Date and time selectors
tab_title: Code
description: Interactive calendar or time selector that allows users to choose a specific date or time.
meta_description: Get code for interactive calendar or time selectors that allow users to choose a specific date or time.
thumbnail: assets/components/date-selector-graphic.svg
categories:
- inputs
- selection-controls
---
## Component Code Examples: date-and-time-selectors
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the date-and-time-selectors component
const component = parsed.components.find(c => c.name === 'date-and-time-selectors');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `date-and-time-selectors`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Date and time selectors
tab_title: Usage
tab_order: 1
description: Interactive calendar or time selector that allows users to choose a specific date or time.
meta_description: Learn how to use interactive calendar or time selectors that allow users to choose a specific date or time.
thumbnail: assets/components/date-selector-graphic.svg
keywords: ["Date picker", "time picker", "calendar selector", "calendar picker", "date input", "time input"]
related:
components:
- input
patterns:
- forms
---
Date and time selectors allow users to input or select a single or range of dates and times from the past, present, or future. They often appear in [Forms](https://design.visa.com/patterns/forms) to condense space and provide a clear, concise selection process. Date and time formats are usually determined by the application and localization standards.
By default, the date and time selector menu will display the current date, time, or the most applicable month, year and time.
Also known as: Date picker, time picker, calendar selector, calendar picker, date input, time input.
## Anatomy
**A. Input (required):** Text field enabling users to enter custom date text.
**B. Calendar icon button (required for web):** UI icon button that indicates and expands/collapses the calendar menu.
**C. Native date selector menu (required for web):** Container displaying the dates in a calendar format.
**D. Month and year label (required):** Text communicating the month and year represented in the calendar.
**E. Month navigation arrows (required):** UI icon buttons for navigating to past and future months within the same year.
**F. Week day labels (required):** Abbreviated labels indicating the days of the week from Sunday to Saturday.
**G. Current date (required):** Outlined square or other indicator communicating the current date based on the user’s settings.
**H. Selected date (required upon selection):** Filled square or other indicator highlighting the date the user selected.
**I. Clear button (required):** UI icon button that clears the selected date and closes the date selector menu.
**J. Today button (required):** Text button that resets the calendar to select today’s date.
**K. Confirm button (required in mobile only):** Confirms the user’s date selection and closes the date selector menu.
## Usage
When to use and when not to use different types of date and time selectors
- Type: For viewing the date in context of the days of the week.
- When to use: If the dates are years in the past and would require more effort to navigate back than to input the date.
- Type: For selecting a custom period of time from one date to another.
- When to use: For selecting two unrelated dates.
- Type: If the time input is limited to what is provided in the dropdown.
- When to use: If time is not limited to what's provided in the dropdown or users may prefer to enter a custom time.
## Best practices
- Follow the default appearance and behavior of date and time selectors on different browsers.
- Always consider local and regional preferences for date and time formats.
- Follow all guidelines for using text fields in [Input](https://design.visa.com/components/input/usage).
### Default date selector
Date selectors help users choose a date from a calendar view. They're typically used for tasks like scheduling, when users would benefit from understanding the relationship between a date and the day of the week.
- Only display dates up to a year in the past or present from the current date to avoid overwhelming users.
- Use a simple date input for memorable, familiar, or dates that do not require the user to reference a calendar to recall.
- Always provide users with the option to enter the date in addition to selecting the date within the menu or modal.
### Date range selector
Date range selectors help users in choose a date span while providing the day of the week context. They’re typically used for selecting precise or significant date ranges, when users would benefit from understanding the relationship between a date and the day of the week.
- Place the input fields next to each other for screens with enough horizontal space.
- Stack date selectors with the start date on top for screens with limited horizontal space.
- Always provide users with the option to enter the date in addition to selecting the date within the menu or modal.
### Time selector
Time selectors help users select times from a dropdown list when options may be limited by availability. Typically, the system will automatically adopt a 12- or 24-hour clock based on the device settings. The default time will be highlighted in blue, however only one column (hours, minutes, am/pm) can be in focus at a time.
- Allow users to change between 12- and 24-hour clock for time inputs.
### Credit card expiration date
Separate select fields for month and year are commonly utilized for credit card expiration date inputs. This lockup is especially beneficial for products catering to international users to ensure the date is entered correctly, as the order can vary by region.
- Clearly label each select field to specify if selecting the month or year, preventing any confusion.
- Always list all 12 months in the dropdown menu, formatted as MM.
- Present the current year along with the following 19 years, for a total of 20 years in the dropdown menu, formatted as YY.
- Enable users to type to quickly navigate to their desired option and select it without needing to open the dropdown menu.
- Refer to [Select (native)](https://design.visa.com/components/select/usage) and [Card input](https://design.visa.com/patterns/card-input) guidelines for further guidance on implementing this lockup.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
## Behaviors
### Input and menu functionality
Date and time selectors include both an input field and interactive menu, allowing users to type custom text or select from the menu directly. On page load, the menus remain closed until prompted by the calendar or clock UI icon button.
When the user expands the date selector menu, it shows the current month and year with the current date in focus, but not selected. When the user expands the time selector menu, it shows the default or first available time in focus, but not selected.
**Note:** The examples below demonstrate this behavior using the default date selector, but the same functionality applies to the date range selector and time selector.
#### Input functionality
When the menu is collapsed, users can enter a custom date or time by typing in the input field. If users expand the menu after entering custom input, the date or time appears selected in the menu.
- Clearly indicate the required format for the date or time entry in the input field label.
#### Menu functionality
When the menu is expanded, users can select a date or time by interacting directly with the menu. Once a date or time is selected, it’s shown in the input field and the menu automatically collapses. If users select the “Today” button, it will automatically select the current date and collapse the menu.
- Ensure the selected date is reflected automatically in the input field.
#### Changing the month and year
To change the month or year, the user selects the month and year label at the top of the calendar. This switches the view from the calendar to a list of years. When the user selects a year, it expands like an accordion to reveal the 12 months within that year. Once they select a month, the menu switches back to the calendar view.
### Date range limits
Since date range selectors require users to select a start and end date, the selection order impacts what dates are available for selection. This ensures the start date is never later than the end date, and vice versa.
#### Start date selected first
When a start date is chosen first, it limits the options available for the end date. When the user prompts the end date menu, any dates that come before the chosen start date appear disabled. This ensures the end date can never be earlier than the start date.
- Ensure only one menu is open at a time by collapsing the menu as soon as soon as a selection is made.
#### End date selected first
When an end date is chosen first, it limits the options available for the start date. When the user prompts the start date menu, any dates that come after the chosen end date appear disabled. This ensures the start date can never be later than the end date.
- Ensure only one menu is open at a time by collapsing the menu as soon as soon as a selection is made.
### Docked menu placement
As a docked menu, the date selector is attached or 'docked' to the input field. This means its position is directly related to the input field. The menu has a fixed width and doesn't scale with the input field or screen size. The input field length can vary and may not match the menu's width.
- Ensure the menu is left-aligned for left to right reading languages, and right-aligned for right to left reading languages.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
- Avoid using unnecessary articles like “the” or “an”, unless they’re included in the proper name of a product or service.
### Labels
- Limit field labels to three to five words when possible.
- Use parallel structure across field labels, using either nouns like "Date" or verbs like "Select a date". Learn more about parallel structure in [Grammar and punctuation](https://design.visa.com/content/grammar).
### Inline message
- Be brief, descriptive, and helpful, limiting the message to one to two short sentences.
- Use sentence case and punctuation. The only exceptions are proper nouns or names.
- Give additional guidance about the field and how to use it if necessary.
- Provide useful information including why a field is needed (if not obvious) without being technical.
- Give an example or specific syntax or values for inputs to help avoid errors.
#### Inline error message
- Follow the general rules for inline messages such as limiting the message to one to two sentences with punctuation.
- Draw attention, without causing frustration. Explain what happened and what they need to do to correct the error.
- Use prescriptive language to provide a clear guidance, actions, instructions, and answers, then get out of their way.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
- Clearly outline the simplest resolution (if applicable) without sending them to another location for answers.
## Platform considerations
Depending on the viewing device(s), the choice can be made to utilize either a web or mobile-based calendar element.
### Web
On web, the calendar typically appears as a docked menu, which is beneficial for leveraging larger screen sizes. However, it's usually not recommended for mobile interfaces. To learn more, reference [Mobile](https://design.visa.com/components/date-selector/usage/#mobile).
#### Appearance
Native date selectors are utilized due to their ready-made functionality and inherent accessibility features. However, it's important to note that the appearance of these menus can vary across different browsers and operating systems.
### Mobile
On mobile devices the menu appears as a modal.
- Always use OK and Cancel buttons within a mobile date and time selector.
## Development notes
Date input field help with the date formatting and with the validation of range. However, there are issues with **input type="date"** because of the limited browser support. In unsupported browsers, it will move to a simple **input type="text"**.
---
# accessibility
---
title: Dialog
description: Messages that float over page content and provide time-sensitive alerts.
meta_description: Find accessibility guidelines for messages that float over page content and provide time-sensitive alerts.
thumbnail: assets/components/dialog-graphic.svg
tab_order: 2
---
## Best practices
**Note:** VPDS uses a native HTML dialog element and backdrop pseudo element. Our library components already handle some of the dialog behaviors.
- Ensure the screen reader announces the dialog title and/or content. When the dialog opens, focus is moved into it and is trapped there until it closes. Tabbing will cycle through the focusable elements in the dialog.
- Use an `h2` element for headings.
- Place the close button at the end of the DOM in the dialog so that the keyboard navigation goes through all the content before the close button.
- Ensure the escape key closes the dialog. When a dialog closes, focus is returned to the control which triggered it.
## Keyboard controls
### Keyboard focus tab order
Keyboard focus tab order for different types of dialog.
- Dialog: Standard keyboard focus tab order will follow the DOM order.
- Dialog: Focus should be placed on the first interactive element inside dialog, excluding close buttons.
- Dialog: Not recommended to use close buttons on dialogs that include form elements.
### Keyboard
Keyboard actions and their corresponding behaviors for dialog
- Key: Prompts the action associated with the focused interactive element in the dialog.
- Key: Moves keyboard focus to the next focused interactive element in the dialog.
- Key: Moves keyboard focus backwards to the previous interactive element in the dialog.
- Key: Closes the dialog.
---
# index
---
title: Dialog
tab_title: Code
description: Messages that float over page content and provide time-sensitive alerts.
meta_description: Get code for messages that float over page content and provide time-sensitive alerts.
thumbnail: assets/components/dialog-graphic.svg
categories:
- feedback-and-status
---
## Component Code Examples: dialog
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the dialog component
const component = parsed.components.find(c => c.name === 'dialog');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `dialog`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Dialog
tab_title: Usage
tab_order: 1
description: Messages that float over page content and provide time-sensitive alerts.
meta_description: Learn how to use messages that float over page content and provide time-sensitive alerts.
keywords: ["Modal", "lightbox", "popup module", "alerts (iOS)", "alert", "dialog (Android)", "dialog feedback", "dialog box", "overlay"]
related:
components:
- banner
- section-message
patterns:
- feedback-and-status
content:
- messaging
---
Dialogs are container that appears over a user’s workflow and provides time-sensitive messages. They can be used to communicate critical status alerts or situations, confirm an action, and facilitate quick user actions.
Also known as: Modal, lightbox, popup module, alerts (iOS), alert, dialog (Android), dialog feedback, dialog box, overlay.
## Anatomy
**A. Title (required):** Brief text summarizing the purpose of the dialog. **B. Message (required):** Descriptive text, or in some cases limited interactive elements, tables, or graphics. **C. Close button (optional):** Icon button that can be used in place of, but not with, a text button to dismiss the dialog. **D. Buttons (optional):** Primary and secondary text buttons used to prompt an action. **E. Overlay (required):** Shaded overlay communicating to the user that only the dialog is interactive.
## Usage
When to use and when not to use different types of dialogs
- Component: For informational messages that are of high enough priority to disrupt the user's workflow, even though they may not require immediate action.
- When to use: For low-priority, system-level messages. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
For low-priority messages that don’t require user action or attention. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
- Component: Success dialogs are not a common use case as they are too disruptive for low-priority confirmations.
- When to use: For system- or section-level success, messages including on-page event confirmations. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
If the user is taken to a success page on submit. Don’t use a messaging component in this case.
- Component: For medium-priority messages that are of high enough priority to disrupt the user's workflow to warn of potential issues that may require action immediately or in the near future.
- When to use: For medium-priority, system-level messages that require attention but not disruption. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
For warnings contextually relevant to a section of a page or workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
For low-priority warnings that don't require user action or attention. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
- Component: For high-priority alerts communicating that critical errors or issues have occurred when completing a task or operation and must be fixed before continuing.
- When to use: For high priority, system-level errors that require attention, instead use a [Banner](https://design.visa.com/components/banner/usage).
For high-priority errors contextually relevant to a section of a page or workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
- Component: For new features or systems to guide, introduce and explain the functionality of different elements to the users.
- When to use: For simple intuitive applications.
For experienced users that are familiar with the features or application.
For minor changes that could cause frustration.
## Best practices
- Use dialogs sparingly and design them for efficient task completion, allowing users to return seamlessly to their workflow.
- If the dialog is prompted by an action, return the focus to where the user was in their workflow.
- Left-align buttons except for touring tips and mobile dialogs with full-width buttons. Learn about alignment in [Button](https://design.visa.com/components/button/usage).
- Visit [Feedback and status](https://design.visa.com/patterns/feedback-and-status) to learn how to use messaging components, understand their level of disruption, and choose the appropriate messaging component for your context.
## Behaviors
### Dismissal
In general, users should be allowed to dismiss dialogs using a close icon button or text button. Dialogs should also dismiss when users complete an associated action, such as correcting an error. Avoid using timed auto-dismissal for dialogs, as they may disappear before screen readers finish announcing the text.
### Dialog height
While there are no strict minimum or maximum height requirements for dialogs, it’s essential to make adjustments based on factors such as use case, screen size, and content volume. As previously mentioned, avoid using full-page dialogs.
- Adjust dialog height according to the use case, screen size, and content volume. Aim for clear, digestible information.
- Be aware of the space above and below the dialog when setting size. Good spacing improves readability.
- For extensive content use a scroll bar, but do so sparingly. If using, always ensure the title and buttons are visible.
### Animation
Dialogs may animate. Typically, they fade in with the background overlay and fade out upon dismissal.
- Ensure animations are brief, subtle, and unobtrusive.
- Implement animations consistently across flags in your experience, either animating all or none.
## Content
- Learn how to craft content for messaging components, like dialogs, visit [Messaging](https://design.visa.com/content/messaging).
- Follow guidelines for [Link](https://design.visa.com/components/link/usage) and [Button](https://design.visa.com/components/button/usage) components when labeling actions and destinations within dialog.
## Platform considerations
### Mobile
- Position dialogs in the center of the page, ensuring left and right margins are 16 dp.
- Configure buttons to fill the container if necessary to enhance visibility where screen space is limited.
- Use a text button as the default close mechanism for mobile instead of the close icon button in the top right corner.
- Use a close icon button as a close mechanism only if the calls to action are required for other actions.
---
# accessibility
---
title: Divider
description: Visual elements used to separate and group information on a page.
meta_description: Find accessibility guidelines for visual elements used to separate and group information on a page.
thumbnail: assets/components/divider-graphic.svg
tab_order: 2
---
## Best practices
- Use the `` tag for dividers used on web.
- Use `aria-hidden="true"` for decorative dividers to hide the element from the accessibility API. Reference [the coded examples](https://design.visa.com/components/divider).
---
# index
---
title: Divider
tab_title: Code
description: Visual elements used to separate and group information on a page.
meta_description: Get code for visual elements used to separate and group information on a page.
thumbnail: assets/components/divider-graphic.svg
categories:
- structure-and-layout
---
## Component Code Examples: divider
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the divider component
const component = parsed.components.find(c => c.name === 'divider');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `divider`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Divider
description: Visual elements used to separate and group information on a page.
meta_description: Learn how to use visual elements used to separate and group information on a page.
keywords: ["Horizontal rule", "rule", "line"]
related:
patterns:
- forms
- application-layouts
tab_order: 1
---
Divider is a minimalistic visual component used for structuring and grouping information on a page. It subtly delineates different sections without causing distraction, thus enhancing user comprehension.
Also known as: Horizontal rule, rule, line.
## Anatomy
**A. Default divider:** A medium-weight, neutral-colored horizontal line.
**B: Section divider:** A heavy-weight, colored horizontal line.
**C: Decorative divider:** A light-weight, neutral-colored horizontal line.
## Usage
When to use and when not to use different types of dividers
- Component: To clearly distinguish between sub-sections or groups of content within a section of page.
In text-heavy contexts where it can improve readability by breaking up large blocks of text.
- When to use: When content grouping can be implied using white space.
- Component: To separate two distinct sections at the page level.
- When to use: In place of a default divider to separate content within a section.
- Component: As an aesthetic element to enhance the look or feel of your content.
- When to use: As a functional separator or when a divider is critical to understanding the organization of your content.
## Best practices
- Use whitespace when possible to group content before resorting to using dividers.
- Use dividers where they make sense. They should help in grouping related content or separating unrelated content.
- Keep the style of dividers consistent throughout your design to maintain visual harmony.
- Ensure decorative dividers meet accessibility contrast ratios. For more information, reference [Accessibility](https://design.visa.com/components/divider/accessibility).
- Ensure margins are equal widths, whether you decide to implement full-width dividers or crop them to the margins.
{/* DOS AND DONTS */}
### Divider hierarchy
Divider styles are meant to communicate different types of content separation. The example below illustrates how you might combine divider styles to establish visual hierarchy.
---
# accessibility
---
title: Dropdown menu
tab_order: 2
description: Interactive elements that allow users to select a single option from a list.
meta_description: Find accessibility guidelines for interactive elements that allow users to select a single option from a list.
thumbnail: assets/components/dropdown-menu-graphic.svg
---
## Best practices
**Note:** Dropdown menu is a composite component. Some of the following requirements are handled by the component out of the box. The contents of the menu are coded in a list comprised of buttons or links so screen readers announce the number of items in the menu.
- Ensure the button that opens the menu uses `aria-expanded`, which is true when the menu is open, and `aria-controls` with the `id` value of the menu container.
- Ensure the menu (which is a container with a list) uses `aria-hidden`, which is false when the menu is closed, and an `id` which is referenced by the triggering button.
## Keyboard controls
Dropdown menus are not coded as listboxes, unlike some similar components. Elements within the dropdown menu use their native roles and shouldn't have added role attributes.
For menu items with actionable items (given the role of buttons in this case), Up/Down arrow keys are not applicable. When the menu is expanded, the user can navigate within the menu using Tab/Shift+Tab keys.
Keyboard actions and their corresponding behaviors for dropdown menu
- Key: Prompts button.
- Key: Moves to the next focusable element within the menu (unlike listbox). If focus is on the last item, tab closes the menu and moves to the next focusable element on the page.
- Key: Moves to the previous focusable element within the menu; if focus is on the first item, shift + tab moves to the triggering element.
- Key: Closes the menu.
---
# index
---
title: Dropdown menu
tab_title: Code
description: Interactive elements that allow users to select a single option from a list.
meta_description: Get code for interactive elements that allow users to select a single option from a list.
thumbnail: assets/components/dropdown-menu-graphic.svg
categories:
- selection-controls
---
## Component Code Examples: dropdown-menu
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the dropdown-menu component
const component = parsed.components.find(c => c.name === 'dropdown-menu');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `dropdown-menu`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Dropdown menu
tab_title: Usage
tab_order: 1
description: Interactive elements that allow users to select a single option from a list.
meta_description: Learn how to use interactive elements that allow users to select a single option from a list.
keywords: ["Menu", "select menu", "command menu dropdown", "actions drop-down", "action menu", "picker (IOS)", "menu (Android)"]
related:
components:
- combobox
- multiselect
---
Dropdown menus enable users to select an action from a list of options. They’re commonly used to save space by grouping related actions, or to provide actions in a confined space like a table column.
Also known as: Menu, select menu, command menu dropdown, actions drop-down, action menu, picker (IOS), menu (Android).
## Anatomy
**A. Button (required):** Text or icon button used to open or close the dropdown menu.
**B. Menu option (required):** Individual option representing an action.
**C. Divider (optional):** Horizontal line used to group related actions.
## Usage
When to use and when not to use different types of dropdown menus
- Component: When there’s sufficient space to provide a list of actions with a label.
- When to use: As form input. Use [select](https://design.visa.com/components/select/usage) instead.
- Component: When space is limited and an icon can accurately summarize the options in the list.
- When to use: As form input. Use [select](https://design.visa.com/components/select/usage) instead.
## Best practices
- Group related actions together in the menu.
- Avoid using dropdown menus for critical actions that should be immediately available.
- Ensure icon buttons are recognizable so users can anticipate what actions are included in the menu.
- Include a scrollbar if menus are long and the container needs to have a maximum height.
- Avoid using a dropdown menu for navigation. If a dropdown menu needs to be used for navigation, follow guidance found in Link for “[Styling and coding buttons and links](https://design.visa.com/components/link/usage#styling-and-coding-buttons-and-links).”
### Buttons vs. links
Dropdown menus are intended to be used for actions only, but it rare cases, they may contain links. Always consult with accessibility partners to ensure interactions are accessible for all users.
- Don’t mix buttons and links within a dropdown menu.
- Follow all guidelines for labeling links to ensure it’s clear what they do and where they lead.
### Icon usage
Icons can be used in dropdown menus to make scanning easier and reinforce familiar ideas.
- Use icons consistently throughout the menu. For example, if you use icons for some options, use them for all.
- Ensure icons are relevant and easy to understand to avoid unnecessary visual elements.
## Behaviors
### Destructive actions
Destructive actions refer to actions that delete or remove data. Dropdown menus can contain destructive actions as necessary. For more information, reference [Button](https://design.visa.com/components/button/usage) guidelines.
### Placement
Menus can align to either side of the button based on its placement in the interface.
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation.
- Avoid abbreviations where possible.
- Limit labels to a few brief words to prevent unnecessary reflow.
- Follow all additional guidance found in [Button](https://design.visa.com/components/button/usage) for crafting action labels.
- Use parallel structure for menu option labels, either always starting with nouns or command verbs. Learn more about parallel structure in [Grammar and punctuation](https://design.visa.com/content/grammar).
---
# accessibility
---
title: Flag
description: Messages that provide low-priority updates about a process or event.
meta_description: Find accessibility guidelines for messages that provide low-priority updates about a process or event.
thumbnail: assets/components/flag-graphic.svg
tab_order: 2
---
## Best practices
**Note:** If you are using a screen reader on the code tab of this component, you may have heard multiple generic messages as examples load. These examples are used in the context of documentation to show the importance and usage of role or aria-live attributes which prompt the screen reader to read the component content aloud.
- Use `aria-live=""` except for error messages which should use `aria-live="assertive"`.
- Use `role="status"` which is equivalent to `aria-live="polite"` with `aria-atomic="true"`.
- Ensure the type of flag (success, warning, etc.) is communicated verbally if it can’t be easily inferred from the message text.
## Keyboard controls
Flags are comprised of other elements that use standard keyboard actions.
**Note:** Activating the Escape key does not close the flag, as that might disrupt what the user is doing by closing something else.
Keyboard actions and their corresponding behaviors for flags
- Key: Prompts the action associated with the focused interactive element.
- Key: Moves focus to the next focusable element.
- Key: Moves keyboard focus backwards to the previous interactive element in the banner.
---
# index
---
title: Flag
tab_title: Code
description: Messages that provide low-priority updates about a process or event.
meta_description: Get code for messages that provide low-priority updates about a process or event.
thumbnail: assets/components/flag-graphic.svg
categories:
- feedback-and-status
---
## Component Code Examples: flag
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the flag component
const component = parsed.components.find(c => c.name === 'flag');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `flag`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Flag
description: Messages that provide low-priority updates about a process or event.
meta_description: Learn how to use messages that provide low-priority updates about a process or event.
keywords: ["Toast message", "snack bar", "notification", "banner"]
related:
components:
- banner
- section-message
patterns:
- feedback-and-status
content:
- messaging
tab_order: 1
---
Flags provide contextual, low priority messages to the user. They’re primarily used for success messages or alerts that require minimal actions, if any, from the user.
Also known as: Toast message, snack bar, notification, banner.
## Anatomy
**A. Icon (required):** Visual indicator communicating the urgency of the flag. **B. Title (optional):** Brief text summarizing the purpose of the flag. **C. Message (required):** Descriptive message detailing important contextual information. **D. Close icon button (optional):** Icon button used as a close button alternative that allows users to manually dismiss the flag. **E. Button and link (optional):** Text button or link that prompts an action or directs users to relevant resources.
## Usage
When to use and when not to use different types of flags
- Component: For low-priority feedback or status updates that don’t require user action or attention.
- When to use: For neutral messages that are important enough to disrupt the users workflow but may not require action before continuing. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For low-priority, system-level messages. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
For low-priority information contextually relevant to a section of a page or workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
- Component: For system- or section-level success, including on-page event confirmations. This is the most frequent use case.
- When to use: If the user is taken to a success page on submit. Don’t use a messaging component in this case.
- Component: For low-priority warnings that don’t require user action or attention.
- When to use: For medium to high-priority warnings that must be fixed or acknowledged before continuing. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For medium-priority, system-level messages that require attention but not disruption. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
For medium- or high-priority warnings contextually relevant to a section of a page or workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
- Component: Error flags are not a common use case.
- When to use: For high-priority errors that must be fixed before continuing. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For high priority, system-level errors that require attention. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
For high-priority errors contextually relevant to a section of a page or workflow. Use a [Section message](https://design.visa.com/components/section-message/usage) instead.
## Best practices
- Limit the use of flags, as overusing can desensitize users and reduce the value.
- Visit [Button](https://design.visa.com/components/button/usage) to learn about best practices for alignment, order, and language for calls to action.
- Visit [Feedback and status](https://design.visa.com/patterns/feedback-and-status) to learn how to use messaging components, understand their level of disruption, and choose the appropriate messaging component for your context.
## Behaviors
### Dismissal
In general, users should be allowed to dismiss flags using a close icon button or text button. Flags should also dismiss when users navigate to a new page or complete an associated action, such as correcting an error. Avoid using timed auto-dismissal for flags, as they may disappear before screen readers finish announcing the text.
### Animation
Flags may use animated graphics. They appear by sliding onto the screen from the nearest edge (top, bottom, left, or right).
- Ensure animations are brief, subtle, and unobtrusive.
- Implement animations consistently across flags in your experience, either animating all or none.
## Content
- Learn how to craft content for messaging components, like flags, visit [Messaging](https://design.visa.com/content/messaging).
- Follow guidelines for [Link](https://design.visa.com/components/link/usage) and [Button](https://design.visa.com/components/button/usage) components when labeling actions and destinations within flags.
## Platform considerations
### Mobile
Flags are available in both mobile and web and should be implemented similarly across both platforms.
- Extend mobile flags across the screen width to ensure they’re large enough to read.
- Place mobile flags consistently at the top or bottom of the screen without covering interactive elements.
---
# accessibility
---
title: Footer
description: Content fixed at the bottom of a page to provide important information or links.
meta_description: Find accessibility guidelines for content fixed at the bottom of a page to provide important information or links.
thumbnail: assets/components/footer-graphic.svg
tab_order: 2
---
## Best practices
- Ensure logos have accessible text using an `aria-label`. Add the label to the svg for custom logos.
- Use a class of `v-logo-hc-dark-foreground` or `v-logo-hc-light-foreground` to make sure logos always have sufficient contrast against the background in Windows high contrast mode.
## Keyboard controls
Keyboard actions and their corresponding behaviors for footers
- Key: Activates link.
---
# index
---
title: Footer
tab_title: Code
description: Content fixed at the bottom of a page to provide important information or links.
meta_description: Get code for content fixed at the bottom of a page to provide important information or links.
thumbnail: assets/components/footer-graphic.svg
categories:
- navigation
- structure-and-layout
---
## Component Code Examples: footer
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the footer component
const component = parsed.components.find(c => c.name === 'footer');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `footer`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Footer
description: Content fixed at the bottom of a page to provide important information or links.
meta_description: Learn how to use content fixed at the bottom of a page to provide important information or links.
keywords: ["Bottom section", "end section", "UITabBar (iOS)", "BottomNavigationView (Android)"]
related:
components:
- vertical-navigation
patterns:
- application-layouts
tab_order: 1
---
Footers are persistent elements on web pages that provide quick links and legal content. Some applications might not include a footer on each page and can provide the same information from a navigation bar or Settings/About section. When they’re used, they’re placed at the bottom of the page.
Also known as: Bottom section, end section, UITabBar (iOS), BottomNavigationView (Android).
## Anatomy
**A. Brand mark (required):** Visual element representing Visa, a partner brand, or a fictitious brand associated with the product.
**B. Copyright text (optional):** Text providing critical legal information including a copyright symbol, year of creation, the author’s name, and a rights statement.
**C. Links (optional):** Link components directing users to legal information.
## Usage
When to use and when not to use different types of footers
- Component: When footer contains minimal content.
- When to use: As a source for site navigation.
- Component: When there’s a need for more content within the footer area including links to important site resources.
- When to use: As the main source for site navigation.
## Best practices
- Follow all guidance found in [Link](https://design.visa.com/components/link) when implementing links in the footer.
- Ensure the footer appears the same on every page where it’s used.
### Placement
Placement of the footer depends on the use case and experience needs. Consider the three options below when using the footer component.
#### Fixed
Footers can be fixed to the bottom of a web page to let users know they’ve reached the end. This is the default behavior for footers as its the least disruptive to the user.
#### Sticky
Footers can also be “sticky” to ensure they’re always visible. Sticky footers stay at the bottom of the viewport regardless of how the user scrolls.
- Only use this method if the footer content is critical and needs to be accessible at all times.
#### About pages
The application can use an “About” page if the footer content doesn’t need to appear on every page. This page could include content like copyright notices or acknowledgments, providing a less high-profile way for users to access this information. Check with Product Legal requirements about what must be accessible to users at all times.
## Platform considerations
### Web
On most web pages, the footer size is determined by the screen size. The footer component has responsive breakpoints to support a full range of devices. The standard 1440 px footer is recommended for desktop web environments.
### Tablet
On tablets, the footer size and layout is determined by screen size and orientation. The standard approach for tablet footers is 768px.
### Mobile
On mobile, the footer size and layout are determined by the screen size and orientation. The mobile navigational footer can be adjusted for different breakpoints to support a range of mobile devices, including tablets and smartphones. The standard approach is 768px for tablets, 767px to 346px for devices between tablet and mobile, and 345px for mobile devices.
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation for navigation items.
- Ensure the links in navigation footers match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Ensure the copyright notice only contains the following details: copyright symbol, year of creation, name of author, rights statement.
- Follow guidance for labeling links. Learn more in [Link](https://design.visa.com/components/link).
---
# accessibility
---
title: Horizontal navigation
description: Menu placed at the top of a site that links to important pages or features.
meta_description: Find accessibility guidelines for horizontal navigation menus placed at the top of a site that links to important pages or features.
thumbnail: assets/components/horizontal-graphic.svg
tab_order: 2
---
## Best practices
**Note:** Horizontal navs are made up of multiple components. Follow guidelines for each of those.
- Use a native HTML `header` landmark. Any `nav` landmark elements used within, such as for the mobile menu, need to have unique and descriptive `aria-labels`.
- Don’t use the word “navigation” in the `aria-label`, as this will be announced automatically and be redundant for screen readers.
- Use `aria-current="page"` on the link which leads to the current page. Links in the vertical menu look like tabs and use CSS classes for tabs, but are not tabs and don’t have tab roles.
- Adjust the behaviors and breakpoints for horizontal navigation to fit your app.The horizontal nav should be responsive, so as the viewport gets narrower, content becomes hidden until the “hamburger” mobile menu is visible.
### Logos
Our library has a classname just for the application name in the horizontal navigation component. There is a component for the Visa logo that adjusts for the user’s high contrast settings.
- Ensure the logo has an accessible name or is inside a link with an accessible name with `aria-hidden="true"` on the svg.
- Use one of the library’s classes for high contrast with a custom logo. Choose between the class for light or dark foreground depending on the custom logo. Setting a contrasting background behind the brand logo ensures it will have maximum contrast in high contrast mode without a visible change in default contrast mode.
### Skip to main content link
The skip to main content link allows keyboard users to go directly to the main content of the page. This link is first in the DOM (unless there is a skip to login link). It appears when users land on the page and activates the tab key and is only visible when it receives keyboard focus. Activating the link moves focus to the `main`component.
Reference the [examples](https://design.visa.com/components/horizontal-navigation) to learn how to implement VPDS's skip-link styles.
### Skip to log in link
When navigation includes an account log in, the skip to log in link will appear when users press tab after page load and is tacked onto the top of the navigation bar. If user presses tab again, the user will be prompted with the skip to main content link.
## Keyboard controls
Keyboard actions and their corresponding behaviors for horizontal navigation
- Key: Activates the focused element.
- Key: Moves keyboard focus forwards to the next interactive element.
- Key: Moves keyboard focus backwards to the previous interactive element.
---
# index
---
title: Horizontal navigation
tab_title: Code
description: Menu placed at the top of a site that links to important pages or features.
meta_description: Get code for horizontal navigation menus placed at the top of a site that links to important pages or features.
thumbnail: assets/components/horizontal-graphic.svg
categories:
- navigation
- structure-and-layout
---
## Component Code Examples: horizontal-navigation
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the horizontal-navigation component
const component = parsed.components.find(c => c.name === 'horizontal-navigation');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `horizontal-navigation`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Horizontal navigation
description: Menu placed at the top of a site that links to important pages or features.
meta_description: Learn how to use horizontal navigation menus placed at the top of a site that links to important pages or features.
keywords: ["Horizontal menu", "horizontal navigation bar", "top navigation bar", "horizontal tab navigation", "row navigation", "UITabBarController (iOS)", "TabLayout (Android)"]
related:
components:
- vertical-navigation
- top-app-bar
content:
- information-architecture
tab_order: 1
---
The horizontal navigation component is a container enabling users to navigate a product or experience. It's a common type of menu that's usually placed at the top of a website.
Also known as: Horizontal menu, horizontal navigation bar, top navigation bar, horizontal tab navigation, row navigation, UITabBarController (iOS), TabLayout (Android).
{/* ANATOMY */}
## Anatomy
**A. Brand mark (optional):** Visual element representing Visa, a partner brand, or a fictitious brand associated with the product. **B. Application name (optional):** Label indicating the name of the application. **C. Navigation link (required):** Label indicating the destination of the link. **D. Nav menu (optional):** Menu that expands to show nested navigation items under a common heading or category. **E. Global search (optional):** Icon button prompting a global search bar to find content across the whole site or app. **F. Notification badge (optional):** Badge component that expands and collapses the notification tray. **G. User profile (optional):** Avatar component representing the current user’s account.
{/* USAGE */}
## Usage
When to use and when not to use different types of horizontal navigation components
- Component: For websites with a few main navigation items.
- When to use: If navigation items are lengthy or complex.
- Component: For websites with more navigation items that require extra space.
- When to use: If website navigation is limited and simple.
{/* BEST PRACTICES */}
## Best practices
- Reference [Application layouts](https://design.visa.com/patterns/application-layouts) for help deciding which navigation component is best for your use case.
- Ensure the order of the navigation items is consistent throughout the application so users aren’t confused.
- Avoid exceeding seven items or links in the main navigation.
- Consider making the brand mark and/or application name function as a link to the homepage of the experience.
- Ensure the navigation bar remains visible as the user scrolls.
- Follow all guidance found in [Search](https://design.visa.com/patterns/search), [Notification tray](https://design.visa.com/patterns/notification-tray), [Link](https://design.visa.com/components/link/usage), and [Avatar](https://design.visa.com/components/avatar/usage) when implementing those items in the navigation.
### Default horizontal navigation
The default horizontal navigation bar includes a single level of navigation items. Items can link directly to a page, dropdown to show nested items, or prompt related functions like a search bar or notification tray.
### Stacked horizontal navigation
The stacked navigation bar provides extra space for websites with more navigation items. If the default bar looks crowded in your app, the stacked version can help declutter the experience. The first level should contain navigation icons and functions such as user profile, search and notification, while the second level should contain page links.
### Nav menus
Nav menus refer to dropdowns in the navigation bar that expand to show nested links. The top-level label doesn’t link to a specific page, and doesn’t change to reflect the user’s selection.
**Note:** Nav menus are built using a modified dropdown menu component. For accessibility reasons, don’t use the default dropdown menu or replace it with a select component. Always consult with accessibility partners before modifying the behavior of any component.
### Icon usage
Icons can be used in navigation menus to make scanning easier and reinforce familiar ideas.
- Ensure icon usage applies to all navigation items within the same hierarchy level. For example, if you use icons for some L1 labels, they should be used in all L1 items.
- Omit icons for nested items, but if they’re necessary, ensure all items within the nested level has one.
{/* BEHAVIORS */}
## Behaviors
### Chevron direction
Visually differentiate expanded and collapsed sections using the chevron direction.
#### Collapsed
Collapsed sections should use the downwards-pointing chevron to indicate collapsed content can be expanded.
#### Expanded
Expanded sections should use the upwards-pointing chevron to indicate expanded content can be collapsed.
## Platform considerations
### Web
Horizontal navigation is responsive for web applications, and the behavior is modified based on screen size. For tablet and smaller web screens, horizontal navigation reduces to the 768px component. At this size, links are placed in a hamburger menu and the application name and brand mark are centered instead of left-aligned.
### Mobile
For mobile screens, the horizontal navigation bar turns into a [top app bar](https://design.visa.com/components/top-app-bar/usage) component instead, with the brand mark centered.
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation for navigation items.
- Ensure labels match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Limit labels to a few brief words to prevent unnecessary reflow.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# accessibility
---
title: Icons and illustrations
description: Explore Visa-branded and generic icon libraries that represent core functions, ideas, and content.
meta_description: Find accessibility guidelines for Visa-branded and generic icon libraries that represent core functions, ideas, and content.
thumbnail: assets/components/icons/icons.svg
tab_title: Accessibility
tab_order: 3
---
## Best practices
### Icons
**Note:** Nova icons include `aria-hidden="true"` by default, which hides them from screen readers.
- Use an `aria-label` along with `aria-hidden="false"` attributes on the svg when needed to give it an accessible name for a screen reader.
- Ensure icon buttons have an `aria-label`, although the icon it contains should not to avoid duplicate announcements.
- Edit the SVG code and add appropriate attributes to hard-coded custom icons, as a hardcoded `fill` color won’t adjust in Windows high contrast mode.
### Images
- Ensure images using an `img` element have an `alt=""` attribute.
- Ensure purely decorative images have an empty `alt` value so they’re ignored by screen readers.
- Ensure images that add meaning have an `alt` value with a succinct description and a color contrast ratio of at least 3:1.
- Use extreme caution when placing images or background images behind text. Remember that the screen will shift responsively for different screen sizes which will reposition items.
- Perform manual testing when needed as automated testing generally won’t test contrast between an image and foreground text.
### Right to left languages
- Use VPDS’s rtl class for “back”, “forward”, “previous”, and “next” arrows for left-to-right languages. Also be aware of directional icons including chevrons, “opens in a new window”, or “maximize tiny”.
- Ensure images that are directional or show progress adjust for rtl languages, as VPDS doesn’t have an RTL class for images.
---
# code
---
title: Icons and illustrations
description: Explore Visa-branded and generic icon libraries that represent core functions, ideas, and content.
meta_description: Get code for Visa-branded and generic icon libraries that represent core functions, ideas, and content.
tab_title: Code
tab_order: 1
---
## Component Code Examples: icon
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the icon component
const component = parsed.components.find(c => c.name === 'icon');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `icon`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Icons and illustrations
description: Explore Visa-branded and generic icon libraries that represent core functions, ideas, and content.
thumbnail: assets/components/icons/icons.svg
tab_title: Icons library
page_size: "full-width"
show_table_of_contents: false
---
---
# usage
---
title: Icons and illustrations
description: Explore Visa-branded and generic icon libraries that represent core functions, ideas, and content.
meta_description: Learn how to use Visa-branded and generic icon libraries that represent core functions, ideas, and content.
tab_title: Usage
tab_order: 2
---
Icons are visual representations of core ideas, functions, or content. The Visa Product Design System currently supports two sets of icons: Visa-branded and generic for all other uses.
Creating on-brand illustrations and visuals is key to designing cohesive, familiar product experiences. Using our brand symbol as the foundation, we extended our iconic color ratio into a unique icon and illustration system. Our new system is consistent and cohesive across our icons, enriched icons, and illustrations. The icons and enriched icons can scale into our illustration style to tell a more comprehensive story. These visual elements broaden our visual language to help us effectively communicate stories, actions, and ideas.
## Anatomy
**A. Tiny resolution (16x16):** Simplified icons placed within components or areas with limited space. **B. Low resolution (24x24):** Icons with more detail placed within components when space permits. **C. High resolution (48x48):** Detailed icons placed outside components to add visual interest and meaning. **D. Illustration:** Larger visuals used to demonstrate complex ideas, add visual interest, or show processes.
## Icon best practices
- Use the Visa icon set for Visa-branded products and the generic set for fictitious or partner brands. Reference [Fictitious brands and user aliases (internal only)](https://bookmarks.visa.com/vpds-fictitious-brands) for more information.
- Use icons only when they add meaning, especially when used within interactive components.
- Avoid relying solely on icons to convey meaning unless they are universally understood by most users.
- Use the predefined or recommended icon sizes that correspond to each specific component design.
## Visa icons
The icon set for Visa-branded products is designed to mirror Visa's original brand assets as closely as possible. Any additions should follow brand guidelines. Existing icons and brand guidelines are available for review on [Visa Creative Asset Manager (VCAM)](https://bookmarks.visa.com/vpds-visa-creative-asset-manager-vcam). First-time users must contact Visa Brand & Marketing Governance or visit [Insite (internal only)](https://bookmarks.visa.com/vpds-insite-tools-brand) to set up an account.
- Use single-color icons for most use cases.
- Use two-color icons when appropriate for dark surfaces.
#### Design specifications
- Designed with a consistent 2px stroke width, suitable for all canvas sizes
- Incorporates open shapes to provide a unique and distinctive style
- Uses a corner radius that’s typically set at zero, although it may be adjusted depending on specific requirements
- Visit the [Visa brand guidelines](https://bookmarks.visa.com/vpds-visa-brand-identity-guide) for more details on design specifications
## Generic icons
Generic icons should be used for mockups or any product that does not specifically represent the Visa brand. This icon set originated from Vault, the previous iteration of the design system before Nova.
- Use single-color icons all generic use cases.
#### Design specifications
- Designed with a 2px stroke width for use on tiny and low-resolution canvas sizes
- High-res icons combine 2px stroke with 3px stroke width used for details
- Uses closed shapes to create clear and distinct icons
- Uses a corner radius that’s set at 1px for tiny and low-resolution canvases, and 2px for high-resolution canvases
## Icon size
To provide flexibility, each icon is designed in three different sizes within each set. Although all versions of an icon share the same basic design, additional details are incorporated as the canvas size increases to ensure they maintain clarity and visibility.
### Tiny resolution
Tiny-resolution icons are the smallest and simplest. They’re designed on a 16px by 16px canvas. Tiny icons are referred to as “UI icons” in the [Visa Brand Identity Guide](https://bookmarks.visa.com/vpds-visa-brand-identity-guide).
- Many components within the design system use the tiny icon size. This includes tabs, navigation components, badges, and more.
### Low resolution
Low-resolution icons have more detail. They’re designed on a 24px by 24px canvas. Low-resolution icons are referred to as “Icons” in the [Visa Brand Identity Guide](https://bookmarks.visa.com/vpds-visa-brand-identity-guide).
- When space permits, it's recommended to use the low-resolution icons, as they communicate the purpose more clearly when compared to smaller versions.
### High resolution
High-resolution icons include additional details to provide visual interest. They’re designed on a 48px by 48px canvas. High-resolution icons are referred to as “Enriched icons” in the [Visa Brand Identity Guide](https://bookmarks.visa.com/vpds-visa-brand-identity-guide).
- Use on content cards or for other, non-component use cases where space allows and visual interest is needed.
## Illustration best practices
Product teams must reference Visa’s brand guidelines throughout the design and development process to make informed decisions. Brand offers documentation for illustration guidance in the Brand Identity Asset Library. In the future, we may offer an extension of this guidance specific to user experiences.
Refer to the [Visa Brand Identity Guide](https://bookmarks.visa.com/vpds-visa-brand-identity-guide) on Visa Creative Asset Manager (VCAM) to learn more. First-time users on VCAM must contact Visa Brand & Marketing Governance or visit [Insite (internal only)](https://bookmarks.visa.com/vpds-insite-access-vcam) to set up an account.
---
# index
---
title: Components
description: Get usage, specs, and accessibility guidance for the building blocks of our system.
meta_description: Discover our components that are the building blocks of VPDS. These reusable elements reduce repetitive work and enhance consistency across Visa products.
page_size: large
show_table_of_contents: false
---
---
# accessibility
---
title: Input
description: Text fields that enable users to enter free-form content.
meta_description: Find accessibility guidelines for text fields that enable users to enter free-form content.
thumbnail: assets/components/input-graphic.svg
tab_order: 2
---
## Best practices
**Note:** VPDS treats a `textarea` element like an input. See the examples for “multiline” inputs.
- Ensure all inputs have an `id` and a label with a matching `for` attribute.
- Link additional text using `aria-describedby`.
- Always indicate required fields in the label text or with an asterisk per [usage guidelines](https://design.visa.com/components/input/usage#optional-vs-required-labels). Additionally, it may have a `required` attribute.
## Keyboard controls
Keyboard shortcuts commonly for editing text should be maintained unless uniquely specified.
### Moving cursor
Keyboard actions and their corresponding behaviors for moving cursor
- Key: Navigates and moves the cursor within the text field.
- Key: Moves cursor to the next word.
- Key: Moves cursor to the previous word.
- Key: Scrolls text area up or moves cursor to the start of the line (depends on app).
- Key: Scrolls text area down or moves cursor to the end of the line (depends on app).
- Key: Moves cursor to the end of the line.
- Key: Moves cursor to the start of the line.
### Cut, paste, & undo
Keyboard actions and their corresponding behaviors for cut, paste, and undo
- Key: Cuts selected text.
- Key: Cuts selected text.
- Key: Copies selected text.
- Key: Copies selected text.
- Key: Pastes selected text.
- Key: Pastes selected text.
- Key: Un-does last text.
- Key: Re-does last text.
- Key: Re-does last text.
### Delete
Keyboard actions and their corresponding behaviors for delete
- Key: Deletes forward to word break.
- Key: Delete back to word break.
### Selecting text
Keyboard actions and their corresponding behaviors for selecting text
- Key: Selects all text.
- Key: Extends selection one character to the right.
- Key: Extends selection one character to the left.
- Key: Extends selection down one line (in multi-line use case).
- Key: Extends selection up one line.
- Key: Extends selection to the beginning of the line.
- Key: Extends selection to the end of the line.
- Key: Extends selection to the next word break.
- Key: Extends selection to the previous word break.
- Key: Extends selection to below paragraph.
- Key: Extends selection to above paragraph.
- Key: Extends selection to the top of the text.
- Key: Extends selection to the bottom of the text.
### Navigation
Keyboard actions and their corresponding behaviors for navigation
- Key: Moves to next input field.
- Key: Moves to previous input field.
### Other
Keyboard actions and their corresponding behaviors for manual line break (in multi-line use case)
- Key: Adds manual line break (in multi-line use case).
---
# index
---
title: Input
tab_title: Code
thumbnail: assets/components/input-graphic.svg
description: Text fields that enable users to enter free-form content.
meta_description: Get code for text fields that enable users to enter free-form content.
categories:
- inputs
---
## Component Code Examples: input
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the input component
const component = parsed.components.find(c => c.name === 'input');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `input`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Input
description: Text fields that enable users to enter free-form content.
meta_description: Learn how to use text fields that enable users to enter free-form content.
keywords: ["Text field", "input field", "text input", "text box", "form field", "text area", "UITextField (iOS)", "EditText (Android)"]
related:
patterns:
- search
- forms
tab_order: 1
---
{/* INTRO */}
Input fields allow users to enter free-form text or data. They are commonly used across long and short forms but can also appear as standalone elements like search bars.
Also known as: Text field, input field, text input, text box, form field, text area, UITextField (iOS), EditText (Android).
{/* ANATOMY */}
## Anatomy
**A. Label (required):** Text indicating the purpose of the field and if the information is required.
**B. Input (required):** Text field enabling users to enter the requested information or data.
**C. UI icon button (optional):** Button controls relevant to the field. Visit [Button](https://design.visa.com/components/button) to learn more.
**D. Leading icon (optional):** Non-actionable icon at the beginning of the field indicating the purpose.
**E. Inline message (optional):** Text communicating format requirements or relevant guidance.
**F. Vertical scroll (optional):** Bar allowing users to scroll through long, multi-line entries.
**G. Corner drag (optional):** Visual indicator communicating that the field may be expanded by dragging.
**H. Character counter (optional):** Fraction indicating the number of current and maximum allowed characters.
{/* USAGE */}
## Usage
When to use and when not to use different types of inputs
- Component: If the expected entry is a single line of text.
For unique information that can’t be predicted with preset options.
For memorable data that can be entered faster in a free-form format.
- When to use: If the expected entry is more than one line, use multi-line instead.
For predetermined options, use select components, such as [Select (native)](https://design.visa.com/components/select) or [Combobox](https://design.visa.com/components/combobox).
- Component: For single-use passcodes for verification purposes
- When to use: For entries other than a one-time passcode.
- Component: If the expected entry is more than a single line and spans multiple lines.
- When to use: If the expected input is a single-line response, use default instead.
- Component: To indicate the expected entry is a unit of measurement or currency.
- When to use: In place of leading or trailing icons or inputs without a unit of measurement or currency.
- Component: For search where users can enter information and discover results.
- When to use: For fields that do not return search results.
{/* BEST PRACTICES */}
## Best practices
- Ensure the length of the input field matches the expected entry length.
- Order fields to match user expectations. For example, “First name” followed by “Last name”.
- Learn more about using input fields in forms in [Forms](https://design.visa.com/patterns/forms).
{/* DO + DON'T */}
{/* LEADING ICONS */}
### Leading icons
Leading icons are placed at the beginning of an input field and are not interactive elements. They visually indicate the type of information required, such as a mail icon for an email field.
- Use one leading icon per input field as multiple icons can confuse users.
- Use icons that are universally understood and directly correlate to expected entry.
- Use leading icons consistently across experiences to help users learn and predict behavior.
{/* UI ICON BUTTONS */}
### UI icon buttons
UI icon buttons are placed at the end of an input field and are visual representations of actions the user can take.
- Only use one UI icon button per input field to ensure users have a single, clear action.
- Always place UI icon buttons in the trailing position of an input field.
- Ensure icons clearly and intuitively indicate the action they represent.
#### Show/hide input value
Show/hide is an optional feature that allows users to display or hide inputted data, such as passwords. The icon button shows the opposite of the current state of the input display.
- Use the show/hide feature wisely, especially for sensitive data. By default, passwords should be hidden.
#### Combobox
Chevron down icon is a UI icon button that prompts an option menu. The icon shows the direction the menu will expand when selected. For more info, reference [Combobox](https://design.visa.com/components/combobox).
- Ensure the chevron points downwards when the menu is collapsed and upwards when the menu is expanded.
#### Information icon button
Information icon is a UI icon button that prompts an inline message with additional guidance when selected. For more information, reference [Card input](https://design.visa.com/patterns/card-input).
- Ensure the icon is universally recognized as an information symbol, usually a lowercase 'i' in a circle.
#### Date selector
Calendar icon is a UI icon button that prompts a dropdown menu allowing users to select a date instead of typing. For more information, reference [Date selector](https://design.visa.com/components/date-selector).
- Always provide users with the option to enter the date in addition to selecting the date within the menu or modal.
{/* PREFIX AND SUFFIX USAGE */}
### Prefix and suffix usage
Prefix and suffix components are input fields with fixed expected data formats. The prefix-suffix component type automatically formats input to matches the expected type. For example, inputs with a “$” only accept monetary values and can auto format to include decimal points or commas in certain regions.
Follow regional expectations when formatting currencies and when considering which units of measurement to use. Learn more in [Grammar and punctuation](https://design.visa.com/content/grammar).
- Only use a prefix or suffix for inputs that require specific formatting, but don’t over use them.
- Use universally recognized currency symbols that are easy to understand and distinguish from the input value.
- Autoformat as the user types, but always ensure validation aligns with expected prefix or suffix symbols or codes.
#### Prefix
Prefixes are commonly used to indicate currencies, such as “$” or “€” and international international phone codes.
- Consider regional norms for currency formatting. This includes the placement of currency symbols (before or after the value) and use of decimal points or commas as thousands separators, which differ across countries.
#### Suffix
Suffixes are commonly used to indicate the unit of measurement or data format expected in the field.
- Adhere to regional conventions when it comes to measurement systems. For example, some countries use the metric system (kilometers, kilograms, liters), while others use the imperial system (miles, pounds, gallons).
{/* HIDDEN LABELS */}
### Hidden labels
Typically, input fields should always include a label. However, in certain contexts such as search fields, the purpose of an input field can be understood without a visible label. In these cases, remember to include the label within the code to support screen readers and speech input software.
Generally, there are two methods used to provide context when labels are hidden. It's important to choose a method and apply it consistently across your experiences.
#### Text and icon buttons
The most common method is positioning a button (text or icon) beside the input field to provide context.
- Use clear labels indicating the outcome for text buttons.
- Use icons for icon buttons that are easy to recognize and understand. Visit [Button](https://design.visa.com/components/button) to learn more.
#### Leading icons and placeholder text
In some scenarios, using an icon and placeholder text ensures there are two visual indicators to provide context.
- Use placeholder text as a temporary label in addition to the leading icon.
- Use icons that are easy to recognize and understand.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
{/* BEHAVIORS */}
## Behaviors
Input fields have optional behaviors and features you may implement based on use case. Learn about these below.
{/* AUTOCOMPLETE */}
### Autocomplete
Autocomplete is a feature that predicts a user's input based on previous entries or a predefined list. As a user types within an autocomplete-enabled field, the system presents a dropdown of suggestions. Selecting a suggestion fills the entire input field with that choice. Autocomplete is often used in form fields such as name, email, and address, and can also be used in search fields. However, it's often more effective and user-friendly to use autosuggest in search fields.
**Note:** Autocomplete is typically enabled in most browsers by default. However, this depends on user settings or how your browser is managed by your organization. The visual representation and functionality of autocomplete formats can vary depending on the browser. Different browsers handle autocomplete differently, from the way they store and suggest input data to the visual presentation of suggestions. The example below is a general representation of the functionality.
- Disable autocomplete for fields that contain sensitive information, like credit card numbers or one-time passcodes.
- Consider styling limitations, for example the autocomplete dropdown provided by browsers has limited styling options.
- Test autocomplete-enabled fields in various browsers to to ensure it works consistently and effectively across browsers.
{/* AUTOSUGGEST */}
### Autosuggest
Autosuggest, like autocomplete, suggests options based on user input. However, it generates suggestions dynamically from a database or possible inputs, not just past entries. Autosuggest is commonly used in search fields for suggesting search terms or products. Remember, different applications handle autosuggest differently, from suggestion generation and presentation to dropdown menu interaction.
**Note:** Implementing autosuggest requires significant development effort compared to native autocomplete. Its effectiveness relies on having relevant, quickly retrievable data. Components do not include search functionality by default. If search-like behavior is needed, this must be considered and implemented separately, which may require significant and additional development effort or potentially re-architecting the application.
- Order suggestions intuitively by listing the most likely options first, common selections, or based on previous interaction.
- Limit options between 5 and 10 to avoid overwhelming users with too many suggestions.
- Test autosuggest for consistency in function, responsiveness, result accuracy, and visual presentation across browsers.
{/* CHARACTER COUNTER */}
### Character counter
Character counters provide users with real-time feedback of the number of remaining characters and indicate when the limit has been reached. This feature is often used with multi-line or text area fields and helps users plan their entry accordingly.
- Avoid imposing arbitrary character limits. Instead, set limits that align with the anticipated length of the user's entry or that are based on the actual requirements of the field or technical constraints.
{/* DO + DON'T */}
{/* CLEAR TEXT BUTTON */}
### Clear text button
Clear text button within input is a user interface (UI) element that allows users to quickly and easily erase all the text in a field. This is typically represented by a small 'x' or similar icon within the field itself and facilitates quick erasure for new entries, such as in search fields.
- Only include a clear button only when useful for resetting to a blank state, such as search fields.
- Avoid clear buttons for short input fields like age or zip code, where users can easily delete characters.
- Provide immediate feedback by instantly clearing the text field when button is selected.
- If possible, provide a way to undo the action, in case the button is selected accidentally.
{/* DO + DON'T */}
{/* FLEXIBLE INPUT */}
### Flexible input
Flexible input, which allows users to input information in a variety of formats, enhances user-friendly experiences. It eases cognitive load, boosts efficiency, and caters to regional preferences. For example, when asking for a phone number, accept the number with or without dashes, parentheses, or country codes. Similarly, for a date field, accept input in different formats like "MM/DD/YYYY", "DD-MM-YYYY", "Month Day, Year". Learn more about formatting dates in [Grammar and punctuation](https://design.visa.com/content/grammar#date-and-time).
- Work with developers early and often to ensure robust validation is in place to confirm data is in an acceptable format.
- Test all possible input scenarios to ensure your flexible input works as expected and handles edge cases gracefully.
- Be mindful of the potential performance impact as each input variation requires different processing and validation logic.
{/* CONTENT */}
## Content
- Use simple language—avoid abbreviations or jargon.
- Use sentence case, except for proper nouns or acronyms.nput fields have optional behaviors and features you may implement based on use case. Learn about these below.
{/* LABELS */}
### Labels
- Limit labels to a maximum of three words.
- Ensure labels accurately represent the expected input to reduce errors.
- Use parallel structure across labels, using either nouns like "Email" or verbs like "Enter email".
{/* LABELS */}
### Inline message
- Limit all inline messages (including errors) to one to two short sentences with punctuation.
- Use inline messages to provide additional guidance such as format or specific syntax or values to help avoid errors.
- Provide concise, descriptive, and helpful guidance about the field's usage and necessity, avoiding technical jargon.
#### Inline error message
- Use inline error messages to draw attention and to errors without causing frustration.
- Provide clear, prescriptive guidance on correcting the error. Avoid redirecting users to another page to fix it.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
{/* DO + DON'T */}
---
# accessibility
---
title: Link
description: Text-based navigation elements that take users to another destination.
meta_description: Find accessibility guidelines for text-based navigation elements that take users to another destination.
thumbnail: assets/components/link-graphic.svg
tab_order: 2
---
## Best practices
- Use an `aria-label` when the link text alone does not convey enough information to a screen reader.
- Ensure `aria-labels` include context to indicate where the link leads, especially if the link is visually grouped in a template. For example, use “Learn more about [something]”.
- Ensure the `aria-label` always starts with the visible link text.
- When a link opens or downloads other formats (e.g., .pdf, .mp3), ensure the label indicates this, such as `aria-label="[link text] (file type)"`.
- Indicate when links open in new tabs or pages using `aria-label="[link text] (opens in a new tab)"`
- Use `rel="noreferrer noopener"` on external links for added security.
## Keyboard controls
Keyboard actions and their corresponding behaviors for links
- Key: Activates link.
---
# index
---
title: Link
tab_title: Code
description: Text-based navigation elements that take users to another destination.
meta_description: Get code for text-based navigation elements that take users to another destination.
thumbnail: assets/components/link-graphic.svg
---
## Component Code Examples: link
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the link component
const component = parsed.components.find(c => c.name === 'link');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `link`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Link
description: Text-based navigation elements that take users to another destination.
meta_description: Learn how to use text-based navigation elements that take users to another destination.
keywords: ["Hyperlink", "anchor link"]
related:
components:
- button
- anchor-link-menu
tab_order: 1
---
{/* INTRO */}
Links are text-based navigational elements that take users to another destination. They may appear as standalone elements or inline with text. Links are commonly used in menus, navigation components, panels, and resources like FAQs.
Also known as: Hyperlink, anchor link.
## Anatomy
**A. Leading icon (optional):** Icon located before the link text used to enhance the meaning of the link.
**B. Destination label (required):** Text indicating where the link will take the user.
**C. Trailing icon (optional):** Icon located after link to indicate the meaning of the text.
**D. Underline (optional):** Line under link text to enhance and indicate a link is present.
## Usage
When to use and when not to use different types of links
- Component: For links that appear outside of sentences or paragraphs.
- When to use: To prompt an action or event. Use a [Button](https://design.visa.com/components/button) instead.
- Component: For links that appear within sentences or paragraphs.
- When to use: To prompt an action or event. Use a [Button](https://design.visa.com/components/button) instead.
In native mobile applications.
## Best practices
- Only use links as navigation elements, not for actions. Use a [Button](https://design.visa.com/components/button) to perform actions.
- Use consistent styling for all links across your experience to ensure users recognize them.
- Ensure icons and link text are the same color.
- Ensure users can select a link anywhere on the link text or associated icon.
- Always use an icon to indicate if a link opens in a new tab. Reference [VGAR INT-5](https://bookmarks.visa.com/VGAR-INT-5) for more information.
- Ensure the visible link text closely matches the name of the resource being linked to.
- Ensure links are clearly identifiable by pairing text color with an icon or underline. This does not apply to navigation components like horizontal or vertical navigation, anchor link menus, and footers, where text color alone suffices.
{/* ----------- DO + DON'T ----------*/}
{/* ----------- STANDALONE LINKS ----------*/}
### Standalone links
Standalone links are interactive elements placed outside of body text. They’re often used in menus, footers, and sidebars for quick access to frequently used features within the site or application, or in resource lists to provide access to external sites.
{/* ----------- DO + DON'T ----------*/}
{/* ----------- INLINE LINKS ----------*/}
### Inline links
Inline links are interactive elements embedded within body text. Inline links are commonly used to provide direct access to additional information or resources without disrupting the flow of the content.
- Limit the number of inline links within a paragraph to avoid overwhelming users.
- Ensure inline links are relevant to the surrounding content.
{/* ----------- DO + DON'T ----------*/}
{/* ----------- EXTERNAL LINKS ----------*/}
### External links
Users should be aware of, and have control over, whether they are leaving their current website. To ensure users have choice, make sure to indicate when a link leads to an external website.
Generally, there are two methods to inform users that links lead to external sites.
{/* ----------- MAXIMIZE ICON + NO ICON ----------*/}
#### Maximize icon
The most common method is pairing a maximize icon with links to external sites.
- For standalone links without supporting content, use a maximize icon to indicate the link leads to a new website.
- Use the “maximize-link” icon to ensure the line height of the link text is aligned with the icon.
#### No icon
In some scenarios, the link label and surrounding content will provide enough context.
- For standalone links, use labels with the name of the destination when omitting the maximize icon.
- For inline links, use surrounding content to indicate the link destination without disrupting the flow of content.
{/* ----------- NEW WINDOW OR TAB ----------*/}
### New window or tab
Generally, avoid opening new windows or tabs. Instead, open links in the current window to avoid disorienting users and causing accessibility problems. Only open a new tab or window when directing users to information that will help them complete a task.
- Always use an icon to indicate when a link opens in a new window or tab. This is especially important for assistive technology users, as new tabs can be disruptive or disorienting. For more information, reference [VGAR INT-5](https://bookmarks.visa.com/VGAR-INT-5).
{/* ----------- "BACK" TO LINKS ----------*/}
### "Back to" links
A "Back to" link can be used as an extra navigation element to take users back one level in the site hierarchy. “Back to” links are generally paired with a backwards-facing arrow.
- Always indicate where the “back to” link will take users.
{/* ----------- DO & DONT'S ----------*/}
## Behaviors
### Styling and coding buttons and links
In general, buttons should be used for in-page actions and links should be used as navigational tools, like leaving a page. Whenever possible, match the visual styling of these elements with their coded and user-expected behavior. However, buttons and links may be styled like one another in some cases. Learn about these exceptions below.
#### Button coded as links
Buttons may be coded as links but styled as buttons when necessary. For example, an icon button may be appropriate when linking to a shopping cart.Use the arrow icon whenever possible as a visual cue that selecting will navigate to another page.
#### Link coded as buttons
Links may be coded as buttons but styled as links when necessary. For example, buttons may be styled as links when information will be presented in an overlay or dialog.Avoid underlining links coded as buttons, as this style is reserved for links, not buttons.
## Content
- Use simple language—avoid abbreviations or jargon.
- Avoid verbs that focus on senses to include all users. For example, use “Visit cart,” instead of “View cart”.
- Use at least two but no more than five words in link labels, unless linking the name of a resource or publication.
- Avoid using articles such as “a,” “an,” or “the”.
- Avoid using “click here,” or “here” as link text.
- Don’t include "link" in link text.
### Link formulas
- Combine action or command verbs with nouns to make labels specific.
- [verb] + [noun] is useful for most product cases.
- [verb] + [adverb] is typically used for marketing and promotions.
- Only use single word labels for common navigational actions such as “Home,” “Profile,” or “Settings”.
{/* ----------- DO & DONT'S ----------*/}
### Standalone links
- Use sentence case except for acronyms or proper nouns, such as resource titles.
{/* ----------- DO & DONT'S ----------*/}
### Inline links
- Follow the capitalization structure of text surrounding inline links. Only capitalize proper nouns, acronyms, or titles.
{/* ----------- DO & DONT'S ----------*/}
## Platform considerations
### Mobile
Avoid using inline links in native mobile apps, as they can be difficult to select on small screens. If your use case requires inline links in a native mobile app, ensure you implement sufficient touch targets.
---
# accessibility
---
title: List item
description: Individual containers that can be grouped to create lists in mobile apps.
meta_description: Get code for individual containers that can be grouped to create lists in mobile apps.
thumbnail: assets/components/list-item-graphic.svg
tab_order: 3
---
## Best practices
An HTML ordered `ol` or unordered `ul` list should have only list items `li` as direct children, and list items should have only lists as direct parents. It’s a common mistake to place other HTML elements such as `div`s as direct children of lists, especially as containers for conditional content. List items may have HTML elements within them, including other lists.
For Angular and React, use a container that doesn’t render such as `ng-container` or `<>>`.
- Use semantic HTML and ARIA roles for lists and list items so that assistive technologies recognize them as part of a list structure. Lists are landmarks and can be used for keyboard navigation. Screen readers announce the item number in ordered lists, and can announce the total number of items in lists.
- If a list item is interactive, its accessible name should match its visible label. Focus should move through list items in a meaningful, logical order.
- Include appropriate text alternatives for icons or images within a list item.
- Don’t use list markers to convey important information. They’re pseudo-elements, meaning they aren’t focusable or clickable and are inaccessible to screen readers.
- Use [logical CSS](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values) for the contents of a list item to ensure it switches seamlessly between right-to-left (RTL) and left-to-right (LTR) modes.
---
# index
---
title: List item
tab_title: Code
description: Individual containers that can be grouped to create lists in mobile apps.
meta_description: Get code for individual containers that can be grouped to create lists in mobile apps.
thumbnail: assets/components/list-item-graphic.svg
---
## Component Code Examples: list-item
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the list-item component
const component = parsed.components.find(c => c.name === 'list-item');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `list-item`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: List item
description: Individual containers that can be grouped to create lists in mobile apps.
meta_description: Learn how to use individual containers that can be grouped to create lists in mobile apps.
keywords: ["List element", "list entry", "UITableViewCell (iOS)", "View (Android)"]
related:
components:
- accordion
- checkbox
- radio
- switch
tab_order: 1
---
A list item is an individual container used to represent options in a list within mobile apps. List items can vary functionally and visually based on the needs of the app or interface.
Also known as: List element, list entry, UITableViewCell (iOS), View (Android).
## Anatomy
**A. List title (optional):** Label used to group list items.
**B. Hyperlink (optional):** Link that navigates users to a new screen, often to show more content.
**C. Leading visual element (optional):** Element, such as avatar, icon, or image, used to represent the list item.
**D. List item (required):** Label representing the individual list item option.
**E. Divider (optional):** Visual element separating the items in a list.
## Usage
When to use and when not to use different types of list items
- Component: To display a simple list of options or information.
- When to use: If the list content needs to be nested more than one level deep and becomes overly complex or lengthy.
- Component: If each item in the list navigates to a different page or section.
- When to use: If the list content is simple and doesn’t need to be expanded.
- Component: To allow users to turn on or off certain options in the list.
For settings or preference interfaces.
- When to use: To switch between alternate options or content views. Use a [toggle](https://design.visa.com/components/toggle-button) instead.
- Component: If users can select multiple options from the list.
- When to use: If options on the list are mutually exclusive.
- Component: If users can select only one option from the list.
- When to use: If users may need to select more than one option from the list.
## Best practices
- Organize content logically and predictably to help users scan information easily.
- Use icons, avatars, or images consistently to enhance the meaning of list items or to provide additional context.
- Consider implementing a scroll bar once the list reaches a maximum height to allow access to all options without overwhelming the user.
### Static list item
Static list items are options within a list that users can’t interact with. They only display information and don’t give users the option to select or change the values.
- Use static list items to present data that doesn’t need to be changed.
### Clickthrough list item
Clickthrough list items act as buttons or links that navigate users to a new page or open additional content upon selection.
- Clearly indicate that options lead to more information by using visual cues like the arrow icon.
- Ensure the entire list item container is clickable, not just the trailing icon.
- Follow all [Link guidance](https://design.visa.com/components/link) for implementing clickthrough list items.
### Switch list item
Switch list items enable users to toggle between two states, usually “on” or “off”. They’re typically used for settings or features that can enabled or disabled.
- Avoid using switches for irreversible actions.
- Follow all [Switch guidance](https://design.visa.com/components/switch) for implementing switch list items.
### Checkbox list item
Checkbox list items allow users to select multiple options from a list. Each list item has an associated checkbox that users can check or uncheck. Use checkboxes for multi-select scenarios where users might want to choose more than one item.
- Provide immediate visual feedback when a checkbox is selected or deselected to confirm the user's action.
- Follow all [Checkbox guidance](https://design.visa.com/components/checkbox) for implementing checkbox list items.
### Radio list item
Radio list items enable users to select only one option from a list of options. Each item has an associated radio button and selecting one option deselects any previously selected option.
- Clearly indicate the selected state of a radio list item.
- Follow all [Radio guidance](https://design.visa.com/components/radio) for implementing radio list items.
## Platform considerations
### Web
List items can also be utilized in web and responsive web applications. Ensure that list items adapt to different screen sizes by allowing option labels to reflow with the container.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Avoid using long lines of text, as it decreases readability.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Labels
- Limit labels to three to five words when possible.
- Be consistent when using plural language or “(s)” in field labels. For example, use “Card type,” “Card types,” or “Card type(s)” consistently. If using “(s),”, use the asterisk method over “(required)” to keep labels concise.
- Avoid using unnecessary articles like “the” or “an,” unless they’re included in the proper name of a product or service.
- Use parallel structure across field labels, using either nouns like "Services" or verbs like "Select a service". Learn more about parallel structure in [Grammar and punctuation](https://design.visa.com/content/grammar#parallel-structure).
---
# accessibility
---
title: Listbox
tab_order: 2
description: Container that displays a list of items available for selection.
meta_description: Find accessibility guidelines for containers that display a list of items available for selection.
thumbnail: assets/components/select-listbox-graphic.svg
---
## Best practices
**Note:** VPDS Listbox components are used within other components such as [Multiselect](https://design.visa.com/components/multiselect) and [Combobox](https://design.visa.com/components/combobox). [Dropdown menu](https://design.visa.com/components/dropdown-menu) components aren't listboxes. They use listbox CSS classes but function differently and have different roles.
An element with `role="option"` cannot have any form controls within it. In some implementations, the “checkboxes” within multi-select listboxes are spans styled to look like checkboxes.
- Use the up and down arrow keys to cycle through the options. Using the Tab key will move the focus to the next focusable element after the listbox.
## Keyboard controls
### All vertical oriented listbox
Keyboard actions and their corresponding behaviors for vertical oriented listbox
- Key: Navigates to an item.
- Key: Moves the focus to the first listbox item. Recommend for lists with more than five items.
- Key: Moves the focus to the last listbox item. Recommend for lists with more than five items.
- Key: Moves to the next element in the form. Persist and maintain the view within the listbox when focus moves to the next element.
- Key: Moves focus onto the previously selected item. Note that this function is only true when the keyboard focus is one element next to listbox.
### Multi-select listbox
Keyboard actions and their corresponding behaviors for multi-select listbox
- Key: Checks/unchecks the checkbox when the component is in focus.
- Key: Selects consecutive items from the most recently selected item to the focused item.
- Key: Moves the focus to and toggles the selected state of the previous item.
- Key: Moves the focus to and toggles the selected state of the next item.
---
# index
---
title: Listbox
tab_title: Code
description: Container that displays a list of items available for selection.
meta_description: Get code for containers that display a list of items available for selection.
thumbnail: assets/components/select-listbox-graphic.svg
categories:
- actions
- selection-controls
---
## Component Code Examples: listbox
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the listbox component
const component = parsed.components.find(c => c.name === 'listbox');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `listbox`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Listbox
description: Container that displays a list of items available for selection.
meta_description: Learn how to use containers that display a list of items available for selection.
keywords: ["List", "menu", "dropdown", "UIPickerView (iOS)", "Spinner (Android)", "Menu (Android)", "MenuItem (Android)"]
related:
components:
- combobox
- dropdown-menu
tab_order: 1
---
Listboxes are a container that organize and display items in a list format. They enable users to select one or more items in a list, navigate to a page, or perform an action. They are a key element in user interfaces and form the foundation for select menus like [Combobox](https://design.visa.com/components/combobox) and [Multiselect](https://design.visa.com/components/multiselect), as well as [Horizontal navigation](https://design.visa.com/components/horizontal-navigation) and [Dropdown menus](https://design.visa.com/components/dropdown-menu) to perform actions.
Also known as: List, menu, dropdown, UIPickerView (iOS), Spinner (Android), Menu (Android), MenuItem (Android).
## Anatomy
**A. Label (required):** Text summarizing the items available for selection.
**B. Menu (required):** Container displaying the list of items that includes scrollbar.
**C. Scrollbar (optional):** Control allowing users to navigate long menus.
**D. Item (required):** Selectable text representing a single item.
**E. Inline message (optional):** Brief text describing the label in more detail.
## Best practices
- Always keep the context in which the listbox is being used in mind to ensure the best possible user experience.
## Usage
When to use and when not to use different types of listboxes
- Component: To present a list of items when the user can only select one.
For long lists where all items can't be viewed at once or require scrolling.
- When to use: For fewer than four items or short lists that can be viewed without scrolling. Use a [radio button group](https://design.visa.com/components/radio)instead.
For long lists when users would benefit from entering text to filter or search the list items. Use a [combobox group](https://design.visa.com/components/combobox) instead.
If space is limited and displaying items in a collapsible menu would help. Use [select (native)](https://design.visa.com/components/select) instead.
To present a list of actions. Use a [dropdown menu](https://design.visa.com/components/dropdown-menu) instead.
- Component: To present a list of items where the user can select one or multiple.
For long lists where all items can't be viewed at once or require scrolling.
- When to use: For fewer than four items or short lists where all items can be viewed without scrolling. Use a [checkbox button group](https://design.visa.com/components/checkbox) instead.
For long lists where users would benefit from entering text to filter or search the list items. Use a [multiselect](https://design.visa.com/components/multiselect) instead.
If space is limited and displaying items in a collapsible menu would help. Use a [multiselect](https://design.visa.com/components/multiselect) instead.
- Component: As menus for a components including multiselect, combobox, dropdown menu, navigation menu.
- When to use: When presenting items doesn’t require user interaction to expand the list. Use a single- or multi-select listbox instead.
### Using in forms
Listboxes are commonly used as a selection control in an always expanded state within forms or on page. They provide users with a straightforward and efficient way to select single or multiple items from a list. Unlike dropdown menus, where items are hidden until interaction, the always expanded state of a listbox allows all items to be visible and directly accessible.
- Consider the length and complexity of your list, aiming to a small to medium number of items.
- Combine with scroll behaviors for longer lists to ensure ease of navigation.
#### Single-select listbox (radio)
Single-select listboxes are coded as radio buttons, allowing users to select only one item from the list at any given time.
- Follow all [Radio guidance](https://design.visa.com/components/radio) for implementing single-select listboxes.
#### Multi-select listbox (checkbox)
Multi-select listboxes are coded as checkboxes, allowing users to select multiple items from the list at once.
- Follow all [Checkbox guidance](https://design.visa.com/components/checkbox) for implementing single-select listboxes.
#### Pre-selected items
While some native select components may have an item preselected by default, listboxes should generally not have any preselected items upon page load. This ensures users are not influenced by any preconceived selections and can make their own choices based on their specific needs and preferences.
**Note:** In some cases, the listbox may load with a preselected item. This is usually due to a user setting or a saved configuration in which the user previously selected the item(s).
### Using as menus
Listboxes are used as the foundation for multiple components like navigation menus, dropdown menus, multiselect, and combobox. In these cases, the behavior of the listbox may be modified to suit the needs of the component. Always consult with accessibility partners before modifying these behaviors further.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Labels
- Limit labels to three to five words when possible.
- Be consistent when using plural language or “(s)” in field labels. For example, use “Select card type,” “Select card types,” or “Select card type(s)” consistently. If using “(s)”, use the asterisk method over “(required)” to keep labels concise.
- Use parallel structure across field labels, using either nouns like "Services" or verbs like "Select a service". Learn more about parallel structure in [Grammar and punctuation](https://design.visa.com/content/grammar).
### Item labels
- Limit item labels to three words or fewer unless referencing proper nouns, such as product names.
- Avoid using unnecessary articles like “the” or “an,” unless they’re included in the proper name of a product or service.
### Inline messages
- Use full sentences with proper punctuation.
- Limit descriptions to 80 characters or 20 words including spaces.
- Provide useful information such as why a field is required (if not obvious) without being technical.
- Give an example or specific syntax or values for inputs to help avoid errors.
#### Inline error message
- Use inline error messages to draw attention and to errors without causing frustration.
- Provide clear, prescriptive guidance on correcting the error. Avoid redirecting users to another page to fix it.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
---
# accessibility
---
title: Multiselect
description: Control that allows users to select multiple options from a dropdown menu.
meta_description: Find accessibility guidelines for controls that allow users to select multiple options from a dropdown menu.
thumbnail: assets/components/select-multiselect-graphic.svg
tab_order: 2
---
## Best practices
**Note:** Multiselects are a composite of native HTML elements. Follow the latest examples to ensure these elements are accessible using the keyboard and screen readers.
- This component can display a message when no options are found.
- Note that the multiselect menu is a listbox component. It uses elements with the role of “option” which doesn’t allow other form controls inside them. The “checkboxes” are not actual checkbox inputs.
- Maintain common keyboard shortcuts used for editing text unless the use case requires a different behavior. Reference [Input](https://design.visa.com/components/input) for more.
## Keyboard controls
### Input
Maintain common keyboard shortcuts used for editing text unless uniquely specified. Refer to [Input](https://design.visa.com/components/input) for details.
Keyboard actions and their corresponding behaviors for input
- Key: Moves to the next interactive focusable element
- Key: Moves to the previous focusable element
- Key: Opens the menu.
### Menu (listbox pop-up)
Reference [Listbox](https://design.visa.com/components/listbox) for detailed interactions. Focus will loop in a circular direction among the menu items.
Keyboard actions and their corresponding behaviors for menu (listbox pop-up)
- Key: Selects the focused highlighted option.
- Key: Dismisses menu and clears any inline autocomplete while maintaining user-entered input.
- Key: Moves to the next interactive focusable element and closes the menu.
- Key: Moves to the previous focusable element and closes the menu.
- Key: - Moves between the options when the menu is open.
- Arrow key interaction will loop focus within the options. When focus is on the last option within the set, the right/down arrow keys will move focus to the first option. When focus is on the first option within the set, the left/up arrow key will move focus to the last option.
---
# index
---
title: Multiselect
tab_title: Code
description: Control that allows users to select multiple options from a dropdown menu.
meta_description: Get code for controls that allow users to select multiple options from a dropdown menu.
thumbnail: assets/components/multiselect-graphic.svg
categories:
- actions
- selection-controls
---
## Component Code Examples: multiselect
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the multiselect component
const component = parsed.components.find(c => c.name === 'multiselect');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `multiselect`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Multiselect
description: Control that allows users to select multiple options from a dropdown menu.
meta_description: Learn how to use controls that allow users to select multiple options from a dropdown menu.
keywords: ["Multi-select menu", "multiple select dropdown", "multi-select combobox", "multi-option selector", "multi-selector"]
related:
components:
- combobox
- listbox
tab_order: 1
---
Multiselect components enable users to select one or more checkboxes from a menu. This component combines an input field and multiselect listbox to ensure users can find and select options quickly.
Also known as: Multi-select menu, multiple select dropdown, multi-select combobox, multi-option selector, multi-selector.
## Anatomy
**A. Label (required):** Text summarizing the options available for selection.
**B. Inline message (optional):** Brief text describing the field label in more detail.
**C. Chevron icon button (required):** UI icon button that expands or collapses menu.
**D. Input (required):** Text field enabling users to enter text to filter menu options.
**E. Option (required):** Selectable text representing a single option.
**F. Menu (required):** Container displaying list of options that includes scrollbar as needed.
**G. Removable compact chip (required):** Chip component representing a selected option.
**H. Select and clear all buttons (optional):** Button pair allowing users to select or clear all options.
## Usage
When to use and when not to use different types of multiselects
- Component: To present a list of options where the user can select one or multiple.
For long lists where all options can't be viewed at once or require scrolling.
If users would benefit from entering text to filter or search the list of options.
If space is limited and displaying options in a collapsible menu would help.
- When to use: If users can only select one option. Use a [Combobox](https://design.visa.com/components/combobox) instead.
For short lists where all options can be viewed without scrolling. Use a [Checkbox group](https://design.visa.com/components/checkbox/usage#checkbox-groups) instead.
To present a list of actions. Use a [Dropdown menu](https://design.visa.com/components/dropdown-menu) instead.
- Component: If users might want to select all or most options.
- When to use: If users won’t likely select all or most options.
## Best practices
- Use checkbox states for multiselect options to ensure they appear visually different when selected and unselected.
- Ensure users can select anywhere within a checkbox or associated option label to choose an option.
- List options in a logical order, either alphabetically or according to the most common or likely selection.
- Ensure multiselect components appear collapsed on page load to save space.
- Follow [Checkbox guidance](https://design.visa.com/components/checkbox) for implementing checkboxes within the menu.
### Select/clear all buttons
Multiselect components can optionally include select all/clear all controls. These enable users to easily select or unselect all options.
- Include select/clear all controls in any case where users may want to select all or most options in the menu.
- Use destructive styling for the “clear all” control to prevent accidental clearing.
### Chevron direction
The chevron UI icon button enables users to manually expand or collapse the menu. The direction it points should indicate what happens when it’s selected.
#### Collapsed
The chevron should point down when the menu is collapsed.
- Allow users to expand the menu by selecting anywhere in the input field, not just the chevron icon.
#### Expanded
The chevron should point up when the menu is expanded.
- Allow users to collapse the menu by removing focus from the field, not just by using the chevron icon.
### Empty state
Empty states occur when text in the input field doesn’t match any menu options. This helps guide users with useful feedback about their input.
- Use clear language to inform users that their input doesn’t match any options, as users may misinterpret an empty state for a loading state and wait for options to appear.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
## Behaviors
### Input functionality
The multiselect component can be implemented with a search or filter feature that allows users to find their desired option more quickly. Implement whichever method applies best to your use case.
**Note:** This feature isn’t automatically included in the component build and can be implemented in various ways. Product teams can determine how to load and filter data for their use case and should work closely with developers to determine the appropriate level of complexity for their product.
#### Menu search
In this method, the text field is used to search the options displayed in the menu. When the user types, the menu jumps so the option that matches their input best appears at the top of the field, and focus is placed on that option.
- Use this method when users may want to browse options that are similar to their input but don’t match exactly.
#### Menu filter
In this method, the text field is used to filter the options displayed in the menu. When the user types, the options displayed in the menu are temporarily reduced so only those matching the entry remain.
- Use this method when users are likely to know exactly what option they’re looking for.
### Selection method
Mulitselect components don’t require users to confirm their choices after selection. As soon as users select a checkbox in the menu, it appears as a chip in the input field.
- Ensure users can select anywhere within a checkbox or associated option label to choose an option.
### Scaling and reflow
Scaling and reflow refers to how content behaves as the container size changes, particularly when the container is small and can’t display all content at once. This is common with multiselect, as it’s often used when screenspace is limited.
Labels should always be fully visible when possible. If truncation is necessary, ensure the full-text option is shown in the expanded menu view and only the chip label is truncated. This approach allows screen readers to function as normal and read or render the option label, regardless of truncation, for assistive technology users.
- Scale the input field vertically to fit selection chips until the set maximum height is reached.
- Implement a scrollbar when the maximum height is reached to allow users to access all menu options or selection chips.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Reference the [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
- Avoid using unnecessary articles like “the” or “an”, unless they’re included in the proper name of a product or service.
### Labels
- Limit field labels to a maximum of three to five words.
- Be consistent when using plural language or “(s)” in field labels. For example, use “Select card type,” “Select card types,” or “Select card type(s)” consistently. If using “(s)”, use the asterisk method to label required fields instead of “(required)” within parenthesis to keep concise.
- Use parallel structure across field labels, using either nouns like "Services" or verbs like "Select a service". Learn more about parallel structure in the [Grammar and punctuation](https://design.visa.com/content/grammar#parallel-structure).
### Option labels
- Limit option labels to three words or fewer unless referencing proper nouns, such as product names.
- Avoid using unnecessary articles like “the” or “an,” unless they’re included in the proper name of a product or service.
- Consistently order labels across experiences based on logical sequence, either alphabetically or by importance.
### Inline messages
- Use full sentences with proper punctuation.
- Limit descriptions to 80 characters or 20 words including spaces.
- Provide useful information such as why a field is required (if not obvious) without being technical.
- Give an example or specific syntax or values for inputs to help avoid errors.
#### Inline error message
- Use inline error messages to draw attention and to errors without causing frustration.
- Provide clear, prescriptive guidance on correcting the error. Avoid redirecting users to another page to fix it.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
## Platform considerations
### Mobile
The multiselect component opens a full-screen menu and spans the full width of the page on mobile screens. For more, [visit the mobile flow (internal only)](https://bookmarks.visa.com/vpds-visit-the-mobile-flow).
- Ensure users can exit the fullscreen view by selecting the close button in the top app bar.
- Remove the chevron icon button from the input field when the menu is in full-screen view.
- Keep the full-screen menu open until users manually exit to ensure they’re finished making selections.
---
# accessibility
---
title: Navigation drawer
tab_order: 2
description: Collapsible navigation panels that float over page content on small screens.
meta_description: Find accessibility guidelines for collapsible navigation panels that float over page content on small screens.
thumbnail: assets/components/navigation-drawer-graphic.svg
---
## Best practices
**Note:** Although the list resembles tabs and uses tab styles, it does not have `tablist` roles or behaviors.
- Use `aria-current="true"` or `aria-selected="true"` to set the active tab.
- Make sure users can scroll to all the content within the drawer.
- Ensure `nav` elements have an `aria-label` with a unique and meaningful name. The label text shouldn’t include the word “navigation” as this will be announced automatically and be redundant for the screen reader.
- Implement navigation drawers as `dialog` elements.
### Logos
Our library has a classname just for the application name in the horizontal navigation component. There is a component for the Visa logo that adjusts for the user’s high contrast settings.
- Ensure the logo has an accessible name or is inside a link with an accessible name with `aria-hidden="true"` on the svg.
- Use one of the library’s classes for high contrast with a custom logo. Choose between the class for a light or dark foreground depending on the custom logo. Setting a contrasting background behind the brand logo ensures it will have maximum contrast in high contrast mode without a visible change in default contrast mode.
## Keyboard controls
Keyboard actions and their corresponding behaviors for navigation drawer
- Key: Activates buttons within the drawer.
- Key: Navigates to the focused element page and activates buttons within the drawer.
- Key: Moves to the next interactive focusable element.
- Key: Dismisses the navigation when the vertical navigation is collapsed into a menu, such as on a mobile viewport.
---
# index
---
title: Navigation drawer
tab_title: Code
description: Collapsible navigation panels that float over page content on small screens.
meta_description: Get code for collapsible navigation panels that float over page content on small screens.
thumbnail: assets/components/navigation-drawer-graphic.svg
categories:
- navigation
- structure-and-layout
---
## Component Code Examples: navigation-drawer
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the navigation-drawer component
const component = parsed.components.find(c => c.name === 'navigation-drawer');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `navigation-drawer`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Navigation drawer
tab_title: Usage
tab_order: 1
description: Collapsible navigation panels that float over page content on small screens.
meta_description: Learn how to use collapsible navigation panels that float over page content on small screens.
keywords: ["Drawer menu", "side menu", "flyout menu", "sidebar navigation", "hamburger menu", "collapsible menu", "Navigation Drawer (Android)"]
related:
components:
- vertical-navigation
- top-app-bar
content:
- information-architecture
---
The navigation drawer is a vertical navigation menu used on mobile devices or small web screens. It’s typically accessed from a menu icon in the [Top app bar](https://design.visa.com/components/top-app-bar).
Also known as: Drawer menu, side menu, flyout menu, sidebar navigation, hamburger menu, collapsible menu, Navigation Drawer (Android).
## Anatomy
**A. Brand mark (optional):** Visual element representing Visa, a partner brand, or a fictitious brand associated with the product.
**B. Application name (optional):** Label indicating the name of the application.
**C. Section title (optional):** Title used to group navigation elements.
**D. Icon (optional):** Visual indicator used to enhance the meaning of the navigation link label.
**E. Navigation link (required):** Label indicating the destination of the link.
**F. User profile (optional):** Avatar component representing the current user’s account.
**G. Close button (required):** Icon button used to collapse the navigation drawer.
**H. Chevron (optional):** Icon indicating the collapsed or expanded state of a multi-level menu item.
## Usage
When to use and when not to use navigation drawer
- When to use: For small screens with many navigation items.
For navigation paired with a [Top app bar](https://design.visa.com/components/top-app-bar).
- When not to use: If your app has a few top-level views, consider a [Tab bar](https://design.visa.com/components/tab-bar).
For larger screen sizes. Use [Vertical navigation](https://design.visa.com/components/vertical-navigation) instead.
## Best practices
- Reference [Application layouts](https://design.visa.com/patterns/application-layouts) for help deciding which navigation component is best for your use case.
- Ensure the order of the navigation items is consistent throughout the application, as changing it may confuse users.
- Ensure text within the navigation panel wraps to a second line instead of truncating to ensure it’s fully visible to users.
- Include a vertical scroll bar if all navigation items can’t be viewed at once.
- Consider making the brand mark and/or application name function as a link to the homepage of the experience.
- Follow all guidance found in [Avatar](https://design.visa.com/components/avatar/usage) and [Link](https://design.visa.com/components/link/usage) for implementing a user profile in the navigation panel.
### Section titles and nesting
Section titles refer to static text used to group navigation items under a common category. They can be used with or without nested navigation items, which expand or collapse other navigation items. Both methods group related content and help users navigate easily. Decide which to use based on your use case and design preferences.
#### Section titles
Section titles group navigation items without nesting them. They’re helpful for grouping items that should always be visible within the menu.
- Use section titles to group items that should always be visible in the menu.
#### Nesting
Nesting items group links within collapsible sections. They’re helpful for more complex apps menus may benefit from limiting the number of links visible at once.
- Consider nesting items in longer navigation menus, as this can help save space and declutter the experience.
### Icon usage
Icons can be used in navigation drawers to make scanning easier and reinforce familiar ideas.
- Ensure icon usage applies to all navigation items within the same hierarchy level. For example, if you use icons for some L1 labels, they should be used in all L1 items.
- Omit icons for nested items, but if they’re necessary, ensure all items within the nested level has one.
## Behaviors
### Responsive web vs. native mobile applications
Navigation drawers can be used in both responsive web and native mobile applications. Whether its implemented in web or mobile determines the levels of hierarchy it can accommodate. Learn about the differences below.
#### Responsive web applications
In responsive web apps, navigation drawers include multiple levels of hierarchy to reflect the more complex navigation structure.
#### Native mobile applications
For native mobile apps, navigation drawers only have one level of links available. It’s expected that further navigation will be appear within sections of the app as needed.
### Scrolling
A scroll bar can be used if the navigation is long and doesn’t fit in one view. The navigation items will scroll, while the brand mark, application name, and any items at the bottom remain fixed in position.
### Chevron direction
Visually differentiate expanded and collapsed sections using the chevron direction.
#### Collapsed
Collapsed sections should use the downwards-pointing chevron to indicate collapsed content can be expanded.
#### Expanded
Expanded sections should use the upwards-pointing chevron to indicate expanded content can be collapsed.
## Platform considerations
Navigation drawers are typically only used on small responsive screens, or in native mobile applications. For large screen sizes, use [Horizontal navigation](https://design.visa.com/components/horizontal-navigation/usage) or [Vertical navigation](https://design.visa.com/components/vertical-navigation/usage) instead.
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation for navigation items.
- Ensure labels match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Limit labels to a few brief words to prevent unnecessary reflow.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# accessibility
---
title: Pagination
tab_order: 2
description: Set of links used to navigate content that’s split between multiple pages.
meta_description: Find accessibility guidelines for sets of links used to navigate content split between multiple pages.
thumbnail: assets/components/pagination-graphic.svg
---
## Best practices
- Use a navigation landmark by containing the pagination in a `nav` element or an element with `role="navigation"` and give the element an aria-label. The landmark allows a user to navigate to this section and see it listed in a page summary.
- Code the pagination controls in an an HTML `ul` so screen readers announce the number of items.
- Ensure the button for the current page has the attribute `aria-current="page"`.
- Manage the disabled state of the navigational buttons using the `disabled` attribute.
- Give all pagination controls accessible labels, as they are icon buttons.
- Don’t code overflow ellipses as button icons, as they’re not actionable.
- Use the library’s rtl class to ensure the arrows will point the correct direction in an RTL language.
{/* CURSOR AND KEYBOARD */}
## Keyboard controls
Keyboard actions and their corresponding behaviors for pagination
- Key: Activates link.
---
# index
---
title: Pagination
tab_title: Code
description: Set of links used to navigate content that’s split between multiple pages.
meta_description: Get code for sets of links used to navigate content split between multiple pages.
thumbnail: assets/components/pagination-graphic.svg
categories:
- selection-controls
- tables
---
## Component Code Examples: pagination
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the pagination component
const component = parsed.components.find(c => c.name === 'pagination');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `pagination`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Pagination
description: Set of links used to navigate content that's split between multiple pages.
meta_description: Learn how to use sets of links used to navigate content split between multiple pages.
keywords: ["Page navigation", "page toggle", "page numbers", "paging"]
related:
components:
- table
patterns:
- dynamic-table
tab_order: 1
---
{/* INTRO */}
Pagination is a set of links that allow users to navigate content split into multiple pages. It typically includes navigational controls such as next and previous buttons, as well as direct links to specific pages.
Also known as: Page navigation, page toggle, page numbers, paging.
## Anatomy
**A. Skip navigation arrow (optional):** Links allowing users to skip to the first or last page.
**B. Sequential navigation arrow (required):** Links enabling users to navigate forward or back one page.
**C. Page numbers (required):** Visible numbers linking to other pages in the collection.
**D. Selected page number (required):** Indicator of the current page the user is interacting with.
**E. Overflow ellipsis (optional):** Non-interactive separator between the start or end page numbers.
## Usage
When to use and when not to use different types of pagination
- Component: To allow users to navigate a collection of content split into multiple pages.
- When to use: For content that can reasonably fit onto one page.
- Component: When space is limited, especially when other ways to filter down results are present.
- When to use: For content split across more than three pages.
## Best practices
- Ensure all page numbers and arrows function as interactive links, except the currently selected page.
- Use a clear visual indicator to show which page is currently selected.
- Always allow users to navigate to the first page, last page, back one page, or forward one page using navigation arrows.
- Display a manageable number of page links, using ellipsis to truncate the list if necessary.
### Default pagination
Default pagination provides a standard way to navigate through large volumes of content or datasets. It's ideal for larger sets of content because it includes more functionality for users to easily move between pages. It typically includes sequential navigational controls, such as next and previous buttons, as well as ellipses and skip navigation controls for users to move to the first and last pages.
### Slim pagination
Slim pagination is a more compact version of default pagination, designed for scenarios where screen space is limited or when a cleaner, less cluttered interface is desired. It includes only the essential navigational controls, such as next and previous buttons, and may omit direct links to specific pages. Slim pagination is ideal for mobile interfaces or when the total number of pages is relatively small and it’s feasible for the user to navigate one page at a time.
### Placement
Pagination is usually centered below an element or at the foot of page content.
- Place pagination controls in consistent locations throughout an interface.
### Results per page
The “Results per page” feature allows users to control how many items they see on each page of a paginated list. This functionality gives users the flexibility to view more or fewer items per page according to their preferences or needs. It’s particularly useful in scenarios where users may want to adjust the volume of information they are processing, such as in search results, product listings, or data tables.
- Set a reasonable default number of results per page that balances performance and usability, such as 10 to 20 items, without overwhelming users with too many choices.
- Clearly indicate the current selection of results per page and make it easy for users to change this setting.
- Save the user's preference for the number of results per page, so that they don’t have to re-select it each time they return to the same page or application.
- Ensure that the "Results per page" feature works well on mobile devices, where screen space is limited and users may prefer fewer results per page to avoid excessive scrolling.
## Behaviors
Pagination has a number of expected behaviors depending on the type selected. The guidance below outlines the expected behaviors of default pagination.
### First four pages selected
When users navigate through pages 1–4 in a pagination set, pagination includes one overflow ellipsis symbol representing the pages between the fifth and last page. When page 1 is selected, the arrow buttons to navigate backward should be disabled.
### Middle pages selected
When users select any page other than the first four or last four, pagination includes two overflow ellipsis symbols on either end of three internal page numbers. The selected page should always be the center of the set. The first and last page number should always show and all navigation arrows should be active.
### Last four pages selected
When users navigate through the last four pages, pagination includes one overflow ellipsis symbol after the number representing page 1. When the last page is selected, the arrow buttons to navigate forward should be disabled.
## Platform considerations
### Web (default)
For web, pagination is shown in a single line with all four navigational arrows and utilizes the behaviors outlined above around overflow. Depending on the use case, navigational arrows can be simplified to the include only sequential controls.
### Mobile
Mobile screen sizes use a five-control design that limits how many pages are available to users. While pagination for mobile screen sizes is available, it’s generally not recommended for use and isn’t available in mobile native.
Consider implementing these common alternatives in place of mobile pagination.
### Infinite scrolling
Infinite scrolling automatically loads new content as a user scrolls through the page, eliminating the need to manually navigate to the next page.
- Use for content-heavy applications where continuous exploration is needed.
- Provide visual feedback if needed, such as a loading spinner, to indicate that new content is being loaded.
- Avoid infinite scrolling for content where users might need to find specific information quickly.
### “Load more” button scrolling
“Load more” buttons allow users to manually load content as needed. It provides more control than infinite scrolling, enabling users to decide when they want more information.
- Place the "load more" button at the bottom of the content list, ensuring it's easily accessible.
- Clearly indicate when new content has been loaded to avoid confusion.
- Consider adding a counter or [Progress](https://design.visa.com/components/progress) indicator to show how much content remains unloaded.
---
# accessibility
---
title: Panel
description: Collapsible or persistent containers used to present supplementary information.
meta_description: Find accessibility guidelines for collapsible or persistent containers used to present supplementary information.
thumbnail: assets/components/panel-graphic.svg
tab_order: 2
---
## Best practices
**Note:** Modal panels are implemented as dialogs whereas responsive ones are not. Modal panels have a backdrop scrim and the escape key closes them.
- Check your panel on different screen sizes to make sure it displays correctly.
- Ensure the content inside is responsive and wraps appropriately. Our components have default widths, but you may need to adjust these. If you make changes, check how the handles fit.
- Ensure modal panels have `aria-modal="true"`.
- Ensure all panels have `aria-labeledby` pointing to the ID of your panel title if present.
- Ensure all panels have `aria-describedby` pointing to the ID of your panel content if present.
## Keyboard controls
Keyboard actions and their corresponding behaviors for panel
- Key: Prompts the action associated with the focused interactive element.
- Key: Moves keyboard focus to the next focused interactive element.
- Key: Moves keyboard focus backwards to the previous interactive element in the panel.
- Key: Closes the panel.
---
# index
---
title: Panel
tab_title: Code
description: Collapsible or persistent containers used to present supplementary information.
meta_description: Get code for collapsible or persistent containers used to present supplementary information.
thumbnail: assets/components/panel-graphic.svg
categories:
- structure-and-layout
---
## Component Code Examples: panel
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the panel component
const component = parsed.components.find(c => c.name === 'panel');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `panel`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Panel
description: Collapsible or persistent containers used to present supplementary information.
meta_description: Learn how to implement collapsible or persistent containers used to present supplementary information.
keywords: ["(Side/bottom) sheet", "drawer", "tray", "flyout", "side panel"]
related:
components:
- dialog
baseElements:
- elevation
tab_order: 1
---
Panels are sections of content that provide supplementary information. They’re commonly used for help content and can include follow-up actions using buttons or links.
Also known as: (Side/bottom) sheet, drawer, tray, flyout, side panel.
{/* ANATOMY */}
## Anatomy
**A. Title (required):** Brief text describing the panel content.
**B. Close icon button (required):** UI icon button used to close a default panel or exit the full screen view on mobile devices.
**C. Subtitle (optional):** Area displaying content, action buttons, or links.
**D. Content area (required):** Area displaying content, action buttons, or links.
**E. Collapse icon button (optional):** Icon button used to collapse or expand the panel.
**F. Skrim (optional):** Semi-transparent overlay distinguishing the panel from the content underneath.
{/* USAGE */}
## Usage
When to use and when not to use different types of panel
- Component: To provide contextual information prompted by a link, button, or similar interactive element.
For information related to a specific action or part of the experience.
- When to use: If users may need to access the information repeatedly. Use an expandable panel instead.
- Component: To provide supplementary information the user may want to reference repeatedly.
For information relating to the whole page or content area.
- When to use: To provide critical guidance, as users may miss important details if they’re hidden in a collapsed panel.
- Component: To divide panel content into categories of information.
- When to use: If you have only a small amount of information or if the information doesn’t naturally divide into categories.
{/* BEST PRACTICES */}
## Best practices
- Use vertical scrolling if there’s overflow content, but avoid horizontal scrolling to maintain readability.
- Ensure all content in the panel relates to the main page content.
- Ensure panel content is brief and specific. Avoid using panels for long paragraphs or sections of text.
### Default panels
Default panels provide contextual information prompted by UI controls, such as buttons or links. They can be dismissed using a close icon button. Default panels are best for providing additional details or controls related to a particular step or action within the main page, which users are likely to access once during their workflow, rather than repeatedly.
### Expandable panels
Expandable panels provide supplemental information that can be expanded or collapsed at any time during the experience. They’re best for providing information relevant to the entire page, which users may want to reference multiple times throughout their workflow. The expand/collapse button remains available at all times, enabling users to access the information whenever needed.
### Tabbed panels
Tabbed panels are similar to expandable panels, but include [Tabs](https://design.visa.com/components/tabs/usage) that divide the content into logical groups or categories. They’re best for larger amounts information that may benefit from being broken into categories. Tabbed panels enable users to navigate between different sections of information easily, making it easier to find specific details within a broader context.
{/* BEHAVIORS */}
## Behaviors
### Modal panels
Modal panels lay on top of the main content using elevation or a semi-transparent skrim overlay. When the panel is open, all other page content is disabled until the panel is dismissed.
- Use modal panels when you need to capture the user’s focus for critical actions or decisions that shouldn’t be distracted by other content on the page.
- Don’t use modal panels if users need to interact with both the panel and the main content simultaneously.
#### Elevation vs. skrim
Modal panels can be indicated using elevation or a semi-transparent skrim overlay. This ensures it’s clear that the page content isn’t interactive when the panel is open. For more information, reference [Elevation](https://design.visa.com/base-elements/elevation).
### Responsive panels
Responsive panels push content to the side when open. They don’t limit the interactivity of other elements on the page, so users can interact with the panel and the main page simultaneously.
- Use responsive panels when users need to interact with both the panel and the main content simultaneously, such as performing tasks that benefit from a side-by-side layout.
{/* Platform considerations */}
## Platform considerations
### Web
In web platforms, panels fill the full height of the content area and are anchored to the right side of the screen.
### Mobile
In mobile platforms, panels can either occupy a portion of the screen or take up the full screen, but they always function as [Modal panels](https://design.visa.com/components/panel/usage#modal-panels), meaning functionality is limited on the rest of the screen. If they don't take up the full screen, they should be anchored at the bottom.
- Consider using a [Dialog](https://design.visa.com/components/dialog) instead to present options or actions. This provides more ergonomic and mobile-friendly interaction.
- Ensure mobile panels always include a close icon button.
{/* Content */}
## Content
- Use simple language—avoid abbreviations or jargon.
- Use sentence case, except for proper nouns or acronyms.
### Panel headings
- Use short, concise content that describes the panel content clearly.
- Only use punctuation when labels are phrased as questions, such as “How do I edit my billing information?”
### Panel content
- Use complete sentences and proper punctuation within each section or panel.
- Keep the content within each panel concise and to the point.
- Avoid unnecessary details or complex language.
- Provide users with the answers they need as quickly and efficiently as possible.
- If content within the panel is becoming too lengthy, it may be a sign that the information should be presented in a different way, such as being broken down further, moved to a separate page, or even represented visually.
---
# accessibility
---
title: Progress
description: Visual representations of the status of a system process.
meta_description: Find accessibility guidelines for visual representations of the status of a system process.
thumbnail: assets/components/progress-graphic.svg
tab_order: 2
---
## Best practices
Implementing progress indicator components for people who rely on screen readers takes thought and is less intuitive than for most of the other components. There is not a one-size-fits all solution.
- Use `alert` , `role="status"`, or `aria-live` to announce the start and end of a progress indicator. Alerts, status, and aria-live interrupt the user, even when set to “polite”, and could be especially disruptive with progress indicators.
- Set timed announcements, such as every 30 seconds or minute, for longer progress indicators.
- Place the progress element near the control prompting it in the DOM so screen reader users can find it easily.
- Don’t give indeterminate progress indicators a `role="progressbar"`, as they only communicate a process is happening and navigating to them doesn’t yield any additional information.
- Use labels and aria labeling attributes with progress indicators as needed. Alerts and live-areas need to be handled with finesse when it comes to their timing.
- Don’t place alerts or live areas inside progress elements, as any content contained in a progress element or an element with `role="progressbar"` will be given an implicit `role="presentation"` by the browser and not announced.
- Check the linear progress indicator’s native `progress` component. It uses a value attribute which often needs to be converted to a percentage by the developer.
- Check the circular progress indicator’s div with the `role="progressbar"`. It must have an `aria-valuenow` attribute which is updated by the developer.
### Determinate vs indeterminate progress behaviors
#### Determinate
- Linear determinate indicators have a `progress` element with a value attribute.
- Circular determinate indicators have `role="progressbar"` and `aria-valuenow` attributes.
- Ensure determinate indicators are located in the DOM near the control that prompted the process. While they’re not in the page tab order, they can be reached with the keyboard when a screen reader is on.
- Ensure progress values are announced only in certain situations, and then in a deliberately timed manner.
#### Indeterminate
- Ensure indeterminate indicators don’t have roles.
- Ensure they’re announced, although they don’t need to be accessible in the DOM.
#### Motion sensitivity
- Consider implementing a way to pause animations for indeterminate progress indicators, especially if they’re displayed for a long time.
---
# index
---
title: Progress
tab_title: Code
description: Visual representations of the status of a system process.
meta_description: Get code for visual representations of the status of a system process.
thumbnail: assets/components/progress-graphic.svg
categories:
- feedback-and-status
---
## Component Code Examples: progress
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the progress component
const component = parsed.components.find(c => c.name === 'progress');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `progress`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Progress
description: Visual representations of the status of a system process.
meta_description: Learn how to use visual representations of the status of a system process.
keywords: ["Progress indicator", "progress bar", "loading indicator", "progress ring", "spinner", "loader", "progress loader", "activity indicator", "ProgressView(iOS)", "ProgressBar(Android)"]
related:
patterns:
- forms
- wizard
tab_order: 1
---
Progress components are non-interactive elements that visually indicate the progress of a task or function.
Also known as: Progress indicator, progress bar, loading indicator, progress ring, spinner, loader, progress loader, activity indicator, ProgressView(iOS), ProgressBar(Android).
## Anatomy
**A. Progress indicator (required):** Animated fill indicating the function is in progress.
**B. Label (optional):** Label indicating what’s in progress, such as a file name.
**C. Status (optional):** Label indicating how much process has been completed for determinate indicators.
## Usage
When to use and when not to use different types of progress
- Component: When space is limited.
- Component: When the design has sufficient space.
- Component: For a more detailed progress indicator, such as in dashboards or control panels.
**Note:** Progress gauges are only available as determinate indicators. Learn more below.
## Best practices
- Avoid using progress components for very lengthy load times, as users may perceive that the app is slow or frozen.
- Only use determinate progress indicators if the exact amount of completion is known. Learn more below.
### Determinate progress
Determinate progress indicators display how long a process will take. They include an exact percentage or fraction indicating how much progress has been made.
- Only use determinate indicators when the amount of completion is known, as estimating can be misleading or cause frustration.
### Indeterminate progress
Indeterminate progress indicators display unknown wait times. Indeterminate progress indicators may turn into determinate progress when more information is available.
- Use indeterminate indicators when the amount of progress is unknown or not important.
### Placement
In general, progress indicators should be placed near the function they represent. o show that an entire page or app is loading, place a linear indicator at the top of the page or just below the navigation bar.
- Consider using skeleton loading to further indicate that loading is in progress.
## Content
- Use plain language without abbreviations or jargon.
- Annotate the percentage completed in determinate progress components.
---
# accessibility
---
title: Radio
description: Interactive elements that allow users to select a single option from a list.
meta_description: Find accessibility guidelines for interactive elements that allow users to select a single option from a list.
thumbnail: assets/components/radio-graphic.svg
tab_order: 2
---
## Best practices
- Ensure all the radio buttons in a group have the same `name` attribute.
- Put the radio buttons inside a `fieldset`, and give it a `legend`.
- Ensure each radio button has an `id` associating it with its label. Be sure to associate additional text and error messages to its relevant radio input or fieldset. Reference [the coded examples.](https://design.visa.com/components/radio)
## Keyboard controls
Keyboard behaviors treat radio buttons as a group. Tabbing into the group focuses the first radio. Tabbing a second time does not go to the second radio, it moves to the next focusable element after the radio group. Placing focus on a radio button automatically selects in. Use the following focus order to ensure radio groups are accessible and predictable:
- Ensure focus is placed on the currently selected option upon tabbing into the group.
- If all options are unselected, ensure focus is placed on the first radio button in the group.
- If the group is in an error state, focus is moved to the first radio button, and the whole fieldset is given the error (red) style.
Keyboard actions and their corresponding behaviors for radio
- Key: Moves the focus and selection to the next radio in the group and unselects the previously focused one. Focus moves in a circular rotation within the group, so progressing past the last option returns focus to the first in the group.
- Key: Moves to the next focusable element outside the radio group.
- Key: Moves to the previous focusable element outside the radio group.
- Key: Selects the focused element if it’s not already selected. This allows the user to select an item without additional keyboard steps.
---
# index
---
title: Radio
tab_title: Code
description: Interactive elements that allow users to select a single option from a list.
meta_description: Get code for interactive elements that allow users to select a single option from a list.
thumbnail: assets/components/radio-graphic.svg
categories:
- selection-controls
---
## Component Code Examples: radio
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the radio component
const component = parsed.components.find(c => c.name === 'radio');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `radio`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Radio
description: Interactive elements that allow users to select a single option from a list.
meta_description: Learn how to use interactive elements that allow users to select a single option from a list.
keywords: ["Radio buttons", "radio selections", "RadioGroup", "RadioButton (Android)"]
related:
components:
- checkbox
- select
- listbox
patterns:
- forms
tab_order: 1
---
Radios buttons present a short list of options where the user must select one. They’re commonly used in forms, user preference selections, surveys, or any scenario where a single selection from multiple options is required.
Also known as: Radio buttons, radio selections. RadioGroup, RadioButton (Android).
## Anatomy
**A. Radio button (required):** Interactive element enabling users to select an option.
**B. Option label (required):** Brief text describing the radio option.
**C. Description (optional):** Brief message detailing important information about the option.
**D. Radio button group (optional):** Short list of radio buttons presented in a group.
**E. Group label (required):** Brief description of options available for selection.
## Usage
When to use and when not to use different types of radios
- Component: Using one radio button alone is not a common use case.
- When to use: To present one option available for selection. Use a [Checkbox](https://design.visa.com/components/checkbox) instead.
- Component: To present a short list of options where the user must select one.
- When to use: If users can select multiple options from a short list. Use a [Checkbox group](https://design.visa.com/components/checkbox/usage#checkbox-groups) instead.
For long lists where all options can't be viewed at once or require scrolling. Use [Select native](https://design.visa.com/components/select) or a [Single-select listbox](https://design.visa.com/components/listbox) instead.
For long lists when users would benefit from entering text to filter or search the list options. Use a [Combobox](https://design.visa.com/components/combobox) instead.
To present a list of actions. Use a [Dropdown menu](https://design.visa.com/components/dropdown-menu) instead.
- Component: Using one radio button panel alone is not a common use case.
- When to use: To present one option available for selection. Use a [Checkbox](https://design.visa.com/components/checkbox) instead.
- Component: To present a short list of options where the user must select one.
To provide an increased touch area.
- When to use: If there is limited space. Use a Radio button group instead.
## Best practices
- Ensure radio buttons appear visually different when selected and unselected by using an appropriate fill color.
- Ensure users can select anywhere within the radio button or associated option label to choose an option.
- List options in a logical order, either alphabetically or according to the most common or likely selection.
- Avoid using a horizontal layout for radio button groups and panel groups, as vertical layouts are easier to scan and more adaptable for small screens.
### Radio button panels
Radio button panels are an alternative to default radio buttons that include a rectangular border around the button and option label. They can be used to draw attention to the radio group or provide an increased touch area on small screens.
- Ensure users can select anywhere within the radio button, label, or panel to choose an option.
### Label size for panel groups
Labels for radio panel groups are available in two sizes. Use whichever is appropriate depending on your use case and the overall hierarchy of your experience.
#### Default
The default option is the UI label font size and matches the text in option descriptions.
- Use the default size to reduce visual weight for users when multiple radio button panel groups are used together.
#### Large
The large UI label size is an alternative option that can be used to draw attention to the checkbox panel group label.
- Use the large size to draw attention to a standalone radio panel group.
### Hidden labels
Radio button groups and panel groups should always include a group label. However, there are some cases where hiding the group label can provide design flexibility or space for additional context. If the group label within the component build is hidden, include a label elsewhere on the screen as well as within the code for accessibility.
- Always include a group label somewhere on the screen if you choose to omit it from the component build.
- Always include the group label within the code to ensure screen readers users have full context.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
### Including "None" as an option
Radio button groups require a single option to be selected. Once a radio button is selected, it can only be unselected by choosing another option in the group.
- Include “None” as an option if users are allowed to omit a selection. This functions as an “unselect” option if users accidentally choose an option they don’t want or wish to omit a selection altogether.
### Default selections
In general, radio buttons should be unselected by default to give users full control over their choices. The main exception is when the selection indicates a default or system setting.
- Avoid default selections when possible to encourage users to make an active choice. Including default selections can make it easier for users to skip fields and may result in choices they don’t agree with.
## Behaviors
### Single-selection
Radio buttons enforce a single selection from a short list. Selecting one option automatically deselects all others. Once a radio button is selected, it can’t be unselected by selecting it again. Another option must be selected to change the current one.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Visit [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Description
- Use full sentences with proper punctuation.
- Limit descriptions to 80 characters or 20 words including spaces.
### Labels
- Don’t use punctuation.
- Limit labels to three words or fewer unless referencing proper nouns, such as product names.
- Ensure group labels accurately summarize the options available for selection.
- Use [Parallel structure](https://design.visa.com/content/grammar#parallel-structure) for labels across your experience, either starting with verbs such as “Select a notification preference” or nouns such as “Notification preferences”.
## Platform considerations
Radio buttons are available in mobile and web and should be implemented similarly on both platforms.
- Use radio button panels to provide a larger touch area when necessary.
- Use default radio buttons to save space and prevent user overload, especially when there are many radio button groups used together in a form.
---
# accessibility
---
title: Section message
description: Section-level messages about the status of a page or action.
meta_description: Find accessibility guidelines for section-level messages about the status of a page or action.
thumbnail: assets/components/section-message-graphic.svg
tab_order: 2
---
## Best practices
**Note:** Section messages shouldn’t rely on visual cues such as color or icons to communicate to users. Ensure there is additional text to relay information. Some of our libraries have default values for message type labels such as “success”, “warning”, and “error” but you may want to use custom labels, especially if your app is multilingual.
- Ensure section messages use headings in the correct hierarchical order without skipping levels. Headings can be styled to look like a different level. See your preferred library for more information on Typography.
- Use attributes to announce content to screen readers if you need to show a section message dynamically after the page loads. Select which attributes to use based on the message purpose and content.`role` with a value of `status` or `alert`, `aria-live`, and `aria-atomic` are useful.
- Ensure screen readers announce the messages at the desired time.
## Keyboard controls
**Note:** Section messages are comprised of other elements which use standard keyboard actions. Activating the Escape key does not close the section message, as that might disrupt what the user is doing by closing something else.
Keyboard actions and their corresponding behaviors for section message
- Key: Prompts the action associated with the focused interactive element.
- Key: Moves focus to the next focusable element.
- Key: Moves keyboard focus backwards to the previous interactive element in the banner.
---
# index
---
title: Section message
tab_title: Code
description: Section-level messages about the status of a page or action.
meta_description: Get code for section-level messages about the status of a page or action.
thumbnail: assets/components/section-message-graphic.svg
categories:
- feedback-and-status
---
## Component Code Examples: section-message
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the section-message component
const component = parsed.components.find(c => c.name === 'section-message');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `section-message`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Section message
description: Section-level messages about the status of a page or action.
meta_description: Learn how to use section-level messages about the status of a page or action.
keywords: ["Informational notice", "inline message", "alert", "callout", "message bar", "notification"]
related:
components:
- banner
- flag
patterns:
- feedback-and-status
content:
- messaging
tab_order: 1
---
Section messages offer feedback that is specific to a user's actions or the status of a particular page section. Rather than applying to the whole site or application, these messages are unique to individual sections and appear near the associated content. They remain visible until the user either engages more or decides to close them.
Also known as: Informational notice, inline message, alert, callout, message bar, notification.
## Anatomy
**A. Icon (required):** Visual indicator communicating the urgency of the section message. **B. Title (optional):** Brief text summarizing the purpose of the section message. **C. Message (required):** Descriptive message detailing important contextual information. **D. Close icon button (optional):** Icon button used as a close button alternative that allows users to manually dismiss the message. **E. Button and link (optional):** Text button or link that prompts an action or providing access to resources relevant to the message.
## Usage
When to use and when not to use different types of section messages
- Component: For low-priority status updates contextually relevant to the user’s current workflow.
- When to use: For informational messages that are of high enough priority to disrupt the user's workflow, even though they may not require immediate action. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For low-priority, system-level messages. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
For low-priority feedback or status updates that don’t require user action or attention. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
- Component: Success section messages are not a common use case.
- When to use: For system- or section-level success, including on-page event confirmations. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
If the user is taken to a success page on submit. Don’t use a messaging component in this case.
- Component: For medium-priority feedback warning of potential issues within the section. This is the most frequent use case.
- When to use: For high-priority warnings that must be fixed or acknowledged before continuing. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For medium-priority, system-level messages that require attention but not disruption. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
For low-priority warnings that don’t require user action or attention. Use a [Flag](https://design.visa.com/components/flag/usage) instead.
- Component: For high-priority feedback alerting that errors or issues have occurred within the section and must be fixed.
- When to use: For high-priority errors that must be fixed before continuing. Use a [Dialog](https://design.visa.com/components/dialog/usage) instead.
For high priority, system-level errors that require attention. Use a [Banner](https://design.visa.com/components/banner/usage) instead.
- Component: For low-priority feedback notifying users of tips or more information.
- When to use: For high-priority errors or feedback. Use section messages that denote more critical status instead.
## Best practices
- Ensure section messages do not block interactive elements or content within the page section.
- Visit [Button](https://design.visa.com/components/button/usage) to learn about best practices for alignment, order, and language for calls to action.
- Visit [Feedback and status](https://design.visa.com/patterns/feedback-and-status) to learn how to use messaging components, understand their level of disruption, and choose the appropriate messaging component for your context.
## Behaviors
### Dismissal
In general, users should be allowed to dismiss section messages using a close icon button or text button. Section messages should also dismiss when users complete an associated action, such as correcting an error. Avoid using timed auto-dismissal for section messages, as they may disappear before screen readers finish announcing the text.
## Placement
Section messages should be placed at the top of the sections they pertain to, either above or below the section title. Consider screen reader order when choosing a placement method. Whichever you choose, implement it consistently across your experience.
## Content
- Learn how to craft content for messaging components, like section messages, visit [Messaging](https://design.visa.com/content/messaging).
- Follow guidelines for [Link](https://design.visa.com/components/link/usage) and [Button](https://design.visa.com/components/button/usage) components when labeling actions and destinations within section messages.
---
# accessibility
---
title: Select (native)
description: HTML element that allows users to select one option from a dropdown menu.
meta_description: Find accessibility guidelines for HTML elements that allow users to select one option from a dropdown menu.
thumbnail: assets/components/select-graphic.svg
tab_order: 2
---
## Best practices
**Note:** VPDS uses native HTML select elements. As a result, developers have a limited amount of control over how these elements appear and behave. The menu is styled by the browser and will differ between them.
- Ensure each select has an ID associating it with its label.
- Always show the full text of longer options in the expanded menu view. Only truncate text in the field after a selection is made.
- Be sure to associate additional text and error messages to the select or its fieldset. Reference the code for more.
## Keyboard controls
Keyboard actions and their corresponding behaviors for selects
- Key: Moves the focus to the first menu item.
- Key: Moves the focus to the last menu item.
- Key: Expands the menu.
- Key: Moves the focus and selection to the next menu item. Selects the next option when the menu is not expanded.
- Key: Opens the menu if the menu is closed. When the menu is open, selects/activates the menu item in focus and closes the menu.
- Key: Closes the menu, setting the focus back on the button or element the menu was activated from. If the focus or hover was set to a different menu item, closing the menu with Esc will not update the selection.
---
# index
---
title: Select (native)
side_nav_title: Select (native)
side_nav_aria_label: Select (native)
tab_title: Code
description: HTML element that allows users to select one option from a dropdown menu.
meta_description: Get code for HTML elements that allow users to select one option from a dropdown menu.
thumbnail: assets/components/select-graphic.svg
categories:
- actions
- selection-controls
---
## Component Code Examples: select
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the select component
const component = parsed.components.find(c => c.name === 'select');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `select`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Select (native)
description: HTML element that allows users to select one option from a dropdown menu.
meta_description: Learn how to use HTML elements that allow users to select one option from a dropdown menu.
keywords: ["Select menu", "dropdown", "select input", "menu", "UIPickerView (iOS)", "Spinner (Android)", "Menu (Android)", "MenuItem (Android)"]
related:
components:
- dropdown-menu
- listbox
- radio
tab_order: 1
---
Select allows users to select one option from a list. They often appear in forms to save space and provide a clear, concise selection process.
Also known as: Select menu, dropdown, select input, menu, UIPickerView (iOS), Spinner (Android), Menu (Android), MenuItem (Android).
## Anatomy
**A. Label (required):** Text summarizing the options available for selection.
**B. Field (required):** Field displaying an empty state or the selected option.
**C. Chevron icon button (required):** UI icon button that expands or collapses menu.
**D. Menu (required):** Container displaying list of options that includes scroll bar as needed.
**E. Option (required):** Selectable text representing a single option.
## Usage
When to use and when not to use a select
- Component: To present a list of options when the user can only select one.
For long lists where all options can't be viewed at once or require scrolling.
If space is limited and displaying options in a collapsible menu would help.
- When to use: If users can select multiple options. Use [Multiselect](https://design.visa.com/components/multiselect/usage) instead.
For short lists where all options can be viewed without scrolling. Use a [Radio button group](https://design.visa.com/components/radio/usage) instead.
For long lists where users would benefit from entering text to filter or search the list options. Use a [Combobox](https://design.visa.com/components/combobox/usage) instead.
To present a list of actions. Use a [Dropdown menu](https://design.visa.com/components/dropdown-menu/usage) instead.
## Best practices
- List options in a logical order, either alphabetically or according to the most common or likely selection.
- Follow the default appearance and interaction of the select component on different browsers.
- Limit the number of options to avoid overwhelming users. Keep the options simple and straightforward.
### Select vs. dropdown
Select and [Dropdown menus](https://design.visa.com/components/dropdown-menu/usage) seem similar but have different functions and code. The select appearance will be determined by the browser, while the dropdown list can be styled as needed.
#### Select
Selects present a list of options from which the users can select only one option. They’re typically used in forms to help users choose an option from the list and submit data.
- Use the select component when users need to choose a single option from a list, especially when the choice is part of a form submission process.
#### Dropdown
Dropdowns present a list of options that users can select one or several options from that list. However, the options are used for taking an action, filtering, or sorting existing content.
- Use the dropdown component when users need to select one or multiple actions from a list, particularly when the actions involve sorting or filtering existing content.
### Appearance
Native selects are difficult to style consistently across different browsers as they leverage the native appearance. Each browser will render the menu differently, so it's important to test the select component on various devices.
#### Collapsed
The chevron should point down when the menu is collapsed.
- Allow users to expand the menu by selecting anywhere in the field, not just the chevron icon.
#### Expanded
The chevron should point up when the menu is expanded.
- Allow users to collapse the menu by removing focus from the field, not just by selecting the chevron icon.
### Optional vs. required labels
Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.
**Note:** Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current [Nielsen Norman Group](https://www.nngroup.com/articles/required-fields/) recommendations. Learn more about optional vs. required labels in [Forms](https://design.visa.com/patterns/forms/#optional-vs-required-labels).
### “Required” in the label (preferred method)
Including “required” within the label ensures it’s easy to find, particularly when instructions at the top might not be visible while scrolling. This method bolsters accessibility for both sighted and non-sighted users.
- Mark all fields that are required. This ensures you’re as explicit and transparent as possible.
- Include “(required)” in field label with a space between the last word and the first parenthesis.
### Asterisk in the label (alternative method)
Asterisks are commonly used to indicate required fields. The main advantage to using this method is that it doesn’t take up much space, helps users along a common edge, and can be used in addition to formatting hints in the label.
- Always include a legend or key at the top of the content area noting that the asterisk indicates a required field.
- Place the asterisk at the beginning of the label with a space between the symbol and the first word.
### When required is implied
Although it's usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.
### Labeling optional fields
It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.
## Behaviors
### Pre-selected options
Some browsers require the native select component to have an option selected by default. This is typically the first option in the list. To ensure users don’t mistake this preselected option as their own choice, developers can use one of two methods.
**Note:** Always work with your development team to ensure that the implementation of the select component design aligns with this default behavior.
#### First option empty
An empty option can be included as the first option. This option will be selected by default but does not represent a valid selection, prompting the user to make a choice. If the field is required, selecting the empty option and attempting to submit will result in an error. However, if the field is not required, it will not prompt an error if left empty.
- Leave field empty, both visually and programatically.
- Use descriptive labels to guide users to make a selection.
- Use error messages to guide users when a valid option is not selected.
#### First option disabled
The first option can be set as 'disabled' and 'selected' simultaneously, acting as a pseudo-placeholder. This option will be selected by default, but the user will not be able to choose it, encouraging them to select a different option. Once a user changes the selection, they cannot select the empty option anymore unless they reload the form/page.
- Use a descriptive text for the first, disabled option such as "Select an option" or “Choose an option.”
- Ensure the option is visually distinct from the rest of the options using disabled styling.
### Selection method
Users can select an option from the menu using the following method, which aims to simplify the process and prevent accidental selections.
**Note:** If you want to use an instant selection method, build your own using our low-level components and your own logic. Product teams using this method are responsible for ensuring accessibility standards and practices are met.
#### Select and confirm
Select and confirm requires users to confirm their choice before it's displayed in the field. When the user places focus on an option within the menu, it won't appear as the selected value in the field until the user selects the option they want on click or using the enter key.
- Ensure the selected option is not displayed until the user confirms their choice. This prevents accidental selection and gives users the opportunity to change their mind before submission.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
- Avoid using unnecessary articles like “the” or “an”, unless they’re included in the proper name of a product or service.
### Labels
- Limit field labels to a maximum of three to five words.
- Be consistent when using plural language or “(s)” in field labels. For example, use “Select card type”, “Select card types”, or “Select card type(s)” consistently. If using “(s)”, use the asterisk method to label required fields instead of “(required)” within parenthesis to keep concise.
- Use parallel structure across field labels, using either nouns like "Services" or verbs like "Select a service". Learn more about parallel structure in [Grammar and punctuation](https://design.visa.com/content/grammar#parallel-structure).
### Option labels
- Limit option labels to three words or fewer unless referencing proper nouns, such as product names.
- Avoid using unnecessary articles like “the” or “an”, unless they’re included in the proper name of a product or service.
- Consistently order labels across experiences based on logical sequence, either alphabetically or by importance.
### Inline messages
- Use full sentences with proper punctuation.
- Limit descriptions to 80 characters or 20 words including spaces.
- Provide useful information such as why a field is required (if not obvious) without being technical.
- Give an example or specific syntax or values for inputs to help avoid errors.
#### Inline error message
- Use inline error messages to draw attention and to errors without causing frustration.
- Provide clear, prescriptive guidance on correcting the error. Avoid redirecting users to another page to fix it.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
---
# index
---
title: Slider
tab_title: Usage
description: Control that allows users to make a selection along a range.
meta_description: Learn how to use controls that allow users to make a selection along a range.
thumbnail: assets/components/slider-graphic.svg
keywords: ["Range selector", "range slider", "trackbar", "scale", "control slider", "value selector", "UISlider (iOS)", "SeekBar (Android)"]
related:
components:
- checkbox
- radio
categories:
- actions
- selection-controls
---
Sliders are interactive controls enabling users to set or select a value along a range. They’re typically used in settings or configurations.
Also known as: Range selector, range slider, trackbar, scale, control slider, value selector, UISlider (iOS), SeekBar (Android).
## Anatomy
**A. Label (required):** Text indicating the purpose of the slider.
**B. Tooltip (optional):** Tooltip component used to indicate the currently selected value.
**C. Rail (required):** Background element representing the available range for the slider.
**D. Min/max value (optional):** Text or icon indicating the range of available values.
**E. Switch circle (required):** Interactive element used to set the value along the rail.
## Usage
When to use and when not to use a select
- When to use: To switch between content views. Use a [toggle button](https://design.visa.com/components/toggle-button/usage) instead.
In place of a [checkbox](https://design.visa.com/components/checkbox/usage) or [radio button](https://design.visa.com/components/radio/usage).
## Best practices
- Position the lower value on the left and the higher on the right for left-to-right languages.
- Consider using a [checkbox](https://design.visa.com/components/checkbox/usage) group or [radio](https://design.visa.com/components/radio/usage) if there are only a handful of options, as they can be easier to interact with.
### Discrete vs. continuous sliders
Sliders can be discrete or continuous, which refers to how the values behave when the slider is adjusted. Learn about each option below.
#### Discrete
Discrete sliders snap to specific values along the rail. They often have defined gaps in the values, like sets of five.
- Use discrete sliders when users need to select a distinct number from a range of predefined choices or steps.
#### Continuous
Continuous sliders don’t snap to specific values and can be set anywhere along the range.
- Use continuous sliders when users can select any value from a range, or the specific value is vague or not critical.
## Min-max range
Minimum and maximum values can be added to clarify the slider’s range. Min-max values can be implemented with text or icons.
### Min-max values in text
Textual values give exact numbers representing the minimum and maximum. This is helpful when the values are known and relevant to the user.
### Min-max values using icons
Icon min-max values visualize the range of values without specifying exact numbers. This is helpful when the values are unknown or not relevant to the user.
## Behaviors
### Dual-point sliders
A dual-point or double slider indicates an upper and lower boundary. Values can be adjusted from both ends, indicating a starting and ending value. This type of slider can be used instead two sliders and is common for filtering search results.
## Content
- Use sentence case without punctuation for all labels.
- Keep labels short to avoid unnecessary truncation.
- Avoid acronyms or jargon.
---
# accessibility
---
title: Switch
description: Binary control that allows users to toggle between two states like on/off.
meta_description: Find accessibility guidelines for binary controls that allow users to toggle between two states like on/off.
thumbnail: assets/components/switch-graphic.svg
tab_order: 2
---
## Best practices
**Note:** The switch component is implemented using a checkbox with `role="switch"`. Screen readers announce it as “on” and “off” instead of “checked” and “unchecked”. The keyboard behavior and best practices are the same as for the [Checkbox](https://design.visa.com/components/checkbox/accessibility) component.
---
# index
---
title: Switch
tab_title: Code
description: Binary control that allows users to toggle between two states like on/off.
meta_description: Get code for binary controls that allow users to toggle between two states like on/off.
thumbnail: assets/components/switch-graphic.svg
categories:
- actions
---
## Component Code Examples: switch
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the switch component
const component = parsed.components.find(c => c.name === 'switch');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `switch`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Switch
description: Binary control that allows users to toggle between two states like on/off.
meta_description: Learn how to use binary controls that allow users to toggle between two states like on/off.
keywords: ["Toggle switch", "flip switch", "light switch", "binary switch", "UISwitch (iOS)", "Switch (Android)"]
related:
components:
- checkbox
- radio
- toggle-button
tab_order: 1
---
Switches are interactive controls used to turn a setting or choice on or off. They’re commonly seen in settings or account configurations.
Also known as: Toggle switch, flip switch, light switch, binary switch, UISwitch (iOS), Switch (Android).
## Anatomy
**A. Label (required):** Text indicating the purpose of the switch.
**B. Description (optional):** Optional text that can be used to describe the label in more detail.
**C. Switch control (required):** Interactive element used to toggle the switch on or off.
## Usage
When to use and when not to use switch
- When to use: For settings that have an on/off or true/false state.
- When not to use: To switch between content views. Use a [toggle button](https://design.visa.com/components/toggle-button) instead.
In place of a [checkbox](https://design.visa.com/components/checkbox) or [radio button](https://design.visa.com/components/radio).
## Best practices
- Don’t use switches in place of radio buttons or checkboxes, except when two radio buttons are being used for a yes/no, on/off, or true/false choice.
- Ensure labels are placed closed to the switch control so it's clear they're related.
- Ensure the filled state indicates the switch is in the “on” position.
## Content
- Use sentence case without punctuation for all labels.
- Avoid acronyms or jargon.
- Keep labels short to avoid unnecessary truncation.
- Phrase labels to describe what the switch will do in the "on" position. For example, toggling to the "on" position should make the statement true.
- Use full sentences with proper punctuation for descriptions.
- Limit descriptions to one to two brief sentences.
---
# index
---
title: Tab bar
tab_title: Code
description: Mobile navigation bar that uses icons to navigate between main pages.
meta_description: Get code for mobile navigation bars that use icons to navigate between main pages.
thumbnail: assets/components/tab-bar-graphic.svg
categories:
- navigation
- structure-and-layout
---
## Component Code Examples: tab-bar
This component is available in the following libraries:
- **Flutter** (@visa/nova-flutter)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- Flutter → `@visa/nova-flutter`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- Flutter → `flutter`
**Example (Flutter 8.3.1)**:
```javascript
const libraryName = "flutter"; // Determined from Step 1
const version = "8.3.1"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-flutter-8.3.1.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the tab-bar component
const component = parsed.components.find(c => c.name === 'tab-bar');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `tab-bar`
**Available in**:
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Tab bar
description: Mobile navigation bar that uses icons to navigate between main pages.
meta_description: Learn how to use mobile navigation bars that use icons to navigate between main pages.
keywords: ["Bottom navigation", "tab strip", "tab navigation", "tab menu", "UITabBar (iOS)", "TabLayout (Android)"]
related:
components:
- top-app-bar
- navigation-drawer
- tabs
- badge
---
Tab bars enable users to navigate between the main pages of a mobile application. They’re typically anchored to the bottom of the screen on mobile applications. They organize content into labeled tabs and switching tabs takes users to a new page.
Also known as: Bottom navigation, tab strip, tab navigation, tab menu, UITabBar (iOS), TabLayout (Android).
## Anatomy
**A. Label (required):** Brief text describing the tab content.
**B. Active tab visual indicator (required):** Visual indicator showing the tab currently in view.
**C. Icon (required):** Icon used to represent the tab.
## Usage
When to use and when not to use a tab bar
- When to use: For mobile and tablet platforms.
- When not to use: For web platforms.
- When to use: For main destinations that users need to access from anywhere in the app.
- When not to use: For sub-destinations such as user preferences.
- When to use: When there are three to five linked destinations.
- When not to use: If there are less than three destinations.
## Best practices
- Reference [Application layouts](https://design.visa.com/patterns/application-layouts) for help deciding which navigation component is best for your use case.
- Avoid using more than five tabs in the tab bar.
- Clearly indicate the active tab to help users understand which tab is related to the information presented.
- Organize tabs in a logical order, such as placing the most frequently accessed tabs at the beginning.
- Ensure there’s sufficient touch area for each individual tab to allow for easy and accurate selection.
- Follow all guidance for implementing [Badges](https://design.visa.com/components/badge) on tab labels.
## Behaviors
### Badges
Tab bar navigation can be paired with number badges in the top right corner of the tab icon to display dynamic information, such as the number of messages. To learn more, reference [Badge](https://design.visa.com/components/badge).
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation for navigation items.
- Ensure labels match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Follow all best practices and guidelines implementing links. Reference [Link](https://design.visa.com/components/link) for more information.
- Limit labels to a few brief words to prevent unnecessary reflow.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# accessibility
---
title: Table
tab_order: 2
description: Fixed grid that organizes information or data using columns and rows.
meta_description: Find accessibility guidelines for fixed grids that organize information or data using columns and rows.
thumbnail: assets/components/table-graphic.svg
---
## Best practices
- If headers don't provide any functionality, they will not be focusable. Screen readers will be aware of headers by announcing them during navigation. They are also navigable during screen reader's reading or browsing mode.
### Table structure
- Ensure every table has a `<caption>`, which is visually hidden in this library using our screen reader class.
- Ensure the `<caption>` adds meaning to the table heading by giving additional information about the columns or contents.
- Ensure tables have both `<thead>` and `<tbody>` elements.
- Add `scope="col"` to the `<th>` elements inside the `<thead>`. Add one row header `<th scope="row">` to each row in the table body. The row header is usually the first or second cell. Using scopes greatly improves the experience for people using screen readers. Screen readers will announce a heading label along with the cell content.
- Use `scope`, `id`, and `headers` attributes if there are multiple rows of headers to associate them with the table cells.
### Table content
- Ensure that each form element ID is unique, which can be easy to forget when generating rows in a loop.
- Ensure links or buttons use aria-labels to clarify where they lead if the visible text is repeated. For example, if every row has a “Details” link, use “Details of <unique row item>”.
### Dynamic features
- Sortable columns’ `th` elements should have an `aria-sort` attribute with the dynamic value of the state. The header should have a focusable control to trigger the sort.
- Ensure checkboxes used to select a row are programmatically labeled with unique and meaningful text. They can use `aria-label` or `aria-labelledby` to connect them to the id of content in another column.
- Inform users in the table’s `caption` if there’s a control to hide columns.
- Use visible or hidden labels to clarify when external controls (such as search) interact with the table.
---
# index
---
title: Table
tab_title: Code
description: Fixed grid that organizes information or data using columns and rows.
meta_description: Get code for fixed grids that organize information or data using columns and rows.
thumbnail: assets/components/table-graphic.svg
categories:
- tables
---
## Component Code Examples: table
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the table component
const component = parsed.components.find(c => c.name === 'table');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `table`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Table
tab_order: 1
description: Fixed grid that organizes information or data using columns and rows.
meta_description: Learn how to use fixed grids that organize information or data using columns and rows.
keywords: ["Fixed table", "non-dynamic table", "read-only table", "non-editable table", "constant table", "static table"]
related:
components:
- pagination
patterns:
- dynamic-table
---
Tables organize and display information using rows and columns, enabling users to access and analyze data. They’re commonly used to sort large amounts of information or present key-value pairs.
Also known as: Fixed table, non-dynamic table, read-only table, non-editable table, constant table, static table.
## Anatomy
**A. Header row (required):** Row listing the category label for each column.
**B. Data row (required):** Horizontal grouping of data cells.
**C. Data column (required):** Vertical grouping of data cells under a category label.
**D. Data cell (required):** Individual value corresponding to a specific category label.
**E. Pagination (optional):** A set of links enabling users to navigate a large table split onto multiple pages.
## Usage
When to use and when not to use a table
- When to use: To organize and display data that can be grouped in rows and columns.
For read-only data that would benefit from being structured in a fixed format.
- When not to use: For more complex data that requires user interaction like filtering or exporting. Use a [Dynamic table](https://design.visa.com/patterns/dynamic-table) instead.
## Best practices
- Limit the data included to ensure all values support the table’s purpose without overwhelming users.
- Avoid truncating data within cells. If necessary, wrap content to ensure it remains visible.
- Consider using pagination if the user needs to scroll to see the entire table.
- Include clear error messaging if data can’t be loaded or if it’s taking longer than expected.
### Text alignment
Text alignment refers to how data is positioned within a cell, either to the right or left edge. Numeric data is typically right-aligned, while textual data is left-aligned to ensure readability and facilitate comparison of similar data types. Although different alignments can exist within a table, alignment should remain consistent within each column.
- Right-align all numeric data such as number count, currency, and dates.
- Left-align textual data such as names, emails, and locations.
- Ensure row headers match the alignment of the associated cell.
### Table style
Tables have two styling options to ensure rows and columns are easy to identify: Bands and dividers. Either method can be used to visually group information. Select the one that best fits your users’ data analysis needs.
### Banding
Banding refers to rows that use alternating background colors to help visually group information.
### Dividers
Dividers refer to thin lines used to show separations between rows, columns, or both.
### Key-value pairs
Tables can be used to present key-value pairs. Key-value pairs refer to datasets with two related pieces of information: A unique identifier or key, and its associated value. This format is useful for displaying structured data where each key is paired with a specific value, making it easy to read and understand.
- Use typography, like bold text, to differentiate the keys from the values.
- Omit the header row from the table unless it adds important context.
### Group headers
Group headers span across multiple columns to create categories within a table. They’re helpful for data that can be easily grouped or categorized.
- Consider using group headers if categorizing the table columns would help users analyze or identify the data.
- Ensure the group headers appear visually different from the header row and general data.
### Pagination
The pagination component is a set of links enabling users to navigate tables divided across multiple pages. This helps reduce cognitive load by reducing the amount of data shown at once. For general information on the pagination component, reference [Pagination](https://design.visa.com/components/pagination/usage).
- Use pagination when the data can’t be easily viewed on one page or requires significant scrolling.
- Place the pagination component below the last row of the table.
- Use the default pagination component for complex tables when space permits.
- Use the slim pagination component for less complex tables with fewer pages, or when space is limited.
- For very complex tables, consider using a [Dynamic table](https://design.visa.com/patterns/dynamic-table) instead to enable users to sort or filter the data.
## Behaviors
Tables have various behaviors designed to make data easy to understand and interact with. Reference the section below to learn about optional features that can be implemented based on the use case.
### Progress indicators
Progress indicators help users identify when data hasn’t finished loading. This is especially helpful for complex data tables, which can have lengthy load times. For general guidelines on progress indicators, reference [Progress](https://design.visa.com/components/progress/usage).
- Use a linear progress indicator in most cases to save space and align with the table layout.
- Place the indicator at the top of the table, stretching the entire width.
- Consider using skeleton loading as an additional visual indication that the data in the table is loading.
- Ensure the progress indicator uses different visual styling from the table header.
### Scroll
Scrolling can help users access data when there’s limited vertical space and all rows aren’t visible at once. This helps when there are few columns but many rows, when tables are likely to be viewed on mobile devices, or when you want to maintain the visibility of all columns.
When implementing vertical scroll, it’s recommended to use a sticky header. Learn more in the section below.
- Ensure the scroll bar is displayed by default so users are aware there's more data available.
- Avoid using a horizontal scroll bar. If there’s enough data that it’s necessary, use a [Dynamic table](https://design.visa.com/patterns/dynamic-table) instead.
### Sticky header
Sticky headers refer to header rows that remain visible when the user scrolls, ensuring it’s clear what column each cell pertains to. Upon scroll, data rows tuck under the header divider while the sticky header stays fixed at the top. This allows users to view the context of the data they are looking at as they scroll to see more.
- Consider implementing a sticky header when users can’t view all data rows in a single view.
- Use a [Divider](https://design.visa.com/components/divider/usage) or other visual indicator to ensure the sticky header appears visually different from other rows.
- Use [Elevation](https://design.visa.com/base-elements/elevation/usage) to visually indicate that the sticky header is floating “above” the rest of the table’s data.
## Platform considerations
### Recommended for responsive web only
The table component is designed and built for responsive web applications. When implemented on mobile devices, tables scroll where the screen cuts off, which may limit their accessibility and usability. Use caution implementing tables on screen sizes smaller than 768px.
## Content
- Use simple language—avoid abbreviations or jargon.
- Use sentence case, except for proper nouns or acronyms.
- Limit use of abbreviations unless the abbreviation is commonly understood and improves readability due to space constraints or line length.
- Ensure column and row headers have distinct labels. If duplicates are required, add additional context to ensure screen readers can differentiate them.
### Table titles and subtitles
- Use informative titles that describe the table as a whole.
- Use subtitles to describe complex tables.
- Don’t include punctuation for table titles.
- Limit titles to three to five descriptive words. If your title can’t be condensed, consider using a subtitle with your title.
- Limit subtitles to one to two short sentences with punctuation.
### Column headers
- Clearly label columns using short, concise, and scannable column headers.
- Ensure column headers accurately describe the contents so users can interpret the data without additional context.
- Include symbols for units or measurement along with its name. For example “Temperature (°F).”
### Table content
- Use short, scannable content within table rows.
- Don’t include symbols, such as “$”. Only include those within the header to avoid issues with filtering information.
- Only use punctuation when using decimals. Ensure all decimal places are consistent for filtering information.
---
# accessibility
---
title: Tabs
description: Organizational element that separates content and allows users to switch views.
meta_description: Find accessibility guidelines for organizational elements that separate content and allow users to switch views.
thumbnail: assets/components/tabs-graphic.svg
tab_order: 2
---
## Best practices
**Note:** Many of the tab components attributes and behaviors use are handled by our library. As with other form components, use IDs to associate additional instructions or error messaging so screen readers will read them. Reference [Angular](https://design.visa.com/components/tabs) or [React](https://design.visa.com/components/tabs) for examples.
- Add the `aria-controls="IDREF"` attribute, which refers to the `tabpanel`, so that it appropriately refers to the tabpanel element associated with the tab.
- Add `aria-selected="true"` when a user activates a tab, the one associated with the currently displayed panel.
- Add `aria-selected="false"` for all tab elements in the tab set except the active tab.
- Add `tabindex="-1"` when a tab is unselected so only the selected tab is in the page Tab sequence.
- Don't set `tabindex="0"` on the selected (active) tab element.
- Add the attribute `role="tabpanel"` to the panel containers, as we don’t export a tab panel in our components.
- Consider using `tabindex="0"` for panels that don’t contain a focusable element to make navigation easier for assistive technology users.
## Keyboard controls
Keyboard actions and their corresponding behaviors for tabs
- Key: Use the Tab key once to enter the tablist. Hit tab again to exit the group of tabs.
- Key: Moves between the tabs when the component group is in focus in a vertical tablist.
Focus loops within the tab set. When focus is on the last tab within the set, the down arrow key will move focus to the first tab. When focus is on the first tab within the set, the up arrow key will move focus to the last tab.
In the automatic update approach, content below the tab should update immediately to match the focused tab.
- Key: Moves between the tabs when the component group is in focus in horizontal tablist.
Focus loops within the tab set. When focus is on the last tab within the set, the right arrow key will move focus to the first tab. When focus is on the first tab within the set, the left arrow key will move focus to the last tab.
In the automatic update approach, content below the tab should update immediately to match the focused tab.
- Key: When the interaction requires a manual update, the user must initiate content load with the Enter key after arrow navigation.
---
# index
---
title: Tabs
tab_title: Code
description: Organizational element that separates content and allows users to switch views.
meta_description: Get code for organizational elements that separate content and allow users to switch views.
thumbnail: assets/components/tabs-graphic.svg
categories:
- selection-controls
- structure-and-layout
---
## Component Code Examples: tabs
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the tabs component
const component = parsed.components.find(c => c.name === 'tabs');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `tabs`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Tabs
description: Organizational element that separates content and allows users to switch views.
meta_description: Learn how to use organizational elements that separate content and allow users to switch views.
keywords: ["Tabbed interface", "tab group", "TabLayout (Android)", "TabItem (Android)"]
related:
components:
- accordion
- anchor-link-menu
tab_order: 1
---
Tabs are organizational elements that group related content. They help users navigate between sections of content by switching views within the same page or container.
Also known as: Tabbed interface, tab group, TabLayout (Android), TabItem (Android).
## Anatomy
**A. Label (required):** Brief text describing the tab content.
**B. Icon (optional):** Icon used to represent the tab.
**C. Active tab visual indicator (required):** Visual indicator showing the tab currently in view.
## Usage
When to use and when not to use different types of tabs
- Component: When there are more categories of content and longer tab labels.
- When to use: If your interface has limited vertical space.
- Component: When there are fewer categories of content and shorter tab labels.
- When to use: When the tab labels are long and can lead to truncation of text.
- Component: When tab labels are short and concise and using icons helps call attention to the content.
- When to use: When tab labels are longer and icons don’t add additional context.
## Best practices
- Reference [Application layouts](https://design.visa.com/patterns/application-layouts) for help deciding which navigation component is best for your use case.
- Organize tabs in a logical order, such as placing the most frequently accessed tabs at the beginning.
- Clearly indicate the active tab to help users understand which tab is related to the information presented.
- Limit the number of tabs to avoid overwhelming users. If you have more than five tabs, consider using a different navigation pattern.
- Avoid displaying disabled tabs without providing an explanation for why the tab is disabled.
### Vertical tabs
Vertical tabs are arranged in a single column on the left side of the content area for left-to-right languages. They’re ideal for interfaces with long tab labels or when there are many categories of content.
- Place the vertical tabs on the left side of the content area to align with common left-to-right reading patterns.
- Ensure the tab list is scrollable if necessary to prevent overwhelming users with too many choices at once.
- Consider using a nav menu to group related tabs and reduce clutter.
**Note:** Nav menus are built using a modified [dropdown menu](https://design.visa.com/components/dropdown-menu) component. For accessibility reasons, don’t use the default dropdown menu or replace it with a select component. Always consult with accessibility partners before modifying the behavior of any component.
### Horizontal tabs
Horizontal tabs are arranged in a single row at the top of the content area. They’re best used when there are fewer categories of content and shorter tab labels to avoid truncation.
- Limit the length of tab labels to avoid wrapping or truncation.
- Avoid using more than five to seven tabs.
- Ensure horizontal tabs adapt to different screen sizes. Consider using a nav menu for additional tabs on smaller screens.
### Stacked tabs
Stacked tabs are similar to horizontal tabs except they include an icon above the tab label. These are best used when more context could be added to tabs using by icons to represent the label in more detail.
## Behaviors
Tabs have various behaviors designed to make content easy to understand and interact with.
### Tabs for in-page content
The expected behavior of tabs is to enable users to access different information within a single page area. They should be positioned below the page title to prevent confusion with site navigation. Place related tabs next to the corresponding content and apply visual styling to emphasize their relationship.
- Place tabs near their related content.
- Use visual styling to clearly indicate the active tab.
### Scaling and reflow
Scaling and reflow refer to how tabs behave as the container size changes, especially when the container is too small to display all content at once. Tabs should adjust responsively to maintain usability and clarity, wrapping or reflowing as needed to fit within the available space.
- Ensure consistent margins and 6 px padding between tab elements to maintain a clean and organized layout.
- Ensure tabs are responsive and adapt to different screen sizes without causing truncation or hiding content.
## Platform considerations
### Mobile
#### Tabs as navigation
While the typical expected behaviors for tabs is to switch between views within the same page, they can also be used as the basis for navigation components, like [tab bar](https://design.visa.com/components/tab-bar). When implemented as a tab bar, switching tabs takes users to a new page.
#### Fixed width
When space and content allows, tab groups on small screens can extend to the width of the screen. Both native mobile and responsive web applications can use this layout.
#### Scrollable tabs (touch devices)
Tabs may overflow horizontally on touch devices, allowing users to scroll through them. This layout isn’t for use on desktop devices.
#### Stacked tabs (non-touch devices)
In the rare instance of a small screen without touch capabilities, tabs may be stacked on top themselves. Consider using an [accordion](https://design.visa.com/components/accordion) instead of tabs to save space.
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation for tab labels.
- Ensure labels match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Follow all best practices and guidelines implementing links. Reference [Link](https://design.visa.com/components/link) for more information.
- Limit labels to a few brief words to prevent unnecessary reflow.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# accessibility
---
title: Toggle button
description: Selection element that allows users to switch between states or views.
meta_description: Find accessibility guidelines for selection elements that allow users to switch between states or views.
thumbnail: assets/components/toggle-graphic.svg
tab_order: 2
---
## Best practices
Toggle buttons are implemented in several ways in our library. Single-select toggles are implemented as radios or buttons while multi-select toggles are implemented as checkboxes or buttons. Best practices and keyboard behavior follow the type of control being used.
- Ensure toggle containers wrap for narrow screens and high zoom levels.
- Use the `aria-pressed` attribute if you are using button components.
## Keyboard controls
### Single-select toggle buttons
Keyboard actions and their corresponding behaviors for single-select toggle buttons
- Key: Moves the focus and selection to the next option in the group and unselects the previously focused one.
Focus moves in a circular rotation within the group, so progressing past the last option returns focus to the first in the group.
- Key: Moves to the next focusable element outside the toggle button group.
### Multi-select toggle buttons
Keyboard actions and their corresponding behaviors for multi-select toggle buttons
- Key: Selects/unselects the toggle button when the component is in focus.
- Key: Moves keyboard focus to the next checkbox in a group or next interactive element.
---
# index
---
title: Toggle button
tab_title: Code
description: Selection element that allows users to switch between states or views.
meta_description: Get code for selection elements that allow users to switch between states or views.
thumbnail: assets/components/toggle-graphic.svg
categories:
- actions
- selection-controls
---
## Component Code Examples: toggle
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the toggle component
const component = parsed.components.find(c => c.name === 'toggle');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `toggle`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Toggle button
description: Selection element that allows users to switch between states or views.
meta_description: Learn how to use selection elements that allow users to switch between states or views.
keywords: ["Flip button", "state button", "selector", "UISegmentedControl (iOS)", "toggle button (Android)"]
related:
components:
- tabs
- switch
- checkbox
- radio
tab_order: 1
---
Toggles are selection tools, typically used to change the view of page information or apply a setting. They’re typically used in data visualization contexts like tables or graphs, forms, search results, and settings pages.
Also known as: Flip button, state button, selector, UISegmentedControl (iOS), toggle button (Android).
## Anatomy
**A. Label (optional):** Text describing the toggle button.
**B. Icon (optional):** Leading or trailing icon used instead of a label or to enhance its meaning.
## Usage
When to use and when not to use different types of toggle buttons
- Component: To change the view of a dataset.
When only one button can be active at a time.
- When to use: To change between pages or content sections. Use [tabs](https://design.visa.com/components/tabs/usage) instead.
- Component: To apply settings.
When any number of buttons may be active, including none.
- When to use: To perform actions or to group unrelated concepts.
## Best practices
- Don’t use toggles in place of [radio buttons](https://design.visa.com/components/radio/usage) or [checkboxes](https://design.visa.com/components/checkbox/usage).
- Ensure toggles within the same group are related and apply to the same element within the interface.
- Place toggles near the element they control to ensure their purpose and function is clear.
- Limit toggle groups to four or five buttons to avoid overwhelming users.
## Behaviors
Toggle buttons have two functionalities:
### Single-select
Single-select toggle buttons can only be selected one at a time. They represent options that can’t be applied at the same time, like separate views of a dataset. One button is always active, and selecting an inactive button deactivates the active button.
### Multi-select
Multi-select toggle buttons can have any number of buttons selected, including none. They’re commonly used to apply settings. Selecting an inactive button does not affect any active buttons. This is the only type of toggle that can be used alone to represent a single option.
## Content
- Use sentence case without punctuation for all labels.
- Avoid acronyms or jargon.
- Keep labels short to avoid unnecessary truncation.
- Phrase labels so selecting the toggle makes the statement true.
---
# accessibility
---
title: Tooltip
description: Short message communicating the function or context of a control or object.
meta_description: Find accessibility guidelines for short messages communicating the function or context of a control or object.
thumbnail: assets/components/tooltip-graphic.svg
tab_order: 2
---
## Best practices
- Ensure all tooltips are accessible using the keyboard as well as a mouse.
- Ensure the tooltip is attached to a focusable trigger object.
- Ensure the tooltip’s triggering object has `aria-describedby` with a value of the tooltip span’s `id`.
## Keyboard controls
Keyboard actions and their corresponding behaviors for tooltips
- Key: Moves focus to the tooltip’s trigger object. When that object is receives focus, the tooltip appears. When it loses focus, the tooltip disappears.
- Key: Dismisses tooltip.
---
# index
---
title: Tooltip
tab_title: Code
description: Short message communicating the function or context of a control or object.
meta_description: Get code for short messages communicating the function or context of a control or object.
thumbnail: assets/components/tooltip-graphic.svg
categories:
- feedback-and-status
---
## Component Code Examples: tooltip
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the tooltip component
const component = parsed.components.find(c => c.name === 'tooltip');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `tooltip`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Tooltip
description: Short message communicating the function or context of a control or object.
meta_description: Learn how to use short messages communicating the function or context of a control or object.
keywords: ["Help text", "hint", "info tip", "screen tip", "TooltipCompat (Android)"]
related:
components:
- dialog
content:
- accessible-text
tab_order: 1
---
Tooltips provide brief, contextual information about a control or element. They appear when users hover over the element with their cursor, or when it receives keyboard focus.
Also known as: Help text, hint, info tip, screen tip, TooltipCompat (Android).
## Anatomy
**A. Label (required):** Brief text providing information about a selected control or element.
## Usage
When to use and when not to use tooltip
- When to use: To give users supplementary details or context about a control or element.
- When not to use: For important information that needs to always be visible to users.
## Best practices
- Ensure tooltips provide relevant and helpful information that’s directly related to the element they’re associated with.
- Ensure tooltips are easily noticeable but don’t obscure their associated element or other important information.
- Ensure users can easily dismiss tooltips, especially if they hover over them accidentally. Tooltips should disappear when the user moves the cursor away or removes focus.
## Behaviors
### Paired component examples
#### Icon button
Include tooltips in icon buttons that aren’t labeled on screen, or when they may be hard to identify.
**Note:** Tooltips aren’t equivalent to image alt text. Reference [Acessible text](https://design.visa.com/content/accessible-text) to learn more.
#### Sliders
Show tooltips with the value when the user interacts with a [slider](https://design.visa.com/components/slider).
#### Table header tooltips
Provide tooltips for category headers if needed to add additional context for the user.
### Displaying content animation
When the mouse hovers over an element, the tooltip may appear with a delay of up to 500 milliseconds (0.5 seconds). Once the mouse moves away, the tooltip will disappear. When an element receives keyboard focus, the tooltip will immediately be displayed with the associated element, and it will disappear once the keyboard focus moves away.
Delay timing for hover, keyboard, and disappearing
- Appear delay (hover): Up to 500ms
- Appear delay (keyboard): None
- Disappear delay: None
## Placement
The recommended placement for tooltips is two pixels from the clickable area, center aligned from the top, bottom, left, or right side of the interactive element. Tooltip placement can be programmatically determined based on the position of the element on the screen to ensure it's always visible.
## Content
- Write all content in sentence case, except for acronyms or proper nouns.
- Don’t use punctuation for tooltips.
- Use abbreviations only when commonly understood.
- Limit labels to a few brief words.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# index
---
title: Top app bar
tab_title: Code
description: Navigation fixed to the top of mobile apps with logo, links, and global search.
meta_description: Get code for navigation fixed to the top of mobile apps with logo, links, and global search.
thumbnail: assets/components/top-app-bar-graphic.svg
categories:
- navigation
- structure-and-layout
---
## Component Code Examples: top-app-bar
This component is available in the following libraries:
- **Flutter** (@visa/nova-flutter)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- Flutter → `@visa/nova-flutter`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- Flutter → `flutter`
**Example (Flutter 8.3.1)**:
```javascript
const libraryName = "flutter"; // Determined from Step 1
const version = "8.3.1"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-flutter-8.3.1.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the top-app-bar component
const component = parsed.components.find(c => c.name === 'top-app-bar');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `top-app-bar`
**Available in**:
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Top app bar
description: Navigation fixed to the top of mobile apps with logo, links, and global search.
meta_description: Learn how to use navigation fixed to the top of mobile apps with logo, links, and global search.
keywords: ["App header", "navigation bar", "menu bar", "app bar", "NavigationBar (iOS)", "Toolbar (Android)"]
related:
components:
- navigation-drawer
- horizontal-navigation
content:
- information-architecture
tab_order: 1
---
The top app bar is a container enabling users to navigate mobile products or experiences. It's usually placed at the top of an app or website and turns into a [horizontal navigation](https://design.visa.com/components/horizontal-navigation/usage) bar on larger screens.
Also known as: App header, navigation bar, menu bar, app bar, NavigationBar (iOS), Toolbar (Android).
## Anatomy
**A. Menu icon (optional):** Menu containing links to navigate through the application.
**B. Brand mark (optional):** Visual element representing Visa, a partner brand, or a fictitious brand associated with the product.
**C. Global search (optional):** Icon button prompting a global search bar to find content across the whole site or app.
**D. User profile (optional):** Avatar component representing the current user’s account.
## Usage
When to use and when not to use top app bar
- Component: As a simple solution for navigating mobile applications.
- When to use: For larger screen sizes. Use [horizontal navigation](https://design.visa.com/components/horizontal-navigation/usage) instead.
- Component: To provide easy access to global search.
- When to use: If the app is designed for a specific task and doesn’t contain a lot of searchable content.
- Component: For the child pages of an application.
- When to use: If your app only has one page, a page title may not be necessary.
## Best practices
- Reference [Application layouts](https://design.visa.com/patterns/application-layouts) for help deciding which navigation component is best for your use case.
- Ensure the order of the navigation items is consistent throughout the application, as changing the order may confuse users.
- Consider making the brand mark and/or application name function as a link to the homepage of the experience.
- Ensure the top app bar is visible at all times, or have a clear way to bring it back into view when hidden.
- Follow all guidance found in [Search](https://design.visa.com/patterns/search), [Navigation drawer](https://design.visa.com/components/navigation-drawer/usage), and [Avatar](https://design.visa.com/components/avatar/usage) when implementing those items in the navigation.
### Icons
Top app bars use icons to save space and enable quick access to important functions. There are two types of icons, leading and trailing.
#### Leading icons
The leading icon refers to the icon on the left side of the screen for left-to-right languages. This icon is reserved for navigational purposes. In the default view, it’s used to expand a [navigation drawer](https://design.visa.com/components/navigation-drawer/usage). In certain cases, it can be replaced with a upward or backward arrow to move users to their previous screen. To learn more, reference the [Page title](https://design.visa.com/components/top-app-bar/usage#page-title) section below.
- Use one leading icon for navigation purposes only.
#### Trailing icons
Trailing icons refer to the icon(s) on the right side of the screen for left-to-right languages. These icons are used to represent common actions, like global search or account settings.
- Place the most-used actions toward the left and least-used actions on the right.
- Limit trailing icons to one or two to avoid overcrowding the menu.
- Only use commonly understood icons to ensure their purpose is clear.
## Behaviors
### Scrolling
By default, the top app bar is hidden when the user scrolls down on the page to provide full use of the screen. If the top app bar contains important actions, it can be fixed at the top of the screen for easy access.
#### Scrolls with content
#### Stays fixed at top
### Page title
The page title variant is a modified top app bar used for child pages in an application. In this use case, the brandmark is replaced by the current page title, and the hamburger menu is a back arrow enabling users to navigate back to the parent page.
### Top app bars as chat navigation
Top app bars can be used as navigation components within chat layouts. The icons can be further customized based on the layout or the intended user function. When implemented in panel chats, top app bar buttons may include a hamburger menu or options menu. The modal chat is less complex and may include minimize and close buttons. Reference [Chat](https://design.visa.com/patterns/chat) for more information.
## Platform considerations
### Mobile
Top app bars are used for mobile or very small responsive web screens. As screen size increases, its behavior changes to utilize the additional space.
#### 768 px (tablet)
As screen size increases for tablets or smaller web screens, the top app bar turns into the 786px [horizontal navigation](https://design.visa.com/components/horizontal-navigation/usage) component. The lower the resolution, the simpler the navigational bar appears in the viewport. At this size, links are placed in the hamburger menu and the application name and brand mark are centered instead of left-aligned.
### Web
When the screen size increases past 768 px, the top app bar turns into a [horizontal navigation](https://design.visa.com/components/horizontal-navigation/usage) component. At this size, links are displayed horizontally.
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation for navigation items.
- Ensure labels match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Follow all best practices and guidelines implementing links. Reference [Link](https://design.visa.com/components/link) for more information.
- Limit labels to a few brief words to prevent unnecessary reflow.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# accessibility
---
title: Vertical navigation
description: Navigation panel located next to page content on screens with sufficient space.
meta_description: Find accessibility guidelines for navigation panels located next to page content on screens with sufficient space.
thumbnail: assets/components/vertical-graphic.svg
tab_order: 2
---
## Best practices
**Note:** Vertical navs are made up of multiple components. Follow guidelines for each of those.
- Use a native HTML `header` landmark.
- Ensure any `nav` landmark elements have unique and descriptive `aria-labels`. The label text should not include the word “navigation” as the screen reader will already announce that and it will be redundant.
- Only use a `header` element for the primary navigation if your application has both top and side navigation.
- Use `aria-curent="page"` on the link which leads to the current page. Links in the vertical menu look like tabs and use css classes for tabs, but are not tabs and don’t have tab roles.
- Ensure the content in the nav responds to a small window.
### Logos
Our library has a classname just for the application name in the horizontal navigation component. There is a component for the Visa logo that adjusts for the user’s high contrast settings.
- Ensure the logo has an accessible name or is inside a link with an accessible name with `aria-hidden="true"` on the svg.
- Use one of the library’s classes for high contrast for a logo with light or dark foreground if you use a different logo, as setting a contrasting background behind the brand logo ensures it will have maximum contrast in high contrast mode without a visible change in default contrast mode.
### Skip to main content link
The skip to main content link allows keyboard users to go directly to the main content of the page. This link is first in the DOM (unless there is a skip to login link). It appears when users land on the page and activates the tab key and is only visible when it receives keyboard focus. Activating the link moves focus to the `main` component.
Reference the [examples](https://design.visa.com/components/vertical-navigation) to learn how to implement VPDS’s skip-link styles.
### Skip to log in link
When navigation includes an account log in, the skip to log in link will appear when users press tab after page load and is tacked onto the top of the navigation bar. If user presses tab again, the user will be prompted with the skip to main content link.
## Keyboard controls
Keyboard actions and their corresponding behaviors for vertical navigation
- Key: Moves focus to the next focusable element.
- Key: Prompts the button when focused.
- Key: Moves keyboard focus backwards to the previous interactive element in the navigation.
---
# index
---
title: Vertical navigation
tab_title: Code
description: Navigation panel located next to page content on screens with sufficient space.
meta_description: Get code for navigation panels located next to page content on screens with sufficient space.
thumbnail: assets/components/vertical-graphic.svg
categories:
- navigation
- structure-and-layout
---
## Component Code Examples: vertical-navigation
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the vertical-navigation component
const component = parsed.components.find(c => c.name === 'vertical-navigation');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `vertical-navigation`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# usage
---
title: Vertical navigation
tab_order: 1
description: Navigation panel located next to page content on screens with sufficient space.
meta_description: Learn how to use navigation panels located next to page content on screens with sufficient space.
keywords: ["Vertical menu", "sidebar navigation", "vertical navigation bar", "left/right navigation bar", "column navigation", "UINavigationController (iOS)", "Vertical ScrollView (Android)"]
related:
components:
- horizontal-navigation
- navigation-drawer
content:
- information-architecture
---
The vertical navigation component is a container enabling users to navigate a product or experience. It’s common on sites or applications with many links that may not fit horizontally.
Also known as: Vertical menu, sidebar navigation, vertical navigation bar, left/right navigation bar, column navigation, UINavigationController (iOS), Vertical ScrollView (Android).
## Anatomy
**A. Brand mark (optional):** Visual element representing Visa, a partner brand, or a fictitious brand associated with the product.
**B. Application name (optional):** Label indicating the name of the application.
**C. Section title (optional):** Title used to group navigation elements.
**D. Icon (optional):** Visual indicator used to enhance the meaning of the navigation link label.
**E. Navigation link (required):** Label indicating the destination of the link.
**F. Chevron (optional):** Icon indicating the collapsed or expanded state of a nested navigation item.
**G. User profile (optional):** Avatar component representing the current user’s account.
**H. Collapse icon (optional):** UI icon button used to collapse or expand the vertical navigation from the left side of the screen.
## Usage
When to use and when not to use vertical navigation
- When to use: For a large number of navigation items.
When horizontal space is limited.
- When not to use: If vertical space is limited.
If there are only a few navigational items, use [Horizontal navigation](https://design.visa.com/components/horizontal-navigation/usage) instead.
## Best practices
- Reference [Application layouts](https://design.visa.com/patterns/application-layouts) for help deciding which navigation component is best for your use case.
- Ensure the order of the navigation items is consistent throughout the application, as changing it may confuse users.
- Ensure text within the navigation panel wraps to a second line instead of truncating to ensure it’s fully visible to users.
- Include a vertical scroll bar if all navigation items can’t be viewed at once.
- Consider making the brand mark and/or application name function as a link to the homepage of the experience.
- Follow all guidance found in [Link](https://design.visa.com/components/link/usage) and [Avatar](https://design.visa.com/components/avatar/usage) for implementing a user profile in the navigation panel.
### Section titles and nesting
Section titles refer to static text used to group navigation items under a common category. They can be used with or without nested navigation items, which expand or collapse other navigation items. Both methods group related content and help users navigate easily. Decide which to use based on your use case and design preferences.
#### Section titles
Section titles group navigation items without nesting them. They’re helpful for grouping items that should always be visible within the menu.
- Use section titles to group items that should always be visible in the menu.
#### Nesting
Nesting items group links within collapsible sections. They’re helpful for more complex apps menus may benefit from limiting the number of links visible at once.
- Consider nesting items in longer navigation menus, as this can help save space and declutter the experience.
### Icon usage
Icons can be used in navigation menus to make scanning easier and reinforce familiar ideas.
- Ensure icon usage applies to all navigation items within the same hierarchy level. For example, if you use icons for some L1 labels, they should be used in all L1 items.
- Omit icons for nested items, but if they’re necessary, ensure all items within the nested level has one.
## Behaviors
### Scrolling
A scroll bar can be used if the navigation is long and doesn’t fit in one view. The navigation items will scroll, while the brand mark, application name, and any items at the bottom remain fixed in position.
### Collapsed state
Vertical navigation menus can include a collapse button enabing users to expand or collapse the whole menu as needed.
- Consider implementing a collapse button if users would benefit from additional horizontal space in the main content area.
### Chevron direction
Visually differentiate expanded and collapsed sections using the chevron direction.
#### Collapsed
Collapsed sections should use the downwards-pointing chevron to indicate collapsed content can be expanded.
#### Expanded
Expanded sections should use the upwards-pointing chevron to indicate expanded content can be collapsed.
## Platform considerations
### Mobile
Vertical navigation is recommended for web applications only. For responsive navigation on small screen sizes, or for mobile designs, consider using a [Navigation drawer](https://design.visa.com/components/navigation-drawer/usage) instead, which is prompted from a hamburger menu and overlays the page content.
## Content
- Write all content in sentence case, except for acronyms or proper nouns, like the application name.
- Don’t use punctuation for navigation items.
- Ensure labels match page titles to enhance the user’s understanding of the site’s information hierarchy.
- Follow all best practices and guidelines implementing links. Reference [Link](https://design.visa.com/components/link/usage) for more information.
- Limit labels to a few brief words to prevent unnecessary reflow.
- Reference [Grammar and punctuation](https://design.visa.com/content/grammar) to learn how to use parallel structure for consistent phrasing.
---
# index
---
title: Accessible text
description: Learn how to effectively apply alternative text and ARIA labels for improved accessibility.
meta_description: Learn how to effectively apply alternative text and ARIA labels for improved accessibility.
thumbnail: assets/content/accessible-text-graphic.svg
header_image: assets/content/alt-text-overview.svg
---
Accessible text refers to text used to improve the accessibility of web content. It includes all text included in the code to help assistive technology users understand and interact with interface elements.
This guidance gives an overview of how to effectively apply alternative text and ARIA labels for improved accessibility. For more guidance on creating inclusive digital experiences, visit [Accessibility](https://design.visa.com/global-accessibility-requirements). Internal users can also visit the [Visa Accessibility SharePoint](https://bookmarks.visa.com/vpds-vgar-accessibility).
## Alt attributes
Alternative text (also known as alt text, alt attributes, or alt descriptions) refers to HTML attributes that provide text descriptions for images. It’s an important accessibility consideration, enabling screen readers to announce descriptions to users who may not be able to perceive images otherwise.
### Screen reader optimization
Alt text descriptions should be written carefully to ensure it's clear and understandable to users. Follow the guidance below to ensure the best experience.
- Use proper punctuation and grammar to ensure descriptions are easy to understand. To learn more, reference [Grammar and punctuation](https://design.visa.com/content/grammar).
- Include a space as the first character in a description to ensure the screen reader pauses before announcing it. This helps users distinguish descriptions from other text.
- Consider hiding decorative images that don’t add meaning by including a null, or empty text alternative.
- Limit text alternatives to one sentence. If you need more than one short sentence to describe an image, which is often true for graphs or diagrams, use a two-part description method as outlined by the [Web Accessibility Initiative](https://www.w3.org/WAI/tutorials/images/complex/).
## Accessible Rich Internet Applications (ARIA) labels
ARIA (Accessible Rich Internet Applications) labels are attributes used in HTML to improve accessibility. They are particularly useful for content that’s difficult for people using screen readers and other assistive technology to understand. ARIA labels provide critical information to ensure these users can navigate and interact with interface elements.
### Best practices
- Use an ARIA label when an element doesn’t have a descriptive name or the name doesn’t provide enough context to understand what the element does.
- Don’t use ARIA and alt-text together to avoid redundancy. Use alt text for HTML img elements, and ARIA labels for other elements with the img role.
- Avoid using ARIA labels if they don’t add meaningful context. For more information, reference [No ARIA is better then Bad ARIA](https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/) from WCAG.
- Write ARIA labels in a “Learn more about x” format.
Aria label content
- Use: Learn more about Visa Token Services
- Instead of: Visa Token Service: read more
- Use: Read more about biometrics
- Instead of: Read more
---
# index
---
title: Grammar and punctuation
description: Learn Visa product grammar and punctuation styles to ensure consistent experiences.
meta_description: Learn Visa product grammar and punctuation styles to ensure consistent experiences.
thumbnail: assets/content/grammar-graphic.svg
---
Grammar refers to the rules for structuring and combining words into sentences. Punctuation refers to the marks used to structure, organize, and clarify sentences. Follow these guidelines to ensure all Visa experiences are consistent, easy to understand, and accurate.
We primarily follow the [Chicago Manual of Style](https://www.chicagomanualofstyle.org/home.html) for grammar, spelling, punctuation, and language usage. However, in some cases we refer to the [Associated Press (AP) Styleguide](https://www.apstylebook.com/).
## Active and passive voice
Active and passive voice refer to how a sentence is structured to highlight different parts of the action. In active voice, the subject performing the action is the main focus. This makes it easy to identify who or what is doing something. In passive voice, the action itself is the main focus, and it's not always clear who or what is doing it.
### Active voice
A sentence is in active voice when a subject, usually a person or entity like Visa, performs an action. Active voice is clear, concise, and actionable. This is the preferred method in most scenarios as it’s generally clearer, more direct, and more concise than passive voice.
How to use active voice
- Use: Add your credentials.
- Instead of: User credentials must be added.
- Use: Enter your response below.
- Instead of: Response should be entered below.
- Use: The content team regularly updates the style guide.
- Instead of: The style guide is regularly updated by the content team.
### Calls to action
A call to action (CTA) describes a [Button](https://design.visa.com/components/button/usage), [Link](https://design.visa.com/components/link/usage), or text intended to guide users toward a task or action.
CTAs should be written with command verbs to ensure it is clear what will happen when selected. Command verbs refer to descriptive verbs that give a direct order or instruction, like “Save”, “Apply”, or “Send”. The only exceptions are common navigational labels like “Next”, or “Back”.
- Ensure all buttons include command verbs like “Save”, “Apply”, or “Send”.
- Avoid using sensory language like “See” or “View”. For more information, reference [Inclusive language](https://design.visa.com/content/inclusive-language).
Call to action language and context
- **Call to action (CTA) language**: Learn more
Explore options
Browse credit cards
Compare products
- **Context**: Discovery or learning
- **Call to action (CTA) language**: Get started
Find your Visa card
Access offer
Download pdf
Check it out
- **Context**: General
- **Call to action (CTA) language**: Join now
Subscribe, Subscribe and save
Sign up
- **Context**: Newsletters
- **Call to action (CTA) language**: Learn more
Start reading
Begin tutorial
Review guide
- **Context**: Product onboarding, Documentation
- **Call to action (CTA) language**: Contact us
Chat with us
Get help
Connect to an expert
- **Context**: Support
- **Call to action (CTA) language**: Buy now
Place order
Complete purchase
Make transfer, Transfer now
Add to cart
Check out
- **Context**: Transactions
- **Call to action (CTA) language**: Next
Back
Continue
- **Context**: Navigation
### Passive voice
A sentence is in passive voice when the subject is omitted or de-emphasized, giving the feeling that something "just happens." While products and experiences usually use active voice, passive voice can be used to soften language and sound less accusatory towards the user or Visa. This is more appropriate in sensitive cases, such as legal statements or error messages, where leaving the subject out can avoid placing blame on the user.
- Use passive voice if you notice a command, instruction, or explanation sounds too critical or accusatory.
How to use the passive voice
- Use: The transaction was not processed due to insufficient funds.
- Instead of: You do not have enough funds to process this transaction.
- Use: Your card was declined.
- Instead of: We declined your card.
- Use: Something went wrong. Please reload the browser window.
- Instead of: You made an error.
We made an error.
- Use: The account was not found.
- Instead of: We can’t find your account.
## Capitalization
### Sentence case
Sentence case refers to capitalizing text like it’s in a sentence: the first letter is capitalized, and everything else is lower case. Sentence case is primarily used in UX writing for products because it's more modern, readable, and "human" than title case. It's also better for globalization as title case is uncommon outside English publications.
- Use sentence case for all aspects of Visa’s product experiences, including page titles, headings, and UI elements like tooltips or tabs.
### Title case
Title case refers to text that’s written with the first letter of each word capitalized. Only use title case for proper nouns, which include the names of people, places, and certain things, such as [Visa branded terms and products (internal only)](https://bookmarks.visa.com/vpds-visa-branded-terms-and-products). If referring to anything trademarked or copyrighted, refer to [Fictitious brands](https://bookmarks.visa.com/vpds-fictitious-brands) for general guidance or consult with the legal or brand team for official instructions on how to proceed.
### All caps
All caps refers to text written in all capital letters. This is reserved for acronyms and initialisms, some abbreviations like file extensions, and certain text styles like overlines.
#### Acronyms
Acronyms are terms based on the first letter of each word in a title, like VPDS for Visa Product Design System. Unless commonly understood, like PDF, acronyms should always be defined in proximity to where they’re being used, such as on the same page or within the same paragraph; for example, Visa Product Design System (VPDS).
Be mindful that users often jump around between content and don’t read everything on a page linearly, so sometimes acronyms need to be defined multiple times within the same experience.
- Use all capital letters for acronyms.
- Use acronyms only after you have defined and contextualized them. For a list of Visa and industry-specific acronyms, refer to the Visa Finance [Global Sourcing Acronyms and Glossary (internal only)](https://bookmarks.visa.com/vpds-global-sourcing-acronyms-and-glossary).
## Punctuation
Punctuation in products and experiences depends on use case. Follow the guidance below to ensure consistent punctuation across products and experiences.
- Use proper punctuation for all text containing full sentences.
- Omit end punctuation, such as periods, for all headings, titles, and UI labels.
- Use exclamation marks sparingly, ideally no more than once per page.
### Apostrophes
#### Contractions
Contractions are a type of abbreviation where words are shortened by omitting certain letters or sounds. These are typically created by combining two words, with the apostrophe placed where the omitted letters would’ve been. Examples of contractions include "don't" (do not), "can't" (cannot), "they're" (they are), and "it's" (it is or it has).
- Use contractions to make your content more conversational and human rather than academic or robotic.
- Avoid using apostrophes in place of numbers or letters unless forming contractions.
Example usage of contractions
- Use: Something didn’t work.
- Instead of: Something did not work.
- Use: This feature isn’t available.
- Instead of: This feature is not available.
- Use: We’re searching for your information.
- Instead of: We are searching for your information.
- Use: 2023
- Instead of: '23
#### Possessives
Possessives in English grammar are used to indicate ownership or a close relationship.
- Use apostrophes to show possession, such as “Visa’s products”.
- Add ‘s for singular nouns like “Company”, even if the word ends in an s.
- Add ‘s for plural nouns that don’t end in an s, like “Children”.
- Add an apostrophe at the end of the word for plural nouns ending in s, such as “Cities”.
Example usage of possessives
- Use: The company’s credit card
- Instead of: The companys credit card
The companies credit card
- Use: The children’s section
- Instead of: The childrens section
- Use: Several cities’
- Instead of: Several cities
### Commas
VPDS recommends oxford commas to boost clarity in written text. This refers to commas placed before the word “and” in a list or series of multiple items.
- Use the oxford (or serial) comma in all product contexts.
- Try breaking sentences with many commas into multiple sentences to improve readability and maintain a reasonable reading level.
Example of how to use a comma
- Use: “Visa uses a sixth grade reading level, sentence case, and white space to improve readability.”
- Instead of: “Visa uses a sixth grade reading level, sentence case and white space to improve readability.”
### Colons
Colons are used to show that a clause is directly related to the one before it.
- Use colons to introduce lists or steps in a process if the sentence is phrased as a complete thought that introduces the content to follow.
- Avoid using colons in sentences.
Examples of how to use colons
- Use: Visa uses the following conventions in all product content:
- Oxford comma
- Sentence case
- 6th grade reading level
- Instead of: Visa uses the following conventions in all product content
- Oxford comma
- Sentence case
- 6th grade reading level
### Semicolons
Semicolons are used to join related, independent clauses, but aren’t recommended for use in products or experiences.
- Try simplifying sentences with a comma to avoid using semicolons.
Examples of how to use semicolons
- Use: Visa connects is a global network, connecting the world by being the best way to pay and be paid.
- Instead of: Visa connects is a global network; we connect the world by being the best way to pay and be paid.
### Ellipses
Ellipses (…) can be a useful tool in UI and product content but should be used sparingly in body content or blocks of text.
### Parentheses
Parentheses are punctuation marks used for information that’s not essential to the main point of the sentence, but provides additional context or clarification. The information inside the parentheses can be a single word, a fragment, or multiple complete sentences.
- Use parentheses for supplemental information in body copy and UI. Never use brackets in place of parentheses.
Examples of how to use parentheses
- Use: In all UI text, including titles and tooltips, use sentence case (as opposed to title case).
- Instead of: In all UI text, including titles and tooltips, use sentence case [as opposed to title case].
- Use: Loading… (55% complete)
- Instead of: Loading… [55% complete]
## Symbols
Symbols shouldn’t be used in place of words like “and”, “or”, or “at”. This includes ampersands (&) or plus signs (+) in place of the word “and”, number signs (#) in place of the word “number”, at signs (@) in place of the word “at”, and slashes (\ or /) and the word “slash” in place of the the words “or,” or “and”.
- Avoid using symbols in place of written words in copy. The only exception is businesses, products, or teams whose names already include symbols, such as Design @ Visa.
Examples of how to use symbols
- Use: Pause your card at the touch of a button.
- Instead of: Pause your card @ the touch of a button
- Use: Save and quit
- Instead of: Save & quit
- Use: Terms and conditions
- Instead of: Terms + conditions
- Use: Enter your phone number.
- Instead of: Enter your phone #.
- Use: Your available balance is your current balance minus any pending charges.
- Instead of: Available balance = current balance – pending charges
### Icons
Text symbols should never be used in place of any Visa icon, no matter how closely they appear in resemblance. Always use the proper Visa-branded or generic icons. Learn more by visiting [Design kits](https://design.visa.com/designing/design-kits).
### Asterisks
Asterisks (*) are used to indicate a source citation (or footnote), an omission, and to point to a disclaimer or comment. The most common use case are disclaimers for products.
- Use the asterisk after every punctuation mark except for dashes. In the case of dashes, place the asterisk before the dash. It’s not necessary to end the disclaimer with an asterisk as you would with a quote.
- Remove spaces before and after an asterisk.
- Never use asterisks to censor inappropriate language. Instead, curse words and violent language should not be used.
Examples of how to use asterisks
- Use: Please enter your CVV number*
*A CVV, or card verification value, is typically a three- or four-digit number found on a credit card.
- Instead of: Please enter your CVV* number
\*Your CVV number is found on the back of your card and is typically 3 numbers.\*
## Dashes and hyphens
Em dashes, en dashes, and hyphens are distinct punctuation elements that are commonly misused. They can be entered in Microsoft Word from the Special Characters tab within the Advanced Symbols section in the Ribbon.
Keyboard shortcuts work in Microsoft Word and other software, like Figma. Refer to the following table for a quick guide on manually entering these characters in text.
Examples of how to use dashes
- Element: minus (-)
- MacOS: minus (-)
- Element: Option and minus (-)
- MacOS: Alt + type 0150 (use num lock)
- Element: Shift + Option + minus (-)
- MacOS: Ctrl + Alt + minus (-)
### Hyphens
Hyphens (-) are punctuation marks used to join words or parts of words together.
- Remove spaces before or after hyphens.
- Use a hyphen to combine two words when they come before a noun, not after.
- Always spell out common fractions and hyphenate them.
Examples of how to use hyphens
- Use: One-half of the pizzas are gone.
- Instead of: 1/2 of the pizzas are gone.
- Use: The interfaces are user friendly.
- Instead of: The interfaces are user-friendly.
- Use: User-friendly interfaces
- Instead of: User friendly interfaces
### En dashes
En dashes (–) are punctuation marks that are slightly longer than a hyphen (-) but shorter than an em dash (—). They’re typically used to indicate a range of values in place of the word "to" or to denote a connection or a conflict between two concepts.
- Remove spaces before or after hyphens.
- Use en dashes (–) to relate one concept to another.
- Avoid using an en dash instead of the words “from”, “to”, or “between” to introduce number ranges.
Examples of how to use En dashes
- Use: Set focus mode on your phone from 8 AM to 5 PM.
- Instead of: Set focus mode on your phone from 8 AM–5 PM.
- Use: Communication is important for establishing designer–developer collaboration.
- Instead of: Communication is important for establishing designer/developer collaboration.
### Em dashes
Em dashes (—) are the longest type of dash. They’re used in place of commas, colons, semi-colons, or parentheses to emphasize information.
- Remove spaces before or after hyphens.
- Use em dashes to separate additional, unessential information from the rest of the sentence.
- Use em dashes to separate distinct, related thoughts.
Examples of how to use Em dashes
- Context: Avoid using punctuation in UI labels—except for apostrophes or internal punctuation—to maintain a friendly tone and improve readability.
- Context: Enabling these security features for cardholders can reduce the number of false disputes issuers have to resolve—in other words, everybody wins.
## Abbreviations
In product content, it’s generally best to avoid uncommon or unnecessary abbreviations where possible. Instead, spell out terms to increase the clarity and legibility of your content. Refer to the [Chicago Manual of Style](https://www.chicagomanualofstyle.org/book/ed17/backmatter/index/a.html) for a detailed list of abbreviations.
### Honorifics and titles
Honorifics and titles are formal styles used to denote professional positions, academic qualifications, or certain family relationships. They can be prefixes, like "Dr.", "Prof.", or "Mr.", which are added before a person's name, or suffixes, like "Jr.", "Sr.", or "Ph.D.", which are added after a person's name.
- Avoid using English honorifics or social title abbreviations such as “Ms.”, “Mrs.”, or “Mr.” to reduce assumptions where gender identity or marital status are unknown.
- Capitalize the first letter and include a period and a space between title abbreviations and names, such as “Mr. Alex Miller.”
- Capitalize and omit periods for academic degrees, placing them after the name with a comma and space, such as “Alex Miller, PhD.”
### Latin abbreviations
- Avoid using abbreviations with Latin or Greek root words to increase clarity.
- Rephrase these terms to be more inclusive of non-native English speakers whose first languages have not adopted widespread use of these abbreviations.
Examples of how to use Latin abbreviations
- Use: For example,
- Instead of: e.g.,
- Use: For now
Temporarily
- Instead of: pro tem.
- Use: In other words,
More specifically,
- Instead of: i.e.,
- Use: Now
Immediately
Right away
- Instead of: stat.
#### Exceptions
Although plain language is the general standard for the UX industry, some Latin terms and abbreviations frequently appear in business, corporate, and research contexts.
- Consider the needs of your users based on localization requirements if you choose to include these terms.
Exeptions and context for using Latin abbreviations
- Term: “when necessary”
For a certain or special purpose requiring your attention
- Meaning: Job postings, descriptions, requirements
- Term: et cetera
“and the others” (inanimate objects)
- Meaning: Lists
- Term: et alia
Document detailing a person’s work experience and education
- Meaning: Job applications or postings
- Term: “after the event”
- Meaning: Statistics, scientific tests, logical fallacy
- Term: in re
“in the matter of” or “concerning”
- Meaning: Email subject lines
- Term: versus
“against”
- Meaning: Court cases, sports games
### Date and time abbreviations
Abbreviations are commonly used to express compact versions of time when space does not permit full versions. Learn more about formatting in [Date and time](https://design.visa.com/content/grammar/#date-and-time).
#### Days of the week
When space is limited, days may be expressed using the standard three or four letter abbreviation.
- Capitalize the first letter of the abbreviation.
- Remove punctuation unless grammatically necessary for the sentence.
Example usage of days of the week
- Use: Sun, Mon, Tues, Wed, Thurs, Fri, Sat
- Instead of: S, M, T, W, Th, F, Sa
#### Months
When space is limited, months may be expressed using the standard three letter abbreviation.
- Capitalize the first letter of the abbreviation.
- Remove punctuation unless grammatically necessary for the sentence.
Examples usage of months
- Use: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
- Instead of: J, F, M, A, M, J, J, A, S, O, N, D.
#### Time of day
Use AM/PM to indicate the time of day when using 12-hour time notation. Learn more about formatting in [Date and time](https://design.visa.com/content/grammar/#date-and-time).
- Capitalize both letters of the abbreviation.
- Remove punctuation unless grammatically necessary for the sentence.
Example usage of times of day
- Use: 12 AM
- Instead of: 12am, 12 a.m.
- Use: 12 PM
- Instead of: 12pm, 12 p.m.
### Time zones
Time zones are typically expressed using two or three uppercase letters, usually within parentheses.
- Capitalize all letters of the abbreviation.
- Include the abbreviation in parentheses following the time.
- Include a space before the zone abbreviation.
- Remove the S (for Standard) or D (for Daylight) if your users are in a single time zone.
- Include an S (for Standard) or D (for Daylight) if your users are in a combination of time zones.
Example usage of time zones
- Use: 5:00 PM (PT)
- Instead of: 5:00 PM (PDT)
- Use: 6:30 AM (CST)
- Instead of: 6:30 AM (cst)
### Units
Units are standards for expressing and measuring quantities. They help specify the amount, size, or degree of something within a specific measurement system.
- Include a space between the last digit of the numerical value and the unit abbreviation.
- Avoid pluralizing or adding periods after the unit of measurement unless needed to end the sentence or distinguish the unit from other words.
Example usage of units
- Use: 12 oz
- Instead of: 12 oz.
- Use: 45 lb
- Instead of: 45 lbs
- Use: Use 24 px margins.
- Instead of: Use 24 px. margins.
#### Units of measurement
The following tables shows commonly-used units of measurement in product or UX contexts.
Example usage of units of measurement
- Unit: Kilobytes
Gigabytes
Terabytes
- Abbreviation: KB
GB
TB
- Context: Storage size
- Unit: Pixels
Megapixels
Pixels per inch
Point
Density-independent pixels/dots per inch
- Abbreviation: px
MP
ppi
pt
dpi
- Context: Graphics
- Unit: Centimeters
Meters
Inches
Feet
- Abbreviation: cm
m
in
ft
- Context: Length
- Unit: Grams
Kilograms
Ounces
Pounds
- Abbreviation: g
kg
oz
lb
- Context: Weight
#### Units of time
Units of time may be expressed as abbreviations when there are space limitations.
- Spell out these units where possible instead of using abbreviations.
Example usage of units of time
- Use: second
- Instead of: sec
- Use: minute
- Instead of: min
- Use: hour
- Instead of: hr
- Use: day
- Instead of: d
- Use: month
- Instead of: mo
- Use: year
- Instead of: yr
## Date and time
### International notation
Visa follows [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html), the international standard maintained and governed by the International Organization for Standardization (ISO) in Geneva. To promote accuracy and prevent error, it’s used to standardize dates and times in product development, especially in back-end programming.
When indicating date and time in user-facing scenarios, select a formatting method based on regional conventions and user expectations. If your product serves a range of countries, use international notation as determined by IOS 8601.
### Regional notation
Throughout most of the world, date formatting follows ISO 8601. However, regional differences exist. Use the tables below to help determine the appropriate formatting for your use case and audience.
#### Date formatting
Date formatting differs by region. Use the table below to help determine the appropriate time formatting for your use case and audience.
Types of date format by country
- Majority of world countries: Day month, year
2 January, 2023
dd-mm-yyyy
02-01-2023
- China, Japan, North Korea, South Korea, Taiwan, Hungary, Mongolia, Lithuania, Bhutan, and ISO 8601: Year, month day
2023, January 2
yyyy-mm-dd
2023-01-02
- United States and territories: Month day, year
January 2, 2023
mm-dd-yyyy
01-02-2023
#### Time formatting
Time formatting differs by region. Use the table below to help determine the appropriate time formatting for your use case and audience.
Time format by country
- Majority of world countries and ISO 8601: 24-hour format:
hh:mm:ss
13:02:03
hh.mm.ss.sss
13:02:03:674
- United States and territories, the Commonwealth: 12-hour format:
hh:mm:ss AM or PM
01:02:03 PM
hh.mm.ss.sss AM or PM
01:02:03:674 PM
- The United Kingdom: Both 24 and 12-hour formats
## Numbers
Numbers are often formatted differently depending on the context. When formatting manually, be mindful of how the number appears in written text, when to truncate, what character (decimal or period) is used as the thousands separator, and how negative numbers are displayed.
- Use numerals for numbers 10 and above in written text and spell out numbers nine and below. This doesn’t apply to other formats like tables, or for precise units of measurement under 10.
- Use commas for numbers with four or more digits.
- Use en dashes between numbers without spaces to indicate a range.
- Use hyphens between groups of numbers, such as in phone numbers. Avoid using parentheses, spaces, or periods to separate numbers if possible, however there may be regional variations.
- Use the + sign before the country code when listing phone numbers for specificity.
Number format examples
- Use: Fintech is one of the fastest growing industries, with the market estimated at roughly $112.5 billion in 2021, with an expectation of reaching $332.5 billion by 2028 according to Globenewswire.com.
- Instead of: Fintech is one of the fastest growing industries, with the market estimated at roughly one hundred twelve billion five hundred million dollars in 2021, with an expectation of reaching three hundred thirty two million five hundred million by 2028 according to Globenewswire.com.
- Use: Visa initiated business with seven more partnering firms in July 2022.
- Instead of: Visa initiated business with 7 more partnering firms in July 2022.
- Use: Visa’s stock went up by 2.34 cents in the last minute.
- Instead of: Visa’s stock went up by two point thirty four cents in the last minute.
- Use: 15,000
6,948
- Instead of: 15k
6948
- Use: 0.00–49.99
- Instead of: 0.00–49.99
0.00-49.99
0.00 — 49.99
- Use: +1-347-555-0100
+1-347-555-0100
- Instead of: 347.555.0100
1-(347) 555-0100
### Negative numbers
Negative numbers can be formatted differently depending on the context or language. In written sentences, it is generally a good practice to use the symbol rather than spelling out the word "negative."
- Follow local best practices.
- Use the negative symbol without adding a space between the symbol and value.
- Use parentheses or brackets without adding spaces between the symbol and the amount.
- Avoid combining negative signs and parentheses or brackets.
- Apply the color red only with the appropriate negative symbol, parentheses, or bracket.
Negative number format examples
- Use: -23
23-
- Instead of: - 23
23 -
- Use: (23)
[23]
- Instead of: ( 23 )
( 23 )
- Use: -23 or 23-
(23) or [23]
- Instead of: -(23)
-[23]
- Use: Note: text in this cell is in a red font
-23
23-
(23)
[23]
- Instead of: Note: text in this cell is in a green font
-23
23-
(23)
[23]
### International currencies
Currencies are expressed differently across the world. [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) is the recognized international standard for representing currencies. Currencies can be represented both numerically and alphabetically, using either three digits or three letters. The alpha code uses the first two letters of the [ISO 3166-1 alpha-2](https://www.iso.org/iso-3166-country-codes.html) country code and the initial of the country’s main currency unit for the third letter.
#### General
- Place uppercase country codes before or after the amount.
- Add a space between the country code and the value.
- Insert an en dash between numerals to indicate a monetary range followed by the country code.
- Avoid spelling out currencies or currency codes.
- Shorten amounts over 999,999 (million, billion, trillion, or M, B, T).
Example formats for currency
- Use: 10 USD
30M EUR
- Instead of: 30,000,000 EUR
#### Symbols and decimals
When formatting currencies with symbols and numbers, consider the following locale-sensitive elements:
- Use the country’s [assigned currency symbol](https://www.xe.com/symbols/).
- Avoid adding a space between symbols and numerals unless local guidelines dictate.
- Place the symbol before or after the numeral, following local guidelines.
- Follow local guidelines to determine whether to use commas or periods when expressing decimals. For example, in the United States, this character is a period (.). In Germany, it is a comma (,). So, two thousand fifty-five and eight-tenths are displayed as 2,055.8 in the United States and 2.055,8 in Germany.
- Use an en dash between numerals to indicate a monetary range and include the symbol before all numerals to avoid mistaking the dash for a decimal.
The following chart shows commonly-used currencies and their formats:
Example format with columns for currency, locale, with symbol, and without symbol and code.
- Currency: en-US
- Locale: $15.50
- With symbol: $15.50 USD
- Currency: en-CA
€15,50 EUR
- Currency: en-GB
- Locale: £15.50
- With symbol: £15.50 GBP
- Currency: ja-JP
- Locale: ¥1550
- With symbol: ¥1550 JPY
- Currency: en-NZ
- Locale: $15.50
- With symbol: $15.50 NZD
- Currency: zh-HK
- Locale: $15.50
- With symbol: $15.50 HKD
- Currency: zh-SG
- Locale: $15.50
- With symbol: $15.50 SGD
- Currency: da-DK
- Locale: 15,50 kr.
- With symbol: $15.50 USD kr. DKR
*When presenting multiple currencies in the same context or presenting unfamiliar currencies, use the currency’s country code along with the symbol. For example, CAD and USD both use $.
## Pronouns
- Avoid using first-person pronouns like “we” or “us” within products. The user is less concerned with the authors of the experience and more concerned about completing tasks.
- Use second-person pronouns by referencing the reader as “you,” especially when giving instructions. Using “you” whenever you want to imply an action on the user’s part can help clarify where their involvement is required.
- Follow best practices outlined in [Inclusive language](https://design.visa.com/content/inclusive-language) when using third-person pronouns.
## Lists
Lists can be phrased and formatted in a variety of ways. Regardless of how you phrase or punctuate lists, ensure it’s consistent across list items or instances in your experience.
- Use consistent verb patterns and punctuation when making lists in sentences.
- Start a list of bullets with verbs or nouns and aim for the same length.
- Punctuate all sentences, bullets, or lists consistently.
### List type
Consider overall structure and the individual relationships between items when creating lists. This will help you determine which list construct is most appropriate for your content.
#### Bulleted lists
Lists of items with no successive relationship should use a bulleted structure but may still contain hierarchy or levels. Consider using a [Checkbox](https://design.visa.com/components/checkbox/usage) if list items are tasks or actions.
#### Lettered lists
Use letters to indicate distinct parts, like for denoting figures or labeling components of diagrams.
#### Numbered lists
Only use numbers and ordinals (1st, 2nd, 3rd; first, second, third, etc.) when indicating succession, order, chronology, or procedure. If these terms must be used, spell them out where possible to avoid using the number format, as some text editors and processors don’t support superscripts.
### List punctuation
Only use end punctuation in lists when the list item is a complete sentence. If complete sentences are used in a list, ensure all list items are full sentences. Do not break structure by mixing full sentences and fragments.
Examples of punctuation in a list
- Use: Visa uses the following conventions in all product content:
- Oxford comma
- Sentence case
- 6th grade reading level
- Instead of: Visa uses the following conventions in all product content:
- Use an oxford comma
- Sentence case
- Write at a 6th grade reading level?
- Use: In all product content:
- Use oxford commas.
- Use sentence case.
- Write at a 6th grade reading level.
- Instead of: In all product content:
- Use oxford commas
- Sentence case.
- Can you write at a 6th grade reading level?
## Parallel structure
Parallel structure means using the same pattern of words to show that two or more ideas have the same level of importance. In the product context, this is accomplished by using consistent sentence and language structure throughout your content. This uniformity helps users more easily form mental models of the interface and navigate intuitively.
Examples of parallel structure
- Use: Accounts | Transactions | Services | Profile
- Instead of: Accounts | Make a transaction | Services | Update profile
- Use: We’re using the power of our network to **create** new solutions, **stimulate** investments, and **promote** usage.
- Instead of: We’re using the power of our network to **create** new solutions, **stimulating** investments, and **promote** usage.
- Use: **Step 1: Diagnose**
**Step 4: Start implementing**
- Use: - **Use** expertise, data, and benchmarking to uncover opportunities
- **Validate** the findings to align on approach to drive business forward
- **Create** a comprehensive roadmap to get you to where you want to be in the future
- **Turn** process into action with VCA Managed Services that drive innovation
- Instead of: - **Use** expertise, data, and benchmarking to uncover opportunities
- **You'll** get findings to align on approach to drive business forward
- **Creating** a comprehensive roadmap can help get you to where you want to be in the future
- **By turning** process into action with VCA Managed Services you’ll drive innovation
- Use: Visa leadership principles:
- We lead by example
- We communicate openly
- We enable and inspire
- We excel with partners
- We act decisively
- We collaborate
- Instead of: Visa leadership principles:
- Lead by example!
- We communicate openly.
- Enable and inspire
- Can your skills help partners excel?
- Act decisively...
- and collaborate.
---
# index
---
title: Inclusive language
description: Gain insight into the use of inclusive language to ensure Visa products include everyone, everywhere.
meta_description: Gain insight into the use of inclusive language to ensure Visa products include everyone, everywhere.
thumbnail: assets/content/inclusive-language-graphic.svg
header_image: assets/content/inclusive-lang-overview.svg
---
Inclusive language refers to language that's respectful of all people regardless of gender, race, ethnicity, age, ability, or any other aspect of identity. For Visa to serve everyone, everywhere, we need to represent and speak to everyone, everywhere.
## Best practices
- **Reference identity with caution:** Ensure references to demographics, identity characteristics, or group membership is essential and relevant before including. When in doubt, opt for neutral language that applies to everyone.
- **Use accurate terms and phrases:** Always seek guidance from subject matter experts or representatives of the group you're referencing to confirm the appropriate language, terms, or phrases to use.
- **Prioritize people-first language:** Avoid labeling individuals, and when you find you must reference their group membership, acknowledge their humanity first.
- **Collect identity data sparingly and responsibly:** While it can ensure experiences relevant and accessible, always collaborate with the legal team before asking users for such information.
Collect data with caution
Consult Legal to ensure applicable laws don't prevent collecting or using demographic information.
### Personally identifiable information (PII)
Personally identifiable information (PII) includes unique identity characteristics that can be used to identify an individual, particularly when combined with other non-sensitive data. This includes full name, social security number, government-issued identification number, mailing or residential address, driver's license number, bank account number, passport number, or email address.
- Only collect PII when it's essential.
- Consult with your designated legal representative before collecting PII in Visa apps or experiences.
- Consider local laws pertaining to certain states, provinces, countries, and regions. Failure to comply can result in Visa and our partners risking fines and violations.
#### Collecting identity characteristics
Identity characteristics refer to personal attributes such as gender, race, and ethnicity that define an individual's identity.
- Only ask for these characteristics when it is immediately relevant to the product or experience or provides you with meaningful information to improve the experience for all users.
- Include the option to select multiple items to enable users to accurately represent themselves.
- Always include options such as “Prefer to self-describe” if collecting this information is essential to your product or experience.
- Avoid including items such as “other”, as it doesn't provide useful data and implies the identities not represented are less important than those that are. If your product can't accommodate custom input, consider including “Not listed”
**Note:** Some of the terms used below, such as those under “Race”, follow standards set by the US government, not Visa. Always confirm the most up-to-date language before collecting identity characteristics, and ensure they reflect the best practices established by your product's region or locale.
Terms for gender identity characteristics
- Use: Gender identity (with option to check multiple items):
- Non-binary
- Transgender woman
- Transgender man
- Cisgender woman
- Cisgender man
- Prefer to self-describe (with form) OR Not listed
- Prefer not to disclose
- Instead of: Sex:
- Male
- Female
- Intersex
- Other
- Use: Pronouns (with option to check multiple items):
- He/him/his
- She/her/hers
- They/them/theirs
- Prefer to self-describe (with form) or Not listed
- Prefer not to disclose
- Instead of: Pronouns:
- She/her/hers
- He/him/his
- Other
- Use: Sexual orientation (with option to check multiple items):
- Gay
- Lesbian
- Bisexual
- Queer
- Asexual
- Straight/heterosexual
- Prefer to self-describe (with form) OR Not listed
- Prefer not to disclose
- Instead of: Sexual orientation:
- Straight/heterosexual
- Gay
- Other
- Use: Race (with option to check multiple items):
- White or caucasion (Not Latinx or Hispanic)
- Latinx or Hispanic
- East Asian (Not Latinx or Hispanic)
- Black or African American (Not Latinx or Hispanic)
- Native Hawaiian or Pacific Islander (Not Latinx or Hispanic)
- Asian – Not listed (Not Latinx or Hispanic)
- Southeast Asian (Not Latinx or Hispanic)
- Middle Eastern or North African (Not Latinx or Hispanic)
- American Indian or Alaska Native (Not Latinx or Hispanic)
- Prefer not to disclose
- Instead of: Race
- Asian
- Black
- Indigenous
- White
- Other
- Use: Relationship status (with option to check multiple items):
- Single
- Married
- Unmarried partner
- Registered domestic partner
- Widowed
- Divorced
- Separated
- Prefer to self-describe
- Instead of: Relationship status:
- Single
- Married
- Widowed
- Separated
- Divorced
### People-first language
People-first language refers to terms and phrases that emphasize someone's humanity before their condition or group membership. In contrast, deficit-based language focuses on what people lack rather than what they possess. In general, avoid deficit-based language and reframe your language to focus on achievements instead. If you must mention a deficit or lack, do so with sensitive language.
- Describe the attribute(s) of a person or group as a secondary feature or characteristic, rather than using the attribute as the primary descriptor.
People-first language is not universal
While we generally align to people-first language when writing content in product interfaces, not all people prefer people-first language. Identity-first language is an alternative that places the descriptor first and is most common in specific communities. Ask individuals how they want to be referred to.
Example usage of people-first terms
- Use: Completed x years of high school
- Instead of: High school dropouts
- Use: People without a high school diploma
People without formal education
- Instead of: Poorly educated
Having little education
- Use: Neighborhoods/communities with high poverty rates
- Instead of: Inner-city
Disadvantaged
- Use: Opportunity gap
- Instead of: Achievement gap
### Universal language
Universal language means writing so everyone, everywhere can understand. As Visa connects businesses, banks, and governments in over 200 countries and territories, it's crucial to ensure products and experiences are usable to everyone they reach.
**Note:** While many Visa products reach global audiences, there are specific use cases for localization. If an experience is designed to target a specific audience or user in only one specific geographic region, the messaging can be localized to match their language, lexicon, culture, grammar, and UX/UI conventions.
## Psychographics
Psychographics are psychological attributes that describe people's attitudes and aspirations, usually used in reference to market research. These include values, lifestyle, attitudes and opinions, spending habits, and interests. Inclusive writing about psychographics means no user feels excluded based on these traits.
- Represent a diverse variety of lifestyles in imagery and examples to help people visualize themselves in association with Visa products. Use the [Visa Brand Identity Asset Library Photography Guidance (internal only)](https://bookmarks.visa.com/vpds-visa-brand-identity-asset-library-photography-guidance) for help selecting imagery.
## Demographics
Demographics refer to attributes like gender identity, orientation, relationship status, race, religion, age, and socioeconomic status. Inclusive language ensures that regardless of demographics, all users feel represented, welcome, and can understand and relate to content.
### Ability
When writing about ability, it's important to avoid ableist language. A more respectful and inclusive approach is to use people-first language. Ableist language, while often unintentional, can inadvertently devalue individuals with disabilities. It tends to undermine their individuality, equality, and dignity. For example, say “person with a disability” instead of “disabled person”. To learn more, visit [People-first language](https://design.visa.com/content/inclusive-language/#people-first-language).
#### Non-sensory guidance
Sensory guidance refers to instructions that use senses to describe actions or behaviors, such as “read” or “view”. Many metaphorical phrases contain insinuations that may not be inclusive of or are offensive to people with disabilities.
- Avoid using sensory language anywhere in product copy, especially for buttons, links, or calls to action.
#### Othering and reductive terms
Othering terms might insinuate there's something wrong with anyone or anything that isn't “typical”.
**Note:** Disabled is a valid state for HTML elements, but isn't appropriate for describing overall feature functionality.
### Age
Ageism is stereotyping or discriminating against individuals or groups based on age. Ageism can take many forms and is often unintentional or subtle.
- Be intentional with your language when talking about age to avoid ageist implications.
- Avoid language that “others” certain populations by segmenting them into one group.
### Gender, gender identity, and orientation
Any common phrases that are used to refer to everyone are gendered as masculine, like “man hours.” When discussing gender, pronouns, and orientation, use language that's accurate, descriptive, and prioritizes neutrality wherever possible.
- Avoid using masculine-gendered phrases like “man hours”
- Omit pronouns unless they're explicitly relevant to the use case.
- Use neutral phrasing like “they” when unsure of the correct pronouns.
### Race and ethnicity
Race and ethnicity are not synonymous and refer to distinct characteristics. While race refers to physical differences that groups and cultures consider socially significant, ethnicity refers to cultural characteristics like language, ancestry, and beliefs. Only reference race and ethnicity if it's immediately relevant.
- Be specific whenever possible to avoid grouping individuals who identify differently from each other.
- Use “Black, Indigenous, Hispanic, Asian, and other people of color” if you must broadly reference groups other than non-Hispanic white.
- Capitalize group titles such as “Asian” rather than “asian”.
- Avoid figurative language that equates white with positive and black or dark with negative, like “blacklisted”.
- Avoid phrases that reference race or race histories whenever possible, such as using “built-in feature” over “native feature”.
### Religion and culture
Many common phrases have origins that are not religiously inclusive or inappropriately reference specific cultures.
- Avoid references to religion whenever possible and opt for neutral phrases to ensure all users are represented.
## Firmographics: Writing about the industry
Firmographics are descriptive attributes used by B2B organizations to identify their target market and ideal customers. These may include industry, location, size, status or structure, and performance. These attributes contribute to the full picture that product designers and partners can consider to ensure they're mindful of stereotypes about business performance.
- Always use neutral language when describing businesses organizations, regardless of their size or performance.
- Use the table below to determine the appropriate phrasing and designation for organizations of various sizes.
**Note:** The following table outlines how business are classified in the United States based on size and revenue. These classifications may not apply in all countries. Always consult local guidelines to ensure you reference businesses accurately.
Neutral terms for company size, revenue, and industry
- Attribute: Company size can vary within industry and country, but generally, there are three categorizations based on number of employees:
- **Small business:** 1,500 employees or less
- **Mid-size or mid-market enterprise:** 1,500 to 2,000 employees
- **Large enterprise:** Over 2,000 employees
It's easy to make assumptions about businesses of various sizes, which means it's important to mitigate bias when it comes to companies of a specific size and the employees that work for them. One assumption that is often made about large enterprises is that they might be outmoded in their approach or might be slow-moving. Large businesses can be very innovative, take risks, and be disruptive! Companies of different sizes have varying needs, so there is no one-size-fits-all approach.
- Attribute: Company size can vary within industry and country, but generally, there are three categorizations based on revenue:
- **Small business:** $38.5 million in revenue
- **Mid-size or mid-market enterprise:** $38.5 million to $1 billion in revenue
- **Large enterprise:** Over $1 billion in revenue
It's easy to make assumptions about businesses of various sizes, which means it's important to mitigate bias when it comes to companies of a specific size and the employees that work for them. For example, there is an assumption that small businesses are typically comprised of struggling individuals working in less than ideal conditions. Small businesses comprise the majority of the world's businesses and can make a maximum of $38.5 million annually. Companies of different sizes have varying needs, so there is no one-size-fits-all approach.
- Attribute: Our biases can affect our perspective on businesses of varying industries. For instance, the bias that the engineering industry is exclusively for men or that education is for women might promote an affinity bias that inhibits these industries from hiring more diverse candidates (of course, any gender of individual can belong to any one of these industries). Every business is unique and has individual needs and approaches.
Visa is a financial services and technology company. We often target and work with these industry subtypes:
- Fintechs
- Merchants
- Inquirers
- Issuers
---
# index
---
title: Content
description: Explore our content guidelines to craft thoughtful and consistent interface content for a well-designed user experience.
thumbnail: assets/home/content-graphic.svg
meta_description: Explore our content guidelines to craft thoughtful and consistent interface content for a well-designed user experience.
page_size: large
show_table_of_contents: false
---
---
# index
---
title: Information architecture
description: Identify the best organizational structure based on page types and user needs.
meta_description: Learn how to structure, label, and organize content based on page types and user needs.
thumbnail: assets/content/ia/information-architecture-graphics.svg
related:
components:
- anchor-link-menu
- horizontal-navigation
- navigation-drawer
patterns:
- application-layouts
---
Information Architecture (IA) is the practice of organizing, structuring, and labeling content in an effective and understandable way. IA involves creating a clear and logical framework that helps users understand where they are and how to find what they’re looking for. Integrating IA early-on in the design process lays the groundwork for smooth and intuitive product experiences.
## Best practices
- Design simple, intuitive, and consistent navigation, avoiding unnecessary complexity.
- Offer meaningful choices to users, keeping the options limited and focused to avoid overwhelming them.
- Organize content logically and progressively. Learn more about [Progressive disclosure](https://design.visa.com/content/information-architecture/#progressive-disclosure).
- Regularly test, iterate, and document IA thoroughly.
- Use clear, consistent, descriptive labels to help users quickly identify and scan for information.
- Treat content as living items that change over time, have specific actions, and need to be managed and updated.
- Provide multiple ways to browse and search content, accommodating different mental models and preferences.
## Components of information architecture
### Organization systems
Organization systems are methods used to categorize and structure content so it’s easy to understand, navigate, and retrieve. They help create a logical flow and hierarchy within the content. There are three organization systems: sequential, hierarchical, and matrix.
#### Sequential
Sequential organization systems arrange content in a linear, step-by-step flow, guiding users through a predefined path. This method is particularly useful for processes or tasks that must be completed in a specific order, such as onboarding tutorials or checkout procedures. By presenting information in a sequence, users can easily follow along and understand each step, ensuring a smooth and logical progression.
#### Hierarchical
Hierarchical organization systems structure content in a tree-like format with parent-child relationships, creating a clear path from general to specific information. This approach is suitable for complex information where categories and subcategories help users drill down to locate specific content.
#### Matrix
Matrix organization systems allow content to be accessed through multiple pathways, providing users with various ways to navigate and find information. This system is particularly useful for content that can be logically categorized in more than one way. By offering multiple access points, this approach caters to different user preferences and mental models, enhancing the overall user experience.
### Labeling systems
Labeling systems are consistent and clear naming conventions that help users find information. Labels should be intuitive and convey information in the simplest format possible. There are three kinds of labeling systems: text-only, icon-only, and combined.
#### Text-only labels
Text-only labels use clear and explicit words to describe the content or function without additional cues like icons. These labels help users understand exactly what they will find or what action will occur.
- Use text-only or combined labels for navigation menus. Use icon-only labels especially for navigation menus
#### Icon-only labels
Icon-only labels use icons to represent the content or function helping users quickly navigate and understand content. Icons should be intuitive and quickly recognizable, helping users to quickly navigate and understand content. These are typically used on mobile experiences where combined or text-based labels might require too much space.
**Note:** Icon-only labels should not be the main labeling strategy in your product experience. A text-only or combined label is preferred.
- Use icon-only labels especially for navigation menus. This can be used very sparingly on mobile, such as a hamburger menu.
#### Combined labels
Combined labels use both text and icons to provide more cues about the content or function. This method enhances meaning by combining text with visuals to help with quick recognition.
- Use text-only or combined labels, especially for navigation menus.
- Ensure icons clearly match the text displayed to enhance meaning and avoid confusion.
### Navigation systems
Navigation systems guide users through content, helping them find information and complete actions quickly. Effective navigation can enhance an experience by providing clear pathways to information, reducing frustration, and increasing efficiency. They play a crucial role in ensuring users can find what they need without disorientation and achieve their goals with minimal effort. VPDS provides designs for common navigation experiences to ensure users can find information quickly. For more information, visit [Anchor link menu](https://design.visa.com/components/anchor-link-menu/usage), [Breadcrumbs](https://design.visa.com/components/breadcrumbs/usage), [Horizontal navigation](https://design.visa.com/components/horizontal-navigation/usage), [Navigation drawer](https://design.visa.com/components/navigation-drawer/usage), [Tab bar](https://design.visa.com/components/tab-bar/usage), [Top app bar](https://design.visa.com/components/top-app-bar/usage), or [Vertical navigation](https://design.visa.com/components/vertical-navigation/usage).
### Search systems
Search systems are mechanisms enabling users to locate specific information quickly using search queries and filters. Effective search systems improve user satisfaction, reduce time spent finding information, and help users complete tasks more efficiently, especially in large or complex information structures.
- Always provide accurate and relevant results to help maintain user engagement and trust in the system.
- Implement flexible search criteria so users can find relevant results regardless of the format or spelling of their query.
## Steps to create effective information architecture
### Step 1: User research
Conduct interviews, surveys, and usability tests to gain insights into user needs, behaviors, and pain points. Analyze this data to inform information architecture (IA) decisions, ensuring the design aligns with user expectations and improves overall user experience.
### Step 2: Content inventory and audit
Examine your website or experience to identify existing content and help teams define all the items or objects in their system. This activity can help you explore and refine your IA with a more informed perspective.
### Step 3: Sitemap creation
Develop a detailed sitemap and wireframes to visually represent the site's structure, illustrating the hierarchy, navigation paths, and content relationships. This helps align your team as they build an experience to ensure clarity and usability.
### Step 4: Wireframing and prototyping
Create visual blueprints of the layout and navigation for your experience. Wireframes provide a basic, low-fidelity representation of the design, focusing on structure and content placement without detailed styling. Prototypes build on wireframes with interactive elements and higher fidelity content, enabling designers and stakeholders to test and iterate on user interactions and design concepts before final development.
The fidelity level (low, medium, or high) used depends on the development stage, with lower fidelity for early conceptual stages and higher fidelity for later, more detailed designs. Learn more about using medium fidelity content in [Placeholder text](https://design.visa.com/content/placeholder-text).
### Step 5: Usability testing
Continuously test the IA of your product experience to gather feedback and make improvements. This process includes planning, designing realistic tasks, conducting tests with representative users, analyzing results, and refining the IA based on findings. Integrating usability testing ensures a user-centered structure to improve overall usability and satisfaction.
## Progressive disclosure
Progressive disclosure is an IA principle that helps manage complexity by revealing information progressively to users. It starts with presenting a simple, uncluttered interface that shows only the most essential information and actions. As users interact with the system, additional information and options are revealed based on their needs and actions, ensuring users are only presented with relevant information.
This approach prevents information overload. Implementing progressive disclosure involves showing primary actions first, providing progressive details through links or buttons, and offering contextual help when needed, ultimately creating more intuitive and user-friendly interfaces.
Benefits of progressive disclosure include improved usability, enhanced learning, and better decision-making, as users can focus on the task at hand without being distracted by unnecessary details. For example, an online banking application may initially show only the account balance and recent transactions, with options for transferring money or viewing detailed statements becoming available as users navigate. Learn more about progressive disclosure in [Forms](https://design.visa.com/patterns/forms).
---
# index
---
title: Messaging
description: Craft content for alert components to increase trust, reduce errors, and improve system performance.
meta_description: Craft content for alert components to increase trust, reduce errors, and improve system performance.
thumbnail: assets/content/alert-messaging-graphic.svg
---
Messages provide information about changes in a system or persistent conditions. Messaging applies to a range of components such as badges, banners, dialogs, flags, notification trays, section messages, and tooltips. Language used in these components is critical as they increase trust, reduce the likelihood of errors, and improve system performance.
For specific guidance on how to decide on the right component for your context, where to place it, and its level of disruption, visit [Feedback and status](https://design.visa.com/patterns/feedback-and-status).
## Anatomy
**A. Title (optional):** Descriptive text previewing the purpose of an alert.
**B. Message (required):** Text elaborating on the nature of the message or providing important context.
**C. Call to action (CTA) (required):** Buttons or links enabling users to respond to alerts by taking relevant actions.
## Best practices
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Be brief, descriptive, and direct.
- Keep the information useful. Don’t disrupt the user’s experience unless necessary.
### Titles
- Limit titles to three to five descriptive words, using the description to provide additional details.
- Avoid using unnecessary articles like “the” or “an”.
- Don’t include punctuation.
- Use descriptive language that indicates the purpose of the alert instead of terms like “warning” or “error”.
### Messages
- Provide details on the reason for the alert without being technical.
- Use contextually relevant language to help users understand why the message is important.
- Clearly outline the simplest way to fix the problem (if applicable) without sending them to another location for answers.
### Calls to action
- Give users the opportunity to edit, view, or in some cases undo their actions, especially if they’ve just created something or changed important settings.
- Use clear, actionable language that is easy to understand without additional context or information.
- Avoid using unnecessary articles like “the” or “an”.
- Don’t include punctuation.
- Avoid ableist verbs that focus on senses. For example, use “Play video” instead of “Watch video”.
- Include a “dismiss”, “cancel”, or “close” button if the alert doesn’t include a close “x” in the top right corner.
- Learn more about calls to action in [Grammar and punctuation](https://design.visa.com/content/grammar) or by visiting [Button](https://design.visa.com/components/button/usage).
## Voice and tone
Voice and tone are key elements to creating alert messages that are helpful without placing blame on the user. The guidance below discusses voice and tone recommendations specific to messages. To learn about voice and tone recommendations in other use cases, visit [Grammar and punctuation](https://design.visa.com/content/grammar).
### Active and passive voice
Using active or passive voice depends of the context and purpose of the message. As a general rule, active voice works better for providing clear, direct instructions, while passive voice is better for explaining errors or mistakes.
Use the active voice whenever possible. If the message sounds harsh, adjust to the passive voice to soften the message.
Learn more about [active and passive voice](https://design.visa.com/content/grammar/#active-and-passive-voice) in Grammar and punctuation.
#### Active voice examples
Use the active voice to communicate success, instructions, or neutral updates. This ensures it’s clear to the user what actions they must take or when they’ve completed a task successfully.
Example usage of active voice
- Use: You have successfully logged in.
- Instead of: The login has been successfully completed.
- Use: Your account is now active.
- Instead of: Account has been activated successfully.
- Use: You have 3 unread messages.
- Instead of: 3 messages have been unread.
- Use: You can update your privacy preferences in Settings.
- Instead of: Privacy preferences can be updated in Settings.
#### Passive voice examples
Use the passive voice to communicate errors and warnings. This helps avoid placing blame on users and softens negative updates. It’s also helpful when the cause of an error is unclear or nobody is at fault, such as network connection issues.
Example usage of passive voice
- Use: Page not found.
- Instead of: We can’t find this page.
- Use: Incorrect credentials. Please try again.
- Instead of: You entered the credentials incorrectly.
- Use: Network connection error. Please try again.
- Instead of: We lost connection. Please try again.
- Use: All required fields must be completed.
- Instead of: You must complete the required fields.
### Tone
At Visa, our tone is flexible depending on the context. When writing alert messages, prioritize giving clear, efficient information to help users complete their goals quickly. The tone should be neutral, clear, and helpful.
- Inform the user without causing alarm. Provide clear, concise instructions that help complete tasks.
- Be direct when providing next steps or instructions for correcting errors.
- Avoid using technical jargon, codes, acronyms, and terminology that assume the user has advanced knowledge.
- Avoid overly playful language, tongue-in-cheek references, or plays on words that aren’t widely understood.
- Avoid accusing or patronizing the user for failing to follow directions or misusing the system.
## Examples
### Informational message
Informational messages should provide information without disrupting the user’s workflow. They can communicate a change in state or important information about an experience or feature.
#### Banner
#### Dialog
#### Flag
#### Section message
### Success messages
Success messages are used to confirm a user’s action or task completion. They usually don’t require additional actions unless providing a pathway to undo the action being confirmed.
#### Banner
#### Dialog
#### Flag
#### Section message
### Warning messages
Warning messages are used to indicate a potential change in the user’s workflow or access to the system. Warning messages should use clear, informative language that conveys the appropriate level of urgency so the user knows how to respond.
#### Banner
#### Dialog
#### Flag
#### Section message
### Error messages
Error messages are used to indicate a a problem has already occurred or that there’s been a mistake during the user’s workflow. They should draw attention to what has happened, communicate the consequences, and tell the user what to do to move forward.
Error messages should use clear, informative language that conveys the appropriate level of urgency so the user knows how to respond.
#### Banner
#### Dialog
#### Flag
#### Section message
#### Inline error messages
Inline error messages are common across a range of components. For help prototyping content for common error messages, VPDS offers component variants with pre-written messages. Access these in the assets panel of our [Design kits](https://design.visa.com/designing/design-kits).
### Badges
Badges are compact components used to communicate status with limited text. There are generally two categories of badges. The first is numeric badges, which display a count or tally of notifications. The second is informational badges, which provide status updates when the number of notifications is unknown or irrelevant.
To learn more, visit [Badge guidance](https://design.visa.com/components/badge/usage).
When to use and when not to use different types of badges
- Do: Use single-word labels like ”Authorized”, “Pending”, “Paid”, “Unpaid”, “Shipped”, “Overdue”, “Ready”, “Complete”, or “Canceled”.
- Don't: Use verbs like “Cancel” as this can lead users to think the badge is a call to action.
- Do: Use no more than two to three short words to describe more complex information like “Out of stock”, “In stock”, or “On backorder”.
- Don't: Use vague labels that don’t appropriately match the urgency of the status status such as, “information,” where more context is needed.
- Do: Use numeric formatting for number badges, like “1”, “12”, “30”, etc.
- Don't: Write out numbers in text, as this can take up too much space.
---
# index
---
title: Placeholder text
description: Replace lorem ipsum text with relevant examples or custom placeholder content.
meta_description: Explore how and when to replace lorem ipsum text with relevant examples or custom placeholder content.
thumbnail: assets/content/placeholder-text-graphic.svg
---
This section outlines guidance for using mid-fidelity content as placeholder text in user-facing contexts. This generally means replacing lorem ipsum text with descriptive text to provide additional context and meaning within prototypes.
## Medium fidelity content
Medium fidelity content, also known as mid-fidelity content, refers to text and labels that describe an element or use case. This is different from low-fidelity content, like lorem ipsum text, or high-fidelity content you’d find in a functional interface.
- Use medium fidelity content when planning and prototyping, as it helps communicate the purpose of an element without requiring substantial content support.
### Naming formula
To ensure mid-fidelity labels are clear and descriptive, VPDS recommends using the **descriptor + text category** formula. This formula results in labels that are clear and descriptive by combining contextual information (descriptors) with text that identifies the purpose of the label (text categories).
**Note:** Descriptors can be left out of labels if the text category provides sufficient context. However, the text category should always be included.
#### Descriptors
Descriptors specify the exact element being labeled with context like location, category, or type. They help indicate sequential order, hierarchy, grouping, or placement. Here are the most common ones used throughout VPDS:
- Component names (like button, checkbox, or link)
- Group
- Level (like L1, L2, L3)
- Page
- Primary, secondary, tertiary
- Section
- Variant names (like informational, success, warning, or error)
**Note:** Use simple descriptors whenever possible, avoiding terms like 1st, 2nd, 3rd, first, second, third, or primary, secondary, or tertiary, as they become complicated beyond the third position. An exception to this rule is calls to action, where labeling “Primary action” and “Secondary action” are common.
#### Text categories
Text categories indicate the type of content being used in an element. These are an essential piece of mid-fidelity labels and should always be included. Here are the most common ones used throughout VPDS:
- Action (for buttons)
- Body text
- Header (for tables)
- Heading
- Label
- Subtitle
- Subheading
- Title
#### Examples
Below are examples of this naming convention formula used in context. For the specific naming conventions of each component, refer to their respective anatomy diagrams at the top of each page.
In this example, “group label” isn’t just any label, but one that describes the whole group of elements.
In this example, “Section title” differentiates the anchor links in one section of the page from the title of the entire page.
## Inline messages
In components, descriptive text is known as an inline message and typically appears below the main text category like a title or label. Inline messages can be optional or required depending on the context or state of a component.
- When composing generic inline messages, follow this formula: “This is required/optional text that describes the **component name / text category** in more detail.”
Having both the component name and text category isn’t always required. In some situations, it helps to refer to the component name if it looks similar to other components when taken out of context. In other instances, such as with more easily recognizable components, referring to just the text category is easier and simpler.
Constantly referring to the checkbox component within each element can get repetitive when users know which component they’re looking at.
As titles are turned off for banners by default, and banners may be confused with flags or section messages, it’s helpful for the message to refer specifically to the component name.
### Empty states
Inline messages should also be included in the empty state of a component to inform users when there’s no data to display in their current view. This can happen if searching or filtering yields no results, data hasn’t been added to an element, or the user doesn’t have permission to view the data. Reference [Feedback and status](https://design.visa.com/patterns/feedback-and-status) for more information.
## Custom content
Custom or fictitious content can be added to prototypes to help further indicate contextualize elements or add examples. Use this level of specificity when trademarked brands can’t be used but a real or simulated use case is needed to provide deeper context than generic labels. Refer to [Fictitious brands](https://bookmarks.visa.com/vpds-fictitious-brands) for more guidance.
---
# index
---
title: Readability
description: Make your content easy to read and understand so people can quickly find what they're looking for.
meta_description: Learn how to make your content easy to read and understand, so people can quickly find what they're looking for.
thumbnail: assets/content/readability-graphic.svg
header_image: assets/content/readability-overview.svg
---
Readability is a measure of how easy it is to read text-based content, which is critical for designing efficient and effective experiences. Users don’t spend a lot of time absorbing information, so it’s important to design experiences that promote scanability with high reading comprehension. This section provides guidance on maintaining clear, readable content.
Ensuring readability requires a combination careful language and phrasing, and visual design. While this section primarily focuses on language, reference [Typography](https://design.visa.com/base-elements/typography/usage) to learn more about, access, and download Visa typefaces to help support readability.
## Reading level
Reading level is one method for measuring readability. Certain formulas, like the the Flesch Reading Ease Score (FRES) and the Flesch-Kincaid Grade Level Test, can help with this. For high readability, Visa uses a 6th grade reading level for all product and documentation content at a global scale.
### Simple language
Many words have synonyms with a different reading level. Always choose shorter, simpler words to increase reading speed and decrease reading level.
Examples of simple language
- Use: About
- Instead of: Approximately
- Use: Buy
- Instead of: Purchase
- Use: Go
- Instead of: Proceed
- Use: Help
- Instead of: Assist
### Sentence length
Shorter sentences promote readability. Use shorter and simpler words, phrases, sentences, and sentence structures to express clearer thoughts. Long, complex sentences keep users from being able to understand information quickly.
Use this chart when writing to help you boost readability:
Difficulty levels of reading sentence by number of words per sentence
- Number of words per sentence: Very easy to read
- Number of words per sentence: Easy
- Number of words per sentence: Fairly easy
- Number of words per sentence: Standard
- Number of words per sentence: Fairly difficult
- Number of words per sentence: Difficult
- Number of words per sentence: Very difficult
## Hierarchy and spacing
Effective hierarchy makes content easy to consume and understand. It helps with scanability and tells users what information to focus on first. Think of it as your tool in guiding the reader’s attention to the content you want in the order you want them to see it.
- Ensure headings are descriptive to support scanning.
- Keep the appearance of text in the same category consistent. For more information, reference [Typography](https://design.visa.com/base-elements/typography/usage).
- Always use sentence case except for proper nouns or acronyms. For more information, reference [Grammar and punctuation](https://design.visa.com/content/grammar).
- Use sufficient negative space to prevent information overload.
---
# index
---
title: Voice and tone
description: Ensure products sound and feel like Visa by learning the foundational pillars of our voice and tone.
meta_description: Ensure products sound and feel like Visa by learning the foundational pillars of our voice and tone.
thumbnail: assets/content/voice-and-tone-graphic.svg
---
Voice and tone are key elements that establish how products sound and feel. Voice refers to Visa’s personality and values, which should appear consistently across experiences, while tone is an expression of mood and changes depending on context. This section describes the pillars of Visa’s voice and provides context on when and how to emulate different tones.
## Voice
To create cohesive, consistent product experiences, we should intentionally craft our content to maintain a voice that feels distinct to Visa. Writing without this voice in mind can create disjointed experiences that leave the user feeling confused and could highlight that content is being authored by multiple people with different approaches.
Our voice is embodied by 3 core qualities: active, readable, and human. The following sections unpack these qualities and explain how to use them to ensure our product content remains consistent.
ActiveActionable and globalVisa connects the world through fast, secure financial access enabled by a partner-trusted network. Our content should support and help users complete tasks quickly and efficiently. Ensure everyone, everywhere can meet their goals using clear, actionable language that translates seamlessly across the globe.ReadableClear, concise, thoughtfulMake experiences effortless by putting users first. Author content that anticipates what the user needs and answers their questions before they’ve asked—like a trusted advisor. Use direct and consistent language that’s easy to scan, makes task completion easy, and simplifies complex concepts.HumanEnergetic, authentic, personableOur products are designed by real people for real people behind the screen. Use inclusive language to empathize with users and show consideration and recognition of their humanity. Be personable and conversational—not too formal, not too casual, and never robotic.
## Tone
Tone is a device used by an author to elicit a feeling, making our messaging more relevant and useful to users as they complete their tasks and goals. This ensures we deliver the most useful language, exactly when users need it, and in the most effective way possible to reinforce the relationship between users and our products.
In general, we recommend a neutral tone that’s straightforward and direct. In certain contexts, tone can be adjusted to convey feelings like encouragement, enthusiasm, or positivity.
### Tones to use
Types of tones to use
- Tone: Positive, congratulatory
- Feeling conveyed to users: Success, task completion
- Context: Success! Your account has been created.
- Tone: Engaging, helpful
- Feeling conveyed to users: Instructions, support, documentation
- Context: Need help? Our support team is just a click away.
- Tone: Clear, direct
- Feeling conveyed to users: Error, alert
- Context: Something went wrong while processing your transaction. Try again in a few moments.
- Tone: Inviting, enthusiastic
- Feeling conveyed to users: First-time use, onboarding, support
- Context: Welcome to your dashboard! Ready to get started?
### Tones to avoid
Types of tones to avoid
- Tone: Aggressive, insensitive, dismissive
- Tone: Complicated, elaborate, intimidating
- Tone: Condescending, superior, pretentious
- Tone: Apathetic, indifferent, lifeless
- Tone: Ambiguous, confusing, indirect
---
# code
---
title: Start contributing to VPDS
description: Learn more about contributions and how you can help shape the future of the Visa Product Design System.
meta_description: Learn more about contributions and how you can help shape the future of the Visa Product Design System.
side_nav_title: Code
side_nav_order: 2
---
## Prep: Identify and validate the work
Before proposing a new component, pattern, or enhancement, make sure your code contribution is necessary. Start by exploring existing resources and checking the VPDS backlog.
1. **Explore existing resources:** Browse [components](https://design.visa.com/components) and [patterns](https://design.visa.com/patterns) to avoid duplication.
2. **Check the VPDS backlog:** Search for open items labeled “contribution” or “in progress” in the [VPDS backlog (internal only)](https://bookmarks.visa.com/vpds-backlog).
3. **Assess design support:** Determine if you need design support, especially if you’re introducing a new visual pattern (not just fixing a code bug).
**Note:** At this time, the VPDS team only has an outlined process for internal code contributions from Visa employees. External contributors may create new issues to work on, but don't have access to our Jira backlog.
### Questions to ask
- Does your contribution solve a common problem?
- Is it flexible enough to serve multiple use cases?
- Will it help other design system users?
- Does it replicate anything in the system? If so, is there evidence that your solution is more effective?
- Is it an enhancement of an existing area of the system, or something new?
- Does it align with Visa’s accessibility and brand standards?
- What impact could your solution have on existing implementations?
- Do you have the necessary resources—such as people, time, and tools—to ensure the contribution meets VPDS standards?
Not sure what kind of contribution you have or where to start? Take our quiz.
## Intake: Propose your idea
Once you’ve confirmed there’s a gap or opportunity, formally propose your idea. Contributors should submit a detailed proposal and the VPDS team will provide feedback and schedule follow-ups if needed.
1. **Determine your type of submission**
a. **For bug fixes:** Assign the ticket to yourself after reviewing the [VPDS backlog (internal only)](https://bookmarks.visa.com/vpds-backlog).
b. **For enhancements or new contributions:** Complete the [VPDS contribution intake form (internal only)](https://bookmarks.visa.com/vpds-contribution-intake-form) and include all required documentation.
2. **Define acceptance criteria:** Clearly outline what success looks like for your issue using our [acceptance criteria template (internal only)](https://bookmarks.visa.com/vpds-acceptance-criteria).
3. **Initial review:** The VPDS team will review your submission, provide feedback, and schedule follow-ups if needed.
4. **Present to the contribution guild (for new contributions):** If your proposal moves forward, you’ll be invited to present it to the VPDS guild. This meeting provides the opportunity to explain your idea, answer questions, and gather additional feedback.
5. **Guild decision (for new contributions):** After your presentation, the guild will review and vote on your proposal, considering priorities, business needs, and feasibility. You’ll be notified once a decision is made.
## Plan: Align and scope
If your idea is approved, you’ll move into the planning phase. Here, you and the VPDS team will work with you to define the scope and clarify roles.
1. **Form a working group:** Collaborate with the VPDS team—including design, content, development, and accessibility experts—to align on roles and responsibilities.
2. **Define the scope:** Decide together what’s in and out of scope, establish required deliverables, and set timelines.
3. **Clarify support pathways:** Set up check-ins with your VPDS working group or attend [office hours (internal only)](https://bookmarks.visa.com/vpds-office-hours) for additional support.
## Set up: Configure your environment
Follow the guidelines for the libraries you’ll be working in to ensure your coding environment is correctly configured.
- [HTML/CSS](https://github.com/visa/nova-styles/blob/main/CONTRIBUTING.md)
- [Angular](https://github.com/visa/nova-angular/blob/main/CONTRIBUTING.md)
- [React](https://github.com/visa/nova-react/blob/main/CONTRIBUTING.md)
- [Flutter](https://github.com/visa/nova-flutter/blob/main/CONTRIBUTING.md)
When developing your code, remember to:
- Build using the latest version of Nova and your preferred code library.
- Use and adhere to Visa's secure coding tools, guidelines, and practices.
- Avoid unnecessary dependencies in your code.
## Build: Create and refine
1. **Develop the code:** Write code to address the issue according to the agreed acceptance criteria.
2. **Run automated tests:** Verify that all components pass aXe automated accessibility tests. These tests are included in the code libraries.
3. **Ensure code coverage:** Maintain at least 80% code coverage through testing. Add new tests as needed for your contribution.
4. **Add documentation:** Document any new classes or properties, and include examples where applicable.
5. **Format your code:** Use [Prettier](https://github.com/prettier/prettier) to maintain consistency and readability. Each web library has its own .prettierrc file at the root, and Prettier is automatically installed as a development dependency.
6. **Write standard commit messages:** Follow the [standard-commit guidelines](https://www.conventionalcommits.org/en/v1.0.0/) to format your commit messages clearly and consistently.
## Submit: Create a pull request
1. **Link the issue:** Reference the original issue in your pull request description to close the issue upon merging.
2. **Review and feedback:** Gather any final feedback and make necessary updates. **Note:** Not all submissions will be accepted. If not accepted, constructive feedback will be provided.
3. **Go live:** After submission, your contribution will undergo rigorous accessibility and QA testing by the VPDS team before it’s published. This process may take some time.
## Want to contribute design assets or report a design issue?
Learn how you can contribute design assets or report issues.
---
# design
---
title: Start contributing to VPDS
description: Learn more about contributions and how you can help shape the future of the Visa Product Design System.
meta_description: Learn more about contributions and how you can help shape the future of the Visa Product Design System.
side_nav_title: Design
side_nav_order: 1
---
## Prep: Make sure it's needed
Before proposing a new component, pattern, or enhancement, make sure your contribution is necessary. Start by exploring existing resources and checking the VPDS backlog.
- **Explore existing resources:** Browse [components](https://design.visa.com/components) and [patterns](https://design.visa.com/patterns) to avoid duplication.
- **Check the VPDS backlog:** Search for open items labeled “contribution” or “in progress” in the [VPDS backlog (internal only)](https://bookmarks.visa.com/vpds-backlog).
**Note:** At this time the VPDS team is only accepting internal design contributions from Visa employees.
### Questions to ask
- Does your contribution solve a common problem?
- Is it flexible enough to serve multiple use cases?
- Will it help other design system users?
- Does it replicate anything in the system? If so, is there evidence that your solution is more effective?
- Is it an enhancement of an existing area of the system, or something new?
- Does it align with Visa’s accessibility and brand standards?
- What impact could your solution have on existing implementations?
- Do you have the necessary resources—such as people, time, and tools—to ensure the contribution meets VPDS standards?
Not sure what kind of contribution you have or where to start? Take our quiz.
## Intake: Propose your idea
Once you’ve confirmed there’s a gap or opportunity, formally propose your idea. The VPDS team will review your submission, provide feedback, and schedule follow-ups if needed.
1. **Submit an intake form:** Complete the [VPDS contribution intake form (internal only)](https://bookmarks.visa.com/vpds-contribution-intake-form) and include all required documentation.
2. **Initial review:** The VPDS team will review your submission, provide feedback, and schedule follow-ups if needed.
3. **Present to the contribution guild:** If your proposal moves forward, you’ll be invited to present it to the VPDS guild. This meeting provides the opportunity to explain your idea, answer questions, and gather additional feedback.
4. **Guild decision:** After your presentation, the contribution guild will review and vote on your proposal, considering backlog priorities, business needs, and feasibility. You’ll be notified once a decision is made.
## Plan: Align and scope
If your idea is approved, you’ll move into the planning phase. Here, you and the VPDS team will work with you to define the scope and clarify roles.
1. **Form a working group:** Collaborate with the VPDS team—including design, content, development, and accessibility experts—to align on roles and responsibilities.
2. **Define the scope:** Decide together what’s in and out of scope, establish required deliverables, and set timelines.
3. **Clarify support pathways:** Set up check-ins with your VPDS working group or attend [office hours (internal only)](https://bookmarks.visa.com/vpds-office-hours) for additional support.
## Define: Discovery and research
In this phase, gather additional information or use existing research to outline what’s needed, why it’s needed, and how it might be used across different contexts.
1. **Conduct or gather existing research:** Interview stakeholders to identify pain points and understand constraints (such as accessibility, responsiveness, interactivity, and localization). Research industry trends and best practices from organizations like the [Nielsen Norman Group](https://www.nngroup.com/).
2. **Competitive analysis:** Review how other teams at Visa or other design systems have addressed similar needs. Collect screenshots, prototypes, or code, and document relevant solutions.
3. **Create a design brief:** Clearly document the design needs using the [Contribution template (internal only)](https://bookmarks.visa.com/vpds-contribution-template) in Figma.
## Design: Create and refine
Contributors are responsible for creating and refining the design based on the design brief, while the VPDS team provides feedback throughout.
1. **Sketch and draft:** Sketch your idea or refine existing designs. Begin drafting initial guidelines—such as when to use or not use the component, best practices, and more—using the [Usage guidelines template (internal only)](https://bookmarks.visa.com/vpds-usage-guidelines-template).
2. **Prototype and outline specs:** Refer to the Nova Figma library to turn your sketches into prototypes. Document states, redlines, platform scaling, and details using the [VPDS specs checklist (internal only)](https://bookmarks.visa.com/vpds-specs-checklist).
3. **Refine and review:** Continue refining your design and documentation, ensuring all states, redlines, and scaling considerations are captured. Keep deliverables up to date and respond to VPDS feedback as needed.
## Deliver: Approval and handoff
Contributors are responsible for finalizing and delivering all required designs and documentation. The VPDS team will review and provide any final feedback before approval.
1. **Present to the VPDS team:** Walk the team through your designs and documentation, highlighting key decisions and addressing questions.
2. **Apply final feedback:** Gather any final feedback and make necessary updates.
3. **Submit final designs and documentation:** Package and deliver the final designs and usage guidance to the VPDS team for approval and inclusion in the system.
## Want to contribute code or report a bug?
Learn how you can contribute code or report issues.
---
# index
---
title: Start contributing to VPDS
description: Learn more about contributions and how you can help shape the future of the Visa Product Design System.
meta_description: Learn more about contributions and how you can help shape the future of the Visa Product Design System.
side_nav_title: Get started
tab_title: Overview
side_nav_order: 0
show_table_of_contents: false
---
The Visa Product Design System (VPDS) is built for our community. We invite designers, developers, and teams across Visa to contribute ideas, solutions, and improvements. Whether you’re enhancing a component, proposing a new pattern, or refining guidance—we welcome your input.
Want a quick overview of our contribution process? Take our quiz.
**Note:** While this quiz is publicly available, the VPDS team is only accepting internal design contributions from Visa employees.
## Why contribute?
Contributing to VPDS helps scale accessible, inclusive, and consistent product experiences across Visa. By contributing, you:
- **Solve once, share widely:** Reusable solutions help other teams and reduce redundant work.
- **Promote best practices:** Contributions ensure consistent accessibility, usability, and brand standards.
- **Showcase your work:** Gain recognition from your peers and further the impact of your day-to-day work.
- **Foster a stronger design community:** Sharing knowledge between teams promotes a healthy design culture.
- **Build a system that reflects real needs:** Contributions based on real product challenges make the system future-proof.
- **Shape the tools you use every day:** Your feedback guides the system’s roadmap, priorities, and growth.
## Who can contribute?
Anyone at Visa can contribute to VPDS. Whether you’re a product designer, content designer, engineer, accessibility specialist, or researcher—your perspective is valuable. We especially encourage contributions from teams addressing real-world needs or edge cases not yet covered by the system.
## What can you contribute?
There are several types of contributions you can make.
### New components and patterns
A new contribution proposes a brand new component, pattern, or guidance to be added to the design system. This can be a design, content, or code contribution. Examples include creating a slider component or developing a bucket-picker pattern.
### Component and pattern enhancements
An enhancement contribution adds a new feature or interaction to existing components, patterns, or guidance. This can be a design, content, or code contribution. Examples include adding a processing state for text buttons or adding new interactions like hot keys.
### Code bug fixes
A bug fix is a code contribution that resolves issues in our coded components or patterns to ensure their behavior matches expectations. This can be a code contribution only. Examples include fixing accessibility issues, correcting visual discrepancies, or restoring broken interactions.
## How do contributions help?
Contributions help VPDS evolve to meet the needs of real products. Your participation helps:
- **Increase adoption** by making the system more comprehensive.
- **Improve quality** through shared knowledge and testing.
- **Make it easier for teams** to build the right thing, the right way, faster.
The more we collaborate, the more powerful the system becomes.
## What's the contribution process?
Contributing to VPDS is a structured but flexible process:
- **Prep:** Review the [VPDS backlog (internal only)](https://bookmarks.visa.com/vpds-backlog) and existing [components](https://design.visa.com/components) or [patterns](https://design.visa.com/patterns) to ensure your idea is unique or an enhancement.
- **Intake:** Complete the [VPDS contribution intake form (internal only)](https://bookmarks.visa.com/vpds-contribution-intake-form) and present your idea to the VPDS Contribution Guild—a group that reviews and recommends contributions.
- **Plan:** If recommended, your contribution is added to the VPDS backlog and assigned a working group with design, content, development, and accessibility representatives.
- **Define:** Conduct any necessary discovery and research, using internal or external resources.
- **Design:** Bring well-developed ideas. The VPDS team is available for support during [office hours (internal only)](https://bookmarks.visa.com/vpds-office-hours) before you submit for final approval.
- **Deliver:** Once approved, the VPDS team will publish design assets and work with engineering to add development assets to applicable libraries. Changes will be published to the VPDS website, along with quality assessments and communications about your contribution.
## Ready to contribute?
Help transform the Visa Product Design System with your contribution.
---
# accessibility
---
title: Bar chart
description: Chart that uses rectangular bars to represent and compare values across different categories or groups.
meta_description: Find accessibility guidelines for bar charts to represent and compare values across different categories or groups.
tab_title: Accessibility
tab_order: 1
---
This chart component has built-in accessibility features to support creating accessible charts from the start. These include descriptive tag properties, keyboard navigation controls, and tools to ensure sufficient color contrast. Find accessibility guidance below.
## Best practices
Ensure the following best practices are met when implementing this component to create accessible data experiences for everyone, everywhere.
### Make thoughtful color choices
Ensure users of all abilities can understand the meaning of colors in your data visualization. Choose color combinations that provide sufficient contrast and add textures to support color-blind and low vision users.
#### Use accessible color palettes
Our data visualization color palettes are designed to ensure that data distinctions remain clear for users with various types of color vision deficiencies. Use this functionality to ensure sufficient contrast between colors and avoid relying only on color to differentiate categories or values.
For example, the Visa red to green divergent color palette ensures that all shades are seen as different values, even under different color-blindness simulators. Meanwhile, a default red to green color palette doesn’t make the shades distinct enough across the full range of the palette.
#### Add contrast with textures
Textures help differentiate categories when color doesn’t provide enough contrast. Use the texture fill option in our bar charts to improve accessibility for users with color vision deficiencies and maintain clarity when charts are printed in grayscale.
#### Outline light objects
Our chart components automatically add darker outlines to light-colored chart elements to ensure contrast and visibility against backgrounds and adjacent marks. Overriding this default behavior can make elements harder to distinguish from the chart background and reduce readability.
### Write clear alternative text
Use the chart components’ descriptive tag properties to provide concise and informative alternative text for screen readers.
A table that provides guidance for writing chart accessibility properties.
- Accessibility property: Summarize what the chart shows and the type of data.
Use simple language for straightforward charts. Describe the layout for uncommon chart types.
Avoid repeating the chart title or subtitle.
- Guidance: “This bar chart shows monthly payment volume for this year compared to last year.”
“This strip chart displays transaction volume across major European cities, with each city represented by a circle placed according to spending volume.”
- Accessibility property: Clearly state the takeaway and highlight key statistical insights and trends.
Group data points to show patterns or outliers.
Do not list numbers without explaining their meaning.
- Guidance: “Sales numbers increased every month except June and July.”
“Europe and Asia Pacific had over 5% growth, while Asia Pacific lagged the global average at 1%.”
- Accessibility property: Explain which controls or filters affect the chart.
Communicate any selections that have been applied to exclude or change the displayed data.
- Guidance: “The values in this chart are based on the filter selections applied to the dashboard.”
### Add descriptive labels for data
Use the chart components’ custom labeling options to provide clear and descriptive names for displayed data. Labels like “num_transactions” may work during analysis, but “Number of transactions” is easier for users to understand and interpret.
#### Data labels
Data labels are the textual representations of data values in charts or tables. Use descriptive labels when presenting data to end users to provide clarity and avoid technical jargon or shorthand that may confuse non-technical audiences.
#### Tooltips
Tooltips add contextual information about data points when users hover or focus on chart elements. Clear and descriptive labels in tooltips help users understand the meaning of the data without requiring knowledge of internal naming conventions.
## Keyboard controls
Keyboard actions and their corresponding behaviors for bar charts
- Key: Enter the chart area/drill down a level on the chart area or a bar group.
- Key: Drill up a level on a bar group or a bar.
- Key: Move among sibling bar groups or bars when focusing on a bar group or a bar.
- Key: Press and hold when using the arrow keys for the best navigation experience on a Mac (VoiceOver).
- Key: Dismiss the tooltip at any time.
---
# code
---
title: Bar chart
description: Chart that uses rectangular bars to represent and compare values across different categories or groups.
meta_description: Get code for bar charts to represent and compare values across different categories or groups.
tab_title: Code
tab_order: 3
show_table_of_contents: true
---
---
# examples
---
title: Bar chart
description: Chart that uses rectangular bars to represent and compare values across different categories or groups.
meta_description: Explore examples for bar charts to represent and compare values across different categories or groups.
tab_title: Examples
tab_order: 2
---
Explore our bar chart examples to see how the VCC bar chart component can be customized for specific business scenarios and analysis tasks.
Find design assets for these bar chart examples in our Figma [Data Experience Charts (internal only)](https://bookmarks.visa.com/vpds-data-experience-charts) library.
---
# index
---
title: Bar chart
tab_title: Usage
description: Chart that uses rectangular bars to represent and compare values across different categories or groups.
meta_description: Learn how to implement bar charts to represent and compare values across different categories or groups.
thumbnail: assets/data-visualization/chart-components/bar-chart-sm.svg
keywords: ["Bar graph", "column graph"]
filter:
category:
- trend
- ranking
related:
charts:
- design-visualization-guidelines/overview
- charts/line-chart
side_nav_order: 1
---
Bar charts use rectangular bars to represent values across different categories or groups. The height or length of each bar represents the numeric value for its category.
Also known as: Bar graph, column graph.
## Anatomy
**A. Title (optional):** Brief text summarizing the contents of the chart.
**B. Data table button (optional):** UI icon button enabling users to view the chart's data in table format.
**C. Keyboard instructions (required):** UI icon button enabling users to access the chart's keyboard navigation instructions.
**D. Subtitle (optional):** Additional text providing details, context, or instructions about the chart.
**E. Plot canvas (required):** Area containing the graphic part of the chart including axes, gridlines, and other elements.
**F. Data markers (required):** Bars representing data points where the length or height of the bar indicates its category's value.
**G. Quantitative axis (required):** Scale representing numeric values, either on the horizontal or vertical axis.
**H. Categorical axis (required):** Scale representing categories or dates, either on the horizontal or vertical axis.
## Usage
A table that displays when to use and when not to use different component variants.
- When to use: To show how trends change over longer time periods, like weeks, months, or quarters.
- When not to use: To compare trends over very short time periods, like days or hours. Consider using a [line chart](https://design.visa.com/data-visualization/charts/line-chart) instead.
When showing continuous changes over time. Consider using a [line chart](https://design.visa.com/data-visualization/charts/line-chart) instead.
- When to use: To show the precise value of each data point.
- When not to use: If your data includes extreme values that distort the scale. Consider using a distribution insight chart instead.
- When to use: To compare ranking across categories and quickly identify the highest and lowest values.
- When not to use: If summarizing your data into categories would hide meaningful patterns.
If you need to show composition within categories. Consider using a composition insight chart, such as stacked bar or clustered bar chart instead.
## Best practices
- Ensure the chart clearly communicates important takeaways, like if the data values are in a desirable or undesirable range.
- Always start the quantitative axis at zero to avoid distorting data or exaggerating differences in bar sizes.
- Avoid displaying too many data points as this makes bar charts difficult to read and interpret.
- Consider using [Pagination](https://design.visa.com/components/pagination) or group data into broader categories to limit how many data points are shown at a time.
- Provide in-context cues and labels to help users interpret the chart correctly without requiring significant effort.
### Layouts
Bar charts can be displayed vertically or horizontally based on the data included. Select whichever layout will provide better legibility and scannability.
#### Vertical layout
In this layout, bars are displayed next to one another with taller bars representing higher values.
- Use this layout to visualize trends, where each bar represents a date period such as week or month.
- Use this layout when data has a meaningful order, like age groups or a scale (low, medium, high).
#### Horizontal layout
In this layout, bars are displayed along the horizontal axis with longer bars representing higher values.
- Use this layout for data with distinct categories, such as countries or market segments.
- Use this layout to help make longer category names easier to read.
### Data order
Bars on the categorical axis should be arranged in a meaningful way to help users quickly grasp the point of the chart. When deciding on the data order, consider what would be the most useful reading order of the data, as well as the story being told.
- Use standard ordering for categories that are chronological, like days, months, or years, if the goal is to visualize changes over time.
- Sort categories in order of their values to emphasize ranking or the differences in quantities between categories.
### Chart size
Chart size should be based on the data within each chart. Use the columns in the [Responsive grid system](https://design.visa.com/base-elements/responsive-grid-system) to set the width of the card, as shown below. Adjust the card's height so it is proportional and accurately represents the shape of the data.
- Ensure charts are wide enough to be interpreted without scrolling or zooming.
- Consider the type of analysis users need to do with the chart, and ensure it’s large enough to support that goal.
### Color
Color can be used to emphasize meaningful information and draw attention to the most important information in a chart. Use one color from the [Neutral data visualization color palette (internal only)](https://dataexperience.visa.com/design-guide/color#What_to_do_when_color_has_no_meaning), unless encoding additional data with color would add significant value.
- Color should never be used alone to communicate meaning. For more, visit [Accessibility](https://design.visa.com/data-visualization/charts/bar-chart/accessibility).
- Learn more about using color for data visualization in the [Color guidelines (internal only)](https://dataexperience.visa.com/design-guide/color).
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Provide more detailed explanations and definitions for any complex metrics if needed.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Titles and subtitles
- Use clear, informative titles to help users understand the chart’s topic and key takeaways.
- Frame titles as a headline that summarizes the trend or insight.
- Use subtitles to add more detail about the data being shown and help users understand how to interpret the chart.
- Consider phrasing titles or subtitles as questions to guide the user’s analysis, especially on exploratory dashboards where users are likely to spend significant time analyzing data.
- Avoid titles and subtitles that are too general or vague.
### Labels
- Ensure numbers, dates, and other data or axis labels are formatted consistently.
- Follow plain language principles, such as using shorter and simpler words and phrases.
#### Number format
Simplify number formats to remove unnecessary details and reduce the mental effort needed to compare numbers. If needed, provide higher-precision numbers in a tooltip for users who want more information.
A table that displays recommended number formats for different data types.
- Data type: Use abbreviated format, such as 1.2k instead of 1,200.
- Data type: Use whole percentage points, except for special cases where basis points are needed.
- Data type: Use basis points (bps) when change percentage is very small. 1 bps equals 0.01% (0.0001 in decimal format).
- Data type: Round to the appropriate level of detail that is required for the analysis. For example, for U.S. currency round to the nearest dollar amount.
---
# accessibility
---
title: Dumbbell plot
description: Chart comparing the difference between two related variables across multiple categories or date periods.
meta_description: Find accessibility guidelines for dumbbell plots to compare two related variables across multiple categories.
tab_title: Accessibility
tab_order: 1
---
This chart component has built-in accessibility features to support creating accessible charts from the start. These include descriptive tag properties, keyboard navigation controls, and tools to ensure sufficient color contrast. Find accessibility guidance below.
## Best practices
Ensure the following best practices are met when implementing this component to create accessible data experiences for everyone, everywhere.
### Make thoughtful color choices
Ensure users of all abilities can understand the meaning of colors in your data visualization. Choose color combinations that provide sufficient contrast and add textures to support color-blind and low vision users.
#### Use accessible color palettes
Our data visualization color palettes are designed to ensure that data distinctions remain clear for users with various types of color vision deficiencies. Use this functionality to ensure sufficient contrast between colors and avoid relying only on color to differentiate categories or values.
For example, the Visa red to green divergent color palette ensures that all shades are seen as different values, even under different color-blindness simulators. Meanwhile, a default red to green color palette doesn’t make the shades distinct enough across the full range of the palette.
#### Outline light objects
Our chart components automatically add darker outlines to light-colored chart elements to ensure contrast and visibility against backgrounds and adjacent marks. Overriding this default behavior can make elements harder to distinguish from the chart background and reduce readability.
### Write clear alternative text
Use the chart components’ descriptive tag properties to provide concise and informative alternative text for screen readers.
A table that provides guidance for writing chart accessibility properties.
- Accessibility property: Summarize what the chart shows and the type of data.
Use simple language for straightforward charts. Describe the layout for uncommon chart types.
Avoid repeating the chart title or subtitle.
- Guidance: “This bar chart shows monthly payment volume for this year compared to last year.”
“This strip chart displays transaction volume across major European cities, with each city represented by a circle placed according to spending volume.”
- Accessibility property: Clearly state the takeaway and highlight key statistical insights and trends.
Group data points to show patterns or outliers.
Do not list numbers without explaining their meaning.
- Guidance: “Sales numbers increased every month except June and July.”
“Europe and Asia Pacific had over 5% growth, while Asia Pacific lagged the global average at 1%.”
- Accessibility property: Explain which controls or filters affect the chart.
Communicate any selections that have been applied to exclude or change the displayed data.
- Guidance: “The values in this chart are based on the filter selections applied to the dashboard.”
### Add descriptive labels for data
Use the chart components’ custom labeling options to provide clear and descriptive names for displayed data. Labels like “num_transactions” may work during analysis, but “Number of transactions” is easier for users to understand and interpret.
#### Data labels
Data labels are the textual representations of data values in charts or tables. Use descriptive labels when presenting data to end users to provide clarity and avoid technical jargon or shorthand that may confuse non-technical audiences.
#### Tooltips
Tooltips add contextual information about data points when users hover or focus on chart elements. Clear and descriptive labels in tooltips help users understand the meaning of the data without requiring knowledge of internal naming conventions.
## Keyboard controls
Keyboard actions and their corresponding behaviors for dumbbell plots
---
# code
---
title: Dumbbell plot
description: Chart comparing the difference between two related variables across multiple categories or date periods.
meta_description: Get code for dumbbell plots to compare two related variables across multiple categories.
tab_title: Code
tab_order: 3
thumbnail: assets/flows/fileupload-graphic.svg
show_table_of_contents: true
---
---
# examples
---
title: Dumbbell plot
description: Chart comparing the difference between two related variables across multiple categories or date periods.
meta_description: Explore examples of dumbbell plots to compare two related variables across multiple categories.
tab_title: Examples
tab_order: 2
thumbnail: assets/flows/fileupload-graphic.svg
---
Explore our dumbbell plot examples to see how the VCC dumbbell plot component can be customized for specific business scenarios and analysis tasks.
Find design assets for these dumbbell plot examples in our Figma [Data Experience Charts (internal only)](https://bookmarks.visa.com/vpds-data-experience-charts) library.
---
# index
---
title: Dumbbell plot
description: Chart comparing the difference between two related variables across multiple categories or date periods.
meta_description: Learn how to use dumbbell plots to compare two related variables across multiple categories.
tab_title: Usage
thumbnail: assets/data-visualization/chart-components/dumbbell-sm.svg
keywords: ["Barbell chart", "connected dot plot"]
filter:
category:
- deviation
- trend
related:
charts:
- design-visualization-guidelines/overview
- charts/line-chart
side_nav_order: 2
---
Dumbbell plots use dots connected by lines to compare the values of two series of data. The position of the dots represents the numeric values, with the length of the line showing the difference or gap between the data series.
Also known as: Barbell chart, connected dot plot.
## Anatomy
**A. Title (optional):** Brief text summarizing the contents of the chart.
**B. Data table button (optional):** UI icon button enabling users to view the chart's data in table format.
**C. Keyboard instructions (required):** UI icon button enabling users to access the chart's keyboard navigation instructions.
**D. Subtitle (optional):** Additional text providing details, context, or instructions about the chart.
**E. Legend (optional):** Area explaining the meaning of each dot in the dumbbell plot to help users interpret the chart.
**F. Plot canvas (required):** Area containing the graphic part of the chart including axes, gridlines, and other elements.
**G. Data markers (required):** Dots connected by lines representing two data series and the difference between them.
**H. Vertical axis (required):** Scale representing numeric values.
**I. Horizontal axis (required):** Scale representing a date period or a category.
## Usage
A table that displays when to use and when not to use different component variants.
- When to use: To compare two related values for each category or time period (e.g., actual vs. target, current vs. previous).
- When not to use: When there are more than two values per category, as the chart becomes cluttered. Consider using clustered or stacked bar chart instead.
- When to use: To highlight the size of the gap or difference between two categories.
- When not to use: When precise trends for each category are more important than the difference. Consider using a [line chart](https://design.visa.com/data-visualization/charts/line-chart) instead.
- When to use: When the goal is to show how differences change across categories or over time.
- When not to use: When gaps between values are too small or not meaningful, making the visual comparison ineffective.
- When to use: To emphasize relative performance against a benchmark or paired value.
- When not to use: If there’s no benchmark or paired value to compare. Consider using a [bar chart](https://design.visa.com/data-visualization/charts/bar-chart) instead.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Provide more detailed explanations and definitions for any complex metrics if needed.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Titles and subtitles
- Use clear, informative titles to help users understand the chart’s topic and key takeaways.
- Frame titles as a headline that summarizes the trend or insight.
- Use subtitles to add more detail about the data being shown and help users understand how to interpret the chart.
- Consider phrasing titles or subtitles as questions to guide the user’s analysis, especially on exploratory dashboards where users are likely to spend significant time analyzing data.
- Avoid titles and subtitles that are too general or vague.
### Labels
- Ensure numbers, dates, and other data or axis labels are formatted consistently.
- Follow plain language principles, such as using shorter and simpler words and phrases.
#### Number format
Simplify number formats to remove unnecessary details and reduce the mental effort needed to compare numbers. If needed, provide higher-precision numbers in a tooltip for users who want more information.
A table that displays recommended number formats for different data types.
- Data type: Use abbreviated format, such as 1.2k instead of 1,200.
- Data type: Use whole percentage points, except for special cases where basis points are needed.
- Data type: Use basis points (bps) when change percentage is very small. 1 bps equals 0.01% (0.0001 in decimal format).
- Data type: Round to the appropriate level of detail that is required for the analysis. For example, for U.S. currency round to the nearest dollar amount.
---
# accessibility
---
title: Heatmap
description: Chart where each cell represents the value of the category pairing to show most and least common combinations of values within a matrix.
meta_description: Find accessibility guidelines for heatmaps to to show the size of values within a matrix.
tab_title: Accessibility
tab_order: 1
---
This chart component has built-in accessibility features to support creating accessible charts from the start. These include descriptive tag properties, keyboard navigation controls, and tools to ensure sufficient color contrast. Find accessibility guidance below.
## Best practices
Ensure the following best practices are met when implementing this component to create accessible data experiences for everyone, everywhere.
### Make thoughtful color choices
Ensure users of all abilities can understand the meaning of colors in your data visualization. Choose color combinations that provide sufficient contrast and add textures to support color-blind and low vision users.
#### Use accessible color palettes
Our data visualization color palettes are designed to ensure that data distinctions remain clear for users with various types of color vision deficiencies. Use this functionality to ensure sufficient contrast between colors and avoid relying only on color to differentiate categories or values.
For example, the Visa red to green divergent color palette ensures that all shades are seen as different values, even under different color-blindness simulators. Meanwhile, a default red to green color palette doesn’t make the shades distinct enough across the full range of the palette.
#### Outline light objects
Our chart components automatically add darker outlines to light-colored chart elements to ensure contrast and visibility against backgrounds and adjacent marks. Overriding this default behavior can make elements harder to distinguish from the chart background and reduce readability.
### Write clear alternative text
Use the chart components’ descriptive tag properties to provide concise and informative alternative text for screen readers.
A table that provides guidance for writing chart accessibility properties.
- Accessibility property: Summarize what the chart shows and the type of data.
Use simple language for straightforward charts. Describe the layout for uncommon chart types.
Avoid repeating the chart title or subtitle.
- Guidance: “This bar chart shows monthly payment volume for this year compared to last year.”
“This strip chart displays transaction volume across major European cities, with each city represented by a circle placed according to spending volume.”
- Accessibility property: Clearly state the takeaway and highlight key statistical insights and trends.
Group data points to show patterns or outliers.
Do not list numbers without explaining their meaning.
- Guidance: “Sales numbers increased every month except June and July.”
“Europe and Asia Pacific had over 5% growth, while Asia Pacific lagged the global average at 1%.”
- Accessibility property: Explain which controls or filters affect the chart.
Communicate any selections that have been applied to exclude or change the displayed data.
- Guidance: “The values in this chart are based on the filter selections applied to the dashboard.”
### Add descriptive labels for data
Use the chart components’ custom labeling options to provide clear and descriptive names for displayed data. Labels like “num_transactions” may work during analysis, but “Number of transactions” is easier for users to understand and interpret.
#### Data labels
Data labels are the textual representations of data values in charts or tables. Use descriptive labels when presenting data to end users to provide clarity and avoid technical jargon or shorthand that may confuse non-technical audiences.
#### Tooltips
Tooltips add contextual information about data points when users hover or focus on chart elements. Clear and descriptive labels in tooltips help users understand the meaning of the data without requiring knowledge of internal naming conventions.
## Keyboard controls
Keyboard actions and their corresponding behaviors for heatmaps
---
# code
---
title: Heatmap
description: Chart where each cell represents the value of the category pairing to show most and least common combinations of values within a matrix.
meta_description: Get code for heatmaps to show the size of values within a matrix.
tab_title: Code
tab_order: 3
show_table_of_contents: true
---
---
# examples
---
title: Heatmap
description: Chart where each cell represents the value of the category pairing to show most and least common combinations of values within a matrix.
meta_description: Explore examples of heatmaps to to show the size of values within a matrix.
tab_title: Examples
tab_order: 2
---
Explore our heatmap examples to see how the VCC heatmap component can be customized for specific business scenarios and analysis tasks.
Find design assets for these heatmap examples in our Figma [Data Experience Charts (internal only)](https://bookmarks.visa.com/vpds-data-experience-charts) library.
---
# index
---
title: Heatmap
description: Chart where each cell shows the value of a category pairing, highlighting the most and least common combinations.
meta_description: Learn how to use heatmaps to show the size of values within a matrix.
tab_title: Usage
thumbnail: assets/data-visualization/chart-components/heatmap-sm.svg
keywords: ["Highlight table", "matrix chart", "mosaic plot", "density plot"]
filter:
category:
- correlation
related:
charts:
- design-visualization-guidelines/overview
- charts/bar-chart
side_nav_order: 2
---
Heatmaps use a grid of colored cells to represent numeric values at the intersection of two categories. Rows and columns represent values of the categorical variables, using colors to represent the numeric value for each category pairing and reveal the most and least common combinations.
Also known as: Highlight table, matrix chart, mosaic plot, density plot.
## Anatomy
**A. Title (optional):** Brief text summarizing the contents of the chart.
**B. Data table button (optional):** UI icon button enabling users to view the chart's data in table format.
**C. Keyboard instructions (required):** UI icon button enabling users to access the chart's keyboard navigation instructions.
**D. Subtitle (optional):** Additional text providing more details.
**E. Plot canvas (required):** Area containing the graphic part of the chart including heatmap cells, axes, and other elements.
**F. Data markers (required):** Colored cells representing the numeric value for a category pairing.
**G. Vertical axis (required):** Scale representing a category, group, or date period.
**H. Horizontal axis (required):** Scale representing a category, group, or date period.
**I. Legend (optional):** Explains how to interpret the color scale used in the heatmap cells.
## Usage
A table that displays when to use and when not to use different component variants.
- When to use: To show patterns or clusters in data visually, making it easy to spot high and low values.
- When not to use: When precise comparisons between individual data points are required. Consider using a [bar chart](https://design.visa.com/data-visualization/charts/bar-chart) or dot plot instead.
- When to use: To summarize large numeric datasets across two dimensions (e.g., categories or time intervals).
- When not to use: When the dataset has extreme outliers that distort the color scale. Consider using a [dumbbell plot](https://design.visa.com/data-visualization/charts/dumbbell-plot) instead.
- When to use: When the goal is to highlight variation and distribution rather than precise individual values.
- When not to use: When the numeric variable shows little variation, as color differences will be hard to interpret. Consider using a [bar chart](https://design.visa.com/data-visualization/charts/bar-chart) instead.
- When to use: To quickly identify correlations or relationships between variables.
- When not to use: When comparing too many categories, which can make the heatmap cluttered. Consider grouping or filtering categories.
## Best practices
- Include a legend unless data labels are included in every cell.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Provide more detailed explanations and definitions for any complex metrics if needed.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Titles and subtitles
- Use clear, informative titles to help users understand the chart’s topic and key takeaways.
- Frame titles as a headline that summarizes the trend or insight.
- Use subtitles to add more detail about the data being shown and help users understand how to interpret the chart.
- Consider phrasing titles or subtitles as questions to guide the user’s analysis, especially on exploratory dashboards where users are likely to spend significant time analyzing data.
- Avoid titles and subtitles that are too general or vague.
### Labels
- Ensure numbers, dates, and other data or axis labels are formatted consistently.
- Follow plain language principles, such as using shorter and simpler words and phrases.
#### Number format
Simplify number formats to remove unnecessary details and reduce the mental effort needed to compare numbers. If needed, provide higher-precision numbers in a tooltip for users who want more information.
A table that displays recommended number formats for different data types.
- Data type: Use abbreviated format, such as 1.2k instead of 1,200.
- Data type: Use whole percentage points, except for special cases where basis points are needed.
- Data type: Use basis points (bps) when change percentage is very small. 1 bps equals 0.01% (0.0001 in decimal format).
- Data type: Round to the appropriate level of detail that is required for the analysis. For example, for U.S. currency round to the nearest dollar amount.
---
# accessibility
---
title: Line chart
description: Chart showing points connected by line segments, used to represent how a number changes over time.
meta_description: Find accessibility guidelines for line charts used to represent how a number changes over time.
tab_title: Accessibility
tab_order: 1
---
This chart component has built-in accessibility features to support creating accessible charts from the start. These include descriptive tag properties, keyboard navigation controls, and tools to ensure sufficient color contrast. Find accessibility guidance below.
## Best practices
Ensure the following best practices are met when implementing this component to create accessible data experiences for everyone, everywhere.
### Make thoughtful color choices
Ensure users of all abilities can understand the meaning of colors in your data visualization. Choose color combinations that provide sufficient contrast and add textures to support color-blind and low vision users.
#### Use accessible color palettes
Our data visualization color palettes are designed to ensure that data distinctions remain clear for users with various types of color vision deficiencies. Use this functionality to ensure sufficient contrast between colors and avoid relying only on color to differentiate categories or values.
For example, the Visa red to green divergent color palette ensures that all shades are seen as different values, even under different color-blindness simulators. Meanwhile, a default red to green color palette doesn’t make the shades distinct enough across the full range of the palette.
#### Add contrast with textures
Textures help differentiate categories when color doesn’t provide enough contrast. Use the texture fill option in our bar charts to improve accessibility for users with color vision deficiencies and maintain clarity when charts are printed in grayscale.
#### Outline light objects
Our chart components automatically add darker outlines to light-colored chart elements to ensure contrast and visibility against backgrounds and adjacent marks. Overriding this default behavior can make elements harder to distinguish from the chart background and reduce readability.
### Write clear alternative text
Use the chart components’ descriptive tag properties to provide concise and informative alternative text for screen readers.
A table that provides guidance for writing chart accessibility properties.
- Accessibility property: Summarize what the chart shows and the type of data.
Use simple language for straightforward charts. Describe the layout for uncommon chart types.
Avoid repeating the chart title or subtitle.
- Guidance: “This bar chart shows monthly payment volume for this year compared to last year.”
“This strip chart displays transaction volume across major European cities, with each city represented by a circle placed according to spending volume.”
- Accessibility property: Clearly state the takeaway and highlight key statistical insights and trends.
Group data points to show patterns or outliers.
Do not list numbers without explaining their meaning.
- Guidance: “Sales numbers increased every month except June and July.”
“Europe and Asia Pacific had over 5% growth, while Asia Pacific lagged the global average at 1%.”
- Accessibility property: Explain which controls or filters affect the chart.
Communicate any selections that have been applied to exclude or change the displayed data.
- Guidance: “The values in this chart are based on the filter selections applied to the dashboard.”
### Add descriptive labels for data
Use the chart components’ custom labeling options to provide clear and descriptive names for displayed data. Labels like “num_transactions” may work during analysis, but “Number of transactions” is easier for users to understand and interpret.
#### Data labels
Data labels are the textual representations of data values in charts or tables. Use descriptive labels when presenting data to end users to provide clarity and avoid technical jargon or shorthand that may confuse non-technical audiences.
#### Tooltips
Tooltips add contextual information about data points when users hover or focus on chart elements. Clear and descriptive labels in tooltips help users understand the meaning of the data without requiring knowledge of internal naming conventions.
## Keyboard controls
Keyboard actions and their corresponding behaviors for line charts
- Key: Enter the chart area/drill down a level on the chart area or a line.
- Key: Drill up a level on a line or a point.
- Key: Move among sibling lines or points when focusing on a line or a point.
- Key: Move among points across lines when focusing on a line or a point.
- Key: Press and hold when using the arrow keys for the best navigation experience on a Mac (VoiceOver).
- Key: Dismiss the tooltip at any time.
- Key: Exit the chart at any time.
---
# code
---
title: Line chart
description: Chart showing points connected by line segments, used to represent how a number changes over time.
meta_description: Get code for line charts used to represent how a number changes over time.
tab_title: Code
tab_order: 3
show_table_of_contents: true
---
---
# examples
---
title: Line chart
description: Chart showing points connected by line segments, used to represent how a number changes over time.
meta_description: Explore examples of line charts used to represent how a number changes over time.
tab_title: Examples
tab_order: 2
---
Explore our line chart examples to see how the VCC line chart component can be customized for specific business scenarios and analysis tasks.
Find design assets for these line chart examples in our Figma [Data Experience Charts (internal only)](https://bookmarks.visa.com/vpds-data-experience-charts) library.
---
# index
---
title: Line chart
description: Chart showing points connected by line segments, used to represent how a number changes over time.
meta_description: Learn how to use line charts to represent how a number changes over time.
tab_title: Usage
thumbnail: assets/data-visualization/chart-components/line-chart-sm.svg
keywords: ["Line graphs", "time series charts"]
filter:
category:
- trend
related:
charts:
- design-visualization-guidelines/overview
- charts/bar-chart
side_nav_order: 4
---
Line charts use points connected by line segments to represent how a number changes over time. The direction and slope of each line segment reveals the rate of change between data points, making it easy to identify trends and fluctuations.
Also known as: Line graphs, time series charts.
## Anatomy
**A. Title (optional):** Brief text summarizing the contents of the chart.
**B. Data table button (optional):** UI icon button enabling users to view the chart's data in table format.
**C. Keyboard instructions (required):** UI icon button enabling users to access the chart's keyboard navigation instructions.
**D. Subtitle (optional):** Additional text providing details, context, or instructions about the chart.
**E. Plot canvas (required):** Area containing the graphic part of the chart including axes, gridlines, and other elements.
**F. Series labels (optional):** Text that identifies each line's category.
**G. Vertical axis (required):** Scale representing a continuous numeric variable.
**H. Data markers (required):** Dots representing individual data points and lines representing the relationships between points.
**I. Horizontal axis (required):** Scale representing a date variable.
## Usage
A table that displays when to use and when not to use different component variants.
- When to use: To show how values change over time or across a continuous sequence.
- When not to use: If the individual values are more important than the overall trend. Consider using a [bar chart](https://design.visa.com/data-visualization/charts/bar-chart) instead.
- When to use: To emphasize overall patterns and trends rather than individual data points.
- When not to use: If the horizontal axis contains categorical or non-sequential data, since line charts imply continuity.
- When to use: To illustrate the rate and direction of change between data points.
- When not to use: If comparing more than five categories which can make the chart cluttered. Consider grouping or using alternative charts.
- When to use: For longer time series where the shape of the trend matters more than exact values.
- When not to use: If the focus is on composition within categories. Consider using a stacked or clustered bar chart instead.
## Best practices
- Select the right chart variant to emphasize the most important takeaways.
- Provide clear explanations, labels and annotations to highlight key data points and help users interpret important findings.
- Always use straight line segments for the most accurate interpretation of data points and trends.
- Use a range of values for the vertical axis that accurately represent the trend and doesn't exaggerate differences between data points.
- Avoid starting the vertical axis at zero when the minimum value in the dataset is significantly higher.
- Select consistent and meaningful intervals for the horizontal axis to ensure the rate of change is represented accurately.
- Avoid displaying too many data points or lines that could overwhelm users and make the chart difficult to interpret.
### Chart size
Chart size should be based on the data within each chart. Use the columns in the [Responsive grid system](https://design.visa.com/base-elements/responsive-grid-system) to set the width of the card, as shown below. Adjust the card’s height so the is proportional and accurately represents the shape of the data.
- Ensure charts are wide enough to be interpreted without scrolling or zooming.
### Color
Color can be used to emphasize meaningful information and draw attention to the most important information in a chart.
- Color should never be used alone to communicate meaning. For more, visit [Accessibility](https://design.visa.com/data-visualization/charts/line-chart/accessibility).
- Learn more about using color for data visualization in the [Color guidelines (internal only)](https://bookmarks.visa.com/vpds-neutral-data-visualization-color-palette)
### Data marker dots
Data markers represent individual data points and can show the progression between points. Users can choose to show or hide data markers with the optional “show dots” feature.
- Choose dot sizes that allow the lines to remain visible and complement the chart without overwhelming it.
{/* ### Represent data accurately
Help users avoid misinterpretations of line charts by ensuring clear communication of data point values and minimizing perception issues that can be caused by lines.
- Select consistent and meaningful date intervals for the horizontal axis, to ensure rate of change is accurately represented.
- Select a range of values for the vertical axis that is large enough to prevent exaggeration of minor changes while still allowing users to see meaningful variation in the data. This ensures that the data representation remains true to the actual trends and patterns.
- Avoid starting the vertical axis at zero when the minimum value in the dataset is significantly higher.
- Be transparent about missing, unknown, or estimated data, to help users understand the limitations of the data and prevent misinterpretations.
- Avoid using curved line styles, which can distort the perception of data values. Straight line segments enable more accurate interpretation of data points and trends.
##### Show vs hide data marker dots
Show dots is an optional feature that allows users to control the visibility of data marker dots.
- Include data marker dots to provide a clear visual reference for the location of data points along the line, representing specific values in the dataset.
- Balance visibility of dots and lines by selecting a dot radius size that complements the chart without overwhelming it.
- Depending on the key analysis tasks and the volume of data to be displayed, consider using data marker dots selectively to emphasize critical data points.
- Use dot size and formatting to establish a strong visual focus for the chart.
*/}
### Handling missing data
Communicate gaps in the data in a clear and consistent way to help users quickly identify where data is missing and understand its limitations. If a data point is missing, don’t connect the points before and after the gap to ensure it’s clear that no data exists between those data points.
- Be transparent about missing, unknown, or estimated data to help users understand the limitations of the data and prevent misinterpretations.
### Direct labeling
Direct labeling refers to placing labels near each data point to communicate precise values. Use direct labeling for data points and line series to make it easier for users to interpret line charts. There are three types of labels in line charts: Data point labels, axis labels, and line series labels.
- Ensure labels don’t clutter the chart or distract from the data by keeping labels short and following number format guidelines.
#### Data point labels
Show labels as close as possible to the data points they represent to reduce the need for users to look back and forth between the chart and the axis labels.
- Label all data points when users should know the specific value of each point.
- Consider hiding the y-axis if you’re showing all data labels.
#### Axis labels
Show axis labels to help users estimate values for unlabeled data points. Use this method when trends are more helpful than individual values.
- Use axis labels when directly labeling every data point would overcrowd or obscure the chart.
#### Line series labels
When a line chart includes multiple line series, ensure users can identify what each line represents. There are generally two methods for this: Labeling lines directly or using a legend.
#### Labeling each line
Directly labeling each line is the clearest method, as users can directly tell what the line represents.
- Show labels close to their lines to ensure users can identify what they refer to.
- Consider hiding the color legend with this method to reduce unnecessary duplicate information.
#### Using a legend
Using a legend is an alternative method that can be helpful when there isn’t sufficient space to label lines directly.
- Include a legend when directly labeling each line series isn't possible or would overcrowd the chart.
- Ensure the legend clearly indicates what each line represents using color, line styling, or similar methods.
## Content
- Always use sentence case except for proper nouns or acronyms.
- Use plain language and avoid abbreviations or jargon.
- Provide more detailed explanations and definitions for any complex metrics if needed.
- Reference [Content](https://design.visa.com/content) for additional guidance on crafting content within apps and experiences.
### Titles and subtitles
- Use clear, informative titles to help users understand the chart’s topic and key takeaways.
- Frame titles as a headline that summarizes the trend or insight.
- Use subtitles to add more detail about the data being shown and help users understand how to interpret the chart.
- Consider phrasing titles or subtitles as questions to guide the user’s analysis, especially on exploratory dashboards where users are likely to spend significant time analyzing data.
- Avoid titles and subtitles that are too general or vague.
### Labels
- Ensure numbers, dates, and other data or axis labels are formatted consistently.
- Follow plain language principles, such as using shorter and simpler words and phrases.
#### Number format
Simplify number formats to remove unnecessary details and reduce the mental effort needed to compare numbers. If needed, provide higher-precision numbers in a tooltip for users who want more information.
A table that displays recommended number formats for different data types.
- Data type: Use abbreviated format, such as 1.2k instead of 1,200.
- Data type: Use whole percentage points, except for special cases where basis points are needed.
- Data type: Use basis points (bps) when change percentage is very small. 1 bps equals 0.01% (0.0001 in decimal format).
- Data type: Round to the appropriate level of detail that is required for the analysis. For example, for U.S. currency round to the nearest dollar amount.
---
# examples
---
title: Charts
description: Explore chart components and best practices for visualizing and communicating data insights.
meta_description: Explore our collection of chart examples tailored to support Visa’s most common business scenarios and analysis tasks.
full_width: true
tab_title: Examples index
page_size: large
show_table_of_contents: false
---
Explore our collection of chart examples, which have been tailored to support Visa’s most common business scenarios and analysis tasks.
---
# index
---
title: Charts
description: Explore usage, accessibility, and design best practices for visualizing and communicating data insights.
meta_description: Chart components are the building blocks for creating insightful, inclusive, and accessible data experiences for everyone, everywhere.
page_size: large
full_width: true
tab_title: Charts index
side_nav_title: Overview
side_nav_additional_screenreader_title: for the Data Visualization chart components
thumbnail: assets/home/data-visualization-graphic.svg
side_nav_order: 0
show_table_of_contents: false
---
**Note:** Our guidelines currently only include these charts: bar chart, dumbbell plot, line chart, and heatmap. Generate charts directly in your design files with exportable code using our [Figma plugin (internal only)](https://bookmarks.visa.com/vpds-charts-playground-figma-plugin).
Explore [Visa Charts Playground (internal only)](https://bookmarks.visa.com/vpds-charts-playground), a rapid prototyping workspace for data visualization. Browse our full library of 30+ chart patterns, customize datasets, and seamlessly transition from concept to code.
---
# index
---
title: Data visualization principles
description: Gain insight into the data visualization principles that help create insightful and accessible data experiences.
meta_description: Gain insight into the data visualization principles that help create insightful and accessible data experiences.
side_nav_title: Data visualization principles
side_nav_order: 1
page_size: large
full_width: true
---
Learn about the five principles we use to provide effective data experiences for our users. They provide a consistent way to measure strengths and weaknesses in the design of Visa's data products.
## Principle #1: Findable
Findable data experiences help users **navigate** the experience, **locate** information, and understand how to **interact** with your data.Questions to explore
* Does your data experience use effective **information architecture** to help users navigate and identify what information is or isn’t available?
* Does the **visual hierarchy** of your experience support the key business question(s) by drawing attention to the most important elements?
* How might the **data representation** or **chart selection** help users locate information and find insights?
* Can users easily discover and understand the **interactivity** of your experience?
## Principle #2: Learnable
Learnable data experiences help users predict how the experience works by using consistent **design and functionality**, providing **feedback and help options**, and matching **common mental models.** Questions to explore
* Do elements with a similar level of importance use the same **visual hierarchy?**
* Can users accurately predict the behavior of **interactive elements** within the experience?
* Does the **data representation** and **visual encoding** help users understand how to read and interpret the chart?
* How could additional **context** like metaphors or annotations be used to make the numbers more memorable or understandable?
## Principle #3: Focused and clear
Focused and clear data experiences help users focus on what’s most important by **limiting distraction** and **directing attention.**Questions to explore
* Does your data experience use effective **information architecture** to provide navigation and flexibility that fits the user’s mental model?
* How can **visual hierarchy** be used to emphasize key data and differentiate between items with different levels of importance?
* How might **interactive features** be used to make it easier to identify specific data points, trends, or relationships?
* How might we spark users’ curiosity with additional **context** or **visual encoding** without adding unnecessary detail?
## Principle #4: Trusted
Trustworthy data experiences increase user engagement by incorporating **predictable patterns**, providing sources to **verify the credibility of the data**, and helping users **interpret data accurately.**Questions to explore
* Is information about the data source, accuracy, and scope communicated with **transparency?**
* Does the **data representation**, including visual styling and color encoding, enhance the meaning of the chart without changing the accuracy of the data?
* Do **interactive elements** behave predictably and make data easier to interpret?
* Is there meaningful **context** provided for accurate interpretation of the key insights of the chart?
## Principle #5: Valuable
Valuable data experiences empower users by clearly **communicating the chart’s purpose**, delivering **actionable insights**, and enabling them to **answer key business questions.**Questions to explore
* Does the chart provide **actionable insights** relevant to the user’s business needs?
* Does the **information structure** and **visual hierarchy** support the user’s main goal?
* How could **labels** or **data representation** be used to add more meaning and emphasize the key purpose of the experience?
* How might **interactive features** help users customize the display for more tailored analysis?
---
# index
---
title: Data visualization guidelines
description: Explore foundational principles and techniques for visualizing and communicating insights.
meta_description: Explore foundational principles and techniques for visualizing and communicating insights.
page_size: full-width
side_nav_title: Overview
side_nav_additional_screenreader_title: for the Data Visualization design guidelines
thumbnail: assets/home/data-visualization-graphic.svg
side_nav_order: 0
show_table_of_contents: false
---
---
# index
---
title: Selecting a chart
description: Learn how to find the right chart for your audience's analysis needs.
meta_description: Learn how to find the right chart for your audience's analysis needs.
side_nav_title: Selecting a chart
side_nav_order: 2
---
Selecting the right chart requires determining the key purpose of the chart and tailoring it to your audience's needs.
Start by understanding the chart types available in our system. Once you're familiar, you can select a chart design from our collection of examples by defining the key insight your chart should provide, and determining the focus elements. Finally, optimize your chart's design to direct attention to the most important information.
## Understand the chart types
Chart types refer to the broad categories of visual representations used to display data. Each chart type is best-suited for particular kinds of data analysis or insights. Charts help users understand and interpret data by leveraging simplified visual representations that highlight patterns and relationships.
To learn more about each chart type visit the [Charts](https://design.visa.com/data-visualization/charts/overview) guidelines.
**Note:** Our guidelines currently only include these charts: Bar chart, dumbbell plot, line chart, and heatmap. You can explore our full library of chart components in the latest release of [Visa Chart Components (VCC)](https://github.com/visa/visa-chart-components).
## Selecting a chart
Each chart type in our library includes specific examples which are adaptations created to solve real-world business problems. These work like templates or starter chart designs that include modifications that tailor the chart for specific data analysis tasks, or to emphasize particular aspects of the data.
Use the insight and focus categories on our [Examples index](https://design.visa.com/data-visualization/charts/overview/examples) page to select a chart variation that is best suited for your user’s analysis needs.
InsightsWhat do you want your audience to learn from this chart?FocusWhat is the most important and meaningful information for users to focus on in this chart?
### Step 1: Choose a key insight category
Insights refer to the high-level purpose of a chart, and the type of analysis it enables. Start by identifying the primary insight category of the chart, based on the type of question that it should enable users to answer.
Table for understanding key insights and business questions
- Insight: How are items related?
- Insight: What is the current value of a metric, and is it good or bad?
- Insight: Which categories have a higher share of the whole?
- Insight: Is there a meaningful pattern between two numbers?
- Insight: How much difference is there between two numbers?
- Insight: What is the range of values, and how does it compare to the average?
- Insight: How do items move through a sequence?
- Insight: How has a number changed over time?
- Insight: Which items have the highest and lowest values?
- Insight: How does location impact a pattern?
### Step 2: Determine the focus
After you’ve selected an insight category, narrow down the examples by determining the key focus element of the chart. Focus elements refer to the specific data points, trends, patterns, or areas in a chart that are emphasized to make it easier for users to understand the key insights from the data.
Three key focus areas that can be highlighted or emphasized: A specific category, within a dataset, and values relative to a threshold. The sections below illustrate how our chart examples have been customized to emphasize different focus elements.
### Highlight a category
Direct the user's focus to a primary category, as illustrated in the [Category share of total](https://design.visa.com/data-visualization/charts/heatmap/examples#heatmap-category-share-of-total) heatmap example.
### Highlight values above a threshold
Direct the user's focus to values above a specific threshold, as illustrated in the [Compare trend to benchmark](https://design.visa.com/data-visualization/charts/bar-chart/examples#bar-chart-compare-trend-to-benchmark) bar chart example.
### Highlight high and low values
Direct the user's focus to the highest and lowest values, as illustrated in the [Trend with categories](https://design.visa.com/data-visualization/charts/dumbbell-plot/examples#dumbbell-plot-trend-with-categories) dumbbell plot example.
### Step 3: Refine the chart
Once you’ve chosen a chart example that works well for your use case, you can refine it to ensure it’s tailored to your audience’s needs. Use the following guidelines to help reduce distracting information and draw attention to the key elements of the chart.
### Reduce distracting information
To establish a clear visual focus, determine what elements only provide details or supporting information. This includes chart elements like gridlines, axes or axis elements, and data labels.
- Create a clear visual focus by limiting distracting information and only adding visual details as need.
- Avoid using chart elements that convey similar or repeated information to help limit visual noise.
- Start by using one neutral color for all data points. This gives you a more flexible starting point for directing attention where it’s needed.
- Use color encoding to provide additional information and context, where necessary. Follow guidelines for [Color palettes (internal only)](https://bookmarks.visa.com/vpds-neutral-data-visualization-color-palette) to make full use of our data visualization color palettes.
### Direct attention
Once you have a simplified chart by reducing distracting elements, you can reintroduce visual emphasis to help users focus on the most important information in your chart.
To direct attention to the right part of the chart, consider the user’s key task: What mental steps do they need to take to answer the key question? Determining the task type can help you choose what information to emphasize.
Table for understanding task types and ways to direct attention
- Task type: Understand the precise value of a selected data point
- Description: - Use direct labeling of data points.
- Provide option to view the chart’s data in table format.
- Task type: Find a specific item or category within a chart
- Description: - Use color to represent individual categories, or to highlight the most important category.
- Provide interactive functionality to enable searching and highlighting specific data points.
- Task type: Find a pattern or an outlier
- Description: - Use reference lines to identify values above or below a threshold.
- Highlight outliers with different color or shape.
- Use annotations to identify and describe significant patterns.
- Task type: Compare the differences and similarities between two items, categories, or metrics
- Description: - Add reference lines to enable comparisons to the typical value.
- Use side-by-side positioning of multiple charts.
- Use statistical techniques for normalizing the data to enable more accurate comparisons.
For more information about visual analysis tasks, reference the Data Representation Pillar of our [Data Experience Critique Framework](https://developer.visa.com/images2/visa-chart-components/Data%20Experience%20Critique%20Framework.pdf)
---
# index
---
title: Start developing data visualizations
description: Select your code library and follow the step-by-step guide to start developing with Visa Chart Components.
tab_title: Angular
meta_description: Follow the step-by-step guide to start developing with Visa Chart Components in Angular.
side_nav_title: Development setup
tab_order: 0
side_nav_order: 1
---
import {
installation,
types,
utils,
compilerOptions,
componentImport,
componentTSFile,
componentHTMLFile
} from "@data/angular/vcc/installation.ts";
## Step 1: Update Angular
Visa Chart Components (VCC) Angular library supports Angular v16 and up. Visit Angular's guide on how to [update Angular to v16](https://angular.io/guide/update-to-version-16) or [update Angular to v17](https://angular.io/guide/update-to-version-17).
## Step 2: Install the library
You can install the Visa Chart Components (VCC) Angular library using the package manager of your choice. Below we've provided the most common: NPM, PNPM, Yarn, and Bun.
**Note:** Package managers can resolve dependencies differently and might not automatically install all required dependencies.
### Step 2b: Install the types library
Next, install the accompanying types library to aid autocomplete features in IDEs and overall code quality.
### Step 2c: Install the utilities library (optional)
Complete this step if you want to access optional functionalities of the Visa Chart Components, like internationalization.
## Step 3: Set up the application
### Step 3b: Update compilerOptions
Add paths in your tsconfig.
### Step 3c: Import the Visa Chart Components (VCC) Angular library
Next, import the Visa Chart Components (VCC) Angular library for full access to our chart components.
## Step 4: Use the components
### Step 4b: Update your components.ts
Update your components type script file to incorporate the minimal example props and data.
### Step 4c: Use the chart components
You're ready to use Angular chart components by copying and pasting the example code into your application. Check out [Bar chart](https://design.visa.com/data-visualization/charts/bar-chart/code) to give it a try.
## Need help?
If you experience any issues while getting set up with Visa Charts Components, visit [Support](https://design.visa.com/support).
---
# react
---
title: Start developing data visualizations
description: Select your code library and follow the step-by-step guide to start developing with Visa Chart Components.
meta_description: Follow the step-by-step guide to start developing with Visa Chart Components in React.
side_nav_title: React
tab_order: 1
---
import {
installation,
types,
utils,
component
} from "@data/react/vcc/installation.ts";
## Step 1: Update React
Visa Chart Components (VCC) React library supports React 18 and up. Visit React's guide on how to upgrade to [React 18](https://react.dev/blog/2022/03/08/react-18-upgrade-guide) for more.
## Step 2: Install the library
You can install the Visa Chart Components (VCC) React library using the package manager of your choice. Below we've provided the most common: NPM, PNPM, Yarn, and Bun.
**Note:** Package managers can resolve dependencies differently and might not automatically install all required dependencies.
### Step 2b: Install the types library (optional)
Next, install the accompanying types library to aid autocomplete features in IDEs and overall code quality.
### Step 2c: Install the utilities library (optional)
Complete this step if you want to access optional functionalities of the Visa Chart Components, like internationalization.
## Step 3: Use the chart components
You're ready to use React chart components by copying and pasting the example code into your application. Check out [Bar chart](https://design.visa.com/data-visualization/charts/bar-chart/code) to give it a try.
## Need help?
If you experience any issues while getting set up with Visa Charts Components, visit [Support](https://design.visa.com/support).
---
# vanilla-javascript
---
title: Start developing data visualizations
description: Select your code library and follow the step-by-step guide to start developing with Visa Chart Components.
meta_description: Follow the step-by-step guide to start developing with Visa Chart Components in Vanilla JavaScript.
tab_title: Vanilla Javascript
tab_order: 2
---
import {
installation,
utils,
importOptions,
propAssignment,
propsObjectExample,
components,
html
} from "@data/js/vcc/installation.ts";
## Step 1: Install the library
You can install the Visa Chart Components (VCC) Web Components library using the package manager of your choice. Below we’ve provided the most common: NPM, PNPM, Yarn, and Bun.
**Note:** Package managers can resolve dependencies differently and might not automatically install all required dependencies.
### Step 1b: Install the types library (optional)
Next, install the accompanying types library to aid autocomplete features in IDEs and overall code quality.
### Step 1c: Install the utilities library (optional)
Complete this step if you want to access optional functionalities of the Visa Chart Components, like internationalization.
## Step 2: Set up the application
### Step 2b: Import the package
Import the package to access charts provided by Visa Chart Components.
### Step 2c: Dynamic prop assignment (optional)
Build a function for dynamic prop assignment to dynamically update object properties.
#### Example props object
## Step 3: Use the chart components
We support Vanilla components, the Template method, and the Jquery method. Choose the one that suit your needs.
### Step 3b: Declare a chart component
Declare any component to test a chart.
### Step 3c: Use the chart components
You're ready to use the chart components by copying and pasting the example code into your application. Check out [Line chart](https://design.visa.com/data-visualization/charts/line-chart/examples) to give it a try.
## Need help?
If you experience any issues while getting set up with Visa Charts Components, visit [Support](https://design.visa.com/support).
---
# index
---
title: Visa Chart Components
tab_title: Visa Chart Components
description: Learn how to use Visa Chart Components with the Visa Product Design System for ease and efficiency.
meta_description: Learn how to use Visa Chart Components with the Visa Product Design System for ease and efficiency.
page_size: medium
side_nav_title: Visa Chart Components
side_nav_order: 0
show_table_of_contents: false
---
The Visa Chart Components library (VCC) is maintained to provide charts that work alongside VPDS’s component libraries. You’ll also find guidelines including general principles on how to craft informative data experiences and how to select effective charts.
## Learn about VCC
Visa Chart Components uses a feature-rich API to bring you accessible, framework-agnostic web components with robust accessibility configurations to enhance your workflow and ensure your product meet the latest standards. Learn about our approach below.
### Accessibility first
Visa Chart Components are designed to make it easier for product teams to deliver accessible data experiences. We use Visa Global Accessibility Requirements (VGAR) to continuously assess and improve the accessibility of our data components.
### Streamlined design
Our component APIs come with built-in design choices tailored for Visa products, reducing the need for developers to code detailed aspects like motion design into each chart. This intentional design choice may offer less flexibility than some other libraries, as VCC is not a low-level library.
### Framework agnostic
Visa Chart Components leverage [stencil.js](https://stenciljs.com/), [d3.js](https://d3js.org/), and other open-source libraries to build custom web components that work with popular web frameworks like Angular, React, and Vanilla JavaScript. In short, you can use VCC almost anywhere you use JavaScript. At this time, the team doesn’t support mobile chart components yet, but can offer guidance on adjusting for mobile applications.
### Unit tested
We've developed detailed, semi-automated unit testing to perform robust regression testing, ensuring consistent quality across our components. This helps ensure we’re continuously improving the breadth and depth of our testing coverage.
## Learn to use our assets
Craft insightful, inclusive, and accessible data experiences following our data visualization guidelines.
- Understand key principles and techniques for visualizing and communicating insights in [Data visualization principles.](https://design.visa.com/data-visualization/design-visualization-guidelines/data-visualization-principles)
- Explore how to choose the most effective chart for the information you need to communicate in [Selecting the right chart.](https://design.visa.com/data-visualization/design-visualization-guidelines/selecting-a-chart)
- Find usage, code and accessibility guidance for our data visualization components in [Chart component library.](https://design.visa.com/data-visualization/charts/overview)
- Find chart examples tailored to support common business scenarios and analysis tasks in [Chart examples.](https://design.visa.com/data-visualization/charts/overview/examples)
## Complete your setup
To get started, visit [React](https://design.visa.com/data-visualization/development-setup/react), [Angular](https://design.visa.com/data-visualization/development-setup), and [Vanilla Javascript](https://design.visa.com/data-visualization/development-setup/vanilla-javascript) for instructions on installation and building your first chart.
### For designers: Get the Figma design kit
Start designing with VCC components, color palettes, and more with our [Figma Data Visualization library (internal only)](https://bookmarks.visa.com/vpds-figma-data-visualization-library).
### For developers: Install the code library of your choice
Visa Chart Components can be used with React, Angular, Vanilla JavaScript, Python, and Vue. To get started, visit [Angular](https://design.visa.com/data-visualization/development-setup), [React](https://design.visa.com/data-visualization/development-setup/react), and [Vanilla Javascript](https://design.visa.com/data-visualization/development-setup/vanilla-javascript) for instructions on installation and building your first chart.
## Connect with us
Have questions or ideas? Visit our office hours, or join Data experience on Teams or get general VPDS help by visiting [Support](https://design.visa.com/support).
---
# bar-chart-compare-category-ranking
---
title: Compare category ranking
shortTitle: Compare category ranking
description: Bar chart used to compare differences between categories, such as countries or product types.
thumbnail: assets/data-visualization/examples/bar/compare-category-ranking.svg
filter:
type: bar
insight:
- ranking
example:
id: bar-chart-compare-category-ranking
chartTag: bar-chart
hasCousinNavigation: true
---
In this example, the chart is optimized to answer the key business question, “Which countries performed better?”, and “What are the similarities and differences between regions?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use the categorical palette to group bars into relevant groups. In this example, this helps indicate which regions had countries that ranked towards the top or the bottom and compare countries within a region.
- **Data labels:** Show lables directly over each bar to make it easier to interpret the exact value of each data point.
- **Reference line:** Use the reference line to provide a reference point between each country and the average value.
- **Order:** Order countries from highest to lowest to make it easy to identify the ranking of countries at a quick glance.
---
# bar-chart-compare-trend-to-benchmark
---
title: Compare trend to benchmark
shortTitle: Compare trend to benchmark
description: Bar chart used to compare trends to a threshold such as goal, budget or average.
thumbnail: assets/data-visualization/examples/bar/trend-to-benchmark.svg
filter:
type: bar
insight:
- trend
focus:
- values relative to threshold
example:
id: bar-chart-compare-trend-to-benchmark
chartTag: bar-chart
hasCousinNavigation: false
---
In this example, the chart is optimized to answer the key business question, “How did performance change over time?” and “When did our performance beat the market average?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use a combination of bold and subtle colors to emphasize which bars fall above or below the benchmark. This example uses the gray and blue highlight palette.
- **Data labels:** Show lables at the bottom of each bar to make it easier to interpret the exact value of each data point without overcrowding the benchmark line.
- **Reference line:** Use the reference line to help users understand which values are good, bad, or typical.
---
# bar-chart-distribution-summary
---
title: Distribution summary
description: Bar chart used to summarize the range of values of a distribution and identify the most common values.
thumbnail: assets/data-visualization/examples/bar/distribution-summary.svg
filter:
type: bar
insight:
- distribution
example:
id: bar-chart-distribution-summary
chartTag: bar-chart
hasCousinNavigation: false
---
In this example, the chart is optimized to answer the key business question, “What is the range of values of low to high spenders?” and “What are the most common values, and how do they compare to the average?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use sequential colors to emphasize the value of bars, typically with darker bars indicating larger values. This example uses the purple sequential color palette.
- **Annotations:** Include annotations to provide a summary of the important data points and in-context instructions to help users interpret the chart.
- **Center baseline axis:** Use a centered baseline on the Y axis to keep the focus on the overall shape of the distribution.
---
# bar-chart-simple-trend
---
title: Simple trend
description: Bar chart used to summarize and compare trends.
thumbnail: assets/data-visualization/examples/bar/simple-trend.svg
filter:
type: bar
insight:
- trend
example:
id: bar-chart-simple-trend
chartTag: bar-chart
hasCousinNavigation: false
---
In this example, the chart is optimized to answer the key business question, “How did performance change over time?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use one color for every bar to emphasize the overall shape of the trend without overwhelming users. This example uses the neutral blue from our single color palette.
- **Data labels:** Show labels directly over each bar to make it easier to interpret the exact value of each data point.
- **Gridlines:** Use horizontal gridlines to make it easier to compare heights between non-adjacent bars.
---
# bar-chart-trend
---
title: Trend
description: Bar chart used to identify high and low values and comparing trends.
thumbnail: assets/data-visualization/examples/bar/trend.svg
filter:
type: bar
insight:
- trend
focus:
- high and low values
example:
id: bar-chart-trend
chartTag: bar-chart
hasCousinNavigation: true
---
In this example, the chart is optimized to answer the key business question, “How did performance change over time?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use sequential colors with a legend to categorize bars according to their values and make it easier to spot the high and low values. This example uses the secondary blue sequential color palette.
- **Data labels:** Show lables directly over each bar to make it easier to interpret the exact value of each data point.
- **Gridlines:** Use horizontal gridlines to make it easier to compare heights between non-adjacent bars.
---
# dumbbell-plot-compare-trend-to-benchmark
---
title: Compare trend to benchmark
shortTitle: Compare trend to benchmark
description: Dumbbell plot used to identify over or underperforming categories relative to a benchmark.
thumbnail: assets/data-visualization/examples/dumbbell/compare-trend-to-benchmark.png
filter:
type: dumbbell
insight:
- deviation
focus:
- values relative to threshold
example:
id: dumbbell-plot-compare-trend-to-benchmark
chartTag: dumbbell-plot
---
In this example, the chart is optimized to answer the key business question: “Which cities performed above or below average?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use two colors to highlight important data on the chart. In this example, the gray and red highlight color palette emphasizes cities that performed below average.
- **Data labels:** Directly label each point to make it easier to interpret the exact value. This example provides additional labels with the difference from the benchmark for quicker analysis.
- **Reference line:** Include a reference line to indicate the benchmark for comparing which values are good or bad. In this example, it shows the the overall U.S. average.
- **Axis annotation:** Use annotations to give contextual explanations of the data. In this example, the annotation labels and arrows at the top of the chart explain how to interpret values along the horizontal axis, as well as how to interpret the red and gray colors.
---
# dumbbell-plot-current-vs-previous-trend
---
title: Current vs previous trend
shortTitle: Current vs previous trend
description: Dumbbell plot used to compare variance and pace of growth between two date periods.
thumbnail: assets/data-visualization/examples/dumbbell/compare-current-vs-previous-trend.png
filter:
type: dumbbell
insight:
- deviation
- trend
focus:
- highlight category
example:
id: dumbbell-plot-current-vs-previous-trend
chartTag: dumbbell-plot
---
In this example, the chart is optimized to answer the key business questions: “Did this year’s performance beat last year’s and by how much?” and “Is that difference growing or shrinking?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use two colors to highlight important data on the chart. In this example, the gray and blue highlight color palette emphasizes the direction of the change from last year.
- **Data labels:** Label important data points to help users interpret the data in the chart without overcrowding the display. In this example, labeling the minimum point, maximum point, and most recent data gives the overall range of the data.
- **Gridlines:** Use vertical gridlines to help users understand which month each dumbbell corresponds to.
- **Marker type:** Use the arrow marker type to emphasize the direction of change, making it easier to quickly understand if this year’s performance was an increase or decrease from last year.
---
# dumbbell-plot-trend-with-categories
---
title: Trend with categories
description: Dumbbell plot used to compare variance between two categories over time.
thumbnail: assets/data-visualization/examples/dumbbell/trend-with-categories.png
filter:
type: dumbbell
insight:
- deviation
- trend
focus:
- high and low values
example:
id: dumbbell-plot-trend-with-categories
chartTag: dumbbell-plot
hasCousinNavigation: false
---
In this example, the chart is optimized to answer the key business questions: “When did our customer growth outpace competitors?”, “How much difference is there between our rate of customer growth and competitors?”, and “How did customer growth change over time?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use two colors to indicate the series membership of each dot. This example uses the gray and blue highlight color palette to emphasize months where the selected client’s performance was better than the competitor benchmark, where the bar is colored based on which series has the highest value.
- **Data labels:** Label important data points to help users interpret the data in the chart without overcrowding the display. In this example, labeling the minimum point, maximum point, and most recent data gives the overall range of the data.
- **Gridlines:** Use vertical gridlines to help users understand which month each dumbbell corresponds to.
---
# heatmap-category-pattern-analysis
---
title: Category pattern analysis
description: Heatmap used to compare categories across discrete date parts.
thumbnail: assets/data-visualization/examples/heatmap/category-pattern-analysis.png
filter:
type: heatmap
insight:
- correlation
- trend
focus:
- high and low values
example:
id: heatmap-category-pattern-analysis
chartTag: heatmap
---
In this example, the chart is optimized to answer the key business questions: ”Do customers prefer to shop on weekdays or weekends, or on a specific day of the week?” and “Which key market segments have similar or different customer purchase patterns?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use color encoding to make very large and very small numbers easier to spot. In this example, this heatmap uses a the full range of colors in the sequential blue palette, with darker colors representing higher quantities.
- **Data labels:** Label every data marker to make it easier to interpret the exact value of each data point.
- **Grouping categorical variable:** Combine smaller groups into one category called “other” to help users focus on the largest categories.
- **Grouping time variable:** Group exact dates into segments, like days of the week or times of day, to help users identify recurring seasonal patterns.
- **Legend:** Use a gradient color legend to help users focus on overall patterns or clusters of high and low values, instead of attempting to use color to interpret precise values of individual cells.
---
# heatmap-category-share-of-total
---
title: Category share of total
description: Heatmap used to highlight one category's contribution to the total, and compare values to a threshold.
thumbnail: assets/data-visualization/examples/heatmap/category-share-of-total.png
filter:
type: heatmap
insight:
- composition
- current status
focus:
- highlight category
example:
id: heatmap-category-share-of-total
chartTag: heatmap
hasCousinNavigation: false
---
In this example, the chart is optimized to answer the key business questions: “What share of all requests have been completed?” and “How close did we get to our target for resolving requests?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use color to show highlight important data. In this example, the gray and blue palette highlights the resolved requests category compared to all requests.
- **Subtitle:** Use subtitles to provide a clear and concise summary of the key takeaways from the chart.
- **Annotation:** Use annotations to emphasize the exact value of the highlighted category and make it easier to understand how to read the chart.
- **Reference line:** Provide a visual indicator of the set goal, making it easy to see the progress made and the distance remaining to achieve the goal.
---
# heatmap-correlation-matrix
---
title: Correlation matrix
description: Heatmap used to compare two metrics, and identify the most and least common combinations.
thumbnail: assets/data-visualization/examples/heatmap/correlation-matrix.png
filter:
type: heatmap
insight:
- correlation
focus:
- high and low values
example:
id: heatmap-correlation-matrix
chartTag: heatmap
---
In this example, the chart is optimized to answer the key business question: “Is there a meaningful relationship between how much a cardholder spends and how frequently they shop?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use color to highlight important patterns. In this example, the complementary blue palette makes the most common combinations of spend amount and purchase frequency easier to spot.
- **Data labels:** Label every data marker to make it easier to interpret the exact value of each data point.
- **Grouping categorical variables:** Translate continuous numeric variable into a few clear categories (like small, medium, and large) to simplify comparisons.
- **Simplified number format:** Rounding data labels to whole percentage points to reduce the effort needed to compare values.
---
# heatmap-seasonal-pattern-analysis
---
title: Seasonal pattern analysis
description: Heatmap used to visualize a metric in a calendar format, to identify seasonal peak.
thumbnail: assets/data-visualization/examples/heatmap/seasonal-pattern-analysis.png
filter:
type: heatmap
insight:
- correlation
- trend
focus:
- high and low values
example:
id: heatmap-seasonal-pattern-analysis
chartTag: heatmap
---
In this example, the chart is optimized to answer the key business questions: “Are there any seasonal patterns when there are peaks or dips in new accounts?” and “Have the slow and busy seasons remained steady, or do they change from year to year?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use color to make clusters with very large and very small numbers easier to spot. In this example, the plum color palette represents the total of new accounts for each month, with darker colors indicating higher quantities.
- **Data labels:** Label every data marker to make it easier to interpret the exact value of each data point.
- **Legend:** Use a color legend to help users easily interpret the color encoding of heatmap cells. In this example, each heatmap cell is labeled with its corresponding month and the legend tells users how to interpret each cell’s color.
---
# line-chart-compare-trend-to-benchmark
---
title: Compare trend to benchmark
shortTitle: Compare trend to benchmark
description: Line chart used to compare trends to a threshold such as goal, budget or average.
thumbnail: assets/data-visualization/examples/line-chart/compare-trend-to-benchmark.svg
filter:
type: line
insight:
- trend
focus:
- values relative to threshold
example:
id: line-chart-compare-trend-to-benchmark
chartTag: line-chart
---
In this example, the chart is optimized to answer the key business questions, “How did expenses change over time?” and “When did expenses exceed budget?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use bold and subtle colors to emphasize which data points fall above or below the benchmark. This example uses the gray and red color palette to emphasize months where expenses exceeded the budget.
- **Data labels:** Show labels directly over each data marker to make it easier to interpret the exact value of each data point.
- **Gridlines:** Show horizontal gridlines make it easier to compare differences across all data points.
- **Reference line:** Provide a comparison to the target budget threshold to help users understand which values are good or bad.
---
# line-chart-current-versus-previous-trend
---
title: Current vs. previous trend
shortTitle: Current vs. previous trend
description: Line chart used to compare a primary metric to a secondary metric, such as current to previous year.
thumbnail: assets/data-visualization/examples/line-chart/current-vs-previous-trend.svg
filter:
type: line
insight:
- trend
focus:
- highlight category
example:
id: line-chart-current-versus-previous-trend
chartTag: line-chart
---
In this example, the chart is optimized to answer the key business questions, “How did performance change over time?” and “How much difference is there between this year and last year’s performance?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use bold and subtle colors to emphasize the change in values over time. This example uses a gray and blue highlight color palette to emphasize the current year’s trend line.
- **Data labels:** Show labels directly over each data marker on the current year's line to make it easier to interpret the exact value of each data point, and help direct attention to the most recent data. This allows users to estimate the gap between current and previous year's data points without overcrowding the chart.
- **Stepped line style:** Use a stepped line chart to emphasize the exact value of each data point and the change between consecutive data points. In this example, the stepped line style helps users easily interpret small changes, and make more precise comparisons between two line series.
- **Y axis labels:** Use axis labels to help users estimate the value of unlabeled data points.
---
# line-chart-one-versus-all-trend
---
title: One vs. all trend
shortTitle: One vs. all trend
description: Line chart used to compare differences in trends between multiple categories, with emphasis on a primary category.
thumbnail: assets/data-visualization/examples/line-chart/one-vs-all.svg
filter:
type: line
insight:
- trend
focus:
- highlight category
example:
id: line-chart-one-versus-all-trend
chartTag: line-chart
---
In this example, the chart is optimized to answer the key business question, “Which countries are experiencing faster or slower pace of growth?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use bold and subtle colors to emphasize overall trend patterns. In this example, the gray and blue highlight color palette emphasizes the worldwide trend line.
- **Data abstraction:** Using the first date period (Q1 FY21) as a baseline allows for easier comparisons of relative growth across countries with diverse economic sizes.
- **Number formatting:** Use symbols and formatting to clarify the meaning. In this example, including a plus sign (+) in the axis labels helps clearly communicate growth rates.
---
# line-chart-trend-with-categories
---
title: Trend with categories
description: Line chart used to compare differences in trends between two to five categories.
thumbnail: assets/data-visualization/examples/line-chart/trend-with-categories.svg
filter:
type: line
insight:
- trend
example:
id: line-chart-trend-with-categories
chartTag: line-chart
---
In this example, the chart is optimized to answer the key business questions, “How did performance change over time?” and “Is the gap between the two categories growing or shrinking?”. The following elements help emphasize the key takeaways:
- **Color palette:** Use colors from the categorical color palette to ensure both categories have equal visual emphasis and importance.
- **Data labels:** Show labels directly over each data marker to make it easier to interpret the exact value of each data point.
- **Gridlines:** Show horizontal gridlines to make it easier to compare differences across all data points.
---
# index
---
title: Brand guidance for products
description: Discover essential guidelines for Visa products, including card art, fictitious brands and user aliases, as well as logo creation and naming conventions.
meta_description: Discover essential guidelines for Visa products, including card art, fictitious brands and user aliases, as well as logo creation and naming conventions.
page_size: full-width
side_nav_title: Brand guidance for products
side_nav_additional_screenreader_title: for the Brand guidance for products
side_nav_order: 0
show_table_of_contents: false
---
---
# index
---
title: Design kits
description: Prototype quickly with VPDS design kits, equipped with everything you need to create user-friendly experiences.
meta_description: Prototype quickly with VPDS design kits, equipped with everything you need to create user-friendly experiences.
side_nav_order: -1
---
## Internal users
#### Step 1: Sign into Figma using Visa SSO
Visa employees should be added to our Figma organization automatically. Once signed in, there's no need to join or request to join any specific team to access the [Nova Figma libraries](https://www.figma.com/files/939645710326344313/team/979490301166271164/Nova?fuid=958800392878624560).
#### Step 2: Ensure VPDS libraries are enabled
In your design file, navigate to the left-side navigation panel and select **Libraries**. A modal will pop up.
The **Nova: Components** and **Nova: Icons** libraries will be enabled automatically and indicated by a checkmark. Additional libraries such as **Data Experience: Charts** can also be enabled from this modal using the search field or by navigating to **Your organization** and then selecting the **Visa Product Design System (VPDS)**.
## External users
#### Step 1: Sign into Figma
Use your credentials to access the Figma platform. If you don't have an account, you can create one for free.
#### Step 2: Get the libraries
Navigate to the [Visa Product Design System](https://www.figma.com/@visa) within the Figma community.
#### Step 3: Duplicate the file to your workspace
Explore the Visa Product Design System files and select one to duplicate in your own workspace.
## Start designing
#### Find and place components
The Visa Product Design System includes more than 50 components, patterns, and their variants. Navigate to or search for components from the **Assets** tab in the left-side navigation panel, and drag and drop them to the stage. Use the **Application layouts** to start your designs from preset examples.
For more help on how to use Figma, visit [Figma Learn](https://help.figma.com/hc/en-us/categories/360002051613-Get-started)
#### Adjust component properties
Drag the component you wish to use onto canvas. The component will be selected, allowing you to view the name of the component in the right-side properties panel until deselected. If the component has variants, you’ll see fields underneath the component name to configure the properties and values of that component set.
Need to customize a component beyond the properties provided in the panel? Find out more about theming and customization in [Design tokens for designers](https://design.visa.com/base-elements/design-tokens/tokens-for-designers).
#### Apply color and text styles
Visa Product Design System color and typography design tokens are surfaced in Figma using styles. As you design, you can use these styles to ensure consistency as you add your own elements. Access these styles in the right-side properties panel under **Appearance**.
Learn more about using color, typography, and more in [Base elements](https://design.visa.com/base-elements/).
For more help on how using variables in Figma, visit [Figma Learn](https://help.figma.com/hc/en-us/articles/15343816063383-Modes-for-variables)
---
# index
---
title: Start designing with VPDS
description: Learn how to start designing with the Visa Product Design System using this step-by-step guide for ease and efficiency.
meta_description: Learn how to start designing with the Visa Product Design System using this step-by-step guide for ease and efficiency.
side_nav_title: Get started
show_table_of_contents: false
---
## Step 1: Familiarize yourself with the system
Check out the Visa Product Design System documentation. It's filled with principles and best practices that will provide a solid foundation, even in the absence of a dedicated design or content team.
- Understand our foundational principles including [Accessibility](https://design.visa.com/global-accessibility-requirements) and [Inclusive design](https://design.visa.com/about-VPDS/inclusive-design) in About VPDS.
- Discover our system's visual and architectural standards used to ensure consistent digital experiences in [Base elements](https://design.visa.com/base-elements).
- Find usage, specs, and accessibility guidance for the building blocks of the system in [Components](https://design.visa.com/components).
- Find layouts for common tasks like uploading a file or requesting a one-time passcode in [Patterns](https://design.visa.com/patterns).
- Create insightful, inclusive, and accessible data experiences for everyone, everywhere with [Data visualization](https://design.visa.com/data-visualization).
- Discover all the essentials for writing product content like voice and tone, grammar, and alert messaging in [Content](https://design.visa.com/content).
## Step 2: Get the Figma design kits
The VPDS team maintains design kits in Figma. These include components and styles that are updated automatically with each system release. To get set up, visit [Design kits](https://design.visa.com/designing/design-kits) and follow the instructions for internal or external users.
## Step 3: Connect with us
Have questions or ideas? Subscribe to our email list, visit our office hours, or join us on Teams by visiting [Support](https://design.visa.com/support).
---
# index
---
title: Accessibility utilities
side_nav_additional_screenreader_title: for Angular
description: Create screen reader-friendly code in Angular to enhance the accessibility of your web apps.
---
---
# index
---
title: Changelog
side_nav_additional_screenreader_title: for Angular
description: Keep up-to-date with the latest updates and enhancements in the Angular changelog.
side_nav_order: 1
show_table_of_contents: false
---
Learn more about the latest Nova Angular version in our article,
[Meet Nova Angular 6](https://design.visa.com/what's-new/latest-news/fy25-nova-angular-6).
For step-by-step instructions on upgrading from Nova Angular 5.x to 6.x, refer to the
[Migration guide](https://github.com/visa/nova-angular/blob/main/MIGRATION_GUIDE.md).
7.0.0 (2026-03-20)
This release adds Angular 21 support and drops Angular 18 support. It introduces new workshop patterns including a comprehensive dynamic-table pattern with filtering, pagination, and expandable rows, a file-upload pattern, and a chat pattern. Several component bug fixes improve combobox reliability, floating UI focus management, and toggle button state handling.
BREAKING CHANGES
- **Angular:** Drop Angular 18 support; library now requires Angular 19, 20, or 21
Features
- **Surface:** Add surface variant classes for styling flexibility
- **Dynamic Table:** Add comprehensive patterns with sorting, filtering, pagination, expandable rows, and action bars
- **File Upload:** Add patterns with drag-and-drop, progress tracking, and validation
- **Chat:** Add dialog-based, panel-based, and full-page chat patterns
Bug Fixes
- **Combobox:** Reinstate automatic selection functionality
- **Combobox:** Handle runtime undefined list case to prevent errors
- **Floating UI:** Restore focus to trigger element when floating UI closes
- **Floating UI:** Close menu on child click and properly bind disabled property
- **Tab:** Fix disclosure tab bug when both expanded prop and disclosureTabToggled event are present
- **Toggle Button:** Allow multiselect toggle group to return to empty state
- **Toggle Button:** Fix initial state handling for multiselect mode
- **Progress:** Allow indeterminate circular progress to be customized
- **Pagination Control:** Prevent duplicate pages from appearing in start and end blocks
- **File Upload:** Fix live region behavior for edge cases improving screen reader announcements
- **Application Layouts:** Correct footer background color in layout patterns
6.0.2 (2025-09-26)Features
- **Library:** Nova Angular now supports Angular 18, 19, and 20
- **Component:** List item
- **Pattern:** Application layouts
- **Pattern:** Wizard
5.1.3 (2025-04-11)Features
- Initial release of the component library.
- Added a collection of components, utilities, and services.
- Components
- Accordion
- Anchor link menu
- Avatar
- Badge
- Banner
- Breadcrumbs
- Button
- Checkbox
- Chip
- Color selector
- Combobox
- Content card
- Date and time selectors
- Dialog
- Divider
- Dropdown menu
- Flag
- Footer
- Horizontal navigation
- Icon
- Input
- Link
- Listbox
- Multiselect
- Navigation drawer
- Pagination
- Panel
- Progress
- Radio
- Section message
- Select
- Switch
- Table
- Tabs
- Toggle
- Tooltip
- Vertical navigation
- Wizard
- Services
- Accordion
- App-ready
- Combobox
- Floating-ui
- Id generator
- Listbox
- Nova lib
- Pagination
- Utilities
- A11y
- Breakpoints
- Elevation
- Flex
- Open-in-new-tab
- Spacing
- Surface
- Typography
---
# index
---
title: Start building with Angular
description: Follow this step-by-step guide to start developing with the Visa Product Design System in Angular.
meta_description: Follow this step-by-step guide to start developing with the Visa Product Design System in Angular.
side_nav_title: Get started
side_nav_aria_label: Get started with Angular
is_nested_index: true
---
## Step 1: Update Angular
Nova Angular supports Angular 19, 20, and 21. See Angular's guide on how to
[upgrade Angular from your current version to the target version](https://angular.dev/update-guide?v=18.0-19.0&l=1).
## Step 2: Install the library
You can install the Nova Angular library using the package manager of your choice. Below we’ve provided the most common: NPM, PNPM, Yarn, and Bun.
**Note:** Package managers can resolve dependencies differently and might not automatically install all required dependencies.
Step 2b: Component-specific installs
If you’re using Dialog, install the Angular cdk package.
Some package managers may require you to install our peer dependency packages if you don't have them already:
***Note:** Install a version of @angular/forms that matches the version of Angular you are using.*
## Step 3: Set up the application
Step 3a: Import Nova styles
Import the Nova styles library and theme in your angular JSON or equivalent file. Visa is the default theme, but can be replaced with other available themes. To learn more, visit [Theming](https://design.visa.com/base-elements/design-tokens/overview), and for more about Nova styles, visit [Get started for Styles (CSS)](https://design.visa.com/developing/styles-css).
Step 3b: Import the Nova Angular component library
Import our library into your standalone component or NgModule.
## Step 4: Add icons (optional)
Nova Angular can be used with Nova icons or a custom icon library. This documentation and the component examples use the Nova icons library. In addition, Angular icons are available as standalone icons or icon sprites. They can be imported into your standalone component file, or your NgModule.
Install Nova iconsStandalone icons (recommended)
If you need just a few icons, you can import them directly from , then use the icons directly inside your HTML.
HTMLIcon sprites
If you need many icons or prefer a single import for all icons of a type, you can use icon sprites. Import them directly from , then use the icons inside your HTML.
HTML
## Step 5: Use the components
After adding Nova icons, you're ready to use Angular components by copying and pasting the example code into your application. Check out [Button](https://design.visa.com/components/button) to give it a try.
---
# index
---
title: App ready check service
side_nav_title: App ready check
description: Ensure your application's stability and readiness by verifying browser and DOM functions.
meta_description: Ensure your application's stability and readiness by verifying browser and DOM functions.
---
## Component Code Examples: app-ready
This component is available in the following libraries:
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- Angular → `angular`
**Example (Angular 7.0.0)**:
```javascript
const libraryName = "angular"; // Determined from Step 1
const version = "7.0.0"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-angular-7.0.0.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the app-ready component
const component = parsed.components.find(c => c.name === 'app-ready');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `app-ready`
**Available in**:
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Floating UI service
side_nav_title: Floating UI
meta_description: Create and manage floating elements seamlessly with our internal Floating UI service.
description: Create and manage floating elements seamlessly with our internal Floating UI service.
---
## Component Code Examples: floating-ui
This component is available in the following libraries:
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- Angular → `angular`
**Example (Angular 7.0.0)**:
```javascript
const libraryName = "angular"; // Determined from Step 1
const version = "7.0.0"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-angular-7.0.0.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the floating-ui component
const component = parsed.components.find(c => c.name === 'floating-ui');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `floating-ui`
**Available in**:
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Uniqe ID generator service
side_nav_title: Unique ID generator
meta_description: Generate unique IDs for elements within applications, ensuring consistency and uniqueness.
description: Generate unique IDs for elements within applications, ensuring consistency and uniqueness.
---
## Component Code Examples: id-generator
This component is available in the following libraries:
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- Angular → `angular`
**Example (Angular 7.0.0)**:
```javascript
const libraryName = "angular"; // Determined from Step 1
const version = "7.0.0"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-angular-7.0.0.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the id-generator component
const component = parsed.components.find(c => c.name === 'id-generator');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `id-generator`
**Available in**:
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Nova library service
side_nav_title: Nova library
meta_description: Access a suite of helper functions designed specifically for Nova components.
description: Access a suite of helper functions designed specifically for Nova components.
---
## Component Code Examples: nova-lib
This component is available in the following libraries:
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- Angular → `angular`
**Example (Angular 7.0.0)**:
```javascript
const libraryName = "angular"; // Determined from Step 1
const version = "7.0.0"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-angular-7.0.0.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the nova-lib component
const component = parsed.components.find(c => c.name === 'nova-lib');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `nova-lib`
**Available in**:
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Accessibility utilities
side_nav_additional_screenreader_title: for Flutter
description: Create screen reader-friendly code in Flutter to enhance the accessibility of your apps.
---
---
# index
---
title: Changelog
side_nav_additional_screenreader_title: for Flutter
description: Keep up-to-date with the latest updates and enhancements in the Flutter changelog.
show_table_of_contents: false
---
8.3.1 (2026-02-25)Accessibility
- Improved `VComboboxScreen` component accessibility:
- Added screen reader announcements for search result count changes
- Added "No results found" and "\{count\} results found" announcements during search filtering
- Enhanced clear button with proper semantics (`label`, `hint`, `button` role) and "Search field cleared" announcement
- Improved close button semantics with descriptive label and hint
- Added `liveRegion` semantics for empty results state
- Enhanced list item accessibility with `selected` state, proper labels, and selection announcements
- Wrapped list items with `Semantics` widget for better VoiceOver/TalkBack support
8.3.0 (2025-11-19)Added
- New `errorBorderColor` token in `VMessageColorSet` for WCAG-compliant form validation borders.
- New `disabledIcon` token in `VDefaultThemeProps` and `VAltThemeProps` for disabled icon states.
- Six new disabled-state color tokens for toggle switch (`trackDisabledOff`, `trackDisabledOn`, `thumbDisabled` and dark mode variants).
- New `VSwitchStyle` properties for disabled state customization: `trackDisabledOff`, `trackDisabledOn`, `thumbDisabled`, `borderDisabledOff`, `borderDisabledOn`, `thumbBorderDisabled`.
- New `VAccordion` properties: `initiallyExpanded`, `isExpanded`, `onExpansionChanged` for controlled accordion behavior.
- New `VToggle` property: `isMultiSelect` for multi-select toggle support.
- New `VBottomNavBarStyle` property: `indicatorColor` for tab bar selection indicator customization.
- New `VBottomBarItems` property: `preserveIconColors` to preserve original icon colors in bottom navigation bar.
- Added 99 new code examples across Accordion, Avatar, Badge, Banner, Button, Chip, Content Card, Dialog, Dropdown Menu, Link, List Item, Radio, Switch, Toggle, and Typography.
- Added missing demo code examples for Accordion groups, Badge icon variants, Banner close icon, Button sizes and icon buttons, Chip read-only and group variants, Dropdown secondary and disabled variants, Link disabled and external variants, Radio individual buttons and panels, Switch states, and Toggle label variants.
Changed
- Improved WCAG 2.1 Level AA compliance across all disabled states with full opacity colors.
- Form validation error borders now use dedicated `errorBorderColor` token in dark mode.
- Toggle switch disabled states now use full opacity colors instead of forced opacity.
- Disabled icons in `VDropdownMenu`, `VInput`, and `VSelect` now use `disabledIcon` token.
- `VToggleStyle` default `height` changed from 50.0 to 40.0.
- `VToggleStyle` default `minimumWidth` changed from 50.0 to 44.0.
- Fixed toggle label alignment, padding, active font styling, and multiselect behavior.
- Fixed icon alternate color rendering.
Fixed
- VPA accessibility gaps: form field error/validation text contrast in dark mode.
- VPA accessibility gaps: toggle switch "Off" state contrast in light and dark modes.
- VPA accessibility gaps: disabled icon color contrast (Face ID, empty states, dropdowns, inputs).
- Regression fixes across Badge, Banner, Button, Toggle, Checkbox, Chips, Tab Bar, Top App Bar, and Radio.
- Resolved all Dart analyzer warnings and info-level issues across the SDK codebase.
Testing
- Added 6 new test files for material widget forks.
- Added golden snapshot tests for all 28 components.
- Expanded test suite to 740+ tests with 100% pass rate.
8.2.0 (2025-09-26)Features
- Added a collection of patterns:
- Application layout
- Chat
- File Upload
- Wizard
- Added a new property enableInteractiveSelection to VInput.
8.1.2 (2025-04-10)Features
- Updated license in all files and pubspec.yaml
8.1.1 (2025-03-26)Features
- Updated pubspec.yaml
8.1.0 (2025-03-26)Features
- Initial release of the component library.
- Added a collection of components:
- Accordion
- App Bar
- Avatar
- Badge
- Banner
- Bottom Navigation Bar
- Button
- Checkbox
- Chip
- Combobox
- Content Card
- Dialog
- Divider
- Dropdown Menu
- Flag
- Icon
- Input
- Link
- List Item
- Navigation Drawer
- Panel
- Progress
- Radio
- Section Message
- Select
- Switch
- Tab
- Toggle
- Wizard
---
# index
---
title: Start building with Flutter
description: Follow this step-by-step guide to start developing with the Visa Product Design System in Flutter.
meta_description: Follow this step-by-step guide to start developing with the Visa Product Design System in Flutter.
side_nav_title: Get started
side_nav_aria_label: Get started with Flutter
is_nested_index: true
---
## Step 1: Update Flutter
Nova Flutter supports Dart 2.19 and up with null safety, and our current Flutter SDK version is 3.29.2. To set up your Flutter development environment, visit the [Flutter App Pre-requisite and Setup Guide (internal only)](https://bookmarks.visa.com/Flutter%20Development%20Environment%20Setup) or [Choose your development platform to get started](https://docs.flutter.dev/get-started/install).
### Version
The version number reflects the number of developed components. Our current version is 8.3.1.
## Step 2: Install the library
### Set up pub.dev
You can install the Nova Flutter library [by setting up your Pub.dev environment](https://pub.dev/), then using the package below.
## Step 3: Import Nova components
Import the library into your Dart code.
## Step 4: Add icons (optional)
We've created a dedicated widget, VIcon, to seamlessly integrate the SVG icon library with the components library. To best use Nova icons, import the library along side our visa_nova_flutter library.
## Step 5: Use the components
After adding Nova icons, you're ready to use Flutter components by copying and pasting the example code into your application. Check out [Button](https://design.visa.com/components/button?code_library=flutter) to give it a try.
---
# index
---
title: Start developing with VPDS
description: Learn how to start developing with the Visa Product Design System using this step-by-step guide for ease and efficiency.
meta_description: Learn how to start developing with the Visa Product Design System using this step-by-step guide for ease and efficiency.
side_nav_title: Get started
side_nav_aria_label: Get started
show_table_of_contents: false
---
## Browser Support
Our design system supports the latest versions of all major evergreen browsers, including Chrome, Firefox, Safari, and Edge. We do not support legacy or non-evergreen browsers.
Why only evergreen browsers?
- Security: Evergreen browsers receive regular security updates, helping protect users and their data.
- Consistency: We use modern HTML and CSS features that are consistently supported across evergreen browsers, ensuring a reliable user experience.
- Performance: By focusing on up-to-date browsers, we can take advantage of the latest web standards for optimal performance.
- Maintainability: Supporting only evergreen browsers allows us to keep our codebase clean and efficient, without the need for legacy workarounds.
For the best experience, please use the latest version of your preferred browser.
## Step 1: Familiarize yourself with the system
Check out the Visa Product Design System documentation. It's filled with principles and best practices that will provide a solid foundation, even in the absence of a dedicated design or content team.
- Understand our foundational principles including [Accessibility](https://design.visa.com/global-accessibility-requirements) and [Inclusive design](https://design.visa.com/about-VPDS/inclusive-design) in About VPDS.
- Discover our system's visual and architectural standards used to ensure consistent digital experiences in [Base elements](https://design.visa.com/base-elements).
- Find usage, specs, and accessibility guidance for the building blocks of the system in [Components](https://design.visa.com/components).
- Find layouts for common tasks like uploading a file or requesting a one-time passcode in [Patterns](https://design.visa.com/patterns).
- Create insightful, inclusive, and accessible data experiences for everyone, everywhere with [Data visualization](https://design.visa.com/data-visualization).
- Discover all the essentials for writing product content like voice and tone, grammar, and alert messaging in [Content](https://design.visa.com/content).
## Step 2: Install the code library of your choice
VPDS supports core parts of the system in CSS, React, Angular, and Flutter. You can visit get started pages for [CSS](https://design.visa.com/developing/styles-css), [React](https://design.visa.com/developing/react), [Angular](https://design.visa.com/developing/angular), and [Flutter](https://design.visa.com/developing/flutter) with quick start guides for each library.
## Step 3: Connect with us
Have questions or ideas? Subscribe to our email list, visit our office hours, or join us on Teams by visiting [Support](https://design.visa.com/support).
---
# index
---
title: Accessibility utilities
side_nav_additional_screenreader_title: for React
description: Create screen reader-friendly code in React to enhance the accessibility of your apps.
---
---
# index
---
title: Changelog
side_nav_additional_screenreader_title: for React
meta_description: ""
description: Keep up-to-date with the latest updates and enhancements in the React changelog.
side_nav_order: 1
show_table_of_contents: false
---
For step-by-step instructions on upgrading from Nova React v2.x to v3.x, refer to the [migration guide](https://github.com/visa/nova-react/blob/main/MIGRATION-GUIDE.md). 3.1.0 (2026-03-20)This release introduces new component properties, hooks, and pattern improvements. Key additions include the hook for form state management, enhanced pagination controls with compact mode and controlled state, and expanded table customization options.Features
- **Button:** Allow button to accept primary type
- **Label:** All labels now extend typography
- **Table:** Added `tableSize` property
- **useModel:** Added new hook for form state management
- **usePagination:** Added compact mode
- **usePagination:** Optional props for provided/controlled state
- **useTabs:** Allows controlled selected index value
- **Utility:** `vFlexRow` now adds `vFlex` by default
- **Dynamic Table:** Complete default pattern example with base shared components
Bug Fixes
- **Application Layouts:** Footer background color now applies correctly
- **Components:** Removed `defaultProps` to suppress React 19 deprecation warning
- **Dropdown:** Dropdown items padding corrected
- **Screen Reader:** Correct component selector typo in API
- **Chat:** Pattern examples now use `hideTimestamp` prop for consistency
- **Chat:** Adds validation reset and responsive behavior
- **Chat:** Responsive padding on chat bubbles
- **Chat:** Uses dialog content for dark mode
- **File Upload:** Upload dialog flexible with boundaries
- **File Upload:** Prevent card shift from uploading text
- **File Upload:** Lowercases file extensions in display text
- **Dynamic Table:** Remove nested components for proper React rendering
3.0.0 (2025-09-26)Features
- Added a collection of patterns:
- Application layout
- Chat
- File Upload
- Wizard
2.5.4 (2025-04-11)Features
- Initial release of the nova-react library.
- Added a collection of components:
- Accordion
- Anchor link menu
- Avatar
- Badge
- Banner
- Breadcrumbs
- Button
- Checkbox
- Chip
- Color selector
- Combobox
- Content card
- Date and time selectors
- Dialog
- Divider
- Dropdown menu
- Flag
- Footer
- Horizontal navigation
- Icon
- Input
- Label
- Link
- Listbox
- Logo
- Multiselect
- Navigation drawer
- Pagination
- Panel
- Progress
- Radio
- Section message
- Select
- Switch
- Table
- Tabs
- Toggle button
- Tooltip
- Vertical navigation
- Wizard
- Added several hooks:
- use-accordion
- use-card-number-validation
- use-debounce
- use-focus-trap
- use-listbox
- use-pagination
- use-tabs
- use-wizard
- Added Utility and UtilityFragment components.
---
# index
---
title: useCardNumberValidation
description: Learn how to utilize the useCardNumberValidation hook to validate card numbers.
meta_description: Learn how to utilize the useCardNumberValidation hook to validate card numbers.
---
## Component Code Examples: use-card-number-validation
This component is available in the following libraries:
- **React** (@visa/nova-react)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- React → `@visa/nova-react`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- React → `react`
**Example (React 3.1.0)**:
```javascript
const libraryName = "react"; // Determined from Step 1
const version = "3.1.0"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-react-3.1.0.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the use-card-number-validation component
const component = parsed.components.find(c => c.name === 'use-card-number-validation');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `use-card-number-validation`
**Available in**:
- React: versions 3.1.0, 3.0.0, 2.5.4
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: useDebounce
description: Learn how to utilize the useDebounce hook to delay the execution of an expensive function.
meta_description: Learn how to utilize the useDebounce hook to delay the execution of an expensive function.
---
## Component Code Examples: use-debounce
This component is available in the following libraries:
- **React** (@visa/nova-react)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- React → `@visa/nova-react`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- React → `react`
**Example (React 3.1.0)**:
```javascript
const libraryName = "react"; // Determined from Step 1
const version = "3.1.0"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-react-3.1.0.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the use-debounce component
const component = parsed.components.find(c => c.name === 'use-debounce');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `use-debounce`
**Available in**:
- React: versions 3.1.0, 3.0.0, 2.5.4
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: useFocusTrap
description: Learn how to utilize the useFocusTrap hook to confine focus within a specified container.
meta_description: Learn how to utilize the useFocusTrap hook to confine focus within a specified container.
---
## Component Code Examples: use-focus-trap
This component is available in the following libraries:
- **React** (@visa/nova-react)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- React → `@visa/nova-react`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- React → `react`
**Example (React 3.1.0)**:
```javascript
const libraryName = "react"; // Determined from Step 1
const version = "3.1.0"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-react-3.1.0.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the use-focus-trap component
const component = parsed.components.find(c => c.name === 'use-focus-trap');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `use-focus-trap`
**Available in**:
- React: versions 3.1.0, 3.0.0, 2.5.4
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Start building with React
description: Follow this step-by-step guide to start developing with the Visa Product Design System in React.
meta_description: Follow this step-by-step guide to start developing with the Visa Product Design System in React.
side_nav_title: Get started
is_nested_index: true
side_nav_aria_label: Get started with React
---
## Step 1: Update React
Nova React supports React 19 and up. Visit React’s guide on how to upgrade to [React 19](https://react.dev/blog/2024/04/25/react-19-upgrade-guide) for more.
## Step 2: Install the library
You can install the Nova React library and the Nova styles library using the package manager of your choice. Below we’ve provided the most common: NPM, PNPM, Yarn, and Bun.
**Note:** Package managers can resolve dependencies differently and might not automatically install all required dependencies.
## Step 3: Set up the application
### Import Nova styles
Next, import the Nova styles library and your desired theme at the root level of your React project. The Visa theme is the default. To learn more, visit [Theming](https://design.visa.com/base-elements/design-tokens/overview), and for more about Nova styles, visit [Get started with Styles (CSS)](https://design.visa.com/developing/styles-css).
## Step 4: Add icons (optional)
For React, each icon has been developed as a React component, allowing you to selectively choose the icons you need. The library is designed to support deep tree shaking, ensuring that only the icons you use are bundled with your app. This optimization reduces build and load times as well as app sizes. The React library also provides native support for TypeScript, along with full support for all SVG properties and refs.
Once you’ve installed the icon library, you can use them as components inside your TSX or JSX.
## Step 5: Use the components
After adding Nova icons, you're ready to use React components by copying and pasting the example code into your application. Check out below how to put our components to use with a few sample components.
---
# index
---
title: Action primary
description: Use these generic styles to enhance user interactions with primary buttons designed for accessibility, or customize and create your own components.
---
## Component Code Examples: action-primary
This component may not be available in the library documentation system.
---
# index
---
title: Action secondary
description: Use these generic styles to enhance user interaction with secondary buttons that complement primary actions, or customize and create your own components.
---
## Component Code Examples: action-secondary
This component may not be available in the library documentation system.
---
# index
---
title: Input
description: Use these generic styles to handle user data entry with various input components, and to customize and create your own components.
---
## Component Code Examples: input
This component is available in the following libraries:
- **CSS** (@visa/nova-styles)
- **Flutter** (@visa/nova-flutter)
- **React** (@visa/nova-react)
- **Angular** (@visa/nova-angular)
### Instructions for AI/LLM Assistants
#### Step 1: Determine the user's preferred library
Ask the user which framework/library they're using, or infer from their project context:
- **React** - For React, Next.js, or React-based projects
- **Angular** - For Angular projects
- **Flutter** - For Flutter/Dart mobile applications
- **CSS** - For vanilla HTML/CSS or framework-agnostic styling
#### Step 2: Get available versions for the chosen library
Fetch the libraries metadata to see all available versions:
**Endpoint**: `https://design.visa.com/api/libraries.json`
**Filter by package name**:
```javascript
const response = await fetch('https://design.visa.com/api/libraries.json');
const data = await response.json();
const allLibraries = JSON.parse(data.body).data;
// Example: Get React versions
const reactVersions = allLibraries
.filter(lib => lib.name === '@visa/nova-react')
.map(lib => lib.version)
.reverse(); // Latest version first
console.log(reactVersions); // ["3.0.0", "2.5.4"]
// Use reactVersions[0] for latest, or let user choose specific version
```
**Package name mappings**:
- CSS → `@visa/nova-styles`
- Flutter → `@visa/nova-flutter`
- React → `@visa/nova-react`
- Angular → `@visa/nova-angular`
#### Step 3: Fetch component data from the selected library
Build the API endpoint using the library and version:
**Endpoint Pattern**: `https://design.visa.com/api/nova-{library}-{version}.json`
**Library name mappings** (for URL):
- CSS → `styles`
- Flutter → `flutter`
- React → `react`
- Angular → `angular`
**Example (CSS 1.6.5)**:
```javascript
const libraryName = "styles"; // Determined from Step 1
const version = "1.6.5"; // Determined from Step 2
const endpoint = `https://design.visa.com/api/nova-styles-1.6.5.json`;
const response = await fetch(endpoint);
const data = await response.json();
const parsed = JSON.parse(data.body);
// Find the input component
const component = parsed.components.find(c => c.name === 'input');
// Access component data
console.log(component.description);
console.log(component.examples); // Array of code examples with snippets
console.log(component.exampleSections); // Categories of examples
```
#### Step 4: Extract the code examples
Each component has an `examples` array with code snippets:
```javascript
// Example structure:
component.examples.forEach(example => {
console.log(example.name); // "Default accordion"
console.log(example.description); // Description of the example
console.log(example.snippets.tsx); // TypeScript/React code
console.log(example.snippets.dart); // Flutter code (if Flutter library)
console.log(example.url.github); // Link to source code
});
```
### Quick Reference
**Component Name**: `input`
**Available in**:
- CSS: versions 1.6.5, 1.6.4, 1.6.2
- Flutter: versions 8.3.1, 8.3.0, 8.2.0, 8.1.2, 8.1.1, 8.1.0
- React: versions 3.1.0, 3.0.0, 2.5.4
- Angular: versions 7.0.0, 6.0.2, 5.1.3
**Recommended workflow**:
1. If you already know the user's library and can infer the latest version, skip directly to Step 3
2. If unsure, ask the user or fetch `/api/libraries.json` to present options
3. Build the endpoint URL and fetch the component data
4. Extract and present the relevant code examples
---
# index
---
title: Message
description: Use these generic styles to communicate important information with message components, or customize and create your own components.
---
## Component Code Examples: message
This component may not be available in the library documentation system.
---
# index
---
title: Accessibility styles
side_nav_additional_screenreader_title: for Styles (CSS)
description: Create screen reader-friendly code in CSS to enhance the accessibility of your apps.
---
---
# index
---
title: Changelog
side_nav_additional_screenreader_title: for Styles (CSS)
description: Keep up-to-date with the latest updates and enhancements in the Styles (CSS) changelog.
show_table_of_contents: false
---
1.6.5 (2026-03-19)Features
- Added Surface 2 and Surface 3 examples.
Bug Fixes
- Improved dark mode support for color, date, and time inputs.
- Fixed table row scope attributes and adjusted inline table padding.
- Fixed Select RTL support.
- Fixed Select options background color styling.
- Improved link wrapping behavior with trailing icons.
- Updated Typography active color variable.
1.6.4 (2025-09-26)Features
- Added patterns:
- Application layouts
- Wizard
- Added List item component.
- Added several classes:
- v-accordion-subtle
- v-icon-success
- v-icon-warning
- v-icon-error
- v-surface-2
- v-surface-3
- Consolidated themes.
1.6.2 (2025-04-11)Features
- Initial release of the component library.
- Added a collection of components:
- Accordion
- Anchor link menu
- Avatar
- Badge
- Banner
- Breadcrumbs
- Button
- Checkbox
- Chip
- Color selector
- Combobox
- Content card
- Date and time selectors
- Dialog
- Divider
- Dropdown menu
- Flag
- Footer
- Horizontal navigation
- Icon
- Input
- Label
- Link
- Listbox
- Logo
- Multiselect
- Navigation drawer
- Pagination
- Panel
- Progress
- Radio
- Section message
- Select
- Switch
- Table
- Tabs
- Toggle button
- Tooltip
- Vertical navigation
- Wizard
---
# index
---
title: Start building with Nova styles
description: Follow this step-by-step guide to developing web experiences with the Visa Product Design System.
meta_description: Follow this step-by-step guide to start developing web experiences with the Visa Product Design System.
side_nav_title: Get started
side_nav_aria_label: Get started with Styles (CSS)
is_nested_index: true
---
## Step 1: Install Nova styles
You can use NPM, PNPM, or Yarn to install Nova styles, depending on your preference or your project's requirements. Choose one of the following package managers for the installation.
## Step 2: Import Nova styles
Once Nova styles is installed, you need to import it in your project. This process might look different depending on whether you're using HTML, [React](https://design.visa.com/developing/react), or [Angular](https://design.visa.com/developing/angular). Follow the instructions for your setup below.
### HTML
If you're working with standard HTML, add a link to the Nova styles CSS file in your HTML file by replacing the actual path where the Nova styles files are located.
## Step 3: Add icons (optional)
You can use Nova CSS to add [Icons](https://design.visa.com/components/icons-illustrations) to your web applications. Use individual SVGs for specific icons or SVG sprites to efficiently load and reuse a full set of icons across your app.
### Installing @visa/nova-icons-svg
### Installing @visa/nova-icons-sprite
### SVGs
SVG stands for Scalable Vector Graphics, which is an image format based on XML for creating two-dimensional graphics. The key feature of SVGs is their scalability, allowing them to be resized without losing quality. This makes them ideal for the web, where images need to look good on various screen sizes and resolutions. Additionally, SVGs are often much smaller in size compared to JPEGs and PNGs.
### SVG sprites
A sprite is a collection of SVG icons combined into a single file. This method is commonly used to enable a single server request for all icons, making it the most efficient way to access a large number of icons, especially if many are likely to be used during a session.
#### Using SVG sprites
Import and use icons sprite from @visa/nova-icons-sprite. This will add all of the icons as a sprite into your project and then reference them as needed. It's up to you if you'd like to use the Visa sprite, the Generic sprite, or both.
## Step 4: Use the components
After importing Nova styles and adding icons, you're ready to use its components by copying and pasting the example code into your application. Check out [Button](https://design.visa.com/components/button) to give it a try.
---
# design practices
---
title: Global accessibility requirements
description: Learn how to ensure people of diverse abilities can use and interact with our digital products and tools.
meta_description: Discover helpful design practices to ensure people of diverse abilities can use and interact with our digital products and tools.
tab_title: Design practices
date: 01/01/2021
---
Each person's experience with a disability is unique, and it’s important to avoid categorizing people by disability "type". Instead, approach accessibility by understanding the ways people with disabilities use and interact with digital technologies, and design for them using the best practices defined in this section.
Designers can prevent about 70% of common accessibility issues by considering VGAR as they work. For additional context, [learn how users with various disabilities navigate web experiences](https://www.w3.org/WAI/people-use-web/user-stories/).
## Use of color
When using color to identify or differentiate elements, ensure the same information is available through alternative methods such as text or icons for users experiencing color blindness.
- Never use color alone to indicate a change in state including errors.
- Combine two of the three elements to assist users: color, icon, and descriptive text.
## Media controls
When using moving content, such as automatically-updating content or a slideshow carousel, clearly present users with the option to stop, pause, or hide the content.
- Never use content that blinks or flashes automatically as this can induce seizures in users with photosensitive disorders.
## Sufficient contrast
Maintaining a minimum contrast ratio between foreground and background colors is crucial for readability. It ensures that content is easily distinguishable and readable, especially for users with visual impairments or color blindness. This adherence to contrast ratio requirements is a key aspect of creating an accessible and inclusive digital experience.
- Ensure that all content adapts to and supports the user's high contrast mode settings.
### Contrast requirements
Contrast ratio requirements by context
- Context: 4.5:1
- Context: 3:1
- Context: No requirement
- Context: 3:1
- Context: No requirement
## Responsive content
Responsive design is a cornerstone of accessibility, as it ensures content adapts well to different devices, screen sizes, and user preferences. This enhances the user experience, making your content more accessible and user-friendly for all.
- Always consider how your content will respond to changes like text resizing, spacing, and reflow.
### Resizing and scaling
Resizing and scaling are key for accessibility as they allow users with visual impairments to enlarge content without losing functionality or ease of navigation.
- Design content to scale effectively, ensuring it remains fully functional and doesn't require horizontal scrolling even when users increase the size to 400%.
### Increasing spacing
Content should adapt to increases in letter, word, line, and paragraph spacing. There should be no loss of content or functionality when:
- Line height or spacing is changed up to 1.5 times the font size.
- Paragraph spacing is changed up to 2 times the font size.
- Tracking or letter spacing is changed up to 0.12 times the font size.
- Word spacing is changed up to 0.16 times the font size.
Reference [Typography](https://design.visa.com/base-elements/typography) for further guidance.
## Navigation
Maintaining a consistent order for components across multiple pages is crucial for accessibility. It provides a predictable and intuitive navigation experience, particularly for users who rely on screen readers or keyboard navigation.
- Provide users with more than one way to locate content within a set of web pages, except when the page is a step in a process or its end result.
- If a page has a login feature and focus is not automatically set to the login field on page load, the page must include a “Skip to login” link as the first link on the page. The link must move focus to the login field, and the link may be hidden from view until it has focus.
- A "Skip to main content" link must be included on every page as the first link (or second if "skip to login" link is present) on the page. The link must skip to the main content of the page or the error summary (if present) and may be visually hidden until it has focus.
## Touch target areas
Ensuring sufficient space around interactive areas is vital as it facilitates easier interaction, particularly for users who may struggle with precise movements. When using components with smaller visual footprints, it's important to design with ample touch area in mind and avoid placing elements too closely together.
### Touch targets
Touch targets should be large and appropriately spaced for easy interaction by users with varying dexterity and vision.
Use the minimum size of 44x44dps for touch areas across all interactive components.
### Non-touch targets
Non-touch targets should be easily navigable and identifiable for users with varying levels of dexterity and vision.
- Use the minimum size of 24x24dps for target areas across all interactive components.
- Rounded corners detract from 24x24dps target area.
- To learn more details and nuances around target areas, check out the WCAG guidance.
## Error feedback
Pages collecting user input need to validate entries and ensure all users are aware of errors. By providing clear and immediate feedback about errors, you can create a more accessible and user-friendly experience.
- Provide users with clear instructions on how to correct errors when applicable.
- Never use color alone to indicate a change in state including errors.
- Combine two of the three elements to assist users: color, icon, and descriptive text.
## Consistent identification
Using consistent identification for content with the same functions is crucial for accessibility. This allows users, especially those using assistive technologies like screen readers, to easily identify and understand the purpose of interactive elements such as links, buttons, and custom controls. By doing so, you enhance the predictability and usability of your content, making it more accessible to all users.
- Use consistent labels, names, and text alternatives for content with the same functions across experiences.
## Labeling and instructions
Ensuring that form input controls have clear, descriptive labels and instructions helps users, particularly those with cognitive impairments or those using assistive technologies, to accurately identify specific components within the content. It also prevents incomplete or incorrect form submissions by providing users with the necessary information to fill out the form correctly.
- Ensure that form input controls have clear, descriptive labels and instructions.
- Use universally understood icons and text to help users understand labels.
## Hierarchy
Clear hierarchy is vital for accessibility. Always ensure that information, structures, and relationships conveyed through visual and auditory presentation formats are also programmatically determined or made available in text. By making this information available in a programmatically determined or text format, you ensure that it's accessible to all users, including those using assistive technologies like screen readers.
- Use headings and other visual cues to associate sections with related content and create a logical hierarchy.
- Content in a list format must use the correct ordered (ol) or unordered list (ul) markup.
- Learn more about structure in our [Content guidelines](https://www.figma.com/proto/nheFDgsLWgVSKTMq1Vbldg/Nova--Notation?type=design&node-id=3027-261561&t=3Nv8k2h0eGI4HWhJ-0&scaling=min-zoom&page-id=1376%3A130977&starting-point-node-id=1696%3A175077).
For further guidance on headings and hierarchy, refer to [Typography](https://design.visa.com/base-elements/typography) and [Information architecture](https://design.visa.com/content/information-architecture).
## Text-based alternatives
Providing accurate text alternatives for images and non-text content ensures the same information is conveyed with the same context and purpose to users who cannot perceive the original content due to visual impairments or those using assistive technologies like screen readers. By ensuring this information can be rendered through any sensory modality, you make your content more accessible.
- Ensure images and non-text content have accurate text alternatives that provide the same information, context, and purpose to users and can be rendered through any sensory modality.
- Always present text using live text and CSS, not images of text. The only exceptions are instances where images of text are unavoidable, such as logos, graphs, and screenshots.
## Multimedia content
Accurate closed captioning for all dialogue in video content allows all users to fully engage with the content. Additionally, they can be beneficial for individuals who may not have their sound turned on or for whom English is a second language. By ensuring all video content is accurately captioned, you make your content more accessible to a wider range of users.
- If the video provides information visually that the accompanying audio doesn’t describe, include an audio description track specifically explaining that information.
- If the audio description track can’t adequately explain the visual information during gaps in the dialogue, use an extended audio description.
- Add pauses at appropriate times in the video to allow the description to finish.
## States
Learn about visual cues and design requirements that help users understand component interactivity in [States](https://design.visa.com/base-elements/states).
---
# development and testing practices
---
title: Global accessibility requirements
description: Learn how to ensure people of diverse abilities can use and interact with our digital products and tools.
meta_description: Learn how to reduce the time spent in manual testing by writing accessible code and using automated tools to check development work.
tab_title: Development and testing practices
thumbnail: assets/about-vpds/accessibility/accessibility.svg
date: 01/01/2021
header_image: assets/about-vpds/accessibility/accessibility-overview.svg
---
Developers can reduce the time spent in manual testing by writing accessible code and using automated tools to check their work. Refer to VGAR to validate and iterate on work throughout the accessibility journey.
## Doctype declaration
HTML doctype is a required preamble. Without a valid doctype declaration, browsers tend to use a different rendering mode (such as no-quirks mode, quirks mode, limited-quirks mode, etc.) that is incompatible with some specifications. The `` doctype is required for legacy reasons. Provide a valid and accurate doctype for all web pages.
## Page title
The page `title` element represents the name of a document and identifies the relevance of information contained in a web page. Provide accurate, descriptive, and unique page titles. Use consistent structures for titles across web pages.
## Language
Identifying the language of a web page helps assistive technologies render text accurately. Provide the `lang` attribute specifying the primary language for the contents of an element and for any of that element's attributes containing text. When content is written in multiple languages, these requirements help assistive technologies present it according to the rules for each language. For instance, screen readers will invoke correct pronunciation rules, visual browsers will display characters and scripts accurately, and media players will show captions correctly.
## Hidden content
Content that may need to be hidden from sighted users, but not screen readers, must be moved off-screen using CSS.
Wrap this content in a `div` with `role="presentation"` and `aria-hidden="true"`. Additionally, set `tabindex="-1"`.
Content that may need to be hidden from both sighted and screen reader users should be removed from the DOM using CSS `visibility:hidden` or `display:none` and `aria-hidden="true"`.
## Structure and semantics
Headings are useful for organizing content into contextual sections, establishing content hierarchy, and enabling screen reader users to jump directly to specific content. They need to be defined with valid markup and structured in a proper nesting order to ensure assistive technologies can present them properly.
- Any text element which conveys information through its visual presentation style must be indicated semantically in code. This includes text styling such as strong, cite, blockquote, sub, and sup, and any other text style which carries secondary meaning.
- Paragraphs must be marked up as paragraphs.
- Groups of items, such as a navigation menu or group of tabs, must be marked up as a list.
To ensure that assistive technologies encounter the content in the same order as the logical presentation of the content, it should be structured in a logical order in the HTML code. Do not use CSS to order content. Additionally, any content that is not shown until a specific time or event should be removed from the DOM or parked at the bottom of the DOM.
## Forms and controls
Ensure that assistive technologies (AT) can gather information on, activate (or set), and update the status of user interface controls in the content.
Form controls that use a label to identify them must have only one label programmatically associated with them.
- Use `for=""`, `aria-labelledby`, or `aria-label` for for this label.
Communicate required controls in text either at the beginning of the form or in-line.
- Use the `aria-required="true"` attribute.
Groups of checkboxes should indicate the required state in text either at the beginning of the form by stating all fields are required, or in the group’s `fieldset` legend instead.
- Do not use the `aria-required` attribute.
Helper text must be programmatically associated with a form control.
- Use `aria-describedby=""`.
If there are multiple pagination controls on a page, they must have unique labels but still contain the word "Pagination".
- Use `role="navigation"` and `aria-label="Pagination"`.
## Error identification and suggestions
Controls being validated for errors must include `aria-invalid="true"` when an error is present.
- Keyboard focus must be automatically set to the first invalid form control when an error is detected using validation after the user submits the form.
- When an error is detected using client-side validation, set `aria-invalid="true"` and add the ID of the error helper text container to the `aria-describedby` attribute.
When an error is detected using in-line validation, any previous `role="alert"` instances must be removed from the DOM and `role="alert"` must be set on the container of the `error_helpertext`.
## System messages and navigation
System messages must include the `role="status"` and `aria-live="assertive"` attributes on the message container when added to the DOM. Only add system messages to the DOM after a button press or on page load so that they don’t interrupt the user’s workflow.
At minimum, the page must have a `main` landmark region defined, and `banner`, `navigation`, `search`, `complementary`, and `contentinfo` roles if these content types are present in the page.
- If a page has multiple landmarks of the same type, such as main navigation and sub-navigation, those regions must have unique names applied using an appropriate naming technique. Do not include the landmark role type in the name.
## Dialogs
Modal dialog windows must have `role="dialog"` and `aria-modal="true"` on the modal container.
Modal dialogs must have `aria-labelledby="id of dialog-title"` where "dialog-title" would be the modal dialog’s title, such as its main heading.
Modal dialogs should have `aria-describedby="dialog-desc"` where "dialog-desc" is helpful information above the first focusable element.
Modal dialogs must have focus set to an appropriate location based on the content presented in the modal dialog.
- Modal dialog windows must trap focus inside the modal dialog.
- Dialogs must restore focus to their triggering element when the dialog is closed.
Modal dialogs must allow the user to move through the modal dialog’s focusable elements, “wrapping around” from bottom-to-top and top-to-bottom using the TabShift + Tab key and keyboard events.
Modal dialogs must prevent mouse-clicks that occur outside the modal dialog from having any effect on the modal dialog.
If a heading is used in a dialog, the first heading level must be `H2` followed by appropriate heading levels.
Dialog windows must have the Esc keyboard event set to close the dialog.
## Tables
Tables must never be used for layout purposes. Data tables must use proper table headers `
`, and every table header must have the scope attribute set to `scope="col”` or `scope="row"`, unless it would invalidate a data relationship. If necessary, the header attribute can be used to hard code how headers should be read to screen reader users.
Data tables must be identified for screen readers by including the “title" of the table in its `
` element (the caption may be hidden visually with CSS). If the table has more than 4 table headings, a caption must be included to summarize its layout and functional relationships.
## Text alternatives
All non-text content must include text alternatives that provide equivalent information, context, and purpose to the user. Non-text content with `` elements provide the text alternative using the `alt` attribute. For non-text content using `role="img"`, use `aria-label`, `aria-labelledby`, or visibly hidden text.
All decorative non-text that provides no contextual value or is already defined by surrounding content must be hidden from screen reader users. For `` elements, use `alt=""`. For everything else, use `aria-hidden="true"`.
## Keyboard interaction
All functionality and content must be available via the keyboard only and should not require the specific timing of keystrokes. If keyboard focus is ever controlled by part of the UI, such as a PDF viewer or modal window, it must allow focus to return to the launching element and browser through keyboard commands only.
Keyboard users should be able to use the Tab key to navigate through the page in the same order as the visual presentation of the content. This tab order should be established by the HTML structure of the page. As the user moves through the page with the keyboard, a highly visible indication of keyboard focus should appear on each element as it receives focus.
Content that remains hidden until it becomes visible on mouse hover must also be shown when it receives keyboard focus and hidden again when focus is removed.
Content that appears and disappears in coordination with keyboard focus or pointer hover—such as tooltips, sub-menus, and other non-modal popups—must be dismissable, hoverable, and persistent.
## Screen reader compatibility
All features and functionality must work with at least one screen reader per platform. Features and functionalities including but not limited to alerts, visual changes on the page, page titles, iframes (used for user interaction, but not system use), landmarks, headings, links etc., must be presented and read accurately by supported screen readers.
---
# index
---
title: Global accessibility requirements
description: Learn how to ensure people of diverse abilities can use and interact with our digital products and tools.
meta_description: Find practical resources to ensure people of diverse abilities can use and interact with our digital products and tools.
thumbnail: assets/about-vpds/accessibility/accessibility.svg
date: 01/01/2021
tab_title: Overview
header_image: assets/about-vpds/accessibility/accessibility-overview.svg
related:
content:
- inclusive-language
aboutVPDS:
- inclusive-design
---
The Visa Global Accessibility Requirements (VGAR) are a set of functional expectations that distill Web Content Accessibility Guidelines (WCAG) into easy-to-learn resources for product teams, customers, and partners. These requirements help ensure Visa’s digital products meet accessibility standards and should be used to guide product planning, design, and development.
To scale accessibility at Visa, we’ve established a unified internal standard for building accessible products. The Visa Global Accessibility Requirements (VGAR) helps teams focus on building rather than interpreting accessibility standards.
- **Communicates how we implement WCAG 2.2 AA standards** in practice to our employees, clients, and partners.
- **Provide an easy-to-follow testing methodology** for web and mobile products.
- **Centrally manage and stay up-to-date** with current accessibility trends.
## Requirements and test procedures
Visa Global Accessibility Requirements outline the expected behavior for accessible user experiences across web, mobile, PDF, and email experiences. Visa teams follow these requirements during design and development.
Each requirement includes specific test procedures to validate compliance at every stage. Visa teams run both automated and manual tests to ensure all applicable requirements are met.
## WCAG 2.2 AA
At Visa, we aim to build all web and mobile components to conform to level AA of the Web Content Accessibility Guidelines 2.2 (WCAG 2.2), the internationally recognized benchmark for building accessible websites developed by the [World Wide Web Consortium (W3C)](https://www.w3.org/) for enhancing web accessibility. W3C is an international body that develops open standards for the web, and WCAG 2.2 focuses on making web content accessible to all, regardless of abilities. Visit [WCAG 2.2](https://www.w3.org/TR/WCAG22/) to learn more about current web content accessibility guidelines.
## Connect with us
Have questions or ideas? Visit our office hours, join Visa Accessibility on Teams, or get general VPDS help by visiting [Support](https://design.visa.com/support/).
---
# index
---
title: Application
side_nav_title: Application
description: Find application requirements for testing mobile experiences.
side_nav_aria_label: Application requirements for mobile.
side_nav_order: 0
---
## Vision support (APP-1)
### Custom display & text settings (APP-1-1)
Text content adapts to Larger Text setting.
#### How to test
**Tool:** Visual inspection
1. Adjust OS level settings for Larger Text:
- iOS: Settings > Accessibility > Display & Text Size > Larger Text On. Set the size to the third notch from the largest accessibility size (notch 8 of 11).
- Android: Settings > Display > Font Size and Style > maximum setting.
2. Confirm that all text content adapts when applied.
#### Test outcomes
- **Pass**: All text content adapts to larger text setting when applied.
- **Fail**: Some or all text content does not adapt to larger text setting when applied.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.4 Resize Textsize Text](https://www.w3.org/TR/WCAG22/#resize-text)
---
### Support screen reader (APP-1-2)
VoiceOver/TalkBack can be used to successfully interact with the full app experience
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Interact with the full app experience and task flows using VoiceOver/TalkBack.
2. Confirm that all functionality can be used easily and effectively by the screen reader.
#### Test outcomes
- **Pass**: All features and functionality can be easily and successfully used with VoiceOver/TalkBack.
- **Fail**: Some features and functionality cannot be easily and successfully used with VoiceOver/TalkBack.
#### Related WCAG criteria
[502.2.2 No Disruption of Accessibility Features](https://www.access-board.gov/ict/)
---
### View titled (APP-1-3)
Each screen/view needs to be titled and the title needs to be an accurate and descriptive title for the content presented on that screen/view.
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Navigate to each view using the screen reader.
2. Confirm that each view has a title read aloud by VoiceOver/TalkBack.
#### Test outcomes
- **Pass**: All views have a title that will be read by VoiceOver or TalkBack.
- **Fail**: One or more views are not titled.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.2 Page Titled](https://www.w3.org/TR/WCAG22/#page-titled)
---
## Physical and motor support (APP-2)
### Flexible orientation (APP-2-1)
Content is not restricted to one orientation, unless that orientation is essential, to allow users to orient the device according to their needs and personal setup.
#### How to test
**Tool:** Visual inspection
1. Enable setting to allow orientation to switch based on how the device is oriented.
2. Open the application being tested and confirm that each screen adapts to the portrait or landscape orientation change when the device is rotated between these orientations.
#### Test outcomes
- **Pass**: All content adapts to current orientation as expected.
- **Fail**: Some content that does not fall under the exception criteria in assumptions does not adapt to the current orientation as expected.
- **NA**: The full app experience falls under the exception criteria in assumptions.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.3.4 Orientation](https://www.w3.org/TR/WCAG22/#orientation)
---
### Motion control (APP-2-2)
When device motion is used to control the interface there is a way to deactivate it and operate the same functionality through UI controls instead
#### How to test
**Tool:** Visual inspection
1. Determine whether device motion is used to control the interface.
2. If device motion is used to control the interface, confirm that there is a way to deactivate motion control and operate the same functionality through UI controls instead.
#### Test outcomes
- **Pass**: Motion input is used but it can be deactivated and an alternative is provided.
- **Fail**: Motion input is used and cannot be disabled or an alternative to motion is not provided.
- **NA**: Motion input is not used to control the interface.
#### Related WCAG criteria
[WCAG 2.2 A - 2.5.4 Motion Actuation](https://www.w3.org/TR/WCAG22/#motion-actuation)
---
### Multiple authentication methods (APP-2-3)
User authentication must avoid relying on a cognitive function test by providing multiple means of filling in authentication information.
#### How to test
**Tool:** Visual inspection
Ensure that authentication form fields allow any of the following:
- The fields allow autofill of information.
- Information may be pasted into the form fields.
- Biometrics can be used to sign into accounts.
#### Test outcomes
- **Pass**: The authentication fields allow autofill of stored information OR information can be copied and pasted into the fields OR biometrics (fingerprints, facial-scan, etc.) can be used to log in.
- **Fail**: The authentication fields do not allow autofill AND information cannot be copied and pasted into the fields AND biometrics cannot be used (for example: none of the pass criteria methods are used).
- **NA**: The view does not require interaction to authenticate.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.3.8 Accessible Authentication](https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum)
---
## Diverse user needs (APP-3)
### App language (APP-3-1)
The application language can be programmatically determined
#### How to test
**Tool:** VoiceOver (iOS) / Talkback (Android)
1. Use the screen reader to interact with the application content.
2. Ensure that the screen reader output matches the correct language for each language supported.
#### Test outcomes
- **Pass**: The screen reader output matches the language of the application.
- **Fail**: The screen reader output does not match the language of the application.
#### Related WCAG criteria
[WCAG 2.2 A - 3.1.1 Language of Page](https://www.w3.org/TR/WCAG22/#language-of-page)
---
### Warn about timeout (APP-3-2)
Users must be warned prior to when a session times out and expires.
#### How to test
**Tool:** Visual inspection
Confirm that users are warned prior to when a session times out and expires.
#### Test outcomes
- **Pass**: Session timeout warning occurs prior to session time out and expiration.
- **Fail**: Session timeout occurs without warning.
- **NA**: No session timeout is present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.2.1 Timing Adjustable](https://www.w3.org/TR/WCAG22/#timing-adjustable)
---
### Extend timeout (APP-3-3)
When a session timeout warning occurs, users MUST be given at least 30 seconds to take action in order to avoid a session timeout by extending the time limit via a simple user action.
#### How to test
**Tool:** Visual inspection
Confirm that users are given at least 30 seconds to take action in order to avoid a session time out by extending the time limit of a session.
#### Test outcomes
- **Pass**: Users are given at least 30 seconds to extend the session.
- **Fail**: Users are given less than 30 seconds to extend the session.
- **NA**: No session timeout is present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.2.1 Timing Adjustable](https://www.w3.org/TR/WCAG22/#timing-adjustable)
---
### Use an automated testing tool (APP-3-4)
For iOS devices, all Xcode - Accessibility Inspector Audit tests pass during development
For Android devices, all Accessibility Scanner tests pass during development
#### How to test
**Tool:** Xcode - Accessibility Audit (iOS)/Accessibility Scanner (Android
1. Open your app in Xcode for iOS or Accessibility Scanner for Android.
2. Start the accessibility tool used on your platform.
3. Ensure that there are no automated errors present.
#### Test outcomes
- **Pass**: Zero issues are found OR issues found are determined to be false positives by Visa Accessibility.
- **Fail**: One or more issues are found.
#### Related WCAG criteria
[WCAG 2.2 A & AA](https://www.w3.org/TR/WCAG22/)
---
# index
---
title: Content
side_nav_title: Content
description: Find content requirements for testing mobile experiences.
side_nav_aria_label: Content requirements for mobile.
side_nav_order: 1
---
## Audio and video media (CON-1)
### Transcripts for audio-only / video-only (CON-1-1)
For audio-only and video-only media, a transcript must be provided which provides the same information as presented in the original media content.
#### How to test
**Tool:** Visual inspection
1. Identify any audio-only or video-only media content.
2. Confirm that a transcript which provides the same information as presented in the original media content is available for all audio-only and/or video-only content.
#### Test outcomes
- **Pass**: Transcripts are provided.
- **Fail**: Transcripts are not provided.
- **NA**: No audio or video only content is present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.2.1 Audio-only and Video-only (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-only-and-video-only-prerecorded)
---
### Accurate captions are available (CON-1-2)
Captions are available for content with both audio and video, except when the content is an alternative for text and is clearly labeled as such.
#### How to test
**Tool:** Visual inspection
1. Identify prerecorded content with both audio and video.
2. Confirm that captions are available.
3. Confirm the captions contain all audio information (for example: speech, sound effects, music, etc.).
#### Test outcomes
- **Pass**: All prerecorded content with both audio and video has accurate captions.
- **Fail**: Any prerecorded content with both audio and video does not have captions, or the captions do not contain all audio information.
- **NA**: No prerecorded content with both audio and video exists.
#### Related WCAG criteria
[WCAG 2.2 A - 1.2.2 Captions (Prerecorded)](https://www.w3.org/TR/WCAG22/#captions-prerecorded)
---
### Audio description or media alternative (prerecorded) (CON-1-3)
A transcript or audio description is available for content with both audio and video, except when the content is an alternative for text and is clearly labeled as such.
**Note:** If all of the information in the video track is provided in the audio track, no audio description is needed.
#### How to test
**Tool:** Visual inspection
1. Test “Audio Description (Prerecorded)”.
2. If "Audio Description (Prerecorded)" passes, this also passes.
3. If "Audio Description (Prerecorded)" fails, confirm a transcript exists that describes the meaningful visual information.
#### Test outcomes
- **Pass**: "Audio Description (Prerecorded)" is passing -or- a transcript is available that describes all meaningful information.
- **Fail**: Neither a transcript or audio description is available and there is meaningful information not described by the audio.
- **NA**: No content with both audio and video exists.
-or- the exception is met
#### Related WCAG criteria
[WCAG 2.2 A - 1.2.3 Audio Description or Media Alternative (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-description-or-media-alternative-prerecorded)
---
### Audio description (prerecorded) (CON-1-4)
An audio description track must be available if there is meaningful visual information that is not included in the audio track for prerecorded content with both audio and video.
**Note:** If all of the information in the video track is provided in the audio track, no audio description is needed.
#### How to test
**Tool:** Visual inspection
1. Identify prerecorded content with both audio and video.
2. If the content provides meaningful visual information that is not described by the audio, confirm it also includes an audio description track that explains the visual information.
#### Test outcomes
- **Pass**: Audio description is available when needed.
- **Fail**: Meaningful visual information in the video is not described by the audio and an audio description track is missing, incomplete, or inaccurate.
- **NA**: The audio describes the visual content -or- there is no prerecorded content with both audio and video.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.2.5 Audio Description (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-description-prerecorded)
---
### Pause or adjust volume for auto playing audio (CON-1-5)
For any audio which 1) plays automatically and 2) lasts for >3 seconds, one of the following must be true:
- A mechanism to pause the content is presented to the user
-or-
- A mechanism for adjusting the volume of the content is presented to the user and it does not rely on the system audio levels to adjust the volume.
#### How to test
**Tool:** Visual inspection
Confirm that for any audio which plays automatically and lasts for >3 seconds, one of the following is true:
- A mechanism to pause the content is presented to the user.
-or-
- A mechanism for adjusting the volume of the content is presented to the user and it does not rely on the system audio levels to adjust the volume.
#### Test outcomes
- **Pass**: For all content which plays automatically and lasts for more than 3 seconds a mechanism is provided to pause or adjust volume.
- **Fail**: A mechanism is not provided to pause or adjust volume for all content which plays automatically and lasts for more than 3 seconds.
- **NA**: No content which plays automatically and lasts for more than 3 seconds is present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.4.2 Audio Control](https://www.w3.org/TR/WCAG22/#audio-control)
---
### Pause, stop, hide moving content (CON-1-6)
A mechanism must be provided to pause, stop, or hide any content that meets the following criteria:
- Starts automatically
- Is presented in parallel with other content
-and-
- moves, blinks or scrolls for >5 seconds
-or-
- All auto-updating content regardless of duration
#### How to test
**Tool:** Visual inspection
Perform a visual inspection of the screen.
Confirm that for any content that meets the following criteria, a mechanism is provided to pause, play, or hide the applicable content:
- Starts automatically
- Is presented in parallel with other content
-and-
- moves, blinks or scrolls for >5 seconds
-or-
- All auto-updating content regardless of the time of duration
#### Test outcomes
- **Pass**: A mechanism is provided to pause, stop, or hide auto-playing; moving or blinking; auto-updating content.
- **Fail**: A mechanism is not provided to pause, stop, or hide auto-playing; moving or blinking; auto-updating content.
- **NA**: No auto-playing; moving or blinking; auto-updating content is present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.3 Sensory Characteristics](https://www.w3.org/TR/WCAG22/#sensory-characteristics)
---
## Text and copy (CON-2)
### Instructions don't rely on sensory cues (CON-2-1)
Instructions must never refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
**Note:** When instructions refer to an interactive element, use the programmatic name of the element.
#### How to test
**Tool:** Visual inspection
1. Review any instruction text (on-screen and screen reader only).
2. Confirm that Instructions and interactions never refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
#### Test outcomes
- **Pass**: Instructions and interactions never refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
- **Fail**: Instructions and interactions refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
- **NA**: No instructions are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.3 Sensory Characteristics](https://www.w3.org/TR/WCAG22/#sensory-characteristics)
---
### Visible and programmatic label consistency (CON-2-2)
If a control's visual label differs from the programmatic/accessible name value, then the programmatic/accessible name value includes the visual label.
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Locate all labels on input fields and interactive components.
2. Note the label presented visually in the user interface.
3. Note the programmatic (accessibility) label using either TalkBack or VoiceOver.
4. Confirm that the accessibility label includes the same text as the visual label .
#### Test outcomes
- **Pass**: All controls which have a different programmatic/accessible name value and visual label have the visual label text within the programmatic/accessible name value text string.
- **Fail**: One or more control which has a different programmatic/accessible name value and visual label does not have the visual label text within the programmatic/accessible name value text string.
- **NA**: No controls which have a different programmatic/accessible name value and visual label are present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.5.3 Label in Name](https://www.w3.org/TR/WCAG22/#link-purpose-in-context)
---
### Link text in context (CON-2-3)
Link text MUST describe the destination or purpose of every link in a way that makes the destination or purpose clear to all users in context with the surrounding content
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android) screen reader
1. Access all link text using a screen reader.
2. Determine whether someone can understand where the link will take them based on the link name, surrounding content, and any additional programmatic context provided (for example: accessibility label).
#### Test outcomes
- **Pass**: All link text effectively describes the destination.
- **Fail**: Some link text does not effectively describe the destination.
- **NA**: No links are present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.4 Link Purpose (In Context)](https://www.w3.org/TR/WCAG22/#link-purpose-in-context)
---
### Language of parts (CON-2-4)
Any content presented in a language other than the default application language is read appropriately by the screen reader.
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android) screen reader
1. Use a screen reader to interact with any application content presented in a language other than the defaul application language.
2. Ensure that the screen reader output matches the correct language.
#### Test outcomes
- **Pass**: Any content presented in a language other than the default language is read appropriately by the screen reader.
- **Fail**: Some or all content presented in a language other than the defaul language is not read appropriately by the screen reader.
- **NA**: No content is presented in a language other than the default application language.
#### Related WCAG criteria
[WCAG 2.2 A - 3.1.2 Language of Parts](https://www.w3.org/TR/WCAG21/#headings-and-labels)
---
### Use headings (CON-2-5)
All text that functions as a heading is read by a screen reader as a heading and uses the correct heading level
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android) screen reader
1. Change the navigation mode to headings.
2. Confirm all headings are reached using heading navigation.
3. Confirm correct heading level is used.
#### Test outcomes
- **Pass**: All headings are reached using heading navigation and are at the correct level.
- **Fail**: Some headings are not reached using heading navigation or use an incorrect level.
- **NA**: No headings are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Headings and labels (CON-2-6)
Headings and labels must accurately describe their content or interactive component
#### How to test
**Tool:** Visual inspection
1. Review all content that serves as a heading for a group of conten.
2. Confirm that each heading makes sense as the heading for the grouped content beneath it.
3. Locate all labels on interactive components.
4. Confirm that all labels on interactive components accurately describe the control's purpose.
#### Test outcomes
- **Pass**: Headings and labels accurately describe their content and/or interactive component.
- **Fail**: One or more headings and/or labels do not accurately describe their content and/or interactive component.
- **NA**: No headings or labels are present.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.4.6 Headings and Labels](https://www.w3.org/TR/WCAG22/#headings-and-labels)
---
# index
---
title: Interaction
side_nav_title: Interaction
description: Find interaction requirements for testing mobile experiences.
side_nav_aria_label: Interaction requirements for mobile.
side_nav_order: 2
---
## Layout (INT-1)
### Content reflow (INT-1-1)
Content must support reflow without requiring two-dimensional scrolling (except when the content requires a two-dimensional layout for meaning like tables, maps, or diagrams)
#### How to test
**Tool:** Visual inspection
1. Increase display zoom using OS level settings:
- iOS: Settings > Display & Brightness > Display Zoom > Larger Text.
- Android: Settings > Display > Screen Zoom, set to maximum.
2. Confirm that all content is available without requiring two-dimensional scrolling.
#### Test outcomes
- **Pass**: There is not a loss of information, meaning, or functionality and only one scroll dimension is required.
- **Fail**: There is a loss of information, meaning, or functionality OR vertical and horizontal scrolling are required to view the content.
- **NA**: Content is any of the following:
- Data tables
- Photos
- Maps
- Charts
- Games
- UI with toolbars
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.10 Reflow](https://www.w3.org/TR/WCAG21/#info-and-relationships)
---
### Consistent help (INT-1-2)
If a view includes the help options listed below, they are in the same location on similar views:
- Human contact details
- Human contact mechanism
- Self-help option
- A fully automated contact mechanism
#### How to test
**Tool:** Visual inspection
1. Locate if any of the listed help options in exist in the view:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
2. Determine if the help is in the same location across similar views.
#### Test outcomes
- **Pass**: Help across similar views is in the same location.
- **Fail**: Help across similar views is not in the same location.
- **NA**: No help options exist in the view.
#### Related WCAG criteria
[WCAG 2.2 A - 3.2.6 Consistent Help](https://www.w3.org/TR/WCAG22/#consistent-help)
---
## Forms (INT-2)
### Group fields and controls (INT-2-1)
When controls are related/grouped together this grouping should be clearly presented to assistive technology.
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Locate any input fields and interactive controls that are related and share a grouping relationship (note: this may be apparent visually or it may just be implied).
2. Confirm that the grouping relationship is communicated by the screen reader.
#### Test outcomes
- **Pass**: All control and input field grouping is communicated by the screen reader.
- **Fail**: One or more control/input field grouping is not communicated by the screen reader.
- **NA**: No control/input field groupings are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Required fields (INT-2-2)
Required fields must be noted and communicated visually through more than color alone, and communicated to assistive technology
#### How to test
**Tool:** Visual inspection and screen reader
1. Locate any required fields or controls.
2. Confirm that there is a visual indication of each field that is required that is not presented through color alone.
3. Confirm that the required fields are communicated programmatically to screen reader users.
#### Test outcomes
- **Pass**: All required fields are noted visually through more than color alone and communicated to assistive technology.
- **Fail**: One or more required fields are not noted visually through more than color alone or communicated to assistive technology.
- **NA**: Required fields are not present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Check for errors (INT-2-3)
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
#### How to test
**Tool:** Visual inspection
1. Identify any inputs that have automatic validation.
2. For each input, verify that errors are described in text.
#### Test outcomes
- **Pass**: Errors are identified and the errors are described to the user in text.
- **Fail**: Errors are identified but the errors are not described to the user in text.
- **NA**: There are no inputs with automatic validation.
#### Related WCAG criteria
[WCAG 2.2 A - 3.3.1 Error Identification](https://www.w3.org/TR/WCAG22/#error-identification)
---
### Highlight in-line errors visually (INT-2-4)
When an error is detected using in-line validation, highlight the field (for example: with a bold red border, error icon with proper alternative text) and place error helper text near it.
#### How to test
**Tool:** Visual inspection
1. Identify any inputs that have automatic validation.
2. Confirm that when an error is detected using in-line validation, the field is highlighted.
#### Test outcomes
- **Pass**: When an error is detected using in-line validation, the visual UI highlights the field and places error helper text near it.
- **Fail**: For one or more client-side validated forms when an error is detected using client side validation, the visual UI does not highlight the field or place error helper text near it.
- **NA**: No forms are present.
#### Related WCAG criteria
[WCAG 2.2 A - 3.3.1 Error Identification](https://www.w3.org/TR/WCAG22/#error-identification)
---
### Summary before submit (INT-2-5)
If user input is collected across multiple pages in order to execute a transaction of some kind the user must be presented with a summary of the input before submitting. The user must be able to change input prior to final submission after reviewing.
#### How to test
**Tool:** Visual inspection
1. Identify any workflows which gather input from the user and conclude with a submit action (for example: sign up, checkout, transactions, or capture of personal information).
2. Confirm that there is a step available to the user for reviewing the information prior to the final submit.
3. Confirm that the user can easily make corrections or changes to the information prior to submit.
#### Test outcomes
- **Pass**: A summary of user input is provided prior to final submit AND the user can edit or make corrections as needed.
- **Fail**: A summary of user input is not provided prior to final submit OR the user cannot edit or make corrections as needed.
- **NA**: User input is not collected across pages to execute a transaction.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.3.4 Error Prevention (Legal, Financial, Data)](https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data)
---
### Error suggestion (INT-2-6)
When errors are detected, suggestions are provided to correct them, unless it would jeopardize the security or purpose of the content.
#### How to test
**Tool:** Visual inspection
1. Locate any errors that can appear.
2. Trigger each error.
3. Confirm that, when possible, an error message describes how to correct the error (eg "username field is required" or "phone number must contain 10 digits").
#### Test outcomes
- **Pass**: Suggestions to fix errors are present.
- **Fail**: One or more errors exist but users are not informed how to fix the errors.
- **NA**: No errors exist.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.3.3 Error Suggestion](https://www.w3.org/TR/WCAG22/#error-suggestion)
---
### Redundant entry (INT-2-7)
If a view is contained within a process then information provided on the first step of the process is auto-filled in the next steps unless the information is required for security.
#### How to test
**Tool:** Visual inspection
1. Inspect the view to determine if it is a step in a process.
2. If information is provided in an earlier step in this process, confirm that this information is auto-filled in later steps.
#### Test outcomes
- **Pass**: Information provided during the process will autofill if later steps require the same information.
- **Fail**: Fields do not autofill when the same information has been provided on previous steps.
- **NA**: The view does not contain any process-based functionality or information reentry is essential or required for security.
#### Related WCAG criteria
[WCAG 2.2 A - 3.3.7 Redundant Entry](https://www.w3.org/TR/WCAG22/#redundant-entry)
---
## Widgets and controls (INT-3)
### Gestures (INT-3-1)
Widgets and controls can be operated via a single pointer with a gesture that does not require a specific path, unless a multi-pointer or path-based gesture is essential to the function of the control.
#### How to test
**Tool:** Visual inspection
1. Identify any controls that are operated via a multi-point OR path-based interaction in the application.
2. Confirm that the same actions can be performed through a single pointer method that does not require a specific path.
#### Test outcomes
- **Pass**: All controls that are operated via a multi-point OR path-based interaction can also be operated through a single pointer method that does not require a specific path.
- **Fail**: There are controls that require multi-pointer interaction OR they require a specific path-based gesture where it is not essential to the function of the control.
- **NA**: No custom gesture control is present OR the multi-pointer or path-based gesture is essential to the function of the control.
#### Related WCAG criteria
[WCAG 2.2 A - 2.5.1 Pointer Gestures](https://www.w3.org/TR/WCAG22/#pointer-gestures)
---
### Name (INT-3-2)
All interactive elements must have a programmatic name accessible to assistive technology
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Review each interactive element with a screen reader.
2. For each interactive element, verify the screen reader announces the name of the element.
#### Test outcomes
- **Pass**: All interactive elements have a name announced by the screen reader.
- **Fail**: One or more interactive elements do not have a name announced by the screen reader.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)
---
### Role (INT-3-3)
All elements with semantic meaning have a valid, accurate programmatic role accessible to assistive technology
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Locate all elements in the view with semantic meaning. (for example: headings, buttons and links, dialogs, etc…).
2. For each element with semantic meaning, verify the screen reader announces the role of the element.
3. Verify that the role announced for the element is valid and matches the semantic meaning of the element (for example: a link announces a link role, a button announces a button role, etc.).
#### Test outcomes
- **Pass**: All elements with semantic meaning have a role announced by the screen reader that matches the semantic meaning of the element.
- **Fail**: One or more semantic elements do not have a role announced by the screen reader or the role announced does not match the semantic meaning of the element.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)
---
### Value, states, properties (INT-3-4)
States, properties, and values of elements are programmatically available to assistive technology, Any changes to these items are also communicated to assistive technology.
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Locate all elements in the view which have states, properties, and/or values associated (for example: pressed/invalid state, an error message property on an invalid input, a user-input text string value in a "name" text field, etc…).
2. For each identified state, property, or value, confirm that the screen reader announces it when interacting with the associated element.
**Note:** If a state, property, or value has changed, the screen reader can determine the change.
#### Test outcomes
- **Pass**: All states, properties, and values are announced by the screen reader when interacting with the associated element.
- **Fail**: One or more states, properties, or values are not announced to the screen reader when interacting with the associated element.
- **NA**: No elements with states, properties, or values are present.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)
---
### Name consistently (INT-3-5)
UI controls with the same purpose need to be identified with the same label for consistency
#### How to test
**Tool:** Visual inspection and screen reader
1. Determine whether there are any duplicate UI controls with the same purpose.
2. Confirm that they are consistently identified with the same label visually and to screen reader users.
#### Test outcomes
- **Pass**: All UI controls with the same purpose are consistently identified with the same label visually and to screen reader users.
- **Fail**: One or more UI controls with the same purpose are not consistently identified with the same label visually and to screen reader users.
- **NA**: No duplicate UI controls with the same purpose are present.
#### Related WCAG criteria
[3.2.4 Consistent Identification](https://www.w3.org/TR/WCAG21/#consistent-identification)
---
### On focus (INT-3-6)
Changes of context do not occur when focus (keyboard, screen reader, switch) moves to controls
#### How to test
**Tool:** Keyboard and screen reader
1. Place focus (keyboard, screen reader) on each interactive control and input field.
2. Interact with each control and input field.
3. Confirm that no changes of context result from moving focus to a control.
#### Test outcomes
- **Pass**: No changes of context result from an on focus.
- **Fail**: A change of context results from an on focus.
#### Related WCAG criteria
[WCAG 2.2 A - 3.2.1 On Focus](https://www.w3.org/TR/WCAG22/#on-focus)
---
### On input (INT-3-7)
Changing the value of any interactive element does not automatically cause a change of context unless the user has been advised beforehand.
#### How to test
**Tool:** Visual inspection
1. Locate any elements in the view that has a value that can be updated (for example: checkboxes, radio buttons, selects, etc.).
2. Change the value for each element.
3. Confirm that unexpected changes do not occur.
#### Test outcomes
- **Pass**: No changes of context occur on value change or the user is advised beforehand.
- **Fail**: One or more changes of context occur on value change and the user is not advised beforehand.
- **NA**: No interactive elements can accept a value change.
#### Related WCAG criteria
[WCAG 2.2 A - 3.2.2 On Input](https://www.w3.org/TR/WCAG22/#on-input)
---
### Same relative order (INT-3-8)
Components, like links, buttons, or contact forms, that appear on multiple views must appear in the same relative order on every view.
#### How to test
**Tool:** Visual inspection
1. Perform a visual inspection of the view looking for navigation components.
2. Confirm that components (links, buttons, contact forms, etc.) that appear on multiple views appear in the same relative order on every view.
#### Test outcomes
- **Pass**: Components that appear on multiple views appear in the same relative order on every view.
- **Fail**: One or more component that appears on multiple views does not appear in the same relative order on every view.
- **NA**: No component appears on multiple views.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.2.3 Consistent Navigation](https://www.w3.org/TR/WCAG22/#consistent-navigation)
---
### Touch cancellation (INT-3-9)
Actions completed with a touch input MUST NOT use the down-event to execute any part of the function.
-OR-
Make sure there is a way for the user to abort or undo the action.
-OR-
Allow the up-event to reverse any outcome of the preceding down-event
#### How to test
**Tool:** Visual inspection
Confirm that there are no actions which are completed using the down-event from touch input OR that there is a way for the user to abort or undo the action OR that the up-event allows the user to reverse any outcome of the preceding down-event.
#### Test outcomes
- **Pass**: No actions are completed using the down event OR there is a way to abort or undo an action completed on the down-event OR the up-event allows the reversal of the preceding down-event.
- **Fail**: Actions are completed using the down event AND there is not a way to abort or undo the action AND the up-event does not allow reversal of the preceding down-event.
#### Related WCAG criteria
[WCAG 2.2 A - 2.5.2 Pointer Cancellation](https://www.w3.org/TR/WCAG22/#pointer-cancellation)
---
### Dragging movements (INT-3-10)
An action that relies on dragging of content can also be achieved by a single pointer without dragging unless dragging is essential to the activity.
Example of single pointer Pass: A quiz relies on users tapping and dragging information into the correct bucket. Users are also able to tap once to select an option, then tap on the correct bucket.
Example of essential activity: A medical app requires tapping and dragging an object to a target to accurately measure the user’s precision.
#### How to test
**Tool:** Visual inspection
1. Inspect the view to determine whether any functionality requires a dragging movement to access content.
2. For any dragging content, confirm that it can be used with a single pointer without dragging.
#### Test outcomes
- **Pass**: All drag functionality can also be performed with a single pointer OR the dragging movement is essential.
- **Fail**: Drag functionality cannot be completed with a single pointer.
- **NA**: The view does not contain drag functionality.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.5.7 Dragging Movements](https://www.w3.org/TR/WCAG22/#dragging-movements)
---
## Notifications and alerts (INT-4)
### Notifications, status messages, etc. (INT-4-1)
When the app sends the user info in a status update or notification it needs to be announced to screen readers without user placing focus there
#### How to test
**Tool:** VoiceOver (iOS) TalkBack (Android)
1. Interact with all notification and status message content using a screen reader.
2. When the app sends the user info in a status update or notification, confirm that it is announced to the screen reader without the user placing focus there and announced correctly.
#### Test outcomes
- **Pass**: All notifications or status messages are shown to the screen reader and announced correctly.
- **Fail**: One or more notifications or status messages is not shown to the screen reader and announced correctly.
- **NA**: No notifications or status messages occur.
#### Related WCAG criteria
[WCAG 2.2 AA - 4.1.3 Status Messages](https://www.w3.org/TR/WCAG22/#status-messages)
---
## Keyboard compatibility (INT-5)
### Focus order (INT-5-1)
When someone navigates using a keyboard or other sequential nav device the focus order is logical
#### How to test
**Tool:** Keyboard
1. Use a keyboard to control the mobile device.
2. Confirm that when someone navigates using a keyboard or other sequential nav device the order they are taken through the UI preserves meaning and operability.
#### Test outcomes
- **Pass**: Focus order is logical.
- **Fail**: Focus order is not logical.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.3 Focus Order](https://www.w3.org/TR/WCAG22/#focus-order)
---
### Visible keyboard focus (INT-5-2)
When a keyboard or any other sequential navigation device is used there is a visible indication of focus that is always on the correct element
#### How to test
**Tool:** Screen reader AND keyboard
1. Use a keyboard to control the mobile device.
2. Confirm that when a keyboard is used, there is a visible indication of focus that is always on the correct element.
#### Test outcomes
- **Pass**: Focus is always visible and in the correct place.
- **Fail**: Focus is not always visible or occurs in the wrong location.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.4.7 Focus Visible](https://www.w3.org/TR/WCAG22/#focus-visible)
---
### Keyboard support (INT-5-3)
All functionality and content must be available to users via keyboard only, without requiring specific timing of keystrokes
#### How to test
**Tool:** Keyboard
1. Use a bluetooth keyboard to control the mobile device.
2. Confirm that everything in the app can be performed with a keyboard alone (without the touch screen).
#### Test outcomes
- **Pass**: All features and functionality of the app are keyboard only compatible.
- **Fail**: One or more features or functionality is not keyboard only compatible.
#### Related WCAG criteria
[WCAG 2.2 A - 2.1.1 Keyboard](https://www.w3.org/TR/WCAG22/#keyboard)
---
### No keyboard trap (INT-5-4)
Keyboard focus must not become stuck when navigating through content.
#### How to test
**Tool:** Keyboard
Run through all use cases using keyboard and confirm that when focus is moved to an interactive element, that focus can also be moved away from the element.
#### Test outcomes
- **Pass**: Focus can move through the content without getting stuck.
- **Fail**: Focus cannot move through the content without getting stuck.
#### Related WCAG criteria
[WCAG 2.2 A - 2.1.2 No Keyboard Trap](https://www.w3.org/TR/WCAG22/#no-keyboard-trap)
---
### Focus not obscured (INT-5-5)
When a focusable element has keyboard focus, the element is at least partially visible.
#### How to test
**Tool:** Keyboard
1. Tab through everything in the view.
2. For each focusable element, when it has focus, confirm at least part of the element is visible (not fully obscured by other content or off the screen).
**Note:** If content can be repositioned by the user, only test the initial position.
#### Test outcomes
- **Pass**: Focusable elements are at least partially visible when focused.
- **Fail**: One or more focusable elements are fully obscured when focused.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.4.11 Focus Not Obscured](https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum)
---
### Single character keyboard shortcuts (INT-5-6)
If a single character shortcut is used then users must have the option to either turn it off or remap it to one or more non-printable keyboard characters.
-or-
Make sure the single character shortcut is only active when the component it affects has focus.
#### How to test
**Tool:** Keyboard
Confirm that where a single character shortcut is used that users have the option to either turn it off or remap it to one or more non-printable keyboard characters or make sure the single character shortcut is only active when the component it affects has focus.
#### Test outcomes
- **Pass**: For all single character shortcuts, users have the option to either turn off or remap it to one or more non-printable keyboard characters or the single character shortcut is only active when the component it affects has focus.
- **Fail**: For all single character shortcuts, users do not have the option to either turn off or remap it to one or more non-printable keyboard characters and the single character shortcut is active at all times.
- **NA**: No single character shortcuts are present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.1.4 Character Key Shortcuts](https://www.w3.org/TR/WCAG22/#character-key-shortcuts)
---
# index
---
title: Visual
side_nav_title: Visual
description: Find visual requirements for testing mobile experiences.
side_nav_aria_label: Visual requirements for mobile.
side_nav_order: 3
---
## Color and contrast (VIS-1)
### Not only color (VIS-1-1)
Color is not the only way that meaning or information is conveyed visually
#### How to test
**Tool:** Visual inspection
1. Identify any content which relies on color to convey meaning or information.
2. Determine whether or not the same meaning or information is provided when color is changed to grayscale.
3. Confirm that something other than color is provided to provide the same meaning or information when color is removed.
#### Test outcomes
- **Pass**: All content that uses color to convey meaning or information also includes a non-color equivalent.
- **Fail**: Some content that uses color to convey meaning or information does not include a non-color equivalent.
- **NA**: Color is not used to convey meaning or information.
#### Related WCAG criteria
[WCAG 2.2 A - 1.4.1 Use of Color](https://www.w3.org/TR/WCAG22/#use-of-color)
---
### Color contrast ratio (VIS-1-2)
A color contrast ratio of text and images of text to their backgrounds must be at least 4.5:1, except if the text is 18pt or 14pt bold or larger, where a ratio of 3:1 is then required.
#### How to test
**Tool:** Contrast Checking Tool such as WebAIM Contrast Checker
1. Determine the color used for the foreground and background on all text content.
2. Enter the values in a color contrast tool such as WebAIM Contrast Checker.
3. Confirm that text has sufficient contrast against its background and/or compared to surrounding elements.
**Note:** If using a physical mobile device, you may need to take a screenshot to verify contrast ratio on a desktop or know the color values.
#### Test outcomes
- **Pass**: All text content has sufficient contrast.
- **Fail**: Some text content does not have sufficient contrast.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.3 Contrast (Minimum)](https://www.w3.org/TR/WCAG22/#contrast-minimum)
---
### Contrast for non-text UI components (VIS-1-3)
All non-text content and controls have sufficient contrast ratio of 3:1 against their respective background. This includes both graphical content (for example: iconography) as well as interactive content and can also include a combination of both.
#### How to test
**Tool:** Contrast Checking Tool such as WebAIM Contrast Checker
1. Determine the color used for the foreground and background on all non-text elements .
2. Enter the values in a color contrast tool.
3. Confirm that each interactive element has at least 3:1 contrast against its background and/or compared to surrounding elements.
**Note:** If using a physical mobile device, you may need to take a screenshot to verify contrast ratio on a desktop or know the color values.
#### Test outcomes
- **Pass**: All non-text content has sufficient contrast.
- **Fail**: Some non-text content does not have sufficient contrast.
- **NA**: A non-text element that is in a disabled state and other similar criteria may result in NA for a specific non-text element (view requirement for details).
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.11 Non-text Contrast](https://www.w3.org/TR/WCAG22/#non-text-contrast)
---
## Size and layout (VIS-2)
### Touch target size (VIS-2-1)
Touch targets need to be large enough - Android 48x48dp minimum, iOS 44x44pt minimum
#### How to test
**Tool:** Xcode - Accessibility Inspector (iOS), Accessibility Scanner (Android)
1. Target each interactive element that will receive touch interaction or input.
2. Determine the size of the touch element's target area.
3. Confirm that the size of the touch element's target area is at least 44x44pt for iOS and 48x48dp for Android.
#### Test outcomes
- **Pass**: All touch target areas are at least 44x44pt for iOS and 48x48dp for Android.
- **Fail**: One or more touch target areas are less than 44x44pt for iOS and 48x48dp for Android.
- **NA**: Target is a link or button in a block of text that requires a specific presentation.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.5.8 Target Size](https://www.w3.org/TR/WCAG22/#target-size-minimum)
---
### Code order matches logical content order (VIS-2-2)
The reading order matches the visual order of content
#### How to test
**Tool:** Visual inspection and screen reader
1. Evaluate the visual content order and compare to the order of presentation when using a screen reader.
2. Verify the reading order matches the visual order of content.
#### Test outcomes
- **Pass**: The visual content order is consistent for screen reader users also.
- **Fail**: The visual content order and screen reader content order do not match.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.2 Meaningful Sequence](https://www.w3.org/TR/WCAG22/#meaningful-sequence)
---
### No blinking or flashing (VIS-2-3)
No Blinking or Flashing (VIS-2-3)
Content that blinks or flashes rapidly must never be used.
"Rapidly" means blinking/flashing more than 3 times in 1 second. If there is any doubt about the frequency of flashing then this would fail.
#### How to test
**Tool:** Visual inspection
1. Perform a visual inspection of the view.
2. Confirm that each view contains no content that blinks or flashes rapidly.
#### Test outcomes
- **Pass**: Content that blinks or flashes rapidly is not used.
- **Fail**: Content that blinks or flashes rapidly is used.
#### Related WCAG criteria
[WCAG 2.2 A - 2.3.1 Three Flashes or Below Threshold](https://www.w3.org/TR/WCAG22/#three-flashes-or-below-threshold)
---
## Images and graphics (VIS-3)
### Text alternatives (VIS-3-1)
All meaningful non-text content MUST provide text alternatives that provide equivalent information, context, and purpose to the user AND all decorative content is hidden from the user.
#### How to test
**Tool:** VoiceOver (iOS), TalkBack (Android)
1. Evaluate all non-text content using VoiceOver/Talkback.
2. Confirm that all non-text content provides text alternatives that provide equivalent information, context, and purpose to the user AND that decorative non-text content is hidden.
#### Test outcomes
- **Pass**: All images and non-text objects that need a text alternative have an accurate and descriptive accessibility label.
- **Fail**: One or more images or non-text objects that need a text alternative do not have an accessibility label OR the description is not accurate.
- **NA**: No images or non-text objects that need a text alternative are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.1.1 Non-text Content](https://www.w3.org/TR/WCAG22/#non-text-content)
---
### No images of text (VIS-3-2)
Use real text instead of images of text to ensure that the text can be programmatically determined and adapts to user settings for zoom and color.
#### How to test
**Tool:** Screen reader or inspect app code
1. Identify images of text:
- Option 1: Move screen reader focus to all text content and listen for any instance where text is read as an image or focus does not move to the text.
- Option 2: Review the code for instances of images with text embedded in them.
#### Test outcomes
- **Pass**: All text content is real text.
- **Fail**: One or more images with embedded were found.
- **NA**: No images with embedded, meaningful text are present.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.5 Images of Text](https://www.w3.org/TR/WCAG22/#images-of-text)
---
# index
---
title: Annotations
side_nav_title: Annotations
description: Find annotation requirements for testing PDFs.
side_nav_order: 7
---
## Annotations (PDF-8)
### Links and link text (PDF-8-1)
Link text in PDF documents is marked up in a way that is identifiable by keyboard and assistive technology users. Links in PDF documents should be represented by a Link tag and objects in its sub-tree, which includes a link object reference (or Link annotation) and one or more text objects. The text object(s) within the Link tag should be utilized by assistive technologies to provide a name for the link.
#### How to test
**Tool:** Screen reader
1. Use a screen reader to go through the PDF document.
2. Verify that the link is read out properly and its description correctly indicates where the link leads to.
3. Verify the tag tree visually to ensure the links are correctly tagged as `` with a nested 'Link-OBJR' tag.
4. Use the Tab key to navigate to each link. Press Enter to verify that the link takes you to the intended target.
#### Test outcomes
- **Pass**: All links are accurately tagged, easily read by a screen reader, can be activated using a keyboard, and the link text clearly states the link's purpose.
- **Fail**: If any link is inaccurately tagged, cannot be read by a screen reader, can't be activated with a keyboard, or the link text does not clearly state the link's purpose.
- **NA**: There are no links present in the document.
#### Related WCAG criteria
- [WCAG 2.2 A - 2.4.4 Link Purpose (In Context)](https://www.w3.org/TR/WCAG22/#link-purpose-in-context)
- PDF-U/A - 7.18.5 Links
---
# index
---
title: Document colors
side_nav_title: Document colors
description: Find document colors requirements for testing PDFs.
side_nav_order: 1
---
## Document colors (PDF-2)
### Color contrast ratio (PDF-2-1)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1. However, if the text is 18pt or 14pt bold or larger, a lower ratio of 3:1 is acceptable.
#### How to test
**Tool:** WebAIM Color Contrast Checker
1. Use the CCA tool (or any similar tool) to analyze the color contrast ratio between text and its background, as well as images of text against their backgrounds.
2. Make sure the contrast ratio is at least 4.5:1. However, if the text is 18pt or 14pt bold or larger, a lower ratio of 3:1 is acceptable.
#### Test outcomes
- **Pass**: Text meets the required minimum contrast ratio.
- **Fail**: Text doesn't meet the minimum required contrast ratio.
- **NA**: Text is part of an inactive UI component or purely decorative.
#### Related WCAG criteria
- [WCAG 2.2 AA - 1.4.3 Contrast (Minimum)](https://www.w3.org/TR/WCAG22/#contrast-minimum)
- PDF-U/A-1 - 7.1 General
---
### Non-text contrast ratio (PDF-2-2)
All significant user interface elements and graphics have a contrast ratio of at least 3:1 against adjacent colors including the background and other non-text objects.
#### How to test
1. Use the CCA tool (or any similar tool) to analyze the color contrast ratio between all significant user interface elements and graphics against the background.
2. Verify that there is a contrast ratio of at least 3:1 against adjacent colors including the background and other non-text objects
#### Test outcomes
- **Pass**: All significant elements of the user interface and graphics maintain a 3:1 contrast ratio with surrounding colors.
- **Fail**: Important user interface elements or graphics don't maintain a 3:1 contrast ratio with the colors around them.
#### Related WCAG criteria
- [WCAG 2.1 AA - 1.4.11 Non-text Contrast](https://www.w3.org/TR/WCAG22/#non-text-contrast)
- PDF-U/A-1 - 7.1 General
---
### Not only color (PDF-2-3)
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
#### How to test
1. Perform a visual inspection of the document.
2. Verify that whenever a difference in color is used to convey information, that information is also available in text or through some other alternative method.
#### Test outcomes
- **Pass**: A non-color alternative is presented along with color.
- **Fail**: Only color is used to indicate meaning.
- **NA**: Color is not used to convey meaning.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.4.1 Use of Color](https://www.w3.org/TR/WCAG22/#use-of-color)
- PDF-U/A-1 - 7.1 General
---
# index
---
title: Forms
side_nav_title: Forms
description: Find form requirements for testing PDFs.
side_nav_order: 8
---
## Forms (PDF-9)
### Form controls (PDF-9-1)
A Widget annotation shall be nested within a Form tag. Widget annotations are used for interactive forms.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for the presence of form fields.
2. Open the tags pane and review tags for all form fields.
3. Verify that they are correctly tagged using `
---
# index
---
title: General
side_nav_title: General
description: Find general requirements for testing PDFs.
side_nav_aria_label: General requirements for PDF.
side_nav_order: 0
---
## General (PDF-1)
### Use an automated testing tool (PDF-1-1)
When run against the page, the automated PDF Accessibility Checker validation tool MUST NOT report any errors.
#### How to test
**Tool:** Adobe Acrobat Pro/PDF Accessibility Checker
1. Execute the accessibility checker and analyze the results.
2. Verify that there are no issues to report (i.e, PDF/UA-1 compliant).
#### Test outcomes
- **Pass**: Issues are not reported by Accessibility Checker.
- **Fail**: Issues are reported by Accessibility Checker.
#### Related WCAG criteria
- [WCAG 2.2 - 4.1 Compatible](https://www.w3.org/TR/WCAG22/#compatible)
- PDF-U/A - 6 Conformance - requirements
- PDF-U/A - 7.1 General
---
### Document title (PDF-1-2)
The document has a title that describes topic or purpose and displays the document title in the title bar of a user agent.
#### How to test
1. Open the document in Adobe Acrobat Pro and navigate to File > Properties.
2. Verify that the document title is both correct and informative.
3. Select the 'Initial View' tab and verify that 'Document Title' is chosen in the 'Window Options' dropdown.
#### Test outcomes
- **Pass**: The document has a title that is relevant and explains its content, AND the initial view is set to 'Document Title'.
- **Fail**: The document lacks a title, OR the title is not relevant OR it doesn't explain its content, OR the initial view isn't set to 'Document Title'.
#### Related WCAG criteria
- [WCAG 2.2 A - 2.4.2 Page Titled](https://www.w3.org/TR/WCAG22/#page-titled)
- PDF-U/A - 7.1 General
---
# index
---
title: Graphics
side_nav_title: Graphics
description: Find graphic requirements for testing PDFs.
side_nav_order: 3
---
## Graphics (PDF-4)
### Text alternatives (PDF-4-1)
Provide text alternatives for images via an /Alt entry in the property list for a Tag.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for all meaningful images.
2. Verify the alt text for every image and ensure they are accurate and descriptive.
3. Verify that the alternative text is less than 150 characters long.
4. For complex images, verify that they have elaborative text descriptions (ideally in a close proximity to the image) rather than long alternative text strings that are more than 150 characters.
#### Test outcomes
- **Pass**: All images have descriptive alt text shorter than 150 characters OR visible and elaborative text descriptions for complex images (for example: graphs).
- **Fail**: One or more images do not have alt text or visible elaborative text descriptions OR the alt text provided is not descriptive OR it is longer than 150 characters.
- **NA**: No images are present.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.1.1 Non-text Content](https://www.w3.org/TR/WCAG22/#non-text-content)
- PDF-U/A-1 - 7.3 Graphics
---
### Decorative images (PDF-4-2)
Purely decorative images in PDF documents MUST be marked with /Artifact so that they can be ignored by Assistive Technology.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for all decorative images.
2. Verify that every decorative image is appropriately marked as decorative or it is artifacted.
#### Test outcomes
- **Pass**: All non-text decorative content has been properly marked as decorative or artifacted.
- **Fail**: Non-text decorative content has NOT been labeled as an artifact.
- **NA**: There is no non-text decorative content present.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.1.1 Non-text Content](https://www.w3.org/TR/WCAG22/#non-text-content)
- PDF-U/A-1 - 7.3 Graphics
---
### Images with captions (PDF-4-3)
A caption accompanying a figure shall be tagged with a Caption tag.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for the presence of images with captions.
2. Verify that caption text is tagged as `
` and is a child element of the `` tag that contains the actual image.
#### Test outcomes
- **Pass**: All the image captions are correctly tagged as `
` and are child elements of the `` tag that contains the image.
- **Fail**: Any image caption is not tagged as `
` or is not a child element of the `` tag that contains the image.
- **NA**: There are no images with captions are present.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.1.1 Non-text Content](https://www.w3.org/TR/WCAG22/#non-text-content)
- PDF-U/A-1 - 7.3 Graphics
---
### No images of text (PDF-4-4)
Text is used to convey information rather than images of text except logos and instances where text within images is unavoidable, such as in graphs or screenshots.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for images that contain text.
2. Verify that information is conveyed using actual text instead of images that contain text (the only exceptions are logos and instances where text within images is unavoidable, such as in graphs or screenshots).
#### Test outcomes
- **Pass**: Images of text are not used.
- **Fail**: Images of text are used.
- **NA**: There are no images of the text present OR the images are exempt from the requirement.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.1.1 Non-text Content](https://www.w3.org/TR/WCAG22/#non-text-content)
- PDF-U/A-1 - 7.3 Graphics
---
# index
---
title: Media content
side_nav_title: Media content
description: Find media content requirements for testing PDFs.
side_nav_order: 9
---
## Media content (PDF-10)
### No blinking or flashing content (PDF-10-1)
Content that blinks or flashes MUST never be used.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Open the document in Adobe Acrobat Pro and visually inspect the pages.
2. Confirm that no page contains content that flickers, blinks or flashes, either as effects controlled by JavaScript or as part of any videos embedded within the PDF.
#### Test outcomes
- **Pass**: Content that blinks or flashes is not used.
- **Fail**: Content that blinks or flashes is used.
#### Related WCAG criteria
- [WCAG 2.2 A - 2.3.1 Three Flashes or Below Threshold](https://www.w3.org/TR/WCAG22/#three-flashes-or-below-threshold)
- PDF-U/A - 7.1 General
---
### Captions for video (PDF-10-2)
All video (both live AND prerecorded) content MUST include accurate captions.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for the presence of videos.
2. Verify that all video content provides accurate captions via an accessible mechanism.
#### Test outcomes
- **Pass**: All video content provides captions.
- **Fail**: Any video content does not provide captions.
- **NA**: No videos are present in the doc.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.2.2 Captions (Prerecorded)](https://www.w3.org/TR/WCAG22/#captions-prerecorded)
- PDF-U/A - 7.18.6 Media
---
### Audio description for video (PDF-10-3)
If video content provides any information visually that is not described by an accompanying audio track, it MUST also include an Audio Description track that fully explains the visual information.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for the presence of videos.
2. Verify that any video content that provides information visually that is not described by the default audio track provides that information via an Audio Description track, which fully explains the visual information.
#### Test outcomes
- **Pass**: All videos with visuals not fully explained by the default audio track have an Audio Description track that fully explains the visual information.
- **Fail**: Any video with visuals not fully explained by the default audio track does not have an Audio Description track to fully explains the visual information.
- **NA**: There are no videos in the document, or Audio Tracks, fully explain the visuals of the presented videos.
#### Related WCAG criteria
- [WCAG 2.2 AA - 1.2.5 Audio Description (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-description-prerecorded)
- PDF-U/A - 7.18.6 Media
---
### Transcripts for audio-only/video-only (PDF-10-4)
For audio-only and video-only media, a transcript MUST be provided which provides the same information as presented in the original media content.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for the presence of audio-only AND/OR video-only content.
2. Verify that a transcript which provides the same information as presented in the original media content MUST be made available for all audio-only AND/OR video-only content.
#### Test outcomes
- **Pass**: All Audio-only AND/OR Video-only content has a transcript.
- **Fail**: Audio-only AND/OR Video-only content does not have a transcript.
- **NA**: There is no Audio-only/Video-only content is present in the document.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.2.1 Audio-only & Video-only (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-only-and-video-only-prerecorded)
- PDF-U/A - 7.18.6 Media
---
# index
---
title: Navigation
side_nav_title: Navigation
description: Find navigation requirements for testing PDFs.
side_nav_order: 5
---
## Navigation (PDF-6)
### Page numbers (PDF-6-1)
Page numbering displayed in the PDF viewer page controls has the same page numbering as the document.
#### How to test
**Tool:** Adobe Acrobat Pro/PDF Accessibility Checker
1. Inspect the document for page numbers.
2. Use the keyboard shortcut CMD/CTRL+Shift+N to open a 'Go To Page' dialogue.
3. Enter a page number and click OK.
4. Verify that the entered page numbers match the actual page numbers of the document (from header/footer).
#### Test outcomes
- **Pass**:Page numbers in PDF reader accurately reflect the Document page number.
- **Fail**: Page numbers in PDF reader do not accurately reflect the document page number.
- **NA**: Page numbers are not available in the document.
#### Related WCAG criteria
- [WCAG 2.2 AA - 2.4.5 Multiple Ways](https://www.w3.org/TR/WCAG22/#multiple-ways)
- PDF-U/A - 7.17 Navigation
---
### Bookmarks (PDF-6-2)
Make it possible for users to locate content using bookmarks (outline entries in an Outline dictionary) in documents that are 21 pages or longer.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Open the document in Adobe Acrobat Pro.
2. Open the bookmarks pane and verify that bookmarks are present.
#### Test outcomes
- **Pass**: Bookmarks are present.
- **Fail**: No bookmarks are present.
- **NA**: The document is less than 21 pages in length.
#### Related WCAG criteria
- [WCAG 2.2 AA - 2.4.5 Multiple Ways](https://www.w3.org/TR/WCAG22/#multiple-ways)
- PDF-U/A - 7.17 Navigation
---
# index
---
title: Tables
side_nav_title: Tables
description: Find table requirements for testing PDFs.
side_nav_order: 6
---
## Tables (PDF-7)
### Tables (PDF-7-1)
Tables should include headers. Tables can contain column headers, row headers or both. As much information as possible about the structure of tables needs to be available when assistive technology is relied upon. Headers play a key role in providing structural information. Structure elements of type TH should have a Scope attribute. If the table’s structure is not determinable via Headers and IDs, then structure elements of type TH shall have a Scope attribute.
Table tagging structures shall only be used to tag content presented within logical row and/or column relationships.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the documents for tables.
2. Verify that all content that resembles a table is correctly tagged as a ``.
3. Verify that all table rows are appropriately tagged using the `
` tag.
4. Verify that table headers are tagged with `
` tags and have a defined scope and span (if applicable).
5. Verify that table data cells are properly tagged with `
` tags.
6. Verify that table caption (if available) is tagged as `
` as its first or last child element of the `` tag.
#### Test outcomes
- **Pass**: All tabular data is correctly tagged with `` tags, row/column headers are marked with `
` tags with an appropriate scope and Span attributes, Table rows are denoted with `
` tags, table data cells are tagged with `
` tags, and table captions(if available) are tagged with `
`.
- **Fail**: Any of the following conditions are not met: Tabular data is not tagged with Table tags, row/column headers are not tagged with `
` tags or they lack a proper scope and Span attributes, Table rows are not tagged with `
` tags, table data cells are not tagged with `
` tags, or table captions(if available) are not tagged with `
`.
- **NA**: The content does not include any table elements.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
- PDF-U/A - 7.5 Tables
---
### No layout tables (PDF-7-2)
Tables are only used for tabular data with a logical column/row relationship and not used for layout or positioning.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Review the Tags panel in Acrobat for Table tags.
2. Confirm that no Table tags are used for layout purposes.
#### Test outcomes
- **Pass**: Tables are not used for layout purposes.
- **Fail**: Tables are used for layout purposes.
- **NA**: No Table tags are present.
#### Related WCAG criteria
- [WCAG 2.2 AA - 2.4.5 Multiple Ways](https://www.w3.org/TR/WCAG22/#multiple-ways)
- PDF-U/A - 7.17 Navigation
---
# index
---
title: Tags
side_nav_title: Tags
description: Find tag requirements for testing PDFs.
side_nav_order: 2
---
## Tags (PDF-3)
### Semantic tagging of text (PDF-3-1)
The most semantically appropriate tag shall be used for each logical element in the document content. Content shall be tagged in logical reading order.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Open the tags panel and review the tags.
2. Verify that the tags selected are semantically appropriate for the content type in a logical reading order.
3. Verify that if non-standard (tag) structure types are used, they are mapped to the nearest functionally equivalent standard tags.
4. Verify that artifacts are not present in the tags tree.
#### Test outcomes
- **Pass**: The document is tagged and has semantically appropriate tags.
- **Fail**: The document is either untagged or has incorrect/non-semantic tags.
#### Related WCAG criteria
- [WCAG 2.2 - 4.1 Compatible](https://www.w3.org/TR/WCAG22/#compatible)
- PDF UA/1 - 7.1 General/7.2 Text
---
### Table of contents (PDF-3-2)
If a PDF contains a table of contents, it MUST contain bookmarks that link to the proper locations within the document.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for the presence of a table of contents.
2. Verify that the Table of contents has links to the correct sections within the document.
3. Verify that all Table of Contents are correctly tagged as a ``.
4. Verify that all Table of Contents Items are appropriately tagged using the `` tag and nested under ``.
5. Verify that `` contains the related `` tag with nested 'Link-OBJR' tag.
6. Verify that the caption (if available) is tagged as `
` and placed as a first child element of ``.
#### Test outcomes
- **Pass**: The table of contents links to the correct section within the document and it is correctly tagged using ``, ``, `` tags and a `
` tag if available.
- **Fail**: The table of contents either doesn't link to the correct sections within the document OR it is not correctly tagged using ``, ``, `` and `
` tags.
- **NA**: A table of Contents is not present.
#### Related WCAG criteria
- [WCAG 2.2 AA - 2.4.5 Multiple Ways](https://www.w3.org/TR/WCAG22/#multiple-ways)
- PDF UA/1 - 7.18.1 General
---
### Headings (PDF-3-3)
Heading tags shall be used as follows:
- If any heading tags are used, H1 shall be the first.
- A document may use more than one instance of any specific tag level. For example, a tag level may be repeated if document content requires it.
- If document semantics require a descending sequence of headers, such a sequence shall proceed in strict numerical order and shall not skip an intervening heading level. H1, H2, H3, is permissible, while H1, H3, is not. Heading levels are said to descend if they use a sequence from H1 to H2, H2 to H3, H3 to H4, etc.
- A document may increment its heading sequence without restarting at H1 if document semantics require it. H1, H2, H3, H4, H3, is a permissible sequence.
**Note:** H1, H2, H3, H3, is a valid sequence if the content has one top-level heading, one second-level heading, and two consecutive third-level headings.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for headings and corresponding tags.
2. Verify that all heading content is tagged as headings using only `
` to `
` tags.
3. Verify that headings follow a sequential order without any levels being skipped. For instance, the order should be Heading 1, followed by Heading 2, followed by Heading 3, and so on. There should be no omission of any numbers in the sequence.
#### Test outcomes
- **Pass**: Heading texts are tagged using only `
` to `
` tags and headings follow a sequential order, increasing and decreasing by one level without any skips.
- **Fail**: Heading texts are not tagged using `
` to `
` tags or Headings do not follow a sequential order and there are skips in the level increments.
#### Related WCAG criteria
- [WCAG 2.2 AA - 2.4.6 Headings and Labels](https://www.w3.org/TR/WCAG22/#headings-and-labels)
- [WCAG 2.2 A - 1.3.2 Meaningful Sequence](https://www.w3.org/TR/WCAG22/#meaningful-sequence)
- PDF UA/1 - 7.4.2 Numbered Headings
---
### Lists (PDF-3-4)
Lists shall be tagged with L tags with the following additional provisions:
- Individual list items shall be specified by LI tags. Lbl and LBody tags may be included.
- Lists shall only be used when required when the content is intended to be read as a list.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for the text that looks like a list.
2. Verify that all Lists are correctly tagged as a ``.
3. Verify that all List Items are appropriately tagged using the `
` tag and nested under ``.
4. Verify that all bullets or numbers tagged using `` and nested under `
` as first child element.
5. Verify that List body content is tagged using `` and nested under `
` as a second child element.
6. Verify that caption(if available) is tagged as `
` and placed as a first child element of `` before first `
`.
#### Test outcomes
- **Pass**: All the lists are correctly tagged and properly nested using ``, `
`, ``, `` and `
` if available.
- **Fail**: Any list is not tagged using ``, `
`, ``, `` and `
` if available.
- **NA**: No lists are present.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
- PDF UA/1 - 7.6 Lists
---
### Footnotes and endnotes (PDF-3-5)
Footnotes, endnotes, note labels and references (cross-references or citations to locations within the document) shall be tagged with a Note tag. Each note tag shall have a unique entry in the ID key
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for Footnotes and End notes.
2. Open the tags pane and review tags for all footnotes and endnotes.
3. Verify that they are tagged rightly as ``.
4. Verify that each Note tag has unique entry in the ID key.
5. Verify that Note tag is always inside another block level tag.
6. Verify the footnotes are read immediately after the black level content where it was referenced (not end notes).
#### Test outcomes
- **Pass**: All footnotes and endnotes are correctly tagged as ``, each with unique IDs, and are in the correct reading order.
- **Fail**: One or more footnotes or endnotes are incorrectly tagged, lack unique IDs, or are not in the correct reading order.
- **NA**: The document has no footnotes or endnotes.
#### Related WCAG criteria
PDF UA/1 - 7.9 Notes and References
---
### Mathematical expressions (PDF-3-6)
All mathematical expressions shall be enclosed within a Formula tag and shall have an Alt attribute.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for Math equations and formulas.
2. Access the tags panel and identify the tags related to the above content.
3. Verify that all math equations are rightly tagged as `` and have an alt text explaining the equation in words.
#### Test outcomes
- **Pass**: All mathematical equations are tagged rightly as `` and have right alt text.
- **Fail**: One or more mathematical equations are not tagged correctly.
- **NA**: No mathematical equations are present.
#### Related WCAG criteria
PDF UA/1 - 7. Mathematical Expressions
---
# index
---
title: Text
side_nav_title: Text
description: Find text requirements for testing PDFs.
side_nav_order: 4
---
## Text (PDF-5)
### Language of document (PDF-5-1)
Each document MUST have a language property that matches the language of the document.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Open the document in Adobe Acrobat Pro and navigate to File > Properties > Advanced Tab.
2. Verify that the language used matches the content of the page.
#### Test outcomes
- **Pass**: A valid language is specified.
- **Fail**: A valid language is not specified.
#### Related WCAG criteria
- [WCAG 2.2 A - 3.1.1 Language of Page](https://www.w3.org/TR/WCAG22/#language-of-page)
- PDF UA/1 - 7.2 Text
---
### Tab and reading order (PDF-5-2)
Users shall be able to navigate through content in a logical order that is consistent with the meaning of the content.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Use the Reading Order tool to verify the content is in the correct sequence.
2. Navigate through the page using a keyboard and verify that all interactive content appears in the right order when using the Tab key.
#### Test outcomes
- **Pass**: The sequence of the content and the order of tabbing through interactive elements is correct.
- **Fail**: Either the sequence of the content or the order of tabbing through interactive elements is incorrect.
#### Related WCAG criteria
- [WCAG 2.2 A - 1.3.2 Meaningful Sequence](https://www.w3.org/TR/WCAG22/#meaningful-sequence)
- PDF UA/1 - 7.2 Text
---
### Headings and footers (PDF-5-3)
Users shall be able to locate themselves in a document by providing running headers and footers in a consistent and predictable way via pagination artifacts.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Inspect the document for running headers and footers.
2. Verify that they are consistent on all pages.
3. Verify that whether the content appears within the header or footer on multiple pages is redundant or not.
4. Verify that redundant content is marked as an artifact.
#### Test outcomes
- **Pass**: All headers and footers are consistent across the pages AND the redundant information is marked as an artifact.
- **Fail**: Any headers or footers are inconsistent across the pages OR the redundant information is not marked as an artifact.
- **NA**: No headers or footers are present in the document.
#### Related WCAG criteria
- [WCAG 2.2 AA - 3.2.3 Consistent Navigation](https://www.w3.org/TR/WCAG22/#consistent-navigation)
- PDF UA/1 - 7.8 Page Headers and Footers
---
### Language of parts (PDF-5-4)
A lang attribute MUST be set on every word or phrase that is in a different language than the document's main language.
#### How to test
**Tool:** Adobe Acrobat Pro
1. Find words or phrases in the document that are in a different language than the rest of the content.
2. Access the tags panel and identify the tags related to the content in the different language.
3. Verify the properties of these tags to ensure the correct language is selected for each word or phrase.
#### Test outcomes
- **Pass**: All words or phrases in a different language from the rest of the content have the correct language property set at the content level.
- **Fail**: Any words or phrases in a different language from the rest of the content do not have the correct language property set at the content level.
- **NA**: The document doesn't contain any words or phrases in a language different from the main document language.
#### Related WCAG criteria
- [WCAG 2.2 AA - 3.1.2 Language of Parts](https://www.w3.org/TR/WCAG22/#language-of-parts)
- PDF UA/1 - 7.2 Text
---
# index
---
title: General
side_nav_title: General
description: Find general requirements for testing web experiences.
side_nav_aria_label: General requirements for web.
side_nav_order: 0
---
## Page title (GEN-1)
### Accurate title (GEN-1-1)
An accurate and descriptive page `` title must be included on every page or view.
#### How to test
**Tool:** ANDI
1. Inspect the HTML DOM and confirm that a `` element is present.
2. Verify that the page title provided is accurate and descriptive of the purpose of the page and content.
#### Test outcomes
- **Pass**: Page title is accurate and descriptive of the page content.
- **Fail**: Page title is not included or page title is inaccurate and/or not descriptive of the page content.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.2 Page Titled](https://www.w3.org/TR/WCAG22/#page-titled)
---
### Unique title (GEN-1-2)
The page title must be unique and conform to a consistent structure among the other pages.
#### How to test
**Tool:** Browser Dev Tools (F12)
1. Inspect the target page.
2. Review the html `` tag.
3. Verify that the page title is unique and conforms to a consistent structure among the other pages.
#### Test outcomes
- **Pass**: Page title is unique and conforms to a consistent structure among the other pages.
- **Fail**: Page title is not unique and/or it does not conform to a consistent structure among the other pages.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.2 Page Titled](https://www.w3.org/TR/WCAG22/#page-titled)
---
## Language (GEN-2)
### Lang attribute (GEN-2-1)
The applicable language must be defined on every page, inside the html tag.
#### How to test
**Tool:** Browser Dev Tools (F12)
1. Use the Inspect feature in the browser (for example: Chrome F12 dev tools) to open a view of the page HTML code.
2. Locate the `` element at the beginning of the HTML DOM.
3. Confirm that the `lang=""` attribute is correct for the language of the page content.
#### Test outcomes
- **Pass**: Correct page language is defined.
- **Fail**: Page language is not defined or the incorrect page language is defined.
#### Related WCAG criteria
[WCAG 2.2 A - 3.1.1 Language of Page](https://www.w3.org/TR/WCAG22/#language-of-page)
---
### Lang of parts of page (GEN-2-2)
A lang attribute must be set on every word or phrase that is in a different language than the page’s main language.
#### How to test
**Tool:** Browser Dev Tools (F12)
1. Locate any words or phrases in the page content that are in a language that is different from the language of the other content in the page.
2. Use the Inspect feature in the browser (for example: Chrome F12 dev tools) to open a view of the page HTML code and inspect each of these words or phrases.
3. Confirm that each of these words or phrases is wrapped in a `` element with a `lang=""` attribute that is correct for the language of the word or phrase.
#### Test outcomes
- **Pass**: All words or pages which are in a different language than the global lang are marked up with the appropriate language.
- **Fail**: Words or pages which are in a different language than the global lang are not marked up with the appropriate language.
- **NA**: No words or phrases are in a different language from the global language.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.1.2 Language of Parts](https://www.w3.org/TR/WCAG22/#language-of-parts)
---
## AT compatible (GEN-3)
### Support screen readers (GEN-3-1)
All features and functionality made available to users within the web application must be functionally supported with at least one screen reader per supported platform (for example: JAWS for Windows desktop, VoiceOver for MAC iOS, etc.).
#### How to test
**Tool:** Screen reader
Run through all use cases with each supported screen reader, confirming that all features and functionality are fully available to non-sighted users.
#### Test outcomes
- **Pass**: All features and functionality are fully available to non-sighted users.
- **Fail**: One or more features or functionality are not fully available to non-sighted users.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1 Compatible](https://www.w3.org/TR/WCAG22/#compatible)
---
### Alerts read (GEN-3-2)
When alerts are shown on screen (for example: success, error, or status/informative) they must also be read aloud by each supported screen reader without receiving focus.
**Note:** Error messages that appear in-line upon leaving a form field are common examples.
#### How to test
**Tool:** Screen reader
Confirm that when alerts are shown on screen (for example: success, error, or status/informative) they are also read aloud by each supported screen reader.
#### Test outcomes
- **Pass**: Alerts shown on screen are read aloud by each supported screen reader.
- **Fail**: Alerts shown on screen are not read aloud by each supported screen reader.
- **NA**: No alerts are shown on screen.
#### Related WCAG criteria
[WCAG 2.1 AA - 4.1.3 Status Messages](https://www.w3.org/TR/WCAG22/#status-messages)
---
## A11y validator (GEN-4)
### Use an Automated Testing Tool (GEN-4-1)
When run against the page, the automated validation tool must not report any errors.
#### How to test
**Tool:** Accessibility Insights
1. Run one automated validation tool of your choice against the page and confirm that it reports no errors.
2. If errors are found, record a FAIL with a FAIL ID for each issue reported by the tool.
#### Test outcomes
- **Pass**: Automated tool returns zero errors.
- **Fail**: Automated tool returns one or more errors.
#### Related WCAG criteria
[WCAG 2.2 A & AA](https://www.w3.org/TR/WCAG22/)
---
# index
---
title: Interactive
side_nav_title: Interactive
description: Find interactive requirements for testing web experiences.
side_nav_order: 2
---
## Form elements (INT-1)
### Fully descriptive control labels (INT-1-1)
Controls and inputs must have one unique label attribute that fully describes the control’s purpose, including any supplementary information that the visual presentation may also provide (for example: related controls grouped together visually).
Some or all of a label MAY be hidden with CSS if the visual presentation provides the necessary context.
#### How to test
**Tool:** Accessibility Insights
1. In the target page, examine each control/input element.
2. Use Accessibility Insights > Adhoc Tools > Accessible Names.
3. Review the names and confirm they describe the elements.
#### Test outcomes
- **Pass**: All form controls have a unique label attribute that fully describes the control purpose and any supplementary information provided by the visual presentation.
- **Fail**: One or more form controls does not have a unique label fully describing the control purpose and any supplementary information provided by the visual presentation.
#### Related WCAG criteria
[WCAG 2.2 A - 3.3.2 Labels or Instructions](https://www.w3.org/TR/WCAG22/#labels-or-instructions)
---
### Info and relationships (INT-1-2)
Where visual presentation conveys information, structure, or relationships in content, the same information is available programmatically or in text.
#### How to test
**Tool:** Screen reader
1. Review the page and identify information, structure or relationships communicated visually (examples: large text conveys headings, bold or italic text conveys emphasis, spacing conveys paragraph structure, etc.).
2. Review any content identified in step 1 with a screen reader and confirm the same information, relationships, or structure is also conveyed programmatically.
3. If the information is not conveyed programmatically, confirm the information is conveyed in text.
#### Test outcomes
- **Pass**: All information, relationships, and structure conveyed through visual presentation is also conveyed programmatically or in text.
- **Fail**: There is information, relationships, or structure on the page that is conveyed visually but not programmatically or through text.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Group controls using fieldsets (INT-1-3)
If there is more than one distinct group of related form controls on a page, the related controls must be grouped programmatically. This may be done using either fieldset/legend or ARIA group role/text container. Text describing the logical grouping MAY be hidden off-screen if it isn't visually necessary.
#### How to test
**Tool:** Screen reader
If fieldsets or aria groups are used on the page to group more than one distinct group of related form controls, confirm that the legends/ARIA legends read properly, for example: before each label for the controls in the given group.
#### Test outcomes
- **Pass**: Related controls are grouped using Fieldset or ARIA group and the legend/ARIA legend is read correctly by screen reader.
- **Fail**: Related controls are not grouped using Fieldset or ARIA group or they are but the legend/ARIA legend is read incorrectly or not read by the screen reader.
- **NA**: No groups of related controls are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Required fields (INT-1-4)
Required fields/controls must use the `aria-required="true"` attribute. They must also be communicated in text either at the beginning of the form or in-line.
Groups of checkboxes should not have the `aria-required` attribute and the required state should be indicated in text either at the beginning of the form, stating all fields are required, or in the group's fieldset legend instead.
#### How to test
**Tool:** Screen reader
1. Ensure that required fields are identified visually with text at the beginning of the form or in-line.
2. Tab through each control on the page and confirm that each required form control is announced as such by each supported screen reader.
#### Test outcomes
- **Pass**: All required fields are marked with `aria-required="true"` and read correctly by a screen reader and text is available at the top of the form or in-line.
- **Fail**: One or more required field is not marked with `aria-required="true"` and read correctly by a screen reader or text is not available at the top of the form or in-line.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Specify input purpose programmatically (INT-1-5)
If an input field is used to collect information about the user and the field supports autocomplete then the input field's purpose is identified programmatically.
#### How to test
**Tool:** Browser Dev Tools (F12)
1. Use the Browser inspection to inspect each input field on the page. to determine if the HTML atutocomplete or autofill attributes have been used.
2. If these attributes have been used, then they must match the type of information requested from the user.
#### Test outcomes
- **Pass**: There are no automated errors reported and all fields which have autocomplete or autofill defined have correct, valid values that match the requested information.
- **Fail**: One or more fields are detected which have incorrect or invalid values for autocomplete or autofill or the specified values do not match the information requested from the user.
- **NA**: No fields with autocomplete or autofill are present.
#### Related WCAG criteria
[WCAG 2.1 AA - 1.3.5 Identify Input Purpose](https://www.w3.org/TR/WCAG22/#identify-input-purpose)
---
### Visible and programmatic label consistency (INT-1-6)
If a control's visual label differs from the programmatic/accessible name value, then the programmatic/accessible name value includes the visual label.
#### How to test
**Tool:** ANDI
1. Use the ANDI tool and select Buttons/Links from the dropdown menu.
2. Use the ANDI Output section to determine whether or not any controls have a programmatic/accessible name value that is different from the visual label.
3. For any control that has a different visual label and ANDI output, confirm that the programmatic/accessible name value includes the visual label.
4. Repeat these steps using the ANDI Focusable Elements dropdown to review form fields.
#### Test outcomes
- **Pass**: All controls which have a different programmatic/accessible name value and visual label have the visual label text within the programmatic/accessible name value text string.
- **Fail**: One or more control which has a different programmatic/accessible name value and visual label does not have the visual label text within the programmatic/accessible name value text string.
- **NA**: No controls which have a different programmatic/accessible name value and visual label are present.
#### Related WCAG criteria
[WCAG 2.1 A - 2.5.3 Label in Name](https://www.w3.org/TR/WCAG22/#label-in-name)
---
### Multiple authentication methods (INT-1-7)
User authentication must avoid relying on a cognitive function test by providing multiple means of filling in authentication information.
#### How to test
**Tool:** Visual inspection
Ensure that authentication form fields allow any of the following:
- The fields allow autofill of information provided by the browser.
- Information may be pasted into the form fields.
- Biometrics can be used to sign into accounts.
#### Test outcomes
- **Pass**: The authentication fields allow autofill of stored information from the browser or information can be copied and pasted into the fields or biometrics (fingerprints, facial-scan, etc.) can be used to log in.
- **Fail**: The authentication fields do not allow autofill and information cannot be copied and pasted into the fields and biometrics cannot be used (for example: none of the pass criteria methods are used).
- **NA**: the page does not require interaction to authenticate.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.3.8 Accessible Authentication Methods](https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum)
---
## Form interactions (INT-2)
### On focus (INT-2-1)
Focusing or removing focus from an element does not cause a change of context.
#### How to test
**Tool:** Keyboard
1. Tab to each focusable element.
2. Tab away from each focusable element.
3. When focus lands on or leaves each element, confirm it does not cause a change of context.
#### Test outcomes
- **Pass**: Focusing or removing focus from an element does not cause a change of context.
- **Fail**: One or more elements cause a change of context when focused or focus is removed.
#### Related WCAG criteria
[WCAG 2.2 A - 3.2.1 On Focus](https://www.w3.org/TR/WCAG22/#on-focus)
---
### On input (INT-2-2)
Changing the value of any interactive element does not automatically cause a change of context unless the user has been advised beforehand.
#### How to test
**Tool:** Keyboard
1. Locate any elements on the page that has a value that can be updated (for example: checkboxes, radio buttons, selects, etc.).
2. Change the value for each element.
3. Confirm that unexpected changes do not occur.
#### Test outcomes
- **Pass**: No changes of context occur on value change or the user is advised beforehand.
- **Fail**: One or more changes of context occur on value change and the user is not advised beforehand.
- **NA**: No interactive elements can accept a value change.
#### Related WCAG criteria
[WCAG 2.2 A - 3.2.2 On Input](https://www.w3.org/TR/WCAG22/#on-input)
---
### Activate only on up event (INT-2-3)
Actions completed with mouse or touch input must not use the down-event to execute any part of the function.
-or-
Make sure there is a way for the user to abort or undo the action.
-or-
Allow the up-event to reverse any outcome of the preceding down-event
#### How to test
**Tool:** Mouse
Confirm that there are no actions which are completed using the down-event from mouse or touch input or that there is a way for the user to abort or undo the action or that the up-event allows the user to reverse any outcome of the preceding down-event.
#### Test outcomes
- **Pass**: No actions are completed using the down event or there is a way to abort or undo an action completed on the down-event or the up-event allows the reversal of the preceding down-event.
- **Fail**: Actions are completed using the down event and there is not a way to abort or undo the action and the up-event does not allow reversal of the preceding down-event.
#### Related WCAG criteria
[WCAG 2.1 A - 2.5.2 Pointer Cancellation](https://www.w3.org/TR/WCAG22/#pointer-cancellation)
---
### Redundant entry (INT-2-4)
If a page is contained within a process then information provided on the first step of the process is auto-filled in the next steps unless the information is required for security.
#### How to test
**Tool:** Visual inspection
Review the page to determine if it is a step in a process. Ensure that if information is provided in an earlier step in this process, that information is auto-filled in later steps.
#### Test outcomes
- **Pass**: Information provided during the process will autofill if later steps require the same information.
- **Fail**: Fields do not autofill when the same information has been provided on previous steps.
- **NA**: The page does not contain any process-based functionality or information reentry is essential or required for security.
#### Related WCAG criteria
[WCAG 2.2 A - 3.3.7 Redundant Entry](https://www.w3.org/TR/WCAG22/#redundant-entry)
---
## Errors & messaging (INT-3)
### Check for errors (INT-3-1)
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
#### How to test
**Tool:** Visual inspection
1. Identify any inputs that have automatic validation.
2. For each input, verify that errors are described in text.
#### Test outcomes
- **Pass**: Errors are identified and the errors are described to the user in text.
- **Fail**: Errors are identified but the errors are not described to the user in text.
- **NA**: There are no inputs with automatic validation.
#### Related WCAG criteria
- [WCAG 2.2 A - 3.3.1 Error Identification](https://www.w3.org/TR/WCAG22/#error-identification)
- [WCAG 2.2 AA - 3.3.3 Error Suggestion](https://www.w3.org/TR/WCAG22/#error-suggestion)
---
### Summary before submit (INT-3-2)
If user input is collected across multiple pages in order to execute a transaction of some kind the user must be presented with a summary of the input before submitting. The user must be able to change input prior to final submission after reviewing.
#### How to test
**Tool:** Visual inspection
Examine the target page to determine whether it allows users to:
- make any legal commitments or financial transactions, or
- modify or delete data in a data storage system, or
- Submit test responses.
- If the page does allow such actions, verify that the following are true:
- the user is presented with a summary of the input before submitting.
- user can review, confirm, and correct information before finalizing the submission.
#### Test outcomes
- **Pass**: A summary of user input is provided prior to final submit and the user can edit or make corrections as needed.
- **Fail**: A summary of user input is not provided prior to final submit or the user cannot edit or make corrections as needed.
- **NA**: User input is not collected across pages to execute a transaction.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.3.4 Error Prevention](https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data)
---
### Error suggestion (INT-3-3)
When errors are detected, suggestions are provided to correct them, unless it would jeopardize the security or purpose of the content.
#### How to test
**Tool:** Visual inspection
1. Locate any errors that can appear on the page.
2. Trigger each error.
3. Confirm that when possible, an error message describes how to correct the error (eg "username field is required" or "phone number must contain 10 digits").
#### Test outcomes
- **Pass**: Suggestions to fix errors are present.
- **Fail**: One or more errors exist but users are not informed how to fix the errors.
- **NA**: No errors exist on the page.
#### Related WCAG criteria
[WCAG 2.2 A - 3.3.3 Error Suggestion](https://www.w3.org/TR/WCAG22/#error-suggestion)
---
### Highlight in-line errors visually (INT-3-4)
When an error is detected using in-line validation, highlight the field (for example: with a bold red border, error icon with proper alternative text) and place error helper text near it.
#### How to test
**Tool:** Visual inspection
Confirm that when an error is detected using in-line validation, the visual UI highlights the fields with errors (for example: with a red border) and places error helper text above or below each one.
#### Test outcomes
- **Pass**: When an error is detected using in-line validation, the visual UI highlights the field and places error helper text near it.
- **Fail**: For one or more client-side validated forms when an error is detected using client side validation, the visual UI does not highlight the field or place error helper text near it.
- **NA**: No forms are present.
#### Related WCAG criteria
- [WCAG 2.2 A - 3.3.1 Error Identification](https://www.w3.org/TR/WCAG22/#error-identification)
- [WCAG 2.2 AA - 3.3.3 Error Suggestion](https://www.w3.org/TR/WCAG22/#error-suggestion)
---
## Interactive controls (INT-4)
### Link text in context (INT-4-1)
The destination of a link is clear from either the link text alone or the link text combined with surrounding programmatically associated text.
#### How to test
**Tool:** Screen reader
1. Use a screen reader to navigate to each link on the page.
2. Confirm that one of the following is true:
- The name of the link provides sufficient information to understand its destination.
or
- The link destination is clear based on its name and surrounding programmatically associated content (for example: text in the same paragraph, list item, or table cell; content in a table header associated with a table cell containing the link; etc.).
#### Test outcomes
- **Pass**: The destination of all links is clear based on the link text alone or the link text and surrounding programmatically associated text.
- **Fail**: The destination of one or more links on the page is unclear and the surrounding programmatically associated context also does not provide information about the link's purpose.
- **NA**: No links are present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.4 Link Purpose](https://www.w3.org/TR/WCAG22/#link-purpose-in-context)
---
### Valid link href attribute (INT-4-2)
Links must contain a valid href attribute value and must not point to `"javascript:void(0);"` nor `"#"`.
#### How to test
**Tool:** ANDI
Bring up the list of links with ANDI if available and confirm no links HREF points to `"javascript:void(0);"` nor `"#"`.
#### Test outcomes
- **Pass**: All links contain valid href attribute values.
- **Fail**: One or more links do not contain valid href values.
- **NA**: No links are present.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)
---
### Click and drag movements (INT-4-3)
An action that relies on clicking and dragging of content can also be achieved by a single pointer without dragging unless dragging is essential to the activity.
- Example of single pointer Pass: A quiz relies on users clicking and dragging information into the correct bucket. Users are also able to click once to select an option, then click on the correct bucket.
- Example of essential activity: A medical app requires clicking and dragging an object to a target to accurately measure the user’s precision.
#### How to test
**Tool:** Visual inspection
1. Visually inspect the page to determine whether any functionality requires a user to click and move their mouse to access content.
2. For any dragging content, confirm that it can be used with a single pointer without dragging.
#### Test outcomes
- **Pass**: All click and drag functionality can also be performed with a single pointer or the dragging movement is essential.
- **Fail**: Click and drag functionality cannot be completed with a single pointer.
- **NA**: The page does not contain click and drag functionality.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.5.7 Dragging Movements](https://www.w3.org/TR/WCAG22/#dragging-movements)
---
### Target size (INT-4-4)
Actionable components have a minimum target size of 24x24 CSS pixels except for:
Objects with a target offset of at least 24px.
- For example, a 20px width “Cancel” button has its right most edge at least 4px away from a “Submit” button placed on the right.
Inline content within a sentence or block of text.
- For example, a wiki paragraph has multiple instances of hyperlinked text. Increasing the height and width of these links would impact the presentation of text and make it more difficult to read.
#### How to test
**Tool:** Browser Dev Tools (F12)
Use browser inspect tool to view the CSS values under the “Computed” tab. Find the height and width properties for the component.
Ensure that each control has a width and height greater than or equal to 24px or
- For example, a 20px width “Cancel” button has its right most edge at least 4px away from a “Submit” button placed on the right.
#### Test outcomes
- **Pass**: Both height and width are greater than or equal to 24px or less than 24px with sufficient spacing between controls.
- **Fail**: Either the height or width is less than 24px and the center of the control is less than 24px from another control.
- **NA**: Target is a link or button in a block of text that requires a specific presentation.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.5.8 Target Size (Minimum)](https://www.w3.org/TR/WCAG22/#target-size-minimum)
---
### Name (INT-4-5)
All interactive elements must have a programmatic name accessible to assistive technology
#### How to test
**Tool:** Screen reader
1. Review each interactive element with a screen reader.
2. For each interactive element, verify the screen reader announces the name of the element.
#### Test outcomes
- **Pass**: All interactive elements have a name announced by the screen reader.
- **Fail**: One or more interactive elements do not have a name announced by the screen reader.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)
---
### Role (INT-4-6)
All elements with semantic meaning have a valid, accurate programmatic role accessible to assistive technology
#### How to test
**Tool:** Screen reader
1. Locate all elements on the page with semantic meaning. (for example: headings, buttons and links, dialogs, etc…).
2. For each element with semantic meaning, verify the screen reader announces the role of the element.
3. Verify that the role announced for the element is valid and matches the semantic meaning of the element (for example: a link announces a link role, a button announces a button role, etc.).
#### Test outcomes
- **Pass**: All elements with semantic meaning have a role announced by the screen reader that matches the semantic meaning of the element.
- **Fail**: One or more semantic elements do not have a role announced by the screen reader or the role announced does not match the semantic meaning of the element.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)
---
### Value, states, properties (INT-4-7)
States, properties, and values of elements are programmatically available to assistive technology, Any changes to these items are also communicated to assistive technology.
#### How to test
**Tool:** Screen reader
1. Locate all elements on the page which have states, properties, and/or values associated (for example: pressed/invalid state, an error message property on an invalid input, a user-input text string value in a "name" text field, etc.).
2. For each identified state, property, or value, confirm that the screen reader announces it when interacting with the associated element.
**Note:** If a state, property, or value has changed, the screen reader can determine the change.
#### Test outcomes
- **Pass**: All states, properties, and values are announced by the screen reader when interacting with the associated element.
- **Fail**: One or more states, properties, or values are not announced to the screen reader when interacting with the associated element.
- **NA**: No elements with states, properties, or values are present.
#### Related WCAG criteria
[WCAG 2.2 A - 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)
---
## Diverse user needs (INT-5)
### Pause, stop, hide moving content (INT-5-1)
A mechanism must be provided to pause, stop, or hide any content that meets the following criteria:
- Starts automatically
- Is presented in parallel with other content
and
- moves, blinks or scrolls for >5 seconds
or
- All auto-updating content regardless of duration
#### How to test
**Tool:** Visual inspection
1. Perform a visual inspection of the page.
2. Confirm that for any content that meets the following criteria, a mechanism is provided to pause, play, or hide the applicable content:
- Starts automatically.
- Is presented in parallel with other content.
and
- moves, blinks or scrolls for >5 seconds.
or
- All auto-updating content regardless of duration.
#### Test outcomes
- **Pass**: A mechanism is provided to pause, stop, or hide auto-playing; moving or blinking; auto-updating content.
- **Fail**: A mechanism is not provided to pause, stop, or hide auto-playing; moving or blinking; auto-updating content.
- **NA**: No auto-playing; moving or blinking; auto-updating content is present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.2.2 Pause, Stop, Hide](https://www.w3.org/TR/WCAG22/#pause-stop-hide)
---
### Pause or adjust volume for auto playing audio (INT-5-2)
For any audio which 1) plays automatically and 2) lasts for >3 seconds, one of the following must be true:
- A mechanism to pause the content is presented to the user
or
- A mechanism for adjusting the volume of the content is presented to the user and it does not rely on the system audio levels to adjust the volume.
#### How to test
**Tool:** Visual inspection
Confirm that for any audio which 1) plays automatically and 2) lasts for >3 seconds, one of the following is true:
- A mechanism to pause the content is presented to the user.
or
- A mechanism for adjusting the volume of the content is presented to the user and it does not rely on the system audio levels to adjust the volume.
#### Test outcomes
- **Pass**: For all content which plays automatically and lasts for more than 3 seconds a mechanism is provided to pause or adjust volume.
- **Fail**: A mechanism is not provided to pause or adjust volume for all content which plays automatically and lasts for more than 3 seconds.
- **NA**: No content which plays automatically and lasts for more than 3 seconds is present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.4.2 Audio Control](https://www.w3.org/TR/WCAG22/#audio-control)
---
### No blinking or flashing (INT-5-3)
Content that blinks or flashes rapidly must never be used.
**Note:** "Rapidly" is blinking/flashing more than 3 times in 1 second. If there is any doubt about the frequency of flashing then this would fail.
#### How to test
**Tool:** Visual inspection
1. Perform a visual inspection of the page.
2. Confirm that each page contains no content that blinks or flashes.
#### Test outcomes
- **Pass**: Content that blinks or flashes is not used.
- **Fail**: Content that blinks or flashes is used.
#### Related WCAG criteria
[WCAG 2.2 A - 2.3.1 Three Flashes or Below Threshold](https://www.w3.org/TR/WCAG22/#three-flashes-or-below-threshold)
---
### Warn about timeout (INT-5-4)
Users must be warned prior to when a session times out and expires.
#### How to test
**Tool:** Visual inspection
Confirm that users are warned prior to when a session times out and expires.
#### Test outcomes
- **Pass**: Session timeout warning occurs prior to session time out and expiration.
- **Fail**: Session timeout occurs without warning.
- **NA**: No session timeout is present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.2.1 Timing Adjustable](https://www.w3.org/TR/WCAG22/#timing-adjustable)
---
### Extend timeout (INT-5-5)
When a session timeout warning occurs, users must be given at least 30 seconds to take action in order to avoid a session time out by extending the time limit (of a session) via a "simple" user action (for example: "press the space bar").
#### How to test
**Tool:** Visual inspection
Confirm that users are given at least 30 seconds to take action in order to avoid a session time out by extending the time limit (of a session) via a "simple" user action (for example: "press the space bar").
#### Test outcomes
- **Pass**: Users are given at least 30 seconds to extend the session via a simple user action.
- **Fail**: Users are given less than 30 seconds to extend the session via a simple user action.
- **NA**: No session timeout is present.
#### Related WCAG criteria
[WCAG 2.2 A - 2.2.1 Timing Adjustable](https://www.w3.org/TR/WCAG22/#timing-adjustable)
---
### Flexible orientation (INT-5-6)
Content must adapt to the device orientation when orientation is changed from portrait to landscape mode unless a specific orientation is required.
#### How to test
**Tool:** System Settings
Set display orientation to each orientation mode (portrait and landscape) and review how the content responds.
This can be done using OS settings (Start > Settings > System > Display) or inspecting the page in your browser and using the device list to change orientations.
https://developer.chrome.com/docs/devtools/device-mode/orientation/
#### Test outcomes
- **Pass**: Content adapts to all display orientations.
- **Fail**: Content does not adapt to all display orientations.
- **NA**: A specific display orientation is essential (for example: bank check).
#### Related WCAG criteria
[WCAG 2.1 AA- 1.3.4 Orientation](https://www.w3.org/TR/WCAG22/#orientation)
---
### Motion control (INT-5-7)
If functionality can be operated or activated by device or user motion then it can also be operated or activated through UI components and motion actuation can be turned off to avoid unintentional activation by the user.
#### How to test
For all functionality that can be operated or activated by moving the device or user motion input confirm that the same functionality can be operated or activated through UI components and confirm that the motion actuation can be turned off by the user
#### Test outcomes
- **Pass**: All functionality that can be operated or activated by device or user motion has a UI control alternative and motion actuation can be turned off by the user.
- **Fail**: Any aspect of functionality that can be operated or activated by device or user motion does not have a UI control alternative or motion actuation cannot be turned off by the user.
- **NA**: No functionality that can be operated or activated by device or user motion is present.
#### Related WCAG criteria
[WCAG 2.1 A - 2.5.4 Motion Actuation](https://www.w3.org/TR/WCAG22/#motion-actuation)
---
# index
---
title: Navigation and wayfinding
side_nav_title: Navigation and wayfinding
description: Find navigation and wayfinding requirements for testing web experiences.
side_nav_order: 3
---
## Keyboard support (NAV-1)
### Keyboard support (NAV-1-1)
All functionality and content must be available to users via keyboard only, without requiring specific timing of keystrokes.
#### How to test
**Tool:** Keyboard
Run through all use cases using keyboard only (for example: without a mouse), confirming that all features and functionality are fully available to users.
#### Test outcomes
- **Pass**: All features and functionality are fully available to keyboard users.
- **Fail**: One or more features or functionality are not fully available to keyboard users.
#### Related WCAG criteria
[WCAG 2.2 A - 2.1.1 Keyboard](https://www.w3.org/TR/WCAG22/#keyboard)
---
### No keyboard trap (NAV-1-2)
If any part of the UI takes control of keyboard focus (for example: PDF viewer or modal window) it must, through keyboard commands only, allow focus to return to the launching element and browser.
#### How to test
**Tool:** Keyboard
Run through all use cases using keyboard only (for example: without a mouse), confirm that no UI elements take control of keyboard focus unless they also return focus.
#### Test outcomes
- **Pass**: No UI elements take control of keyboard focus without returning it.
- **Fail**: One or more UI elements takes control of keyboard focus and does not return it.
#### Related WCAG criteria
[WCAG 2.2 A - 2.1.2 No Keyboard Trap](https://www.w3.org/TR/WCAG22/#no-keyboard-trap)
---
### Mouse hover and keyboard focus are equivalent (NAV-1-3)
Content which is hidden until it receives mouse hover and then becomes visible must also be shown when it receives keyboard focus and hidden again when focus is removed.
#### How to test
**Tool:** Keyboard
1. Run through all use cases using the keyboard only (for example: without a mouse).
2. Confirm that any mouse hover events are also available to the keyboard when the keyboard focus is placed on the element.
#### Test outcomes
- **Pass**: All mouse hover events are also available to the keyboard when the keyboard focus is placed on the element.
- **Fail**: One or more mouse hover events are not available to the keyboard when the keyboard focus is placed on the element.
- **NA**: Mouse hover events are not present.
#### Related WCAG criteria
- [WCAG 2.1 AA - 1.4.13 Content on Hover or Focus](https://www.w3.org/TR/WCAG22/#content-on-hover-or-focus)
- [WCAG 2.2 A - 2.1.1 Keyboard](https://www.w3.org/TR/WCAG22/#keyboard)
---
### Content on hover or focus (NAV-1-4)
For tooltips and components that show hidden content when they receive keyboard or pointer focus and hidden after removal of focus ensure they are dismissible, hoverable, and persistent.
#### How to test
**Tool:** Keyboard/Mouse
1. For tooltips and components that show hidden content when they receive keyboard or pointer focus and hidden after removal of focus.
2. ensure they are dismissible, hoverable, and persistent.
#### Test outcomes
- **Pass**: All of the hover show/hide content is dismissible, hoverable, and persistent.
- **Fail**: Hover show/hide content is not all dismissible, hoverable, and persistent.
- **NA**: No hover show/hide content is present.
#### Related WCAG criteria
[WCAG 2.1 AA - 1.4.13 Content on Hover or Focus](https://www.w3.org/TR/WCAG22/#content-on-hover-or-focus)
---
### Pointer and multipoint gestures (NAV-1-5)
An action that is performed by a 'path-based gesture' or multipoint gesture must also be completable using a single pointer gesture and a keyboard or alternative input device.
#### How to test
**Tool:** Mouse
1. Use the keyboard to navigate to all path-based or multipoint gesture operable controls and confirm that they can all be operated with keyboard control.
2. Use the mouse to interact with all path-based or multipoint gesture operable controls and confirm that they can all be operated with a single pointer gesture control as well.
#### Test outcomes
- **Pass**: All actions that can be performed by a path-based or multipoint gesture can also be completed with a keyboard and a single pointer gesture (individual mouse clicks).
- **Fail**: One or more actions that can be performed by a path-based or multipoint gesture cannot be completed with a keyboard or a single pointer gesture (individual mouse clicks).
- **NA**: no actions that can be performed by a path-based or multipoint gesture are present.
#### Related WCAG criteria
[WCAG 2.1 A - 2.5.1 Pointer Gestures](https://www.w3.org/TR/WCAG22/#pointer-gestures)
---
### Single character keyboard shortcuts (NAV-1-6)
If a single character shortcut is used then users must have the option to either turn it off or remap it to one or more non-printable keyboard characters.
-or-
Make sure the single character shortcut is only active when the component it affects has focus.
#### How to test
**Tool:** Keyboard
Confirm that where a single character shortcut is used that users have the option to either turn it off or remap it to one or more non-printable keyboard characters.
-or-
Make sure the single character shortcut is only active when the component it affects has focus.
#### Test outcomes
- **Pass**: For all single character shortcuts, users have the option to either turn off or remap it to one or more non-printable keyboard characters or the single character shortcut is only active when the component it affects has focus.
- **Fail**: For all single character shortcuts, users do not have the option to either turn off or remap it to one or more non-printable keyboard characters and the single character shortcut is active at all times.
- **NA**: No single character shortcuts are present.
#### Related WCAG criteria
[WCAG 2.1 A - 2.1.4 Character Key Shortcuts](https://www.w3.org/TR/WCAG22/#character-key-shortcuts)
---
### Skip to main content link (NAV-1-7)
A "skip to main content" link must be included on every page as the first link (or second if "skip to login" link is present) on the page. The link must skip to the main content of the page or the errors summary if present and may be visually hidden until it has focus.
#### How to test
**Tool:** Keyboard
Hit Tab after the page loads. Confirm that the first or second link on the page is "skip to main content" - it may be visibly hidden until it receives focus. If running the test on a Single Page Application (SPA) refresh the page and confirm that the first or second link is “Skip to main content”.
#### Test outcomes
- **Pass**: A skip to main content link is provided and it is fully operational.
- **Fail**: A skip to main content link is not provided or the skip to content link is not fully operational.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.1 Bypass Blocks](https://www.w3.org/TR/WCAG22/#bypass-blocks)
---
## Focus & tab order (NAV-2)
### Visible keyboard focus (NAV-2-1)
During keyboard navigation, the keyboard focus indicator is visible.
#### How to test
**Tool:** Keyboard
1. Tab through the entire page.
2. Confirm each focusable element has a visible focus indicator.
#### Test outcomes
- **Pass**: Each focusable element has a visible focus indicator.
- **Fail**: One or more focusable elements do not have a visible focus indicator.
#### Related WCAG criteria
- [WCAG 2.2 AA - 2.4.7 Focus Visible](https://www.w3.org/TR/WCAG22/#focus-visible)
- [WCAG 2.2 AAA - 2.4.13 Focus Appearance](https://www.w3.org/TR/WCAG22/#focus-appearance)
---
### Focus not obscured (NAV-2-2)
When a focusable element has keyboard focus, the element is at least partially visible.
#### How to test
**Tool:** Keyboard
1. Tab through the entire page.
2. For each focusable element, when it has focus, confirm at least part of the element is visible (not fully obscured by other content or off the viewport).
**Note:** If content can be repositioned by the user, only test the initial position.
#### Test outcomes
- **Pass**: Focusable elements are at least partially visible when focused.
- **Fail**: One or more focusable elements are fully obscured when focused.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum)
---
### Focus order (NAV-2-3)
Tab focus must follow a logical and meaningful order that preserves relationships and matches how the page is naturally read.
#### How to test
**Tool:** Keyboard
1. Navigate through all interactive elements on the page using the tab key.
2. Confirm that focus moves to each element in a logical order (generally top to bottom, left to right).
#### Test outcomes
- **Pass**: The focus order is logical and meaningful, preserving relationships and matching how the page is naturally read.
- **Fail**: The focus order is not logical. The meaning or relationships in the content are affected.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.3 Focus Order](https://www.w3.org/TR/WCAG22/#focus-order)
---
## Landmarks (NAV-3)
### Appropriate use of landmark regions (NAV-3-1)
The page must have a 'Main' landmark region defined at a minimum and Banner, Navigation, Search, Complementary, and ContentInfo roles are present if these content types are present in the page.
#### How to test
**Tool:** Accessibility Insights
1. Open the page in the Chrome browser and use Accessibility Insights > Adhoc Tools >Landmarks to visualize the landmark regions that are present in the page.
2. Confirm that the page has a 'Main' landmark region defined at a minimum.
3. Confirm that the Banner, Navigation, and ContentInfo roles are present if these content types are present in the page.
#### Test outcomes
- **Pass**: The page contains a main landmark region and if content suited for a navigation, banner, or contentinfo region is present then the appropriate roles are applied to each content area respectively.
- **Fail**: The page does not contain a main landmark region or content suited for a navigation, banner, or contentinfo region is present and the appropriate roles are not
applied to each content area respectively.
- **NA**: The page content is not substantial enough to be grouped in one or more landmark regions.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.1 Bypass Blocks](https://www.w3.org/TR/WCAG22/#bypass-blocks)
---
### Keep all content in appropriate regions (NAV-3-2)
All rendered content must be within the appropriate landmark region and the Main landmark must contain all of the primary page content and no blocks of content that repeat on multiple pages are within the Main landmark.
#### How to test
**Tool:** Accessibility Insights
Using the Accessibility Insights Landmarks tool, examine the landmark regions in the page and confirm that:
1. All page content is within a landmark region.
2. All primary page content is within the Main landmark region.
3. No content that repeats on multiple pages is within the Main landmark region.
#### Test outcomes
- **Pass**: All page content is within the appropriate landmark region.
- **Fail**: One or more blocks of page content are not within a landmark region or the Main landmark region does not include all primary page content or content that repeats on multiple pages is within the Main landmark region.
#### Related WCAG criteria
[WCAG 2.2 A - 2.4.1 Bypass Blocks](https://www.w3.org/TR/WCAG22/#bypass-blocks)
---
### Redundant landmarks have unique names (NAV-3-3)
If a page has multiple landmarks of the same type (for example: Main Nav and Sub Nav), those regions must have unique names applied using an appropriate naming technique and the landmark role type must not be included in the name.
#### How to test
**Tool:** Accessibility Insights
1. Use Accessibility Insights > Adhoc Tools > Landmarks to review all of the landmarkroles in the page.
2. Locate any instance of two or more landmarks of the same type (for example: Main Nav and Sub Nav).
3. Confirm that each duplicate landmark has a unique name that does not include the landmark role type in the name to help screen reader users distinguish between the two.
#### Test outcomes
- **Pass**: All landmark regions of the same role type have unique names applied and the name for each does not include the role type.
- **Fail**: Two or more landmark roles of the same type are present and they do not have unique names applied or the name of one or more region includes the role type in the name value.
- **NA**: No landmark regions of the same role type are present.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.4.6 Headings and Labels](https://www.w3.org/TR/WCAG22/#headings-and-labels)
---
## Consistent experience (NAV-4)
### Same relative order (NAV-4-1)
Components, like links, buttons, or contact forms, that appear on multiple pages must appear in the same relative order on every page.
#### How to test
**Tool:** Visual inspection
1. Perform a visual inspection of the page looking for navigation components.
2. Confirm that components (links, buttons, contact forms, etc.) that appear on multiple pages appear in the same relative order on every page.
#### Test outcomes
- **Pass**: Components that appear on multiple pages appear in the same relative order on every page.
- **Fail**: One or more component that appears on multiple pages does not appear in the same relative order on every page.
- **NA**: No component appears on multiple pages.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.2.3 Consistent Navigation](https://www.w3.org/TR/WCAG22/#consistent-navigation)
---
### Name consistently (NAV-4-2)
Consistent labels, names, and text alternatives must be used for content that has the same functionality.
#### How to test
**Tool:** Visual inspection
Confirm that content with the same functionality has consistent labels, names, and text alternatives.
#### Test outcomes
- **Pass**: Content with the same functionality has consistent labels, names, and text alternatives.
- **Fail**: Content with the same functionality does not have consistent labels, names, or text alternatives.
- **NA**: No content with the same functionality is present.
#### Related WCAG criteria
[WCAG 2.2 AA - 3.2.4 Consistent Identification](https://www.w3.org/TR/WCAG22/#consistent-identification)
---
### Consistent help (NAV-4-3)
If a page includes the help options listed below, they are in the same location on similar pages:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
#### How to test
**Tool:** Visual inspection
1. Locate if any of the listed help options in exist on the page:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
2. Determine if the help is in the same location across similar pages.
#### Test outcomes
- **Pass**: Help across similar pages is in the same location.
- **Fail**: Help across similar pages is not in the same location.
- **NA**: No help options exist on the page.
#### Related WCAG criteria
[WCAG 2.2 A - 3.2.6 Consistent Help](https://www.w3.org/TR/WCAG22/#consistent-help)
---
### More than one way to find content (NAV-4-4)
Users must be provided more than one way to find content within a website except when the web page is the result of a step or process. This provision must include two or more of the following navigational methods:
- Links to navigate to related Web pages
- a Table of Contents
- a Site Map
- a search function
- a list of links to all other Web pages
- Linking to all of the pages on the site from the home page
#### How to test
**Tool:** Visual inspection
1. Review the page and site navigation structure.
2. Confirm that the site provides at least 2 of the following ways to find content:
- Links to navigate to related Web pages
- Table of Contents
- Site Map
- Search function
- List of links to all other Web pages
- Linking to all of the pages on the site from the home page
Exception: Small sites (4 pages or fewer) can meet this requirement if the main navigation menu links to all other pages.
#### Test outcomes
- **Pass**: The site provides 2 or more ways to find content.
- **Fail**: The site provides fewer than 2 ways to find content.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.4.5 Multiple Ways](https://www.w3.org/TR/WCAG22/#multiple-ways)
---
# index
---
title: Text requirements for web
side_nav_title: Text
description: Find text requirements for testing web experiences.
side_nav_aria_label: Text requirements for web.
side_nav_order: 1
---
## Heading structure (TXT-1)
### Headings and labels (TXT-1-1)
Headings and labels must accurately describe their content.
#### How to test
**Tool:** Accessibility Insights
1. Reveal headings via Accessibility Insights > Ad hoc tools>Accessible Names.
2. View all headings and labels on the page.
3. Confirm that the page headings and labels accurately describe their content.
#### Test outcomes
- **Pass**: Headings and labels are used and they accurately describe their content.
- **Fail**: Headings and labels are not used or they do not accurately describe their content.
- **NA**: There is not sufficient content to warrant the use of headings or labels.
#### Related WCAG criteria
[WCAG 2.2 AA - 2.4.6 Headings and Labels](https://www.w3.org/TR/WCAG22/#headings-and-labels)
---
### Use a single descriptive H1 (TXT-1-2)
Each page must have only one H1 which is descriptive of the overall page topic/purpose. The H1 and the page title should be similar and consistent.
#### How to test
**Tool:** Accessibility Insights
1. Reveal headings via Accessibility Insights > Ad hoc tools > Headings.
2. View all headings and confirm there is a single H1 on the page.
3. Confirm that the H1 is descriptive of the overall page topic/purpose.
4. Confirm that the H1 and page title are similar and consistent.
#### Test outcomes
- **Pass**: There is only one H1 level heading present and it is descriptive of the page topic/purpose and similar to the page title.
- **Fail**: There are two or more H1 level headings present or the H1 is not descriptive of the page topic/purpose or not similar to the page title.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Sequential headings (TXT-1-3)
Headings must be implemented sequentially in order without skipping levels. (for example: Heading 1, then Heading 2, then Heading 3 and so on). Headings of the same level may be repeated (for example: H2, H2, H2, etc.).
#### How to test
**Tool:** Accessibility Insights
1. Reveal headings via Accessibility Insights > Ad hoc tools > Headings.
2. View all headings and confirm that headings occur in sequential order without skipping levels. (for example: Heading 1, then Heading 2, then Heading 3 and so on, no skipping numbers).
#### Test outcomes
- **Pass**: Headings descend in single increments with no skipping.
- **Fail**: Headings do not descend in single increments and levels are skipped.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.2 Meaningful Sequence](https://www.w3.org/TR/WCAG22/#meaningful-sequence)
---
## Semantic markup (TXT-2)
### Group items with lists (TXT-2-1)
Groups of items (for example: a navigation menu or group of tabs) must be marked up as a list.
#### How to test
**Tool:** Browser Dev Tools (F12)
1. Locate any text content that is presented in a list format such as bulleted or numbered lists.
2. Locate any groups of items that should be marked up as lists (for example: a navigation menu or group of tabs).
3. Use the browser inspect feature to examine the HTML for these list components and confirm that they are properly marked up as lists.
#### Test outcomes
- **Pass**: All groups of items are marked as lists.
- **Fail**: All groups of items are not marked as lists.
- **NA**: No groups of items are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
## Logical order (TXT-3)
### Code order = logical content order (TXT-3-1)
The logical order of content must be present in the code order, allowing for successful use of the content when linearized and/or without CSS.
#### How to test
**Tool:** Web Accessibility Evaluation Toolbar (WAVE)
1. Open the WAVE tool with the page you are testing open in your browser.
2. Use the toggle switch to 'Disable styles'.
3. Confirm that the logical order of content is present in the code order.
#### Test outcomes
- **Pass**: The logical order of the content is followed.
- **Fail**: The logical order of the content is not followed.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.2 Meaningful Sequence](https://www.w3.org/TR/WCAG22/#meaningful-sequence)
---
## Non-sensory instructions (TXT-4)
### Instructions don't rely on sensory cues (TXT-4-1)
Instructions must never refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
**Note:** When instructions refer to an interactive element, use the programmatic name of the element.
#### How to test
**Tool:** Visual inspection
1. Review any instruction text (on-screen and screen reader only).
2. Confirm that Instructions and interactions never refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
#### Test outcomes
- **Pass**: Instructions and interactions never refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
- **Fail**: Instructions and interactions refer solely to sensory cues such as size, shape, color, sound, or spatial directions.
- **NA**: No instructions are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.3 Sensory Characteristics](https://www.w3.org/TR/WCAG22/#sensory-characteristics)
---
## Tables (TXT-5)
### No layout tables (TXT-5-1)
Tables must not be used for layout purposes. Layout tables are not a direct WCAG 2.2 AA failure, however when a table is linearized it can complicate or confuse the linear order of the content (See WCAG F49 for details).
#### How to test
**Tool:** ANDI
1. Run the ANDI tool on the page.
2. Locate any table elements identified by ANDI on the page.
3. Confirm that none of the tables are used for layout purposes.
#### Test outcomes
- **Pass**: Tables are not used for layout positioning; CSS is used instead.
- **Fail**: One or more layout table(s) is used.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.2 Meaningful Sequence](https://www.w3.org/TR/WCAG22/#meaningful-sequence)
---
### Markup tables (TXT-5-2)
All data tables must use THs and every TH must have scope="col" or "row" set unless any implied relationships would be untrue. In that case, headers= must be used to hard code how headers are read to users.
#### How to test
**Tool:** ANDI
1. Run the ANDI tool on the page.
2. Locate any table elements identified by ANDI on the page.
3. Confirm that `
` elements are used as appropriate and every `
` element has scope as appropriate. If present, confirm that headers point to the correct `
` elements' IDs.
#### Test outcomes
- **Pass**: Tables have correct `
` elements, `
` elements, and scope applied appropriately.
- **Fail**: One or more tables does not have correct `
` elements, `
` elements, and scope applied appropriately.
- **NA**: No tables are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
### Identify tables (TXT-5-3)
Data tables must be identified for screen readers by including the "title" of the table in its `
` element, for example: "Transaction History for x2304".
**Note:** The caption may be hidden visually with CSS.
#### How to test
**Tool:** Screen reader
Bring up the list of tables (or cycle through each if a list is not available) with each supported screen reader and confirm that each table is identified.
#### Test outcomes
- **Pass**: All tables have titles that are read by the screen reader.
- **Fail**: One or more tables does not have a title that is read by the screen reader.
- **NA**: No tables are present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
---
# index
---
title: Visual design and multimedia
side_nav_title: Visual design and multimedia
description: Find visual design and multimedia requirements for testing web experiences.
side_nav_order: 4
---
## Content resizing, styling, & reflow (VIS-1)
### Browser zoom usable (VIS-1-1)
Using the built-in browser functionality to zoom all page content to 200% (including text), all interactive content must remain fully usable.
#### How to test
**Tool:** System Settings
Use browser zoom to magnify your viewport to 200% and confirm that all interactive content remains fully usable.
#### Test outcomes
- **Pass**: All interactive content remains fully usable up to 200%.
- **Fail**: Some interactive content does not remain fully usable between 0 - 200%.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.4 Resize Text](https://www.w3.org/TR/WCAG22/#resize-text)
---
### Content reflow (VIS-1-2)
Content remains functional and no information is lost when viewed at 320px width (for vertical scrolling content) or 256px height (for horizontal scrolling content). Scrolling in two directions must not be required.
Exception: two direction scrolling is allowed for elements that require it for usage such as:
- Data tables/charts
- Photos
- Maps
#### How to test
**Tool:** Browser Dev Tools (F12)
1. Use the browser dev tools/Inspector to set the page width to 320px for vertical scrolling content or 256px for horizontal scrolling content.
2. Confirm that all content remains functional and that no information is lost (for example: cut off text, missing UI, overlapping content).
3. Confirm that scrolling in two directions is not required.
Exceptions:
Horizontal scrolling is allowed for the following content:
- Data tables
- Photos
- Maps
- Charts
- Games
- UI with toolbars
#### Test outcomes
- **Pass**: Content remains functional and no information is lost when viewed at the required height or width. Scrolling in two directions is not required unless an element requires it for usage.
- **Fail**: Content is not functional or information is lost when viewed at the required height or width. Alternatively, scrolling in two directions is required.
- **NA**: Content is any of the following:
- Data tables
- Photos
- Maps
- Charts
- Games
- UI with toolbars
#### Related WCAG criteria
[WCAG 2.1 AA - 1.4.10 Reflow](https://www.w3.org/TR/WCAG22/#reflow)
---
### User text styling (VIS-1-3)
User text style settings do not cause a loss of content when:
- Line height (line spacing) is increased to at least 1.5 times the font size;
- Spacing following paragraphs is set to at least 2 times the font size;
- Letter spacing (tracking) is increased to at least 0.12 times the font size;
- Word spacing is set to at least 0.16 times the font size.
#### How to test
**Tool:** Text Spacing Bookmarklet
1. Load the page in the browser of your choice.
2. Run the Text Spacing Bookmarklet.
3. Perform a visual inspection of the content and confirm that there is not a resulting loss of content or meaning.
#### Test outcomes
- **Pass**: There is not a resulting loss of content or meaning when any of the four text spacing settings are changed.
- **Fail**: There is a loss of content or meaning when the four text spacing settings are changed.
#### Related WCAG criteria
[WCAG 2.1 AA -1.4.12 Text Spacing](https://www.w3.org/TR/WCAG22/#text-spacing)
---
## Color usage (VIS-2)
### Color contrast ratio (VIS-2-1)
A color contrast ratio of text, informational images, and images of text to their backgrounds must be at least 4.5:1, except if the text is 18pt or 14pt bold or larger, where a ratio of 3:1 is then required. Text that is part of a logo is not subject to this requirement.
If there is content that does not pass color contrast requirements, then an alternate (high-contrast) compliant style sheet must be available.
#### How to test
**Tool:** WebAIM Contrast Checker
Use a contrast analyzer to check color contrast ratio of text, and images of text to their backgrounds. Use the eye dropper tool to check any text that is missed by the automated scan. If a failure is identified with the automated scan which seems questionable use the eye dropper tool to double check. Contrast ratio must be at least 4.5:1, except if the text is 18pt or 14pt bold or larger, where a ratio of 3:1 is then required.
**Note:** All of this information will be provided in the contrast validation tool's side panel, except for text that is not HTML text or an HTML colored background (for example: text over a gradient image). In this case, use the color picker tool from the panel to pick samples and determine if the text fails in any places.
If there is content that does not pass color contrast requirements, then an alternate (high-contrast) compliant style sheet must be available.
#### Test outcomes
- **Pass**: All text meets expected minimum contrast ratio.
- **Fail**: All text does not meet the expected minimum contrast ratio and an alternate style sheet is not provided.
- **NA**: Text is part of an inactive user interface component or pure decoration.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.3 Contrast (Minimum)](https://www.w3.org/TR/WCAG22/#contrast-minimum)
---
### Contrast for non-text UI components (VIS-2-2)
User interface components and graphical objects must have a contrast ration of at least 3:1 against adjacent colors.
#### How to test
**Tool:** WebAIM Contrast Checker
Confirm that all user interface components and graphical objects have a contrast ratio of at least 3:1 against adjacent colors including the background and other non-text objects by using the eye dropper tool in a contrast analyzer.
#### Test outcomes
- **Pass**: All user interface components and graphical objects have a contrast ratio of 3:1 against adjacent colors.
- **Fail**: Some user interface components and/or graphical objects do not have a contrast ratio of 3:1 against adjacent colors.
#### Related WCAG criteria
[WCAG 2.1 AA - 1.4.11 Non-text Contrast](https://www.w3.org/TR/WCAG22/#non-text-contrast)
---
### Support high contrast (VIS-2-3)
All content adapts and supports the user's high contrast theme settings
#### How to test
**Tool:** System Settings
Windows: Use the search feature to search for Contrast Themes. Activate the high contrast themes from the settings window.
Mac: Go to System Preferences>Accessibility>Display>Invert Colors.
#### Test outcomes
- **Pass**: All content supports high contrast themes.
- **Fail**: Some content does not support high contrast themes.
#### Related WCAG criteria
- [WCAG 2.1 – 4.1 Compatible](https://www.w3.org/TR/WCAG22/#compatible)
- [Section 508 302.2 With Limited Vision](https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#302-functional-performance-criteria)
- [Section 508 302.3 Without Perception of Color](https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#302-functional-performance-criteria)
- [Section 508 502.2.2 No Disruption of Accessibility Features](https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#502-interoperability-assistive-technology)
---
### Not only color (VIS-2-4)
If a color difference is used to convey information, that information must also be available in text or through some other alternative method.
Link text may be distinguished from static text through use of color as long as the following are true:
- A 3:1 contrast ratio difference exists between the link text and other static text
- A visual indicator is provided when the link receives focus (for example: visible underline on hover and keyboard focus)
#### How to test
**Tool:** Visual inspection
1. Perform a visual inspection of the page.
2. Confirm that whenever a difference in color is used to convey information, that information is also be available in text or through some other alternative method.
#### Test outcomes
- **Pass**: A non-color alternative is presented along with color.
- **Fail**: Only color is used to indicate meaning.
- **NA**: Color is not used to convey meaning.
#### Related WCAG criteria
[WCAG 2.2 A - 1.4.1 Use of Color](https://www.w3.org/TR/WCAG22/#use-of-color)
---
## Images (VIS-3)
### Text alternatives (VIS-3-1)
All non-text content must provide text alternatives that provide equivalent information, context, and purpose to the user using the following techniques (as applicable):
- For `` elements, provide the text alternative using the alt attribute
- For other non-text content (for example: `role="img"`), aria-label/labelledby, or visibly hidden textaria-label/labelledby, or visibly hidden text
- For decorative `` elements, provide `alt=""` (alt null)
- For other decorative non-text content, `aria-hidden="true"`
#### How to test
**Tool:** Accessibility Insights
Using Accessibility Insights, confirm that all non-text content provides text alternatives that provide equivalent information, context, and purpose to the user and that decorative non-text content is appropriately hidden using null alternative text or `aria-hidden="true"`
#### Test outcomes
- **Pass**: All non-text content provides text alternatives and all decorative content is hidden correctly.
- **Fail**: Some non-text content does not have text alternatives or some decorative content is not hidden correctly.
- **NA**: Non-text content is not present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.1.1 Non-text Content](https://www.w3.org/TR/WCAG22/#non-text-content)
---
### No images of text (VIS-3-2)
Text must always be presented using live text and CSS rather than an image of text, except for logos and within pictures where it cannot be avoided (for example: graphs or screenshots).
#### How to test
Using the mouse, click and drag over all text on the page to select it.
HTML text will be selectable. Text that is part of an image will show the entire image being highlighted.
Confirm that text is presented using text rather than in an image of text, except for logos and within pictures where it cannot be avoided (for example: graphs or screenshots).
#### Test outcomes
- **Pass**:Images of text are not used.
- **Fail**: Images of text are used.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.4.5 Images of Text](https://www.w3.org/TR/WCAG22/#images-of-text)
---
## Multimedia (VIS-4)
### Captions (prerecorded) (VIS-4-1)
Captions are available for content with both audio and video, except when the content is an alternative for text and is clearly labeled as such.
#### How to test
**Tool:** Visual inspection
1. Identify prerecorded content with both audio and video.
2. Confirm that captions are available.
3. Confirm the captions contain all audio information (for example: speech, sound effects, music, etc.).
#### Test outcomes
- **Pass**: All prerecorded content with both audio and video has accurate captions.
- **Fail**: Any prerecorded content with both audio and video does not have captions, or the captions do not contain all audio information.
- **NA**: No prerecorded content with both audio and video exists.
#### Related WCAG criteria
[WCAG 2.2 A - 1.2.2 Captions (Prerecorded)](https://www.w3.org/TR/WCAG22/#captions-prerecorded)
---
### Audio description or media alternative (prerecorded) (VIS-4-2)
A transcript or audio description is available for content with both audio and video, except when the content is an alternative for text and is clearly labeled as such.
#### How to test
**Tool:** Visual inspection
1. Test “Audio Description (Prerecorded) VIS-4-4”.
2. If "Audio Description (Prerecorded) VIS-4-4" passes, this also passes.
3. If "Audio Description (Prerecorded) VIS-4-4" fails, confirm a transcript exists that describes the meaningful visual information.
#### Test outcomes
- **Pass**: "Audio Description (Prerecorded) VIS-4-4" is passing.
or
A transcript is available that describes all meaningful information.
- **Fail**: Neither a transcript or audio description is available and there is meaningful information not described by the audio.
- **NA**: No content with both audio and video exists.
or
The exception is met.
#### Related WCAG criteria
[WCAG 2.2 A - 1.2.3 Audio Description or Media Alternative (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-description-or-media-alternative-prerecorded)
---
### Captions (live) (VIS-4-3)
Captions must be available for live content with both audio and video.
#### How to test
**Tool:** Visual inspection
1. Identify live content with both audio and video.
2. Confirm that captions are available.
3. Confirm the captions contain all audio information (for example: speech, sound effects, music, etc.).
#### Test outcomes
- **Pass**: All live content with both audio and video has captions.
- **Fail**: Any live content with both audio and video does not have captions or the captions do not contain all of the audio information.
- **NA**: No live content with both audio and video exists.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.2.4 Captions (Live)](https://www.w3.org/TR/WCAG22/#captions-live)
---
### Audio description (prerecorded) (VIS-4-4)
An audio description track must be available if there is meaningful visual information that is not included in the audio track for prerecorded content with both audio and video.
#### How to test
**Tool:** Visual inspection
1. Identify prerecorded content with both audio and video.
2. If the content provides meaningful visual information that is not described by the audio, confirm it also includes an audio description track that explains the visual information.
#### Test outcomes
- **Pass**: Audio description is available when needed.
- **Fail**: Meaningful visual information in the video is not described by the audio and an audio description track is missing, incomplete, or inaccurate.
- **NA**: The audio describes the visual content.
or
There is no prerecorded content with both audio and video.
#### Related WCAG criteria
[WCAG 2.2 AA - 1.2.5 Audio Description (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-description-prerecorded)
---
### Transcripts for audio-only/video-only (VIS-4-5)
For audio-only and video-only media, a transcript must be provided which provides the same information as presented in the original media content.
#### How to test
**Tool:** Visual inspection
A transcript which provides the same information as presented in the original media content must be made available for all audio-only and/or video-only content.
#### Test outcomes
- **Pass**: Transcripts are provided.
- **Fail**: Transcripts are not provided.
- **NA**: No audio or video only content is present.
#### Related WCAG criteria
[WCAG 2.2 A - 1.2.1 Audio-only & Video-only (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-only-and-video-only-prerecorded)
---
# index
---
title: Address
tab_title: Usage
description: Groups of input or text fields that collect address details from users.
meta_description: Learn how to implement groups of input or text fields that collect address details from users.
thumbnail: assets/components/address-graphic.svg
keywords: ["Address country code", "country selection", "address state abbreviations", "billing address", "mailing address", "shipping address"]
related:
components:
- combobox
- input
patterns:
- forms
---
The address pattern is a set of [input](https://design.visa.com/components/input) fields intuitively laid out to collect address information. Users can enter their name, country, street address, city, state, ZIP code, country code, and phone number information.
Also known as: Address country code, country selection, address state abbreviations, billing address, mailing address, shipping address.
## Anatomy
**A. Name fields (required):** Text input field for first name and last name to be entered in separate fields.
**B. Country field (required):** Combobox input field for country selection.
**C. Address field (required):** Text input field for address entry. The second address line is optional.
**D. City, State, and ZIP code fields (required):** Text input fields for City, State and ZIP code entry.
**E. Country code field (required):** Combobox input field for country code entry.
**F. Phone number field (required):** Numeric input field for phone number entry.
## Usage
When to use and when not to use address pattern
- When to use: When user’s address information needs to be collected.
- When not to use: In cases where the user’s address isn’t necessary or the application requires minimal data collection.
## Best practices
- Follow all guidelines found in [Input](https://design.visa.com/components/input) and [Combobox](https://design.visa.com/components/combobox) when implementing those items in the address pattern.
- Match address information to local region expectations whenever possible.
### Familiar formatting
Display content in a format that’s familiar and intuitive to users. Aim to reflect the pattern that the information is usually presented in for that region to make it easier for users to understand the content. Some fields such as postal code or phone number may include text formatting. The order that these fields appear may also be different from the provided layout. Make sure to use the correct labels and address form fields to increase form success.
#### Name order
In some regions, the last name should be the first field in this set. If this is a billing address, the name should match the name of the registered card holder. Check with your product team and the US Office of Foreign Assets Control (OFAC) for specific business requirements.
## Behaviors
### Autosuggest
Each region and locale should have an optimized address format, which may be adjusted based on country selection. Autosuggest provides a list of suggested addresses as the user types. The suggestions typically come from a database of known addresses, and the user can select the correct one from the list. This helps in reducing user errors and speeds up the process of filling out the form. Learn more about Autosuggest in [Input](https://design.visa.com/components/input).
### Autocomplete
Enable autocomplete of the rest of the address fields (such as city, state, and ZIP code) once the user completes typing or selects an address from the autosuggest list. Allow free-form input in the main fields in case there are unregistered addresses.
### States and provinces
The user selects their state using a combobox. Refer to the [Full menu with automatic selection](https://design.visa.com/components/combobox/usage#automatic-selection) section in the combobox guidelines for complete keyboard and interaction behavior and guidance on autocomplete functionality.
#### Shortened field width
The shortened width of the field sets user expectations for entering the abbreviation instead of the full name of the state. The list of options will be in alphabetical order.
#### Typed input
As the user types, highlight in the menu moves to the first matching item. When the user hits enter, the item will be selected.
#### Reopening the field
When reopened, the menu shows the selected item in the context of the full list of menu items.
#### Error prevention
Invalid entries won't be automatically selected. Upon exiting the field, it resets to the last valid entry or its default state.
### Country code and phone number
The country code field includes a combobox and can be selected by entering the country code or country name. The phone number field is a numeric input field. This field may include formatting with an area code parentheses, spaces, and dashes.
## Content
- Write all content in sentence case, except for proper nouns.
- Follow guidance in [Forms](https://design.visa.com/patterns/forms) when writing form titles, field labels, and inline messages.
### Labels
- Limit labels to a few brief words.
- Ensure labels accurately represent the expected input to reduce errors.
- Use parallel structure across labels, using either nouns like “Email” or verbs like “Enter email”.
#### Inline messages
- Limit all inline messages (including errors) to one to two short sentences with punctuation.
- Use inline messages to provide additional guidance such as format or specific syntax or values to help avoid errors.
- Provide concise, descriptive, and helpful guidance about the field’s usage and necessity, avoiding technical jargon.
#### Inline error messages
- Use inline error messages to draw attention and to errors without causing frustration.
- Provide clear, prescriptive guidance on correcting the error. Avoid redirecting users to another page to fix it.
- Communicate whether the problem can occur again and offer an alternative backup solution in case it does.
---
# accessibility
---
title: Application layouts
description: Learn how to choose a navigational frame based on page content and information architecture.
meta_description: Find the right navigational frame for your project based on page content and information architecture.
thumbnail: assets/patterns/application-layouts/layouts.svg
tab_order: 2
---
Creating access for everyone, everywhere requires attention to accessibility attributes, best practices, and requirements. Find accessibility guidance below.
## Best practices
### Landmarks
Each page needs landmark regions, such as, main (which is required), header, and footer. These areas help keyboard users to easily navigate a page. Each landmark needs an accessible name, particularly if there’s more than one of them. For example, if there are two `