@uswds/uswds
Advanced tools
Open source UI components and visual style guide for U.S. government websites
The United States Web Design System includes a library of open source UI components and a visual style guide for U.S. federal government websites.
This repository is for the design system code itself. We maintain another repository for the documentation and website. To see the design system and its documentation on the web, visit https://designsystem.digital.gov.
USWDS's components and style guide follow industry-standard accessibility guidelines and use the best practices of existing style libraries and modern web design. The U.S. Digital Service and 18F created USWDS for designers and developers. USWDS is a project of GSA’s Technology Transformation Service, maintained by the Office of Products and Programs. It is designed for use by government product teams who want to create beautiful, easy-to-use online experiences for the public. To learn more about the project, check out this blog post, and to view websites and applications, check out our list here.
Information about the most recent release of the design system can always be found in the release history. We include details about significant updates and any backward-incompatible changes along with a list of all changes.
We’re glad you’d like to use the design system — here’s how you can get started:
npm (recommended). Follow the instructions in this README to get started without npm.
How you implement the design system depends on the needs of your project and your workstyle. We recommend implementing the design system with npm, but we also provide a direct download if npm will not work for you or your project.
Download the design system if you are not familiar with npm and package management.
Use the design system npm package if you are familiar with using npm and package management.
If you’re interested in maintaining a package that helps us distribute USWDS, the project’s build system can help you create distribution bundles to use in your project. Please read our contributing guidelines to locally build distributions for your framework or package manager.
npmIf you’re using a framework or package manager that doesn’t support npm, you can find the source files in this repository and use them in your project. Otherwise, we recommend that you follow the steps outlined in this section. Please note that the core team isn’t responsible for all frameworks’ implementations.
Download the USWDS zip file from the latest USWDS release and open that file.
After extracting the zip file you should see the following file and folder structure:
uswds-3.0.0/
├── css/
│ ├── uswds.min.css.map
│ ├── uswds.min.css
│ └── uswds.css
├── fonts/
├── img/
├── js/
│ ├── uswds-init.js
│ ├── uswds-init.min.js
│ ├── uswds-init.min.js.map
│ ├── uswds.min.js.map
│ ├── uswds.min.js
│ └── uswds.js
├── scss/
└── theme/
The three files critical to any USWDS project are the stylesheet, the library, and the intializer. Any project requires both the stylesheet and library to function properly.
Stylesheet: This is the compiled CSS stylesheet that describes how design system components look. Reference either uswds.css or uswds.min.css in the <head> of your document.
Library: This is the compiled JavaScript that controls component interactivity. Reference either uswds.js or uswds.min.js at the end of the <body> of your document.
Initializer: This small JavaScript file (less than 1 KB minified) helps the browser know if the USWDS JavaScript library is loading properly. This prevents component content from "flashing" or "shifting" while the page loads. Reference uswds-init.min.js in the <head> of your page, or inline its contents directly into the <script> tag.
Copy these files and folders into a relevant place in your project's code base. Here is an example structure for how this might look:
example-project/
├── assets/
│ ├── uswds-3.0.0/
│ ├── stylesheets/
│ ├── images/
│ └── javascript/
└── index.html
You'll notice in our example above that we also outline a stylesheets, images and javascript folder in your assets folder. These folders are to help organize any assets that are unique to your project and separate from the design system assets.
Reference the stylesheet, library, and initializer in each HTML page or dynamic template in your project. We also provide Sass (.scss) files in the zip package which you should use to generate new CSS with project-specific settings. See Sass and theme settings for more information.
Here is an example of how to reference these assets in your index.html file:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<title>My Example Project</title>
<script src="assets/uswds-3.0.0/js/uswds-init.min.js"></script>
<link rel="stylesheet" href="assets/uswds-3.0.0/css/uswds.min.css" />
</head>
<body>
<script src="assets/uswds-3.0.0/js/uswds.min.js"></script>
</body>
</html>
We offer both the CSS and the JavaScript in two versions — minified and un-minified. (In the examples above, we are using the minified files.) Use the minified files in a production environment or to reduce the file size of your downloaded assets. Use the un-minified files if you are in a development environment or would like to debug the CSS or JavaScript assets in the browser.
And that’s it — you should now be able to copy our code samples into your index.html and start using the design system.
npm is a package manager for Node-based projects. USWDS maintains the @uswds/uswds package that includes both the pre-compiled and compiled files — just like the direct download. npm packages make it easy to update and install the design system from the command line.
Install Node/npm. Below is a link to find the install method that coincides with your operating system:
Note for Windows users: If you are using Windows and are unfamiliar with Node or npm, we recommend following Team Treehouse's tutorial for more information.
Make sure you have installed it correctly:
npm -v
6.13.0 # This line may vary depending on what version of Node you've installed.
Create a package.json file. You can do this manually, but an easier method is to use the npm init command. This command will prompt you with a few questions to create your package.json file.
Add @uswds/uswds to your project’s package.json:
npm install --save @uswds/uswds@latest
The @uswds/uswds module is now installed as a dependency. You can use the compiled files found in the node_modules/@uswds/uswds/dist/ directory or the source files in the node_modules/@uswds/uswds/packages/ directory.
node_modules/uswds/
├── dist/
│ ├── css/
│ ├── fonts/
│ ├── img/
│ ├── js/
│ └── scss/
├── packages/
│ ├── _usa-password/
│ ├── templates/
│ ├── usa-accordion/
│ │ ├── src/
│ │ │ ├── content/
│ │ │ ├── styles/
│ │ │ ├── test/
│ │ │ ├── index.js
│ │ │ ├── usa-accordion.stories.js
│ │ │ └── usa-accordion.twig
│ │ └── _index.scss_/
│ ├── usa-add-aspect/
│ ├── usa-alert/
│ ├── usa-banner/
│ ├── usa-breadcrumb/
│ ...
Note: We do not recommend directly editing the design system files in node_modules. One of the benefits of using a package manager is its ease of upgrade and installation. If you make customizations to the files in the package, any upgrade or re-installation will wipe them out.
If you want to take full advantage of USWDS custom settings and add build new styles and components with the USWDS toolset, you'll need a way to access the assets in the USWDS package and compile custom CSS from the USWDS source files.
USWDS uses the task manager Gulp as a way to add USWDS assets to a project and compile our CSS from the package source. Gulp is a useful and powerful tool, but it can be difficult to set up if you are new to it.
The uswds-compile repo is made for developers new to Gulp or those who just want a simple setup to compile USWDS Sass. The repo contains files and instructions for setting up the compiler, initializing USWDS, and compiling CSS from the source files.
The design system is customizable using the power of Sass (Syntactically Awesome Style Sheets). The critical files you'll need in your project are those in dist/scss/theme:
scss
├── components/
├── core/
├── elements/
├── lib/
├── packages/
├── settings/
├── theme/
│ ├── _uswds-theme.scss
│ ├── _uswds-theme-custom-styles.scss
│ ├── styles.scss
_uswds-theme.scss: custom theme settings_uswds-theme-custom-styles.scss: additional project CSS for customizing or adding to what USWDS providesstyles.scss: The Sass entry point. This is the primary Sass file that you'll compile. It collects theme settings, USWDS source files, and custom CSSstyles.scss looks something like the following code. It adds all the project theme settings, then adds USWDS source, and finally adds your project's custom styles:
@forward "uswds-theme";
@forward "uswds";
@forward "uswds-theme-custom-styles";
Technical note: The @forward 'uswds' statement above references the uswds package in node_modules/@uswds/uswds/packages. The compile functions included in uswds-compile automatically look for USWDS packages in the proper directory using includePaths.
The design system requires autoprefixing to work properly. This is included in the uswds-compile package.
Autoprefixing uses a service like gulp-autoprefixer to automatically add vendor prefixes to the precompiled stylesheets. Don't add vendor prefixes to your custom styles manually — it is more reliable to use autoprefixing. We use the following autoprefixer settings via .browserslistrc config:
> 2%
last 2 versions
IE 11
not dead
We recommend using a minifier like csso to compress your final compiled CSS and sourcemaps like gulp-sourcemaps to keep track of the location of all the source Sass for easier debugging.
require('uswds') will load all of USWDS’s JavaScript onto the page. Add this line to whatever initializer you use to load JavaScript into your application.
If you’re using another framework or package manager that doesn’t support npm, you can find the source files in this repository and use them in your project. Otherwise, we recommend that you follow the download instructions. Please note that the core team isn’t responsible for all frameworks’ implementations.
If you’re interested in maintaining a package that helps us distribute USWDS, the project’s build system can help you create distribution bundles to use in your project. Please read our contributing guidelines to locally build distributions for your framework or package manager.
usa (For example: .usa-button). This identifier helps the design system avoid conflicts with other styles on a site which are not part of USWDS.__). Multi-word blocks use single hyphens instead of spaces. Modifier classes are additive — proper markup requires the base class and the modifier class or classes. Modifier classes consist of the base class plus a modifier suffix, separated by two hyphens (--) as in .usa-button.usa-button--secondary or usa-accordion.usa-accordion--bordered.units() function as described in the USWDS 2.0 documentation. In general, we use spacing in multiples of 8px — expressed as a multiple in units([multiple]). For instance units(2) is the equivalent of 2 * 8px or 16px. In the final, compiled CSS, this value will be expressed in rem, as a multiple of the base font size set with $theme-base-font-size.For more information, visit: 18F’s CSS Guide
Unfortunately, customizing the JavaScript for the USWDS currently requires NodeJS and a module bundler like Browserify or Webpack. We apologize for this inconvenience, and are working to resolve it in a future release of the design system.
USWDS JavaScript is separated into components (just as with the CSS and HTML) and initialized with event handlers when the DOM is ready. These components are accessible as CommonJS modules that can be required in other JavaScript files, then built for the browser. The components are not accessible in the global browser scope, but can be extended to be included by requiring components and setting it to a global scope:
window.uswds = require("./components");
Each component has a standardized interface that can be used to extend it further. The components store a HTML class (like .usa-accordion__button[aria-controls]) used to link HTML elements with the JavaScript component. When a component is initialized, it searches through the current HTML DOM to find all elements that match the class and initializes the component JavaScript for those elements. The primary methods for each component include:
on: Initialize a component's JavaScript behavior by passing the root element, such as window.document.off: The opposite of on, de-initializes a component, removing any JavaScript event handlers on the component.hide: Hide the whole component.show: Shows a whole, hidden component.toggle: Toggles the visibility of a component on and off based on the previous state.Some components have additional methods based on that component's functionality. Any additional methods are found in that component's JavaScript file.
If you’re using a modern framework like React or Angular you can import components and initialize them in your library's DOM ready lifecycle event.
Importing a modular component.
import USWDS from "@uswds/uswds/src/js";
const { characterCount, accordion } = USWDS; // deconstruct your components here
// Alternatively
import accordion from "@uswds/uswds/js/usa-accordion";
⚠️Requires webpack 5+
React hooks example:
function App() {
const ref = document.body;
useEffect(() => {
// initialize
characterCount.on(ref);
// default ref is document.body, if you want to use
// default you do not have to pass arguments
accordion.on();
// remove event listeners when component un-mounts.
return () => {
characterCount.off();
accordion.off();
};
});
}
Angular example:
export class App implements OnInit {
constructor() {
this.ref = document.body;
// default ref is document.body, if you want to use
// default you do not have to pass arguments
}
ngOnInit() {
// initialize
characterCount.on(this.ref);
accordion.on();
}
// remove event listeners when component un-mounts.
ngOnDestroy() {
characterCount.off();
accordion.off();
}
}
USWDS 2.0 provides extensive support for theming via its theme settings files introduced in Sass and theme settings, above.
Set theme settings with USWDS design tokens, not with values directly. They tend to be quoted strings like 'desktop' or 'md' or unitless numbers like 2 or -1.5. Tokens are the values passed into the USWDS functions and mixins that parse them. They are the keys that, through the mechanism of a function or mixin, unlock a value — they are not the values themselves.
Visit the Design tokens section of USWDS 2.0 documentation for more on the available tokens for color, spacing units, font size, and more.
The following is an example of theme settings from _uswds-theme.scss:
@use "uswds-core" with (
$theme-site-max-width: "desktop",
$theme-site-margins-breakpoint: "desktop",
$theme-site-margins-width: 4,
$theme-site-margins-mobile-width: 2,
)
The USWDS uses those tokens to build component styles:
.usa-example {
@include u-padding-x($theme-site-margins-mobile-width);
max-width: units($theme-site-max-width);
@include at-media($theme-site-margins-breakpoint) {
@include u-padding-x($theme-site-margins-width);
}
}
This is the functional equivalent of:
.usa-example {
@include u-padding-x(2);
max-width: units("desktop");
@include at-media("desktop") {
@include u-padding-x(4);
}
}
Which, if $theme-respect-user-font-size is set to true would output something like:
.usa-example {
padding-left: 1rem;
padding-right: 1rem;
max-width: 64rem;
}
@media screen and (min-width: 64em) {
.usa-example {
padding-left: 2rem;
padding-right: 2rem;
}
}
In general, USWDS sets variables with tokens, and passes those variables into functions and mixins in the source Sass.
The values of $theme-font-path and $theme-image-path will be appended to USWDS font paths and image paths, respectively:
@use "uswds-core" with (
$theme-font-path: "../fonts",
$theme-image-path: "../img",
);
As of USWDS 3.0.0, our codebase is centered around funtional packages, typically components. For more about how we organize packages, see our Packages documentation. In each of the following examples, we use [package] to represent a specific package. For example, component Sass is located in packages/[package]/src/styles for an accordion, this would be packages/usa-accordion/src/styles.
packages/[package]/src/[package.twig] in the site root. These, however, are written in the templating language Twig. It's best to get HTML source markup directly from designsystem.digital.gov/componentspackages/[package]/src/styles. Many components also have a component entry point at packages/[package]/_index.scss that includes references to all a component's dependencies as well. Compiled CSS is located in dist/css.packages/[package]/src/index.js. General JavaScript utilities and polyfills are located in the uswds-core package: packages/uswds-core/src/jsdist/fonts and packages/uswds-core/src/assets/fonts. The fonts in dist are simply a copy of the files in uswds-core.dist/img. The source for component-specific images can be found in a package's src/img directory.We’ve designed the design system to support older and newer browsers through progressive enhancement. The current major version of the design system (3.0.0) follows the 2% rule: we officially support any browser above 2% usage as observed by analytics.usa.gov. Currently, this means that the design system version 3.0.0 supports the newest versions of Chrome, Firefox, and Safari.
As of USWDS 3.0.0 we no longer officially support Internet Explorer 11 (IE11). We will continue to include IE11 polyfills and prefixing for the first few releases in USWDS 3.x — when we finally drop IE11, we'll make a note in the release notes and in this docmentation.
The design system also meets the WCAG 2.0 AA accessibility guidelines and conforms to the standards of Section 508 of the Rehabilitation Act.
We use the following tools to ensure USWDS is accessible:
We’re happy to answer questions about accessibility — email us for more information.
We're using StorybookJS to generate an interactive component library for the design system. You can run it locally after npm install with:
npm start
Then, visit http://localhost:6006/ to see the design system in action. It will watch for changes in twig, scss, and JS and refresh.
Version 1.x is no longer maintained.
Version 2.x is in maintenance mode and will continue to get important bugfixes and security patches until May 2023.
Do you have questions or need help with setup? Did you run into any weird errors while following these instructions? Feel free to open an issue here:
https://github.com/uswds/uswds/issues.
You can also email us directly at uswds@gsa.gov.
For complete instructions on how to contribute code, please read CONTRIBUTING.md. These instructions also include guidance on how to set up your own copy of the design system style guide website for development.
If you would like to learn more about our workflow process, check out the Workflow and Issue label Glossary pages on the wiki.
If you have questions or concerns about our contributing workflow, please contact us by filing a GitHub issue or emailing our team.
Much of the guidance in USWDS leans on open source designs, code, and patterns from other civic and government organizations, including:
A few parts of this project are not in the public domain. Attribution and licensing information for those parts are described in detail in LICENSE.md.
The rest of this project is in the worldwide public domain, released under the CC0 1.0 Universal public domain dedication.
All contributions to this project will be released under the CC0 dedication alongside the public domain portions of this project. For more information, see CONTRIBUTING.md.
FAQs
Open source UI components and visual style guide for U.S. government websites
The npm package @uswds/uswds receives a total of 24,684 weekly downloads. As such, @uswds/uswds popularity was classified as popular.
We found that @uswds/uswds demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.
Research
Security News
A threat actor's playbook for exploiting the npm ecosystem was exposed on the dark web, detailing how to build a blockchain-powered botnet.