{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "event",
    "type" : "single",
    "title" : "USWDS Monthly Call - January 2024 |Digital.gov",
    "description": "USWDS Monthly Call - January 2024",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/01/18/uswds-monthly-call-january-2024/index.json","item" : [
    {"kicker" : "USWDS","title" :"USWDS Monthly Call - January 2024","deck" : "Component-based accessibility tests for the U.S. Web Design System","summary" : "This month the Design System team will talk about the development and rollout of their new accessibility tests for components.","date" : "2024-01-18T14:00:00-05:00","date_modified" : "2025-01-27T19:42:55-05:00","start_date" : "2024-01-18T14:00:00-05:00","end_date" : "2024-01-18T15:00:00-05:00",
      "event_organizer" : "Digital.gov","host" : "U.S. Web Design System","registration_url" : "https://gsa.zoomgov.com/meeting/register/vJIsd-2upjwsHjfq2qWtf_LN9pVV8YV6SX8","youtube_id" : "xP4IWCdzWmA","topics" : {
        
            "accessibility" : "Accessibility",
            "design" : "Design",
            "research" : "Research"
            },"primary_image" : { "uid" : "2024-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 blue text, the first line says, U.S. Web Design System (USWDS). Below in white text, the second line has the event name, USWDS monthly call January 2024. Below in blue text is date followed by the date of the event in white, January 18, 2024. The next line in blue text is Time followed by the time of the event in white, 2:00 pm ET.", "width" :
  "1200", "height" :
  "628", "credit" :
  "", "caption" :
  "", "format" :
  "png" },"content" :"\n\u003ca\n    href=\"https://s3.amazonaws.com/digitalgov/static/uswds-monthly-call-january-2024.pptx\"\u003eView the slides (PowerPoint presentation, 7.8 MB, 87 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 2024\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 Welcome everyone, to the U.S. Web Design System monthly call for for January, 2024 — our first monthly call of the new year, and it kind of feels like it\u0026rsquo;s been forever since the last one, way back in November. Welcome back! On screen we see the USWDS logo in wintery pale whites and blues, with one of the triangles of the logo in green and looking like an evergreen in a snowy landscape.\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 here on-screen is my avatar: dark hair, blue sweater, collared shirt. Today my physical self is wearing a plaid button-down. And since it\u0026rsquo;s cold where I am out on the west coast, I\u0026rsquo;m also wearing a pair of wool socks.\u003c/p\u003e\n\u003cp\u003eAs Jeannie mentioned, we are recording this call, and I\u0026rsquo;m happy to say we\u0026rsquo;ve started to be able to share the recordings of these monthly calls publicly. You can find the last year\u0026rsquo;s worth of monthly calls — back to January 2023 — on our website, at \u003ca href=\"https://designsystem.digital.gov/about/monthly-calls/\"\u003edesignsystem.digital.gov/about/monthly-calls/\u003c/a\u003e. We typically post videos within a week of the monthly call, and we also link out to the slides and the script, hosted at digital.gov. We\u0026rsquo;ve posted a link to our monthly call page 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?\u003c/p\u003e\n\u003cp\u003eWell, we’ve got a site launch, a few product updates, including an update on our roadmap goals, and then we’ll spend the rest of the time talking about launching an important new feature of our site: accessibility tests.\u003c/p\u003e\n\u003cp\u003eWe should also have some time for Q\u0026amp;A at the end of the hour.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 4:\u003c/strong\u003e Let\u0026rsquo;s get into it with site launches.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 5:\u003c/strong\u003e We\u0026rsquo;ve got one nice new site to show today: \u003ca href=\"https://www.mcc.gov/\"\u003eMCC.gov\u003c/a\u003e. A new site for Millennium Challenge Corporation, a Congressional initiative that partners with the world’s poorest countries to invest in their populations and foster just and democratic governance and economic freedom. The home page for MCC.gov includes the gov banner, classic shades of blue, and a prominent hero image that features three circular flag images — Cabo Verde, the Philippines, and Tanzania— with the text “New MCC Grants Announced” in the bottom left of the image.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 6:\u003c/strong\u003e Congratulations and great work! Be sure to let our team know when a new site launches, either with an email or a note on the USWDS public Slack channel!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 7:\u003c/strong\u003e Now for a few product updates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 8:\u003c/strong\u003e First, USWDS 3.8.0, featuring a focus on community PRs. We get a lot of good contributions from the community, and we\u0026rsquo;re happy to publish a number of these contributions in this new release.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 9:\u003c/strong\u003e Key improvements in USWDS 3.8.0 include:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAdding support for sticky headers in tables.\u003c/li\u003e\n\u003cli\u003eBetter text wrapping and alignment in button groups (especially with longer button text).\u003c/li\u003e\n\u003cli\u003eWe\u0026rsquo;re also improving icon alignment in buttons as well.\u003c/li\u003e\n\u003cli\u003eWe\u0026rsquo;re giving teams more control over the headings included in in-page navigation, if you need to be more specific about which heading levels should be pulled into the in-page navigation.\u003c/li\u003e\n\u003cli\u003eWe\u0026rsquo;re also adding contrast checking for disabled elements. Technically disabled or inactive elements don\u0026rsquo;t have the same contrast requirements as active elements, but teams increasingly want to deliver designs that go beyond the requirements, and this release will help teams understand any potential low-contrast elements.\u003c/li\u003e\n\u003cli\u003eAnd finally, indeterminate checkboxes. It turns out there can be three potential states for a checkbox: checked, unchecked, and indeterminate, for when, in a multi-level checklist, a parent checkbox contains child checkboxes in both checked and unchecked states. It\u0026rsquo;s a bit of a complex case, but a real one, and we\u0026rsquo;re happy to be able to support it.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 10:\u003c/strong\u003e Those features, and others, make up USWDS 3.8.0, coming soon: by the end of the month.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 11:\u003c/strong\u003e Next, I wanted to take a couple minutes to give an update on the items in our development roadmap. Currently we\u0026rsquo;re on a planning cadence where we update our roadmap and schedule once a quarter, and we just finished planning for this quarter. Going forward, we expect to give these roadmap updates every three months.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 12:\u003c/strong\u003e So, first up, web components. We expect to deliver a mature beta of USWDS web components by this fall, October 2024. Upcoming milestones include:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThis month we\u0026rsquo;re planning for a web components working group: identifying folks who can actively help us through this process, and also planning for sequencing and scheduling.\u003c/li\u003e\n\u003cli\u003eIn February, we\u0026rsquo;ll finish a requirements draft for Web Components.\u003c/li\u003e\n\u003cli\u003eIn March, we\u0026rsquo;ll have an alpha of a couple core components, most likely banner and identifier.\u003c/li\u003e\n\u003cli\u003eBy June, we\u0026rsquo;ll get to form components, with the goal of a mature web components beta by October of this year.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 13:\u003c/strong\u003e Relatedly, JSON tokens: This is moving our tokens data from Sass into the more portable JSON data format. This is related to web components and shares a similar milestone: a mature beta in October.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThis month, we\u0026rsquo;re finishing a landscape analysis of how tokens are stored and used in other design systems, and finalizing a data structure for the JSON.\u003c/li\u003e\n\u003cli\u003eBy April, we hope to use some of these new tokens internally and power our site with them.\u003c/li\u003e\n\u003cli\u003eBy May, we\u0026rsquo;ll complete theme and state tokens and be ready to demo color tokens\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTogether with web components, this begins to define the shape of a new major version of the design system, one that\u0026rsquo;s tested with a long-term beta to make sure we\u0026rsquo;re getting things right. Right now we think that a new major version could be on track for Spring 2025, but that\u0026rsquo;s a bit too far in the future to really know for sure.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 14:\u003c/strong\u003e Now for a few things that are shorter term: starting with publishing a component lifecycle model — describing how we develop components, how they’re proposed, and how they mature. We\u0026rsquo;ll talk a lot more about this next month!\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThis month we\u0026rsquo;re thinking about a proposal status page prototype and clarifying roles and responsibilities throughout the lifecycle.\u003c/li\u003e\n\u003cli\u003eNext month we\u0026rsquo;ll be codifying our software lifecycle definitions, establishing a GitHub repo for component proposals, and presenting our work at a monthly call.\u003c/li\u003e\n\u003cli\u003eBy March, all this documentation should be up on our site!\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 15:\u003c/strong\u003e We\u0026rsquo;re also working to operationalize usability research, specifically component and pattern usability research with people with disabilities.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThis month we\u0026rsquo;re finishing a research plan for our second round of research (called \u0026ldquo;Zebra\u0026rdquo; in our GitHub issues) and publishing a recruitment page.\u003c/li\u003e\n\u003cli\u003eIn February we\u0026rsquo;ll perform this research, in March, we\u0026rsquo;ll document the findings, and by April we should be planning for Round 3 with a repeatable process to get us through Rounds 4, 5, and beyond.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 16:\u003c/strong\u003e We\u0026rsquo;re working to finish up tasks related to a website content audit. By next month we should have the page-level analysis complete, and have a set of success metrics for key pages. We\u0026rsquo;ll finish this roadmap item up in March by documenting a repeatable process for managing and evaluating our content.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 17:\u003c/strong\u003e We\u0026rsquo;ve talked about Top Tasks here in the monthly call. This month we\u0026rsquo;re documenting usability tests that address these tasks and adding a recruiting form to Touchpoints to help us find Federal employees that can be part of upcoming usability testing.\u003c/p\u003e\n\u003cp\u003eIn April we\u0026rsquo;ll do this round of top tasks testing, and look at the results in May.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 18:\u003c/strong\u003e We\u0026rsquo;re also working to strengthen our guidance around disabled states, trying to do more to encourage interactions that do not involve disabled or inactive inputs.\u003c/p\u003e\n\u003cp\u003eNext month we\u0026rsquo;ll be finalizing these guidance updates. In April, we\u0026rsquo;ll finish our communications plan, in May we\u0026rsquo;ll publish supporting research, and update all the site guidance by June.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 19:\u003c/strong\u003e And finally, critical checklists. We’ve been talking about this since last summer. As of today in January, we’re publishing our first tests. And now we\u0026rsquo;re on a roll!\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWe\u0026rsquo;ll do the next round of usability testing in March, all the while continuing on the first pass of testing, and finally documentation, which we should complete in July.\u003c/li\u003e\n\u003cli\u003eEach month we\u0026rsquo;ll also be doing a second round of testing as well, and publishing new component checklists as we finish this work.\u003c/li\u003e\n\u003cli\u003eBy August this should all be complete!\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 20:\u003c/strong\u003e As you can see, there\u0026rsquo;s a lot on our plate right now! And you can check out the full roadmap over at GitHub at \u003ca href=\"http://github.com/orgs/uswds/projects/8/views/31\"\u003egithub.com/orgs/uswds/projects/8/views/31\u003c/a\u003e. And you don\u0026rsquo;t have to write that down, we\u0026rsquo;re pasting it into the chat.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 21:\u003c/strong\u003e And this brings us to today, where we\u0026rsquo;ll talk about launching the first of our component accessibility tests; what we hope is a way to make accessibility more accessible for everyone who uses the design system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 22:\u003c/strong\u003e We launched this project in June 2023, about six months ago. It\u0026rsquo;s taken us a little while to get to this launch, but it\u0026rsquo;s been slow and steady progress. We\u0026rsquo;re posting \u003ca href=\"https://designsystem.digital.gov/about/monthly-calls/#june-2023-introducing-critical-checklists\"\u003ethe link to our June 2023 monthly call\u003c/a\u003e — where we first discussed the importance of this work — in the chat.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 23:\u003c/strong\u003e Perhaps our biggest goal in this project is transparency — we want to know that our components are accessible and to say that our components are accessible, but we also need to be able to show what we did and how we did it and make that process repeatable and transparent so you can do it as well in your own projects.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 24:\u003c/strong\u003e And we wanted these checklists to be an example of simplicity and clarity. We know it often can be challenging to understand accessibility requirements. If we\u0026rsquo;re talking about what we did and what we checked, we ought to be able to do this in plain language. Anyone familiar with the web should be able to follow these tests.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 25:\u003c/strong\u003e And finally, an important project goal was to empower participation. Accessibility is something that should be integrated into the fabric of a product and a product team. Anybody on the team should be involved in understanding the accessibility implications of what they build. There is absolutely a role for domain specific accessibility expertise, but anyone should be able to understand what a component needs to do to be accessible, and to help check if their solutions meet those needs. There\u0026rsquo;s value in democratizing accessibility. We believe that hands-on accessibility experience builds familiarity and understanding, and that any team member ought to be able to point out if something isn\u0026rsquo;t working as expected.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 26:\u003c/strong\u003e It has taken some time to get here. Like so many things, it has taken longer than expected.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 27:\u003c/strong\u003e But this is important. These accessibility tests are, we think, worth the time to get it right and do it well.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 28:\u003c/strong\u003e When we introduced this idea, we talked about these elements as critical checklists, the things a component needs to do to be accessible and usable, but as this idea has matured over the last six months, we learned that this name itself could be simpler, clearer, and more accessible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 29:\u003c/strong\u003e So we\u0026rsquo;ve renamed Critical Checklists to Accessibility Tests.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 30:\u003c/strong\u003e So here we go! Let\u0026rsquo;s take a look at one of the three component accessibility test pages we published today, Accordion, at \u003ca href=\"http://designsystem.digital.gov/components/accordion\"\u003edesignsystem.digital.gov/components/accordion\u003c/a\u003e. One of the first things you\u0026rsquo;ll notice is that every component that has an accessibility tests page, now has an accessibility status badge. This is up at the top of the page, and this accordion badge reads \u0026ldquo;Passed WCAG 2.1 AA\u0026rdquo;. The side navigation on this page also includes a link to \u0026ldquo;Accordion accessibility tests\u0026rdquo;.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 31:\u003c/strong\u003e Further down the page, in the accessibility section, you\u0026rsquo;ll find a callout to test the accordion in your own project, and a call-to-action link to \u0026ldquo;Use accordion accessibility tests\u0026rdquo;. We\u0026rsquo;re trying to stress here and on the accessibility tests page as well, that it\u0026rsquo;s also important to perform these tests on your own site, since any implementation will necessarily be different from the environment in which we perform our tests.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 32:\u003c/strong\u003e So let\u0026rsquo;s take a look at the Accordion accessibility tests page itself. You can take a look for yourself at \u003ca href=\"http://designsystem.digital.gov/components/accordion/accessibility-tests\"\u003edesignsystem.digital.gov/components/accordion/accessibility-tests\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eAny USWDS accordion should pass these manual accessibility tests. In the top section you can see how we did, and read a bit about how to test the accordion in your own project. Let\u0026rsquo;s take a look at each of the elements of an accessibility tests page.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 33:\u003c/strong\u003e First, the introduction, where we document the accessibility status and talk about testing in your own project. Each test can have one of three statuses: \u003cstrong\u003ePassed\u003c/strong\u003e, \u003cstrong\u003ePassed with Exceptions\u003c/strong\u003e, \u003cstrong\u003eConditional\u003c/strong\u003e, or \u003cstrong\u003eFailed\u003c/strong\u003e. Pass and fail statuses are as straightforward as they imply. \u003cstrong\u003ePassed with exceptions\u003c/strong\u003e means that a test passes in most cases, but we\u0026rsquo;ve identified at least one case where it does not. We\u0026rsquo;ll look at an example in a moment. \u003cstrong\u003eConditional\u003c/strong\u003e means that \u0026ldquo;it depends\u0026rdquo; — specifically that it depends on the context in which you use the component in your project, like using the proper heading level for an element on a page. These are elements that we can\u0026rsquo;t test in isolation, and those that teams need to be able to test in their project.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 34:\u003c/strong\u003e Next we have the accessibility tests themselves. These are checklists grouped by type-of-test. We have zoom magnification tests, keyboard navigation tests, screen reader tests, and sometimes general accessibility tests.\u003c/p\u003e\n\u003cp\u003eEach test group is preceded by an accordion that includes instructions for setting up your computer for performing this type of test: for instance, instructions for setting up a screen reader.\u003c/p\u003e\n\u003cp\u003eThen there are the tests themselves, which show the relevant WCAG success criteria and level, the test status from our last USWDS check, and the USWDS version when we last performed the test.\u003c/p\u003e\n\u003cp\u003eAnd each test is also an active checkable checklist item. You can think of these pages as a scratchpad for your own accessibility testing, a way to keep temporary notes of your progress.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 35:\u003c/strong\u003e On this page, we\u0026rsquo;ve also got an example of passing with exceptions. This exception notes that for a screen reader test of announcing the \u0026ldquo;collapsed\u0026rdquo; state of the accordion, our USWDS code works as expected, but that some of the accordions on our website don\u0026rsquo;t have the expected readout in the JAWS screen reader. JAWS tests of accordions on other USWDS sites produced the correct readout.\u003c/p\u003e\n\u003cp\u003eIn this case, we\u0026rsquo;re noting this exception, and linking to a GitHub issue where we\u0026rsquo;re tracking it and addressing it. Once we\u0026rsquo;ve fixed this issue, we\u0026rsquo;ll re-test and update the tests page.\u003c/p\u003e\n\u003cp\u003eIf there were a fail state, we\u0026rsquo;d note it similarly on that page and link to the GitHub issue where we\u0026rsquo;re addressing the problem.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 36:\u003c/strong\u003e Finally, at the bottom of the tests, we have two calls to action: \u003cstrong\u003ePropose a new test\u003c/strong\u003e, and \u003cstrong\u003eReport an error\u003c/strong\u003e. These calls to action send folks to either a GitHub feature-request issue or to a GitHub bug-report issue. And that\u0026rsquo;s an accessibility tests page!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 37:\u003c/strong\u003e Today we\u0026rsquo;re publishing accessibility test pages for three USWDS components: Accordion, Button and Link.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 38:\u003c/strong\u003e What comes next is… all the rest of our components. And at least one more round of usability testing.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 39:\u003c/strong\u003e As I mentioned at the start of the call, we\u0026rsquo;re on track to deliver a batch of new accessibility test pages each month, finishing up in August. If you\u0026rsquo;d like some more detail of our schedule and plan, we\u0026rsquo;re posting a link to \u003ca href=\"https://github.com/uswds/uswds/issues/5578\"\u003ea GitHub issue that goes into more detail\u003c/a\u003e in the chat.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 40:\u003c/strong\u003e So before I pass it to my colleagues to dig into how we got here, let\u0026rsquo;s check back in on our goals. First and foremost, we\u0026rsquo;re interested in making accessibility more accessible to anyone working on the web. If you\u0026rsquo;re working on a project, you can be a part of its accessibility.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 41:\u003c/strong\u003e Next, we\u0026rsquo;re interested in establishing a baseline for change. As the design system grows and changes, we want to make sure that we establish a continuity of accessible functionality-that-teams-can-trust and that we can check from release to release.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 42:\u003c/strong\u003e And finally, this can be another great example of using the design system to scale expertise: It takes a fair amount of time to develop these tests and understand what to look for. To write in plain language. To make things simpler. It can be pretty complicated to make something simple! We\u0026rsquo;re trying to do a lot of that hard work, so we can deliver not only accessible components, but a way to manually test components that takes minutes instead of hours or days. It took us hours and days so that it can take you only minutes! That\u0026rsquo;s the hope at least.\u003c/p\u003e\n\u003cp\u003eAnd to talk more about the how, I\u0026rsquo;d like to introduce some of my colleagues\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 43:\u003c/strong\u003e First Amy Cole, a contractor, and our Accessibility Expert. Amy can you introduce yourself?\u003c/p\u003e\n\u003cp\u003eAmy: Amy intro Hi, I’m Amy Cole. My pronouns are she/her and I’m a woman with curly brown hair wearing a blue sweater with a bird on it.\u003c/p\u003e\n\u003cp\u003eDan: Thanks Amy!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 44:\u003c/strong\u003e Next, I\u0026rsquo;d like to introduce Jacline Contrino, a contractor, and our UX researcher. Jacline, can you introduce yourself?\u003c/p\u003e\n\u003cp\u003eJacline: Sure! Hi everyone, this is Jacline, she/her. I\u0026rsquo;m a white woman with shoulder length brown hair and I\u0026rsquo;m wearing a burnt-orange sweater today.\u003c/p\u003e\n\u003cp\u003eDan: Thanks Jacline!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 45:\u003c/strong\u003e And finally, I’d like to introduce Anne Petersen, our Experience Design Lead. Anne, could you introduce yourself?\u003c/p\u003e\n\u003cp\u003eAnne: Sure can. Hi, I’m Anne Petersen. My pronouns are they/them, and I’m a white person with brown hair and small glasses, wearing a blue plaid today.\u003c/p\u003e\n\u003cp\u003eDan: Thanks Anne\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 46:\u003c/strong\u003e So first, I\u0026rsquo;ll pass it off to Amy to talk some more about our approach to accessibility: and how we understood what to test. Amy, take it away!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 47:\u003c/strong\u003e Amy: So, with the goals of transparency, simplicity, and empowerment in mind, undertaking the task of auditing each component took a lot of planning. We had to think about what our time and labor constraints were. And then practically, how we might tackle this with just two partially allocated accessibility specialists. We wanted to be able to do the majority of the up-front accessibility thinking for you, per component. We also wanted these pages to both inform you of what we’ve tested for, but also how you can test them yourself.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 48:\u003c/strong\u003e Before delving into the specifics of how we conducted our tests, I want to establish a clear understanding of the foundation guiding our testing process. Section 508, a component of a 1998 amendment to the Rehabilitation Act of 1973, is a federal law mandating accessibility for all Federal electronic content. This law relies on The Web Content Accessibility Guidelines (WCAG) 2.0 standards. With over 78 Success Criteria categorized into three levels (A – minimum conformance, AA – recommended, AAA – best and most accessible), Section 508 sets the benchmark. Our testing was conducted against WCAG 2.1 AA, and in certain instances, we also evaluated compliance with the newly released 2.2 AA standards.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 49:\u003c/strong\u003e But getting back to our constraints, it’s important to note that we tested each component’s preview code, in isolation, and not a prototype of the component on an actual webpage with other interactive elements. Since some criteria can only be tested when the component appears in context, we were unable to fully test for each success criteria. For example, if you were to use our button code, you’d probably put it on a webpage where you could test for focus order or meaningful sequence. We were unable to test for those criteria since, again, we test components in isolation where they’re removed from any context. For those success criteria, we marked them “conditional.” For this reason, error handling, error prevention, or some criteria such as heading levels are best tested in your own project.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 50:\u003c/strong\u003e The audit has been an iterative process that’s evolved over time. We gained inspiration from other design systems to determine what we felt would best benefit our community. From that starting point, we moved into using the \u003ca href=\"https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1#top\"\u003eW3C Quick reference resource\u003c/a\u003e as a testing guide (we are adding that link in the chat). As I mentioned earlier, there are more than 78 potential success criteria to check against, so the W3C quick reference provided us the means by which we, hopefully, didn’t overlook specific success criteria for a given component.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 51:\u003c/strong\u003e So, how did we sequence our components? How did we choose which components to begin the audit? We decided to take a strategic approach. After our initial audit of the accordion, which is our most visited component page, we transitioned to examining the least complex elements in the design system. These components are the building blocks of the design system including links, buttons, lists, and so on. Starting with accessible fundamental components means we have a higher chance of creating an accessible design system as a whole. We shared that link in the chat to the \u003ca href=\"https://github.com/uswds/uswds/issues/5578\"\u003eGitHub audit roadmap issue\u003c/a\u003e which lists each component audit issue in the order in which we are reviewing them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 52:\u003c/strong\u003e The initial audit of a component is done by an accessibility specialist. There are two of us on the team. In order to gain a comprehensive view of the component against the success criteria, we ask the person who didn’t participate in the initial review to do an additional audit. We do this to capture checks that may have been overlooked, but also to gain an additional perspective of not only if the checks were passed, but wording of the prompts themselves.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 53:\u003c/strong\u003e We also wanted to make each testing prompt easy to follow. WCAG success criteria can be confusing, so it was important to us that the testing prompts be written in easy-to-follow plain language. Something like, “When you do this, the component does this.”\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 54:\u003c/strong\u003e While an accessibility specialist wrote the first draft of each testing prompt, the wording was reviewed by our content specialists before being published. Not only did this editing process ensure we were providing consistency in our writing, it tested clarity and understanding of the prompts with team members who were not accessibility experts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 55:\u003c/strong\u003e While all of our components were tested when they were created, this is the first comprehensive accessibility audit we’ve done to WCAG 2.2 standards. We’ll be doing this type of audit on a rolling basis going forward, ideally annually, with the intention of re-checking every component in an ongoing cycle over the course of that year. We’ll also be updating what we test for based on new findings, new standards, and new research.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 56:\u003c/strong\u003e But what happens if a component fails one of the checks? Simple; we create a high priority issue in GitHub. Luckily, so far our checks have found very few failures and only a handful of concerning issues we wanted to examine further. Those have all been addressed or are in the process of being addressed. We also have been crafting suggestions on content updates to the relevant guidance for these components. And finally, we have plans to create more robust component examples that better reflect the type of environment components will be used in.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 57:\u003c/strong\u003e As I mentioned earlier, we realize that we are testing these components in isolation; but you won’t be. You might need to piece together multiple checks per page or perform a more comprehensive page-level test. In the future we hope to bring you guidance on how to do those tests, too. For now, we recommend you use these checks as prompts to begin a conversation or bring awareness to accessibility at a fundamental level. Anyone new to accessibility should feel welcome to try using the checks themselves. We hope they help reduce any reservations you might feel about testing web accessibility and expand your knowledge of the testing process.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 58:\u003c/strong\u003e We want you to feel comfortable sharing suggestions and feedback on these checks. They, along with everything we do, are a work in progress, and we want to invite you to contribute to the accessibility of the design system. If you feel a check could be worded better, or if we overlooked something or you just want to give us feedback, there are buttons for submitting an issue or suggesting a check on each page. We can’t claim to have thought of everything, but that’s where you come in! In the future we hope to expand these pages to include color contrast, design and other manual checks. This will help us ensure all audiences have equal access to our work. And speaking of audiences, it’s important that you use these checks in conjunction with usability testing. Something that doesn’t technically pass a check might actually work better for your particular audience. It’s important to know that distinction and include your audience in your process. And speaking of testing, I’m going to hand it off to Jacline to talk about how we tested prototypes of our new accessibility test pages.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 59:\u003c/strong\u003e Jacline: Thanks Amy - hi everyone, this is Jacline again. It’s important to us that WHAT we build is useful and usable to you, the USWDS community. So, before launching this page, we tested it with some of you. I’m going to talk a little bit about what we did, what we learned, and how it influenced the design of our new component Accessibility Tests pages.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 60:\u003c/strong\u003e This has been an ongoing effort for the last half of 2023 to now, and the research we’ve done has also been ongoing. First, we created the content for the new page in a simple document, and we did some content testing last summer with a few USWDS users to make sure we were providing the right content.\u003c/p\u003e\n\u003cp\u003eOnce we made some tweaks based on what we learned from the content testing, we created a high fidelity prototype of what the page could look like. We wanted to put that prototype in front of users so we could make necessary design improvements before launch. So, that’s what we did - in December, we tested the prototype with 6 USWDS users.\u003c/p\u003e\n\u003cp\u003eThese prototype tests themselves were iterative - so we tested with 3 people, made updates to the prototype design and testing script mid-stream based on the feedback we were getting, and then tested with 3 more.\u003c/p\u003e\n\u003cp\u003eAnd now, we just launched these new pages and we plan to test them again in March.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 61:\u003c/strong\u003e Our main goals for testing the prototype were to gauge first impressions, discover what’s confusing, get a sense of how the structure and presentation of information was working for people, and just generally discover what improvements need to be made before launch.\u003c/p\u003e\n\u003cp\u003eSome specific research questions we were trying to answer were:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIs the purpose of the page clear? Do they know what it can help them do?\u003c/li\u003e\n\u003cli\u003eIs it useful and usable to someone who’s not an accessibility expert?\u003c/li\u003e\n\u003cli\u003eIs the page where they expect to find it?\u003c/li\u003e\n\u003cli\u003eWhat page title makes the most sense to users?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eGetting more insights into these areas would help us gauge if we are on the right track with our design choices and decide what changes to make.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 62:\u003c/strong\u003e Let’s talk about our approach. We tested with 6 USWDS users from a variety of agencies and who fill a variety of professional roles, including Tech Specialists, engineers, designers, etc.\u003c/p\u003e\n\u003cp\u003eParticipants also varied in expertise with accessibility. 2 people were well versed in accessibility and manual testing, and 4 people had little to no experience with it. We were happy to get the perspectives of folks who are not familiar with manual testing since one of our goals for this page was that we want anyone, regardless of technical skill or accessibility knowledge, to be able to easily use it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 63:\u003c/strong\u003e We met with each participant for 30 minutes on a video call and had them share their feedback about the prototype with us. We also asked participants to actually use the checklist to do zoom magnification testing on an accordion so we could see how easy or difficult it was for people who weren’t accessibility experts to actually use the checklist to carry out manual testing themselves.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 64:\u003c/strong\u003e So, what did we learn and how did it affect how we designed our new accessibility tests pages?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 65:\u003c/strong\u003e Let’s start with the bright spots, or things that tested well. First, we learned that overall, folks really liked the page and said that they hadn’t encountered a resource quite like it and felt it’d be a useful resource to reference.\u003c/p\u003e\n\u003cp\u003eOne person said “I think this is really great. I\u0026rsquo;ve never seen accessibility stuff explained in such plain language.” Another commented that “This is new and it’s interesting and it’s something I’m going to use moving forward.”\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 66:\u003c/strong\u003e Next, we learned that all participants easily found the page, so that was a nice confirmation that we were linking to it from the right places on the main component page.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 67:\u003c/strong\u003e And very importantly, we found that using the checklists to do zoom magnification testing was very easy for all participants. Many felt delighted by how easy it was to use and commented that they learned something new.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 68:\u003c/strong\u003e So, what could be improved?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 69:\u003c/strong\u003e First, communicating overall Section 508 compliance more effectively was needed. In the first round of testing, folks weren’t clear on if the accordion was actually Section 508 compliant and wanted some kind of clear designation from us. In other words, people wanted a clear answer to- does the accordion pass or fail?\u003c/p\u003e\n\u003cp\u003eSo, we added the green badge of “Passed WCAG 2.1 AA” at the top of the page - we’re showing a screenshot of the page with a red arrow pointing to that new badge. Hopefully, the badge will make it clearer to users that the accordion does meet WCAG standards and is Section 508 compliant overall.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 70:\u003c/strong\u003e Another major finding was that there was some confusion about the purpose of the page. It wasn’t clear that the page had a dual purpose of both communicating component compliance through the tests WE’VE carried out PLUS helping you do your OWN tests. Participants tended to think it was either for one or the other at first. It wasn’t until they spent more time with the page that the dual purpose started to be more apparent to them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 71:\u003c/strong\u003e Some of that confusion could be due to how we presented the test results in the early prototype. It seemed the way the green checkmarks were presented with the ‘passed’ badge made people wonder if they really needed to test the component if we already had and it passed. It wasn’t clear that those items were actions that they should be taking too.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 72:\u003c/strong\u003e We decided to change how the checklist items look - we replaced the green check icons with interactive check boxes and added clarifying language to the test status in an effort to make it clearer that you all will need to take action even though we did testing on our end.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 73:\u003c/strong\u003e Another thing we learned was that many participants, especially those new to accessibility, felt a bit intimidated by the page and said that they thought the intended audience was a 508 Specialist, or possibly a Product Owner who needs proof that a component is compliant.\u003c/p\u003e\n\u003cp\u003eOur goal for the page is that it could be used by anyone, regardless of subject matter expertise or technical ability, so it was good to get the perspective from people that actually use these pages that we may be missing the mark there.\u003c/p\u003e\n\u003cp\u003eThat said, once participants spent more time with the page and used checklists, their opinions seemed to turn a corner and they didn’t feel intimidated anymore. So, we needed to think about how to help participants get over that initial impression.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 74:\u003c/strong\u003e We also learned that folks felt a bit overwhelmed by the amount of content on the page and described it as a “wall of text” — that they had to scroll too much to go through and to find specific information. We observed our participants just skimming right over and missing important information.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 75:\u003c/strong\u003e To improve the presentation of content and hopefully make it less overwhelming, we reduced the amount of text, used information chunking, and used more visual elements like icons and buttons for critical content.\u003c/p\u003e\n\u003cp\u003eWe also improved the headings structure to make the hierarchy of the information more apparent. We added jump links to the testing categories (including zoom magnification tests, keyboard navigation tests, and screen reader tests) so it\u0026rsquo;s easier to quickly find them than from scrolling alone.\u003c/p\u003e\n\u003cp\u003eFinally, we moved the test status over to the right to make it easier to scan and find. In the screenshot we have here you can see the ‘USWDS test status: Passed’ all the way over to the right. Making all of these changes will hopefully improve the scannability of the page and help you locate the content you want faster.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 76:\u003c/strong\u003e Finally, we still needed a name for the page. Folks were split over what to name the page and there was no real consensus.\u003c/p\u003e\n\u003cp\u003eIt was tricky for both the USWDS team and others to find a fitting name for the page since it has a dual purpose.\u003c/p\u003e\n\u003cp\u003eWe ultimately decided that ‘Accordion accessibility tests” (or button, or link, or whatever relevant component) encompasses the purpose of the page well and has a nice, sturdy simplicity to it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 77:\u003c/strong\u003e We’ll continue to keep our finger on the pulse of what you all need from these pages, and will make iterative improvements as we learn more. We have more testing for this page planned for March, so stay tuned.\u003c/p\u003e\n\u003cp\u003eWe’re really grateful to our participants for taking the time to give us their feedback and we feel we’re launching a much better product because of it. If you’re interested in participating in any of our usability research, \u003ca href=\"https://touchpoints.app.cloud.gov/touchpoints/08432480/submit\"\u003eplease fill out our brief signup form that we’re pasting in the chat\u003c/a\u003e. We also intend to publish a page on our site where you can sign up in the future. Now I’ll pass it off to Anne. Thanks!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 78:\u003c/strong\u003e Anne: Thanks Jacline. Finally, we want to take a moment to talk about the work, alongside talking about the work itself.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 79:\u003c/strong\u003e As I’ve said before, and you’ll probably keep hearing from me, our process is part of our product. Showing how we do our work benefits you in multiple ways.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 80:\u003c/strong\u003e Firstly, we want to show our work so that you can decide what from all this might be useful to you and your team. Which itself is both practical and kind of meta. We’re thinking about how we do the work, during the work, all the time, so we can tell you what worked, what didn’t, what we improved, what we want to improve, and what to expect. So all this work serves multiple purposes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 81:\u003c/strong\u003e In this case, it’s making the practice of accessibility itself more accessible to you, hopefully. That’s the goal. Let’s make our accessibility goals, the standards we follow, and how we test, and how we make that testing sustainable, easier to understand, easier to do, easier to manage, easier to test, easier to make changes in and repeat.\u003c/p\u003e\n\u003cp\u003eAll that to say: if you’re not doing manual accessibility testing alongside automated accessibility testing, you should. By showing you, component by component, how we do it, we hope to better enable your testing.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 82:\u003c/strong\u003e As well as support your decision-making on when and how to use USWDS components. We want to be obvious about our process of testing and what we found, so that everyone can make informed decisions.\u003c/p\u003e\n\u003cp\u003eMuch like with our recent usability testing with people with visual disabilities from our last call in November, and this round of testing on these new pages, ensuring you’re informed means talking it about it here, but also means publishing our research, getting that connected logically on our website, and continuing to talk with you, our community, as we keep making our process more understandable and showing the progress we’ve made, which then supports your decision-making on when and how to use USWDS components.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 83:\u003c/strong\u003e \u003cem\u003eAnd\u003c/em\u003e showing we rarely start where we end up. We improve things in small cycles along the way.\u003c/p\u003e\n\u003cp\u003eIterating — that is, learning and changing as we go, continuously — is key to our work. Amy talked about it in the audit, when we changed how we were explaining those tests. Jacline talked about it in our usability testing of these pages, when we changed those tests to include exploration of the page title, as well as changing the design of the prototype, to gather feedback on both.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 84:\u003c/strong\u003e This cycle of learning and improving and learning again, happens always. It’s continuous; it’s a way of working, and how we serve people best. Serving people like all of you, who are supporting sites and services and products that support others. Serving the public, ultimately, which is what working in and for government is all about.\u003c/p\u003e\n\u003cp\u003eWe — and you — are doing the work. Let’s improve how we do that work, and improve our outcomes, together.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 85:\u003c/strong\u003e So! You’ve now seen all we’ve published on this as of today.\u003c/p\u003e\n\u003cp\u003eAs for how we continue: in March, we’ll do more usability testing on these new accessibility test pages. Each month we’ll be adding new accessibility test pages for additional components, working toward completing them all by the end of August. After that and on an ongoing basis, we’ll audit the accessibility of our components continuously, gradually re-checking each over the course of every year.\u003c/p\u003e\n\u003cp\u003eA bit sooner than that — before our next monthly call, look for updates to our main pages about Accessibility and Research, which will aggregate the ways we’re helping you to make informed decisions, including details from this round of usability research, if you’re interested.\u003c/p\u003e\n\u003cp\u003eThanks for coming along with us as we iterate and improve, in the interest of helping you and your team and your processes iterate and improve, in the interest of all kinds of benefits for your published product. And with that, I’ll pass it back to Dan to open it for questions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 86:\u003c/strong\u003e Q\u0026amp;A\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 87:\u003c/strong\u003e We\u0026rsquo;ll be back next month where we\u0026rsquo;ll be talking about component lifecycle.\u003c/p\u003e\n\u003cp\u003eIf you have a question we weren\u0026rsquo;t able to answer in the call, or thought of later, please head into our public Slack and ask it there. We\u0026rsquo;ll be around after the call to answer questions.\u003c/p\u003e\n\u003cp\u003eWelcome to 2024. Here we go. Have a great day and we\u0026rsquo;ll talk with you next month!\u003c/p\u003e\n\u003c/div\u003e\u003c/div\u003e\n\n\u003cp\u003eJoin the U.S. Web Design System (USWDS) team as they continue to highlight accessibility by discussing the new component-based accessibility test pages and talk more about their development and phased rollout.\u003c/p\u003e\n\u003cp\u003eIn this session, you will learn:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eHow the Design System team documents their accessibility testing\u003c/li\u003e\n\u003cli\u003eThe new checklists to conduct your own accessibility testing\u003c/li\u003e\n\u003cli\u003eOur schedule for publishing additional component accessibility tests\u003c/li\u003e\n\u003cli\u003eLocating known issues for some Design System components\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eThis event is best suited for:\u003c/strong\u003e Designers, accessibility specialists, developers, and content managers (all levels)\u003c/p\u003e\n\u003ch2 id=\"speakers\"\u003eSpeakers\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDan Williams\u003c/strong\u003e \u003cstrong\u003e—\u003c/strong\u003e Product Lead, USWDS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnne Petersen\u003c/strong\u003e \u003cstrong\u003e—\u003c/strong\u003e Experience Design Lead, USWDS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAmy Cole\u003c/strong\u003e \u003cstrong\u003e—\u003c/strong\u003e Accessibility Specialist, USWDS Contractor\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJacline Contrino\u003c/strong\u003e \u003cstrong\u003e—\u003c/strong\u003e UX Researcher, USWDS Contractor\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"join-our-communities-of-practice\"\u003eJoin our Communities of Practice\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://designsystem.digital.gov/about/community/\"\u003eUSWDS\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.section508.gov/manage/join-the-508-community/\"\u003eSection 508 IT Accessibility\u003c/a\u003e\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" :"2024-01-10-uswds-monthly-call-january-2024.md",
      
      "filepath" :"events/2024/01/2024-01-10-uswds-monthly-call-january-2024.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/events/2024/01/2024-01-10-uswds-monthly-call-january-2024.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/events/2024/01/2024-01-10-uswds-monthly-call-january-2024.md","slug" : "uswds-monthly-call-january-2024","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/01/18/uswds-monthly-call-january-2024/"
    }
  ]
}