{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "event",
    "type" : "single",
    "title" : "USWDS Monthly Call - January 2023 |Digital.gov",
    "description": "USWDS Monthly Call - January 2023",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2023/01/19/uswds-monthly-call-january-2023/index.json","item" : [
    {"kicker" : "USWDS","title" :"USWDS Monthly Call - January 2023","deck" : "Answering your most-asked questions about the U.S. Web Design System","summary" : "Join the Design System team as we tackle your most commonly-asked questions.","date" : "2023-01-19T14:00:00-05:00","date_modified" : "2025-01-27T19:42:55-05:00","start_date" : "2023-01-19T14:00:00-05:00","end_date" : "2023-01-19T15:00:00-05:00",
      "event_organizer" : "Digital.gov","host" : "U.S. Web Design System","registration_url" : "https://gsa.zoomgov.com/meeting/register/vJItceqrrDsuEhxA7eoRggB3Cf4RRjcrMjU","captions" : "https://www.streamtext.net/player?event=BIS-GSA-JY","youtube_id" : "JApBVTwZans","topics" : {
        
            "open-source" : "Open source",
            "usability" : "Usability"
            },"primary_image" : { "uid" : "2023-uswds-monthly-call-jan-title-card", "alt" :
  "Title card image of USWDS logo, a multi-colored pentagon shape consisting of five triangles, centered on a black background. In white text, the first line says, USWDS Monthly Call. Below that in yellow text, the second line has the date of the event, January 19, 2023.", "width" :
  "1200", "height" :
  "628", "credit" :
  "", "caption" :
  "", "format" :
  "png" },"content" :"\n\u003ca\n    href=\"https://s3.amazonaws.com/digitalgov/static/uswds-monthly-call-january-2023.pptx\"\u003eView the slides (PowerPoint presentation, 1.9 MB, 60 pages)\u003c/a\u003e\n\n\n\u003cdiv class=\"usa-accordion accordion\"\u003e\u003ch3 class=\"usa-accordion__heading\"\u003e\n    \u003cbutton\n      class=\"usa-accordion__button\"\n      title=\"View \"\n      aria-expanded=\"false\"\n      aria-controls=\"accordion-1\"\n    \u003e\n      \u003cspan class=\"icon\"\u003e\n          \u003csvg\n            class=\"usa-icon dg-icon dg-icon--standard margin-bottom-05\"\n            aria-hidden=\"true\"\n            focusable=\"false\"\n          \u003e\n            \n            \u003cuse xlink:href=\"/preview/gsa/digitalgov.gov/bc-archive-content-3/uswds/img/sprite.svg#content_copy\"\u003e\u003c/use\u003e\n          \u003c/svg\u003e\n        \u003c/span\u003e\u003cspan class=\"src\"\u003e\n        \u003cstrong class=\"kicker\"\u003eSlide by Slide\u003c/strong\u003eUSWDS Monthly Call - Presentation Script for January 2023\n        \u003c/span\n      \u003e\n    \u003c/button\u003e\n  \u003c/h3\u003e\u003cdiv\n      id=\"accordion-1\"\n      class=\"accordion-body usa-accordion__content usa-prose\"\n    \u003e\u003cp\u003e\u003cstrong\u003eSlide 1:\u003c/strong\u003e Hi there and welcome to the U.S. Web Design System monthly call.\u003c/p\u003e\n\u003cp\u003eFor January 2023. It\u0026rsquo;s the start of a new year, month one. So this month, we\u0026rsquo;ve turned every triangle but one gray. Here we go again!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 2:\u003c/strong\u003e My name is Dan Williams, he/him, and I\u0026rsquo;m the USWDS product lead — and this is my avatar: dark hair, blue sweater, collared shirt. I\u0026rsquo;d also like to mention that when we introduce ourselves in these calls, you\u0026rsquo;ll hear things like self-descriptions and pronouns — these help everyone share the same context and know a bit more about who we are, whether or not you can see us. For instance, today, real me has dark hair and a fuzzy fleece.\u003c/p\u003e\n\u003cp\u003eFirst, I\u0026rsquo;d like to mention that we\u0026rsquo;re recording this monthly call, so please refrain from turning on your camera. We will manually turn off any cameras to ensure the recording doesn\u0026rsquo;t show us on camera. Unfortunately, while we are recording this call, we currently aren\u0026rsquo;t able to share the video publicly.\u003c/p\u003e\n\u003cp\u003eI’d also like to remind you that by voluntarily attending this Digital.gov event, you agree to abide by Digital.gov’s community guidelines at \u003ca href=\"https://digital.gov/communities/community-guidelines/\"\u003edigital.gov/communities/community-guidelines/\u003c/a\u003e you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat.\u003c/p\u003e\n\u003cp\u003eIf you are in the Zoom app, you can use integrated live captioning by selecting the “CC” button on the bottom of the screen. If you prefer live captioning in a separate window, we\u0026rsquo;ve posted a link to the live captioning in the chat.\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ll be posting other links and references into the chat as we go along, and I encourage you to ask questions in the chat at any time. If any member of our team can answer your question in the chat, we\u0026rsquo;ll do so, otherwise there\u0026rsquo;ll be some time for questions and answers at the end of the hour. Also, be sure to introduce yourself in the chat as well — it\u0026rsquo;s nice to know who\u0026rsquo;s here. It\u0026rsquo;s good to have you here today.\u003c/p\u003e\n\u003cp\u003eFor those of you who find the chat distracting, you’re welcome to close or hide the chat window during the main presentation. You can reopen it later during the Q\u0026amp;A session at the end of this call.\u003c/p\u003e\n\u003cp\u003eSo thanks! And, with that, let\u0026rsquo;s get started!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 3:\u003c/strong\u003e So what\u0026rsquo;s our agenda for today? Well this month we\u0026rsquo;re trying to answer some of the questions we\u0026rsquo;re asked most frequently here at the design system. Here\u0026rsquo;s what we hope to cover, getting progressively more technical as we get further into the call!\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eHow we approach component testing\u003c/li\u003e\n\u003cli\u003eWhat\u0026rsquo;s up with the Tabs component?\u003c/li\u003e\n\u003cli\u003eDesign kits: what platforms do we support and when do we update them?\u003c/li\u003e\n\u003cli\u003eTheming USWDS\u003c/li\u003e\n\u003cli\u003eCustom fonts and colors\u003c/li\u003e\n\u003cli\u003eHow do I prevent the flash of banner content on page load?\u003c/li\u003e\n\u003cli\u003eUSWDS in other popular frameworks\u003c/li\u003e\n\u003cli\u003eand\u0026hellip; Importing USWDS component JavaScript\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnd if all goes well, we should have time for more of your questions today! So let\u0026rsquo;s get started!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 4:\u003c/strong\u003e I\u0026rsquo;d like to introduce a couple members of the USWDS core team, who\u0026rsquo;ll be helping answer some of these questions. First, James Mejia, a contractor and an engineer. James, do you want to say hi and describe yourself for anyone audio-only?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 5:\u003c/strong\u003e Next, I\u0026rsquo;d like to introduce Amy Leadem, a contractor and a front-end developer. Amy, so you want to say hi and describe yourself for anyone audio-only?\u003c/p\u003e\n\u003cp\u003eAbsolutely. Hello everyone! My name is Amy Leadem and I have long brown wavy hair, dark brown eyes, and today I am wearing a cozy, rust colored sweater.\u003c/p\u003e\n\u003cp\u003eThanks Amy. I\u0026rsquo;m glad to have both you and James here with me today!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 6:\u003c/strong\u003e Today, we\u0026rsquo;re kicking off the year by trying to answer a few common questions we get from folks that use the design system. In each of these cases, the question is a signal to us that we need to do a better job delivering the answers on our website, in our documentation, in our code, or in these monthly calls — or all of these things. We\u0026rsquo;ve started taking steps to improve our documentation for many of these questions, and these questions will also be top of mind as we perform our Top Tasks research over the next month. We\u0026rsquo;re always trying to improve our documentation and how we talk about what we do. Your questions and your feedback drives our development. So, while we\u0026rsquo;ll do our best with today\u0026rsquo;s USWDS FAQ, to answer these frequently asked questions, keep asking. Here we go!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 7:\u003c/strong\u003e \u003cstrong\u003eFirst, do we test components with real users before releasing?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 8:\u003c/strong\u003e So, the answer here is yes and no. There are a few things that we always do when it comes to testing our components. There are a few things that we\u0026rsquo;ve started to do more recently, and there are some plans that we have for the near future. When it comes to getting the most comprehensive view of our component usability, we can always do better.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 9:\u003c/strong\u003e We always do a thorough internal review that includes manual accessibility testing across browsers and screen readers. Any component we release has been through a landscape analysis, live prototyping, and is most often drawn from existing government and non-government solutions. We favor proven solutions from government services.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 10:\u003c/strong\u003e We also circulate our guidance and code to our USWDS Public Slack channel for public feedback and review from developers and our community before we release a component.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 11:\u003c/strong\u003e We\u0026rsquo;ve also started adding testing with real users of assistive technology. We added this level of testing as a part of our inclusive patterns project.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 12:\u003c/strong\u003e And what we\u0026rsquo;ve learned from starting this level of testing is that it\u0026rsquo;s extremely valuable, and it\u0026rsquo;s not replaceable. This level of testing allows our team to be more proactive, and especially when it comes to assistive technology, it helps us to better understand the expectations and conventions of real-world users — and how those expectations and conventions differ from manual accessibility testing and conformance with accessibility standards. It\u0026rsquo;s helped us understand that while conformance with standards is critically important and a key heuristic when it comes to usability, it doesn\u0026rsquo;t typically tell the whole story.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 13:\u003c/strong\u003e Since the beginning of the design system, we\u0026rsquo;ve relied on a reactive strategy for continuous improvement of our code, guidance, and components. And the way that it works is that we provide a baseline of testing for what we release, and we always respond to issues in our code repo — which is another way of saying that we rely on downstream usability testing from teams that use the design system to help us fill in the blanks and understand how our components are performing in the real world. This is also critically important. We don\u0026rsquo;t typically have insight into how teams are using the design system. We\u0026rsquo;re not building the applications. We\u0026rsquo;re not directly exposed to your audiences. And occasionally, we miss things that subsequent testing reveals. As an example, we heard from an issue in our repo that some screen reader users were misinterpreting the vocalization of our banner text, hearing \u0026ldquo;An official website\u0026rdquo; as \u0026ldquo;Unofficial website\u0026rdquo;. This was something our own testing hadn\u0026rsquo;t revealed, and we were able to update the vocalized text in the banner to remove the ambiguity.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 14:\u003c/strong\u003e We depend on our users and the community to be reactive, and that feedback is always going to be important. Knowing what you\u0026rsquo;ve found from your own tests and experiments will continue to drive the design system forward. But we need to be more proactive as well. Testing with real users on the design system side needs to be an ongoing part of a component’s lifecycle. Not only before release, but after release as well. A component\u0026rsquo;s lifecycle doesn\u0026rsquo;t end at release, so we\u0026rsquo;re working to better operationalize real-world testing before and after release.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 15:\u003c/strong\u003e Figuring this out is tough. We\u0026rsquo;re a small team and it\u0026rsquo;s always a balance. Next month, we\u0026rsquo;ll release our short-term roadmap for the next four months. On it, you\u0026rsquo;ll see a few things we\u0026rsquo;ve talked about here and we\u0026rsquo;ll also mention later in the call: including operationalizing accessibility-first usability testing with real users, codifying and publishing a component acceptance criteria checklist, and connecting that checklist to a public component lifecycle model. Between these three items, we\u0026rsquo;ll be able to be more proactive and more transparent.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 16:\u003c/strong\u003e As I said, we\u0026rsquo;ll publish the updates to our short-term roadmap next month. We\u0026rsquo;ll hear more about it in this call, and we\u0026rsquo;ll be talking about it throughout the year.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 17:\u003c/strong\u003e \u003cstrong\u003eOur next frequently asked question is \u0026ldquo;What\u0026rsquo;s going on with Tabs\u0026rdquo;?\u003c/strong\u003e So, if you\u0026rsquo;ve been active in our public Slack or following along on the pull requests in our repo, you may have noticed that we had a large contribution of a Tabs component. But it\u0026rsquo;s been a bit like a package sitting on the porch that\u0026rsquo;s too big to fit through the front door. What\u0026rsquo;s happening with this pull request?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 18:\u003c/strong\u003e And what getting a big PR like this has meant is that we need to design a repeatable process to do something with it, and that\u0026rsquo;s going slowly.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 19:\u003c/strong\u003e It\u0026rsquo;s also a bit like that Carl Sagan quote about apple pie that\u0026rsquo;s a favorite of mine: \u0026ldquo;If you wish to make an apple pie from scratch, you must first invent the universe.\u0026rdquo; In this case, realizing that as much as we\u0026rsquo;ve been interested in public contributions like this, we\u0026rsquo;d never actually gotten one. And once we did, we had the real practicality of it, needing to step back and understand really what\u0026rsquo;s required to consider a component for inclusion in the design system. And keep stepping back until we have a good starting place.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 20:\u003c/strong\u003e And that starting place is a process that\u0026rsquo;s fair, practical, and repeatable. We want what we do here to be a model for what we do in the future. And we want to be sure we\u0026rsquo;re setting a standard that\u0026rsquo;s appropriate for both internal work and contributions from the public.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 21:\u003c/strong\u003e I\u0026rsquo;ve referred to elements of that process earlier, when I was talking about usability testing. And one of the key elements of that process is a common component acceptance criteria checklist. Understanding, codifying, and publishing our requirements for publishing any component.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 22:\u003c/strong\u003e The second is a component lifecycle model that connects phases of a component\u0026rsquo;s iterative development to elements of its acceptance criteria. This means making is clear what it means for a component to be in phases like under consideration, in development, experimental, in-use, or deprecated — stuff like that — and what it takes to move from one phase to another.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 23:\u003c/strong\u003e And finally, how all of this works alongside pattern-first development. Starting with real user needs to understand how any component supports real-world interactions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 24:\u003c/strong\u003e So when it comes to Tabs, the proposal uncovered the places where our process needed work. We\u0026rsquo;ve been able to elevate those process improvements into upcoming roadmap items, so we\u0026rsquo;re ready to start moving forward with deliberation. We appreciate your patience here, as do what we need to do to be fair, practical, and repeatable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 25:\u003c/strong\u003e \u003cstrong\u003eNext up: When will the design kit be updated?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 26:\u003c/strong\u003e Basically, we update the design kit (otherwise known as our Sketch and Adobe XD assets) after every USWDS release that has a design change, like a visual change to a component or a change to a color. Because of the realities of our production cycle, it often follows about a month behind the USWDS release. So, because we didn\u0026rsquo;t make any visual updates to the design system with USWDS 3.0, we didn\u0026rsquo;t publish a new version of the design kit. We did however, add some new components in the last USWDS release, USWDS 3.3.0, and we\u0026rsquo;re in the process of finalizing the design kit for that release now. The holidays slowed down our progress, but the newest components should be available by the end of the month.\u003c/p\u003e\n\u003cp\u003eNow this isn\u0026rsquo;t the only time we update the design kit — at a minimum we\u0026rsquo;ll update it when there\u0026rsquo;s a design change in the USWDS codebase, but there may be more releases if we find a bug or an inconsistency in the design kit as well. In general, though, the design kit has far fewer releases than the USWDS code.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 27:\u003c/strong\u003e Relatedly, while we\u0026rsquo;ve supported Sketch and Adobe XD in our design kit for the last few years, we know that those aren\u0026rsquo;t the only tools that design teams use. This year, we\u0026rsquo;re adding Figma support to our short term roadmap. There are community implementations that we\u0026rsquo;ve linked to from our documentation site and our repo,that you can use in the interim, but we now have USWDS in Figma planned.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 28:\u003c/strong\u003e So look for a component release to the existing design assets later this month, and a Figma design kit coming later this spring. You can find the USWDS design kit at \u003ca href=\"http://github.com/uswds/uswds-for-designers\"\u003egithub.com/uswds/uswds-for-designers\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 29:\u003c/strong\u003e \u003cstrong\u003eRelatedly, Are you allowed to change how USWDS looks?\u003c/strong\u003e That is, are teams able to customize USWDS and adapt it to their own project needs and tone?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 30:\u003c/strong\u003e The simple answer is yes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 31:\u003c/strong\u003e USWDS is designed for designers, and meant to be a tool for designers — a way to support human centered design by giving teams a common starting point and a common design language for their design choices. From our perspective, it\u0026rsquo;s less about making changes and more about how and why you\u0026rsquo;re making those changes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 32:\u003c/strong\u003e We want teams to build faster, test faster, and make decisions faster\u0026hellip;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 33:\u003c/strong\u003e Which is why our advice is always to start with our defaults and customize with tokens. Build faster and test faster by changing as little as possible at first. Understand key interactions and flows. Work on your content. But brand, tone, and design do matter — and there can be a good case for adapting our defaults for your specific audience. What we ask is that when you do change how USWDS looks, that you use our design language of tokens. If you want to change from blue to green, use the USWDS green system tokens in your design. If you want to make the text bigger, use our font-size tokens. And use spacing tokens instead of hardcoded px, em, or rem in your stylesheets. All of this assures a baseline continuity between design system projects.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 34:\u003c/strong\u003e We believe in experimentation. And we believe that experimentation drives adaptation. Every project is an ongoing experiment, and as you experiment and learn, we want that learning to be reflected in the design system itself.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 35:\u003c/strong\u003e And that\u0026rsquo;s why feedback and community is critical to the health and success of the design system. We want to know what you find. If there\u0026rsquo;s an opportunity to improve something for every user of the design system, we want to know about it. So find good solutions for your audience, and let us know what you find.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 36:\u003c/strong\u003e \u003cstrong\u003eSo, how do you set custom fonts and colors in USWDS?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 37:\u003c/strong\u003e Well, we\u0026rsquo;ve got a setting for that. And to talk more about these settings and tokens, I\u0026rsquo;d like to pass it over to Amy.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 38:\u003c/strong\u003e Thanks, Dan. And hello again, this is Amy speaking. We recommend using standard USWDS tokens whenever possible, but we understand that sometimes customizations \u003cem\u003eneed\u003c/em\u003e to be made to fit project needs. The Design System is built with these needs in mind and can accommodate both custom colors and fonts.\nThe solutions and considerations are a bit different for each type of customization – so to start – we’ll talk about colors.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 39:\u003c/strong\u003e \u003cstrong\u003eUSWDS color tokens\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eUSWDS comes with a suite of hundreds of curated color tokens in 25 color families and vivid variants.\u003c/p\u003e\n\u003cp\u003eWe call these colors – like red-50 and blue-cool-50-V – \u003ca href=\"https://designsystem.digital.gov/design-tokens/color/system-tokens/\"\u003esystem tokens\u003c/a\u003e. On this slide, we see a color wheel showing the USWDS system color tokens. System tokens give everyone who uses the Design system a broad color palette that enables teams to customize the look and feel of their project while still maintaining a common color language.\u003c/p\u003e\n\u003cp\u003eThese system tokens are not editable — the value of a system color like red-50 will be the same in any USWDS installation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 40:\u003c/strong\u003e Theming USWDS means editing the values of a \u003cem\u003edifferent\u003c/em\u003e set of color tokens: \u003ca href=\"https://designsystem.digital.gov/design-tokens/color/theme-tokens/\"\u003etheme tokens\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eTheme tokens are the colors we actually use in our component stylesheets. They\u0026rsquo;re type-based, where BASE is used primarily for text, PRIMARY is for your project primary colors, SECONDARY is the secondary color, and so on.\u003c/p\u003e\n\u003cp\u003eThis slide shows an example of theme tokens, which include the families \u003cstrong\u003ebase, primary\u003c/strong\u003e, \u003cstrong\u003esecondary\u003c/strong\u003e, \u003cstrong\u003eaccent-cool\u003c/strong\u003e, and \u003cstrong\u003eaccent-warm\u003c/strong\u003e, in a range of brightness from darkest to lightest.\u003c/p\u003e\n\u003cp\u003eTheme color tokens – like primary-dark – are meant to accept system color tokens – like blue-60. This means that when you use the \u003cstrong\u003eprimary-dark\u003c/strong\u003e color token in your style rules, the system outputs the color \u003cstrong\u003eblue-60\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eTeams are meant to update their project settings and customize their theme tokens. And while theme tokens are meant to accept system tokens, we understand that there will be times when your project must adhere to strict color schemes and use a non-USWDS color in order to be compliant. The Design System is built to handle that.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 41:\u003c/strong\u003e \u003cstrong\u003eAdding custom colors via settings\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe best method for adding custom colors to your project is to edit the values of your theme color variables in your \u003ca href=\"https://designsystem.digital.gov/documentation/settings/#configuring-custom-uswds-settings\"\u003esettings configuration\u003c/a\u003e. In this example, we show how you can edit the values for the theme-color-primary theme tokens. While these are meant to receive system colors like \u003cstrong\u003egold-40v\u003c/strong\u003e, you can see we\u0026rsquo;ve given the primary-vivid token a custom hex color: #F5CA55.\u003c/p\u003e\n\u003cp\u003eNow, whenever you want to use this custom hex color, you simply reference the “primary-vivid” token inside the color function.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 42:\u003c/strong\u003e When you customize your colors in this way — through settings variables — you get the added bonus of running your color through the Design System’s accessibility checks. Behind the scenes, the Design System checks to see if your color has the required contrast level to be accessible, and will send a warning if it is not.\u003c/p\u003e\n\u003cp\u003eIn contrast, if you were to add your hex value directly into a custom Sass rule, none of these checks will happen. This means that accessibility checks would be your responsibility entirely. For this reason, we recommend always adding colors via your settings configuration.\u003c/p\u003e\n\u003cp\u003eAnd that’s it for adding a custom color. Let’s move on to fonts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 43:\u003c/strong\u003e Out of the box, USWDS provides and supports 10 different \u003ca href=\"https://designsystem.digital.gov/design-tokens/typesetting/font-family/\"\u003efont families\u003c/a\u003e. We provide these as a recommended set, but the system also has the capacity to accept new fonts.\u003c/p\u003e\n\u003cp\u003eWe’ll go through two typical scenarios for adding a custom font. The first is when you want to add a font that is hosted from a service like Google Fonts or Typekit. The second is when you want to add a self-hosted font.\u003c/p\u003e\n\u003cp\u003eToday I’ll give a high-level overview to show what is possible, but we’ll also add a \u003ca href=\"https://designsystem.digital.gov/design-tokens/typesetting/font-family/#adding-fonts-to-uswds\"\u003elink\u003c/a\u003e to our more detailed documentation in the chat for reference.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 44:\u003c/strong\u003e First up: If you want to add a font that is hosted from a service, you’ll need to complete the following steps.\u003c/p\u003e\n\u003cp\u003eFirst, you’ll add a reference to the JavaScript and CSS according to the instructions given by the font hosting service. This is typically done in the head of your HTML files.\u003c/p\u003e\n\u003cp\u003eSecond, you’ll create a new font token in your settings configuration, and then use the new token in your theme. We’ll walk you through these last two steps on the next slide.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 45:\u003c/strong\u003e Creating a new font token is simple. In your USWDS settings configuration, you will need to add information about your new font to the theme-typeface-tokens settings variable.\u003c/p\u003e\n\u003cp\u003eThis example shows that you’ll need to ONE reference the display name and TWO declare which fonts you want in your font stack. In this setting, there is also an opportunity to adjust your font’s cap height, but that is fine to leave for now – we’ll get into that more in just a bit.\u003c/p\u003e\n\u003cp\u003eOnce you have your new token, you’ll need to assign its value to its related theme setting. In the example, you’ll see that we have assigned Lato to theme-font-type-sans. This means that wherever the system is told to use the “sans” font type, it will use your new Lato token.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 46:\u003c/strong\u003e Alternatively, if you want to host additional fonts in your own project, there are a few more steps to do in addition to creating your own token.\u003c/p\u003e\n\u003cp\u003eYou also need to assign this new token to its font type, and then add custom path information for this font type before using the new font type token in your stylesheet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 47:\u003c/strong\u003e Configuring the theme-font-custom-source settings variable provides the custom path information that lets the system create new font-face rules in your CSS.\u003c/p\u003e\n\u003cp\u003eIn this setting, you will first tell the system where to find the fonts in your project. Second, you’ll specify which weights you want the system to use and third you’ll identify the file name for each font weight. It will look something like this example.\u003c/p\u003e\n\u003cp\u003eNote that there are several theme-font-custom-source settings variables — one for each font type. In the example shown, we configure theme-font-SANS-custom-source to find the Lato font files.\u003c/p\u003e\n\u003cp\u003eIf you self-host your own custom font, you\u0026rsquo;ll need to provide the woff, woff2, and ttf versions of the font for the @font-face rules to build correctly.\u003c/p\u003e\n\u003cp\u003eOnce these font-face rules are created, you can repeat the steps we did in earlier slides to create a new font token and associate the token with your theme.\u003c/p\u003e\n\u003cp\u003eAnd those are the steps for adding a custom font to USWDS! For reference, you can find full instructions on our site. We’ll also throw the \u003ca href=\"https://designsystem.digital.gov/design-tokens/typesetting/font-family/#adding-fonts-to-uswds\"\u003elink\u003c/a\u003e in the chat to make it easier.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 48:\u003c/strong\u003e Before we wrap up the section, I want to note that there are some considerations that should be made when adding fonts to your project.\u003c/p\u003e\n\u003cp\u003eFirst, consider the size and performance footprint. Every weight added is another font file the end-user must download, so minimize the number of weights you use.\u003c/p\u003e\n\u003cp\u003eSecond, we urge you to consider normalizing the size of your font to match the ones included in the Design System. One great feature of USWDS fonts is that they are designed to output a consistent optical size regardless of the typeface.\u003c/p\u003e\n\u003cp\u003eThis is useful because it means that if you ever switch faces, you won’t have to worry about a bunch of layout shifts or code adjustments. Everything is already adjusted to be the same optical height!\u003c/p\u003e\n\u003cp\u003eTo normalize your new font, you’ll simply need to adjust the cap-height when you create your new font token. Once its optical size matches the other USWDS fonts, you’ll be set for font flexibility in the future.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 49:\u003c/strong\u003e \u003cstrong\u003eOur next question is \u0026ldquo;How do I stop the banner from flashing unstyled content?\u0026rdquo;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 50:\u003c/strong\u003e If you use the banner, header, or modal component on your site, there is a chance you noticed that the component will momentarily \u003cem\u003eflash\u003c/em\u003e open for a few milliseconds before closing again as expected. If you experience this on your site, there is an easy fix. You simply need to use uswds-init.js.\u003c/p\u003e\n\u003cp\u003eUSWDS-init is a JavaScript file that checks to see that all page content is loaded before allowing the open content to be visible. This prevents the component from flashing open on the screen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 51:\u003c/strong\u003e Adding it to your project is easy. Just copy the uswds-init.js file into your site’s asset directory from either the \u003cem\u003edist\u003c/em\u003e directory in our downloadable zip file or from the uswds-core package in npm. We’ll also post a \u003ca href=\"https://github.com/uswds/uswds/blob/develop/packages/uswds-core/src/js/uswds-init.js\"\u003elink\u003c/a\u003e to the file in GitHub in the chat.\u003c/p\u003e\n\u003cp\u003eOnce you have added the file to your site, the only thing left to do is reference the USWDS-init in the head of your HTML files.\u003c/p\u003e\n\u003cp\u003eMore information about uswds-init can be found in the \u003ca href=\"https://designsystem.digital.gov/components/banner/#using-the-banner-component\"\u003elink\u003c/a\u003e we’ll provide in the chat.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 52:\u003c/strong\u003e Thanks Amy. This is Dan again. Next I\u0026rsquo;m going to ask James, \u003cstrong\u003eCan I use USWDS with FRAMEWORK NAME HERE, and what I mean there is frameworks, products, or CMSs like Angular, React, or Drupal?\u003c/strong\u003e James, what do you say?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 53:\u003c/strong\u003e Yes, probably. But we don\u0026rsquo;t have direct support. That is, USWDS is framework agnostic. Meaning at the very least you can use it with any framework or platform that lets you add or modify markup, javascript, styles, and assets like fonts or images to reference in code later. But we don\u0026rsquo;t support a native version of USWDS for React, USWDS for Angular, or USWDS for Drupal.\u003c/p\u003e\n\u003cp\u003eIf you\u0026rsquo;re interested in community-supported solutions for any individual framework or project, check out our USWDS \u003ca href=\"https://designsystem.digital.gov/documentation/implementations/\"\u003eImplementations page\u003c/a\u003e before getting started.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 54:\u003c/strong\u003e There aren’t many technical requirements to using USWDS. The recommended requirements to using the design system are:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eNodeJS (LTS version 16)\u003c/strong\u003e: to download the code and stay up-to-date with the design system.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSASS (with load paths)\u003c/strong\u003e: to be able to customize and compile your SASS to CSS successfully.\nWe offer a tool called \u003ca href=\"https://www.npmjs.com/package/@uswds/compile\"\u003eUSWDS/Compile\u003c/a\u003e, available on NPM, that can compile USWDS code with minimal configuration and help you stay up-to-date with the design system.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAutoprefixer\u003c/strong\u003e: for CSS compatibility across all browsers.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAn optional requirement is a javascript bundler if you’re looking to import individual component JS. Keep in mind that USWDS currently uses CommonJS syntax. We have a migration to ES Modules in the works, but ESM support in the NodeJS environment is a little quirky and our work is still in the early stages.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 55:\u003c/strong\u003e \u003cstrong\u003eKnown issues with frameworks.\u003c/strong\u003e We’re doing our best to make sure USWDS works everywhere, but there are always things to improve. For example, some frameworks might require special configuration to get USWDS setup properly.\u003c/p\u003e\n\u003cp\u003eThere are also some interactive components that don\u0026rsquo;t always initialize or behave as expected. Especially in dynamic frameworks.\u003c/p\u003e\n\u003cp\u003eWe’re actively looking for ways to improve this experience and the documentation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 56:\u003c/strong\u003e \u003cstrong\u003eAnd our final question today is \u0026ldquo;How do I import USWDS component JavaScript into my project?\u0026rdquo;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 57:\u003c/strong\u003e I mentioned earlier that USWDS javascript uses the commonJS require syntax for importing scripts. Please keep in mind that you’ll need a bundler in your project. There are two ways to import USWDS javascript.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 58:\u003c/strong\u003e One way is to use the default \u003cstrong\u003eimport\u003c/strong\u003e, which includes all component code, and then destructure, so import USWDS and then extract accordion to later initialize:\u003c/p\u003e\n\u003cp\u003eimport USWDS from “@uswds/uswds/js”;\nconst { accordion } = USWDS;\u003c/p\u003e\n\u003cp\u003eYou can also simply import a single component script by taking advantage of the package exports we’ve defined in package.json. For example:\u003c/p\u003e\n\u003cp\u003eimport accordion from “@uswds/uswds/js/accordion”;\u003c/p\u003e\n\u003cp\u003eThere are also additional entrypoints for sass partials, images, and fonts. Check out the exports object in USWDS’s package.json for the full list.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 59:\u003c/strong\u003e Thank you James. And that\u0026rsquo;s the last of our frequently asked questions. Now let\u0026rsquo;s get to the questions you actually have today.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 60:\u003c/strong\u003e Thanks for joining today’s USWDS monthly call. Next month, we’ll be talking tokens, with a whole call dedicated to learning about design tokens and how we use them in the design system. If you\u0026rsquo;re new to the design system, this can be a good way to learn about one of our most important concepts. Please look out for an event feedback survey from Digital.gov. You\u0026rsquo;ll get this in your email, and there\u0026rsquo;s also a link in the chat. Your feedback makes a difference to us, so we\u0026rsquo;d appreciate the extra time it takes you to provide it.\u003c/p\u003e\n\u003cp\u003eThank you, and see you next month!\u003c/p\u003e\n\u003c/div\u003e\u003c/div\u003e\n\n\u003cp\u003eJoin the Design System team as we tackle your most commonly-asked questions.\u003c/p\u003e\n\u003cp\u003eIn this session, we’ll answer questions like:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCan and should I theme USWDS?\u003c/li\u003e\n\u003cli\u003eWhat\u0026rsquo;s the component testing process?\u003c/li\u003e\n\u003cli\u003eHow do I set custom fonts?\u003c/li\u003e\n\u003cli\u003eHow do I use USWDS with my technology stack?\u003c/li\u003e\n\u003cli\u003eHow do I update my project setup after moving to USWDS 3?\u003c/li\u003e\n\u003cli\u003eWhen should I expect updates to the USWDS design kit?\u003c/li\u003e\n\u003cli\u003eWhen will new components be released?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eThis event is best suited for:\u003c/strong\u003e Designers and developers who use the U.S. Web Design System plus those who are planning to use it.\u003c/p\u003e\n\u003ch2 id=\"speakers\"\u003eSpeakers\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDan Williams -\u003c/strong\u003e Product Lead, USWDS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJames Mejia -\u003c/strong\u003e Engineer, USWDS Contractor\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAmy Leadem -\u003c/strong\u003e Front-End Developer, USWDS Contractor\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cem\u003eThis event is part of a monthly series that takes place on the third Thursday of each month. Don’t forget to set a placeholder on your personal calendar for our future events this year.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"about-the-uswds\"\u003eAbout the USWDS\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://designsystem.digital.gov/\"\u003eThe U.S. Web Design System\u003c/a\u003e is a toolkit of principles, guidance, and code to help government teams design and build accessible, mobile-friendly websites backed by user research and modern best practices.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://designsystem.digital.gov/\"\u003eThe U.S. Web Design System\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/uswds/uswds/issues\"\u003eContribute on GitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"mailto:uswds@support.digitalgov.gov\"\u003eEmail Us\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://digital.gov/communities/uswds/\"\u003eJoin our community\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/uswds\"\u003eFollow @uswds on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n",
      "branch" : "bc-archive-content-3",
      "filename" :"2023-01-05-uswds-monthly-call-january-2023.md",
      
      "filepath" :"events/2023/01/2023-01-05-uswds-monthly-call-january-2023.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/events/2023/01/2023-01-05-uswds-monthly-call-january-2023.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/events/2023/01/2023-01-05-uswds-monthly-call-january-2023.md","slug" : "uswds-monthly-call-january-2023","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2023/01/19/uswds-monthly-call-january-2023/"
    }
  ]
}