diff --git a/content/about/policies.md b/content/about/policies.md
index 43d869ecb4..bbab0eed4e 100644
--- a/content/about/policies.md
+++ b/content/about/policies.md
@@ -8,23 +8,17 @@ aliases:
---
-## Comment Policy
-
-{{< legacy-img-right src="/2013/12/250-x-290-Keep-Calm-and-Follow-the-Rules-meme-ScreenShot-December-19th-2013-at-12-55-16pm.jpg" alt="Screen capture of an internet Keep Calm meme that says: Keep Calm and Follow the Rules" >}}
-
-Comments are available on many pages and posts on this site. We welcome your comments and expect that our conversation will follow the general rules of respectful civil discourse. We will only post comments related to our purpose. We will review comments for posting within one business day. You’re fully responsible for everything that you submit in your comments, and all posted comments are in the public domain. We don’t discriminate against any views, but we reserve the right to not post comments. We do not post comments that are off-topic, spam, or overtly self-promoting.
-
## Privacy
The U.S. General Services Administration (GSA) will not share or sell any of your personal information with any other organization or government agency except as required by law. Please view [GSA’s privacy and security notice](http://www.gsa.gov/portal/content/116609).
-### Cookies and Analytics
+### Cookies and analytics
DigitalGov uses single-session cookies to serve technical purposes, like providing seamless navigation through the platform. These cookies do not permanently record data, and they are not stored on your computer’s hard drive. DigitalGov’s session cookies are only available during an active browser session. When you close your browser, the session cookie disappears.
DigitalGov also uses multi-session cookies to help us understand how people use the platform, and how we can make it better. We use Google Analytics Web analytics software. We do not collect any personally identifiable information (PII). Traffic statistics are collected anonymously and aggregated, and no information is traceable to any specific individual. [You can change the setting of your browser to block cookies by following these instructions](https://www.usa.gov/optout-instructions).
-## Linking Policy and Endorsement
+## Linking policy and endorsement
This site may include useful hypertext links or pointers to information created and maintained by others. We provide these links and pointers solely for your information and convenience. When you select a link to an outside website, remember that you’re leaving this blog and are subject to the privacy and security policies of the owners/sponsors of the outside website. When you leave this blog, remember that GSA
@@ -34,7 +28,7 @@ This site may include useful hypertext links or pointers to information created
* is not responsible for transmissions users receive from linked websites
* does not guarantee that outside websites comply with Section 508 (Accessibility Requirements) of the Rehabilitation Act
-## Reuse and Copyright
+## Reuse and copyright
Most material on DigitalGov is free of copyright and may be copied and distributed without permission. We are flattered that you want to share. Citation of DigitalGov and a link back is much appreciated.
@@ -42,7 +36,7 @@ We sometimes use photos or graphics that we licensed or that are restricted. Che
*[More about copyright and other rights pertaining to U.S. Government works](https://www.usa.gov/copyrighted-government-works).*
-## Citation Examples
+## Citation examples
Below are four examples of how to cite Digital.gov.
diff --git a/content/communities/web-managers-forum.md b/content/communities/web-managers-forum.md
index 2197fafefd..b3b021ee6a 100644
--- a/content/communities/web-managers-forum.md
+++ b/content/communities/web-managers-forum.md
@@ -18,7 +18,6 @@ topics:
- product-and-project-management
- user-experience
- content-strategy
- - product-and-project-management
# see all authors at https://digital.gov/authors
authors:
- toni-bonitto
diff --git a/content/events/2020/10/2020-10-01-plain-language-summit-2020.md b/content/events/2020/10/2020-10-01-plain-language-summit-2020.md
index 1aeec2495e..79eb53fc76 100644
--- a/content/events/2020/10/2020-10-01-plain-language-summit-2020.md
+++ b/content/events/2020/10/2020-10-01-plain-language-summit-2020.md
@@ -55,7 +55,6 @@ In this session you will hear from the following speakers:
* **10:35 am - 11:15 am: Putting Plain Language to the Test**—Nicole Fenton, Senior Content Strategist
- {{< asset-static file="pl-summit-2020-nicole-fenton.pdf" label="View the slides (PDF, 18.7 MB, 43 pages)" >}}
* **11:15 am - 12:15 pm: Keynote**—Mark Mchale, GSA's Senior Plain Language Official Associate Administrator, Office of Strategic Communications, GSA
-title="The Average American Reader Needs You to Write (Even More) Clearly"
{{< youtube id="EsJh0GuGYDA" title="Plain Language Summit 2020 - First Session" >}}
diff --git a/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md b/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md
index 9c21a2e5bc..c07d36c0c0 100644
--- a/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md
+++ b/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md
@@ -56,7 +56,7 @@ In this session, you’ll learn how to:
{{< youtube id="It-I7gcaaBg" title="Cultivating a dynamic career in UX" >}}
-1. Cultivating a dynamic career in UX - Carlos Alvarado (time length: 8:11)
+3. Cultivating a dynamic career in UX - Carlos Alvarado (time length: 8:11)
{{< youtube id="UW8v-I8JM_U" title="Cultivating a dynamic career in UX" >}}
diff --git a/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md b/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md
index c11f441a53..4e195ea92b 100644
--- a/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md
+++ b/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md
@@ -22,6 +22,359 @@ primary_image: 2024-uswds-monthly-call-feb-title-card
{{< asset-static file="USWDS Monthly Call Feb 2024.pptx" label="View the slides (PowerPoint presentation, 5.8 MB, 81 pages)" >}}
+{{< accordion kicker="Slide by Slide" title="USWDS Monthly Call - Presentation Script for February 2024" icon="content_copy" >}}
+
+**Slide 1:** Welcome everyone, to the U.S. Web Design System monthly call for February, 2024 — This month we're celebrating Black History Month with shades of green, gold, orange, and brown. As well as Valentine's Day yesterday with shades of pink.
+
+**Slide 2:** My name is Dan Williams, he/him, and I'm the USWDS project lead — and here on-screen is my avatar: dark hair, blue sweater, collared shirt. Today my physical self is wearing a plaid flannel shirt and a fleece, because it's still winter. On my fleece is a green button with some sprouts on it that my son made for me.
+
+As Jeannie mentioned, we are recording this call, and I'm happy to say we've started to be able to share the recordings of these monthly calls publicly. You can find pretty much everything from the last year's worth of monthly calls — back to January 2023 — on our website, at [designsystem.digital.gov/about/monthly-calls](https://designsystem.digital.gov/about/monthly-calls). 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've posted a link to our monthly call page in the chat.
+
+We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today.
+
+For 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&A session at the end of this call.
+
+So thanks! And, with that, let's get started!
+
+**Slide 3:** So what's our agenda for today?
+
+We’ve got a couple nice new site and feature launches, a couple product updates, and then we’ll spend the rest of the time talking about a USWDS component lifecycle model and our new approach to new-component proposals.
+
+**Slide 4:** Let's get into it with site launches.
+
+**Slide 5:** First, [simpler.grants.gov](https://www.google.com/url?q=https://simpler.grants.gov&sa=D&source=docs&ust=1711052748736300&usg=AOvVaw2YSQ8xGM91WUdioPsTCZMY), an exciting new initiative from the grants.gov team at the Department of Health and Human Services.
+
+Grants.gov provides a centralized location for grant seekers to find and apply for federal funding opportunities. Simpler.grants.gov is a new site from the grants.gov team that's using a transparent, iterative, and agile process to document their progress modernizing and improving the grants.gov service. It's an exciting project where they'll be building software out in the open, and I for one, am pretty interested in their approach and their progress! The simpler.grants.gov homepage features a simple, text-focused layout, with a large blue hero field and the words "We're building a simpler Grants.gov!"
+
+**Slide 6:** Next, [Search.gov](https://www.google.com/url?q=https://search.gov&sa=D&source=docs&ust=1711052748730824&usg=AOvVaw3N-xMZKFbY9VHxVGWKAjS-) is starting to roll out hosted search results pages powered by USWDS code.
+
+You know search.gov, right? It's the search engine by and for the federal government, a free service powering search results on over 2,000 websites. Earlier this year they released a beta of a USWDS-based redesign of their hosted results page. Now Digital.gov is the first site to be able to use it, hosting a USWDS-powered search result layout! Search.gov and DigitalGov — a real chocolate and peanut butter combination in my book.
+
+On this slide we see the [Digital.gov search results](https://www.google.com/url?q=https://find.digitalgov.gov/search?utf8%3D%25E2%259C%2593%26affiliate%3Ddigitalgov%26query%3Dusability%26commit%3D&sa=D&source=docs&ust=1711052748731793&usg=AOvVaw1J9MZWOISXo_njMu-hJ7Ti) page for the keyword "usability." We see a clean display of search results, as well as a way to select between all search results and just videos.
+
+**Slide 7:** 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!
+
+**Slide 8:** Now for a few product updates…
+
+**Slide 9:** First USWDS 3.8.0. Last month I said that it would be coming in January… but that didn't happen. We got super busy with a lot of the component lifecycle work we're talking about today, so we had to delay the release.
+
+Well it's still coming — and it's still a release that has a number of good improvements largely contributed by the community, like sticky headers in tables, alignment improvements for icons in buttons, and indeterminate checkbox styling — but we're now aiming for the end of this month. And this time, we will hit that deadline, and you can check in on our progress on our public project board — [we're posting that link in the chat](https://www.google.com/url?q=https://github.com/orgs/uswds/projects/8/views/32?sliceBy%255Bvalue%255D%3Duswds%2B3.8.0&sa=D&source=docs&ust=1711663441786792&usg=AOvVaw1fmg5gDdwSmTHDPqCZLvai).
+
+**Slide 10:** Next, I'd like to give an update on the accessibility tests we launched last month.
+
+**Slide 11:** This month we'll be launching accessibility test pages for three more design system components: table, icon, and typography. We're just finishing these up as well, and we'll be publishing them alongside USWDS 3.8.0 by the end of the month. And that's it for product updates!
+
+**Slide 12:** So today, we'd like to talk about work we've done to outline a USWDS component lifecycle model, and improvements we're making to new-component proposals.
+
+**Slide 13:** At the end of last year, we did a lot of thinking about where we're going as a design system; what we value, and where we're going to spend our time and energy. At the end of that thinking, we came to the monthly call and talked about updates to our mission and vision. And also about our Polestar, where we're pointed as a product.
+
+**Slide 14:** Polestar: We help government teams align, design, and keep their websites and services up to date.
+
+**Slide 15:** Vision: Empowered and supported digital service teams. Familiar and easy-to-use digital services.
+
+**Slide 16:** Mission: Shaping the future of government digital services.
+
+**Slide 17:** As we come into 2024, you may ask, "Why component lifecycle now?" It may seem surprising that we're talking about a component lifecycle model — about how components are proposed and developed, how they make their way into the design system, mature, and how sometimes they're deprecated and retired. Why is this a priority now?
+
+Well, a component lifecycle is not just for devs and pedants. Today we'd like to talk about how it really connects to our mission and supports the kinds of connections and activities at the heart of our product.
+
+**Slide 18:** Thinking about how components start, grow, and mature is something of a scale model of how the design system itself grows and matures, since components are such an important part of what we deliver.
+
+**Slide 19:** Specifically, we're really focussed on how USWDS can be a place to connect digital design and delivery teams across government, to better know what we know, and learn from each other.
+
+**Slide 20:** You know, I hate to be the person to tell you this, but our government is big.
+
+And collectively, in the aggregate, we know a lot. There's incredible skill, talent, sensitivity, craftsmanship, and care across our teams, our agencies, and our products.
+If you take a long view of what we, together, are building, I believe it's inarguable that government digital services are improving — and I would argue further that government digital services are improving faster than the internet as a whole.
+
+If government is the tortoise in the race between the tortoise and the hare, I'd say the tortoise has the momentum these days.
+
+**Slide 21:** And I'd say _that's_ because of a real mission-driven commitment to human centered design and to our inclination to pitch in, to help out, to share what we know with each other, and keep pushing forward.
+Because for sure, while momentum may be on our side, there's a long way to go, and honestly there's never really a finish line.
+
+
+**Slide 22:** It's long been our challenge here at USWDS to facilitate collaboration and contribution, to share and scale effective solutions from anywhere in government. To convert the skill and experience that we clearly have in the aggregate into a common infrastructure that supports and elevates any team and product. And that's been a tough nut to crack.
+
+**Slide 23:** Today we're going to get started on this challenge through the angle of splitting bigger problems into smaller problems, and trying to build a framework for solving complex problems — and building complex solutions — a little at a time. Lowering the barriers to participation in the service of delivering high quality finished work.
+
+We're going to approach this from two angles: one which you might call the food truck scenario, and the other which you might call finding the elephant. Or, _you_ might not yet call it that, yet, but _I_ am!
+
+**Slide 24:** First, the food truck scenario — or simply that it is hard to start something really big like a restaurant. It's complicated, expensive, and can take a huge amount of resources and risk to even consider building an operation like that. It really limits who can participate.
+
+I live in Portland, and one solution to this problem that's popular here and now pretty much is popular everywhere else as well, is the food truck. What if you could begin to reduce the resources and risk to participate? What if you could prove an idea at a smaller scale? Or like a pop-up restaurant that exists for only a week, using an existing restaurant and kitchen. All these smaller-scale solutions to the problem of the restaurant — of getting food — still need to be safe, they still need to be up to code, and they still need to _deliver_ good food.
+
+**Slide 25:** But in general: what if there were smaller steps between nothing and everything?
+
+In our world, the "restaurant" is something like the component. Delivering a final component requires design, development, and research of course, but also a complete guidance page and now accessibility tests. Developing a new component is a big commitment, and contributing a component to the design system is a big risk and a lot of work, like trying to get a big new piece of furniture into a tiny walk-up apartment. There's really no guarantee you'll actually be able to get it up the stairs and into the door.
+
+**Slide 26:** So how can we lower the barrier to participation by creating smaller steps between nothing and a component?
+
+**Slide 27:** How can we enable contribution by defining what we need at each phase?
+
+**Slide 28:** How can we help get component contributions into the design system with fewer up-front requirements?
+
+**Slide 29:** And how can we establish cross-team and cross-agency conversations and communication as the continuity between these phases?
+
+**Slide 30:** Let's get into it with two of my colleagues…
+First, Amy Leadem, a contractor and a developer on the USWDS core team. Amy, can you introduce yourself and give a brief self description?
+
+AL: Absolutely. Hello everyone, I’m Amy and I am a contractor on the engineering team here at USWDS. I am a white woman with long, wavy brown hair, and today I am wearing a light pink sweater. My pronouns are she/her.
+
+DW: Thanks Amy!
+
+**Slide 31:** I'd also like to introduce Anne Petersen, the Experience Design lead on the core team. Anne, can you introduce yourself and give a brief self description?
+
+AP: For sure. I’m Anne Petersen, my pronouns are they/them. I’m a white person with short brown hair and small glasses in a dark blue shirt today.
+
+DW: Thanks Anne. First, I'd like to pass it to Amy, to walk us through our new component lifecycle model.
+
+**Slide 32:** AL: Thanks, Dan. This is Amy and I’m going to show you how we structured the steps in the component lifecycle model, starting with what we're calling **phases**.
+
+**Slide 33:** The overall shape of the lifecycle covers the progression of a component on the way up from just an idea to a mature, stable component published in the design system and in use in projects. It also covers the — as yet unused — process for a component on the way down, deprecating and retiring components that we no longer recommend or support.
+
+The overall shape is a bit like the rising and falling shape we see on the slide as the life cycle progresses: rising to maturity and falling at the end.
+
+**Slide 34:** These main phases in our component lifecycle may seem familiar to you. They are:
+
+* **Proposal:** These components are under consideration for development through public discussion and a formal proposal. This part of the shape is now colored gold.
+
+* **Development:** These are the components undergoing active design, development, testing, and documentation before public release. This part of the shape is now colored blue.
+
+* **Released:** These are the components we've released to the public in our distribution package and documented on the USWDS website. This part of the shape is now colored green.
+
+* **Deprecated:** These are the components that do not meet requirements or are no longer needed. This part of the shape is now colored pink.
+
+**Slide 35:** But what's perhaps less familiar are the sub-phases (or steps) within these larger lifecycle groupings. We're putting a lot of work into establishing smaller steps with clearer transitions between steps.
+
+Establishing sub-phase steps allows us to know precisely what is happening — and needs to happen — with the component at any point in the life cycle. This clarity allows us to define specific responsibilities and requirements for each step, which not only will help us know what needs to happen next to keep the component moving, but also will present opportunities for community contributors to help fulfill those requirements as well.
+
+**Slide 36:** I'd like to call out a new step we're introducing in the Released phase: **Experimental**.
+
+The Experimental step of the Released phase — now colored in darker green in our diagram — is a bit of a pilot. To Dan's earlier point, we're considering Experimental to be something of the food truck to the brick-and-mortar of stable USWDS components. We're hoping we can use an Experimental step to release promising components earlier to help collect more real-world usability research. These components might have fewer documentation requirements, less research backup, maybe a few unanswered questions — along with the expectation that they might change more than stable components. But they would include accessibility tests and would be OK to use in production websites.
+
+Today, we've published an overview of all of these phases and steps on our new component lifecycle page on our website. Let’s take a look.
+
+**Slide 37:** Our new component lifecycle page gives an overview of each phase and step of the component lifecycle. This page covers:
+
+ * What happens in each step,
+
+ * When each step starts and ends,
+
+ * How you can contribute during each step,
+
+ * Where you can find the components that are in each step.
+
+You can find this new page at [designsystem.digital.gov/components/lifecycle](https://designsystem.digital.gov/components/lifecycle).
+And now, since every component — from idea and proposal to stable and deprecation — is in one of the steps of the life cycle, we've also been able to build a new component status page to help you know what's happening with both components we've released in the design system and components that aren't in the design system yet.
+
+**Slide 38:** Our new component status page lists all of the USWDS components — and component ideas — currently in the life cycle, and shows which phase the component is currently in. We also provide a link to the most current information on the component. Depending on the phase, this link might point to the discussion, issue, pull request, or component page. You can find this new page at [designsystem.digital.gov/components/status](https://designsystem.digital.gov/components/status).
+
+And it's worth repeating that this page will list components that are in the Proposal phase as well, so it can serve as an important reference if you're interested in whether the design system has a specific component, or whether a component you need has a proposal already in progress. If there isn't a proposal, or if you want to speed up the proposal process with your own contributions, well… that's what we'll talk about in just a moment!
+
+**Slide 39:** But first, I'll pass it over to Anne to talk about what's next with the component lifecycle.
+
+**Slide 40:** AP: Thanks Amy, this is Anne. That’s a great question. How will this component lifecycle evolve? What’s next for it, and next after that? The exciting part is that we don’t know. Iteration! In action! We’ll find out, basically, as we go.
+
+**Slide 41:** But we do have some assumptions. We think that it's going to be important to get more and more clear and provide more and more detail about how a component moves from one step or phase to another, to develop specific requirements and criteria, and continue to remove ambiguity.
+
+Determining things like: What's necessary to release a component as experimental?
+
+Or: When we evaluate proposals, what criteria should we use?
+
+We're still working through these questions and we hope, eventually, that more clarity will empower folks like you to contribute. But right now we’re figuring out how this initial version works in reality. Where might people not feel empowered or comfortable to participate? Will the detail we need to make sure the components we offer are practical and grounded and are well-tested mean an extra burden for you?
+
+So we'll have to pay attention, see it in action, and listen. To _you_. We want to hear from you.
+
+**Slide 42:** And when we're thinking about all these details, requirements, and evaluation criteria, we're going to be starting from our stated values. We'll go back to our [mission, vision, polestar](https://www.google.com/url?q=https://designsystem.digital.gov/about/&sa=D&source=docs&ust=1711663441787888&usg=AOvVaw3BnY43NX-mYZhnPJj37ynX), and [design principles](https://designsystem.digital.gov/design-principles/), and [product values](https://designsystem.digital.gov/about/product-values/), and proceed from there.
+
+These values are our best articulation of how we think about our own priorities and decision-making, and ultimately the direction of USWDS. They’re where we start, and where we'll ground our evaluation considerations.
+
+You’ve maybe heard the platitude that tells you how to think about whether to say things out loud: Is it true? Is it kind? Is it necessary? This is our version.
+
+**Slide 43:** In order to be effective, the transitions between phases need public, practical, easy-to-understand requirements. They'll need to be concrete and clear.
+And in order to be fair, we'll need to publish any requirements before we start any evaluation.
+
+**Slide 44:** So there are still a number of things to work out. This process _itself_ is in beta.
+
+I feel like I’m always the one to get meta in these calls, so here we go again. I’ll try to keep it brief.
+
+This whole thing is something we’re trying out. Our first but maybe-not-best attempt; though certainly the best we think works right now. We don’t know how well it will work, so we’re open to change here. As we put it into action, I bet we’ll quickly find out if we need to revise. Tell us how it goes.
+
+**Slide 45:** So: let’s try it out! And we think that the best place for folks to start to engage with this process is at the beginning.
+How does this process start, for you, right now? Dan, want to give us that starting point?
+
+**Slide 46:** DW: Thanks Anne, this is Dan again. Since we're actively building a process we hope to refine with real contributions and community participation, it makes sense to start where we think we'll need participation from lots of perspectives: at the beginning, with the **component proposal** process.
+
+**Slide 47:** And in our process, we're starting with a discussion.
+
+**Slide 48:** As I'd mentioned earlier, our second metaphor for solving complex problems is one I'd described as finding the elephant.
+
+This is like the story of the blind sages who each encounter only a specific part of an elephant, and thus, individually, can describe only that specific aspect. The trunk appears as a snake, the leg as a tree, the tail as a rope, the ear as fan. This is often understood as a parable about the limits of perception. But the ultimate moral depends on if and how the sages react to the knowledge of their peers. Their knowledge is distributed, their understanding is necessarily influenced by their perspective, so where do they go from there? What can they do with this distributed knowledge? How can they coordinate these different perspectives into an integrated, coherent model?
+
+I will say that here at the design system, we wish to find the elephant. And we aim to build a place and a process where we might collect and expand our perspectives in the service of an integrated understanding.
+
+**Slide 49:** In our case the elephant in the room is a proposal for a component.
+
+What do we need to ask about it? What perspectives do we need to understand it?
+
+Why this component? What interactions does it support? When do you use it? When should you consider something else? What are its accessibility considerations? How do you use it when you can't see it? How might you control it with only your voice? What harm might it unintentionally cause? What should a team need to know to start development? What do we already know that can help a development team start from a place of known knowns and known unknowns?
+
+**Slide 50:** To that end, we need every component to begin with a discussion.
+
+**Slide 51:** And the point of that discussion is to describe the _shape_ of a proposal.
+
+**Slide 52:** Not a requirements doc, but a _case_.
+
+**Slide 53:** Not a prescriptive document, but an _actionable_ one.
+
+**Slide 54:** And we believe that the more participation we can generate, the better the proposals we can deliver.
+
+So to talk about the process we're launching today, here's Amy.
+
+**Slide 55:** AL: Thanks, Dan. This is Amy again. Our new proposal process is how we introduce new component ideas and evaluate them.
+
+**Slide 56:** Our first goal was to make the process **intuitive** for all kinds of contributors. We wanted something that was more welcoming to anyone who has a perspective on components: folks like designers, usability experts, accessibility pros, and writers — not just developers.
+
+**Slide 57:** Our second goal was to make the process **incremental**. As Dan mentioned earlier, we wanted to lower the burden on contributors suggesting new component ideas. To lower the barriers to participation at each step.
+
+So we knew we wanted to make the component proposal something we _all_ can build, collaboratively, a bit at a time. Not something where a single person or team needs to put their heads down for a month and return with a finished document, then repeat and repeat. This is more like how the process was working before, and, honestly, it wasn't _really_ working.
+
+We've developed a new component proposal process that has two distinct parts, sort of a frontstage and a backstage.
+
+**Slide 58:** The frontstage is a new Component Proposal discussion board that will be the persistent home for public, community conversation about new components. You can find this new discussion board at [github.com/uswds/uswds/discussions/categories/component-proposals](https://www.google.com/url?q=https://github.com/uswds/uswds/discussions/categories/component-proposals&sa=D&source=docs&ust=1711663441787743&usg=AOvVaw1Fe3HHeStdk-sosZMHy_rb). On this slide, there's a screenshot of this proposals board, with a pinned post reading, "Getting started with USWDS component discussions."
+
+**Slide 59:** The backstage is a new proposals repo, uswds-proposals, at [github.com/uswds/uswds-proposals](https://www.google.com/url?q=https://github.com/uswds/uswds-proposals&sa=D&source=docs&ust=1712093682783342&usg=AOvVaw1001oegxcZVR0lPvLlqXlP).
+
+On this slide we see a screenshot of this new proposals repo. It features a README with the text, "USWDS component proposal process."
+
+This is where the USWDS core team collects what we've learned from these discussions into formal component proposals. It will be the new place where we document our decisions and reasoning. If you're familiar with the concept of Architectural Decision Records (or ADRs) that's pretty much what we're starting here, starting with new component decisions.
+
+But really, the discussions are where the action will be. So let’s take a look at how we think discussions can work.
+
+**Slide 60:** The new Component Proposal board in GitHub Discussions is the **central hub** for community discussion about new USWDS component ideas. This is where the community should work through all the merits, risks, and potential design of the component.
+
+**Slide 61:** We chose to use a GitHub discussion board because it's a tool we're already using, and it's designed for conversations. And these discussions _are_ conversations, not issues or pull requests. You don't even need to know what an issue or a pull request _is_ to get involved.
+
+This discussion board has a lot of the tools folks expect for managing discussions:
+
+ * There are threaded comments to help organize different topics of conversation.
+
+ * There are simple ways to sort and filter discussions, and labeling as well.
+
+ * And discussions also offer native upvoting functionality, which gives everyone an easy method for expressing interest in a component, and gives the USWDS team an easy
+ method of assessing that interest.
+
+**Slide 62:** What do you need to know to start a discussion? Really, just two things:
+
+ * Are you interested in suggesting a new component?
+
+ * And, is there already an existing discussion about that new component?
+
+If you are, and there isn't, go ahead and start a new discussion!
+
+**Slide 63:** Discussions are meant to be **incremental**. You can start with a lot or a little. The person who authors the discussion doesn't need to know everything. We'll work it all out together eventually.
+
+Discussions are meant to be **informal**. Of course, be formal if that's your style, but we aren't expecting to post and exchange formal briefs, we're trying to work out a common understanding together. But it's also worth pointing out that we all agree to a code of conduct to participate. Informal doesn't mean uncivil.
+
+And discussions are meant to be **persistent**. We want to have a single discussion related to a component that we can all use as a common reference and a common place for communication as a component moves through the Proposal phase and into assignment and development.
+
+**Slide 64:** So if you want to check out new component discussions and maybe start a new one yourself, head over to [github.com/uswds/uswds/discussions/categories/component-proposals](https://www.google.com/url?q=http://github.com/uswds/uswds/discussions/categories/component-proposals&sa=D&source=docs&ust=1711663441789995&usg=AOvVaw0mX5Q-VhtQsBwgFnBAwMJ5).
+
+We've been converting existing component-request issues into discussions, and the current contents of that board should be up to date, but if you know you've submitted a component-request issue and don't see it there, let us know.
+
+**See a component you'd like to see in the design system?** Get involved in that discussion.
+
+**Got a new component idea that's not yet on the board?** Select New discussion and start a new one.
+
+**Slide 65:** So - What do we hope to get out of these discussions? How do we turn discussions into proposals? And what happens next? For that, I'll pass it back to Anne.
+
+**Slide 66:** AP: Thanks Amy. This is Anne. While proposal discussions are freeform, we are looking to collect a few specific bits of information that will help us understand the component better, and lead to the proposal that could form the practical starting point for component development, which is the next phase in the life cycle.
+
+**Slide 67:** First, we want to address some general information about the proposed component:
+
+ * What's the common name (or names) of this component?
+
+ * What gap does it fill in the design system? And how is this different from existing USWDS components?
+
+ * And does this component directly support any federal laws, guidance, or policies?
+
+**Slide 68:** As well as potential design ideas and context:
+
+ * What's the potential core functionality of this component?
+
+ * Are there any examples of how the component might work?
+
+**Slide 69:** We'll want to address what this component is _used_ for.
+
+We want to outline the appropriate use cases:
+
+ * What common interactions does this component support?
+
+ * What does this component need to do to be successful and effective?
+
+ * What kind of content — that is, information inside it — would be ideal for this component?
+
+**Slide 70:** And also scenarios where this component would _not_ be the appropriate choice:
+
+ * Are there common ways this type of component is misused?
+
+ * Are there similar interactions that would be better supported by other components?
+
+ * What kind of content should teams not use with this component?
+
+**Slide 71:** We also want to understand any usability considerations, with supporting evidence if possible.
+
+From a usability or UX perspective, we want to understand:
+
+ * What are the characteristics of a successful interaction with this component? How does that interaction go?
+
+ * What would make this component less usable?
+
+ * What are common pitfalls or implementation mistakes associated with this component?
+
+ * How might the mobile context affect how folks use this component?
+
+**Slide 72:** From the accessibility perspective we want to understand:
+
+ * Will this component cause difficulty for people who use any assistive technologies?
+
+ * And could this component be difficult for any other audiences?
+
+**Slide 73:** And finally, we want to identify potential stakeholders, advocates, and volunteers related to the component. These are folks willing to help design, develop, or test the component, and any significant support from an agency or group.
+
+**Slide 74:** These questions are the common criteria we'll use to create a formal proposal document. We'll prompt discussions to make sure we cover all this, then we'll collect it into a formal proposal in our uswds-proposals repo as a decision-record candidate.
+
+**Slide 75:** When the formal proposal is complete, we'll post it back into the discussion for a final comment period of at least 45 days before we evaluate it.
+
+The **comment period** is an opportunity to tell us what works and what doesn’t about this proposal, before we evaluate the proposal as a team to consider how the proposed component fits into the system and its needs, including the needs of the teams who use it. So again, your input is important.
+
+If we approve the proposal, it moves to the **assignment period:** where an individual or team can take that proposal into development. This _might_ be the USWDS team, but it doesn't have to be.
+
+**Slide 76:** Throughout the process, we'll highlight active discussions in our newsletter and in these monthly calls. We don’t want to overwhelm folks with these, but we'll be working hard to get you — the USWDS community — involved, and highlight opportunities to contribute from month to month, and keep everyone up to date as we refine this process.
+
+We want to make this as easy as we can. Help us understand what will work for you, to facilitate your contributions and thoughts and experiences. We can all help, to help each other.
+
+**Slide 77:** And if interacting on GitHub isn’t an option for you, you can always email us at uswds@gsa.gov, and we can cross-post your proposal, comment, or vote.
+Now I'll pass it back to Dan to wrap things up.
+
+**Slide 78:** DW: Thanks Anne. We've done a lot and we still have a lot to do.
+
+And I'd like to acknowledge that getting this far has been a really big team effort for us, and I appreciate how our team's been able to put this work together.
+
+This is important because this process stuff is what everything else is built from. I think what we're beginning to develop here is the nervous system for the design system, and perhaps, by extension, a nervous system for digital service practitioners across government — helping a complex system move with coordination and intention because we've connected activities and information from across the network.
+
+**Slide 79:** We're still working to take baby steps, but this is really what it's all about when I think about the USWDS mission: Shaping the future of government digital services. This process of shaping is complex and interesting and can be really challenging and satisfying. And it's something we can only effectively do together. And I know if we keep at it, there's going to be an elephant in there… somewhere.
+
+**Slide 80:** Q&A
+
+**Slide 81:** Thanks for joining today’s USWDS monthly call. We'll be back in March with a dev-focused call, about building new things with USWDS that feel like USWDS. It'll be a nice follow-up from this call, as we start to think about how the component lifecycle moves from proposal to development!
+
+If you have a question we weren't able to answer in the call, or thought of later, please head into our public Slack and ask it there. We'll be around after the call to answer questions.
+
+Have a great day and we'll see you next month!
+
+{{< /accordion >}}
+
Join the U.S. Web Design System (USWDS) team to learn more about the complete lifecycle of a USWDS component.
In this session, you will learn:
diff --git a/content/guides/accessibility-for-teams/_index.md b/content/guides/accessibility-for-teams/_index.md
new file mode 100644
index 0000000000..0e8e34b194
--- /dev/null
+++ b/content/guides/accessibility-for-teams/_index.md
@@ -0,0 +1,42 @@
+---
+date: 2017-02-01 09:00:00 -0500
+title: "Accessibility for Teams"
+deck: "A ‘quick-start’ guide for embedding accessibility and inclusive design practices into your team’s workflow"
+summary: "A ‘quick-start’ guide for embedding accessibility and inclusive design practices into your team’s workflow"
+guide: accessibility-for-teams
+image: accessibility-for-teams-guide
+primary_image: accessibility-for-teams-guide
+topics:
+ - accessibility
+ - product-and-project-management
+ - user-experience
+ - design
+ - content-strategy
+ - human-centered-design
+ - user-centered-design
+ - software-engineering
+ - mobile
+ - usability
+ - research
+layout: single
+---
+
+Everyone who works on government websites has a role to play in making federal resources accessible and inclusive.
+
+**This guide provides:**
+
+- An overview of how each team member can contribute to a product's accessibility.
+- A framework for thinking about accessibility and inclusive design in your role.
+- An understanding of the human need behind accessibility practices.
+
+We focus on the issues most likely to impact government sites. These guidelines do not provide a comprehensive list of all possible issues. Your team will need additional resources and work to conduct manual audits to conform to the standards of [Section 508](https://www.section508.gov/), a law that ensures all web content is accessible to anybody with a disability. It aligns with the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) [Web Content Accessibility Guidelines (WCAG) 2.0, Level AA](https://www.w3.org/WAI/WCAG22/quickref/?versions=2.0¤tsidebar=%23col_overview&levels=a%2Caaa).
+
+Choose the guide that best fits your role:
+
+1. Product management
+2. Content design
+3. User Experience (UX) design
+4. Visual design
+5. Front-end development
+
+_These roles are based on the roles we have at the Technology Transformation Services at GSA._
diff --git a/content/guides/accessibility-for-teams/content-design.md b/content/guides/accessibility-for-teams/content-design.md
new file mode 100644
index 0000000000..d10d9f6a86
--- /dev/null
+++ b/content/guides/accessibility-for-teams/content-design.md
@@ -0,0 +1,253 @@
+---
+date: 2018-07-09 09:00:00 -0500
+title: "Accessibility for content designers"
+deck: "Accessible writing ensures your content is easier for everyone to read. As we build government services, we want to ensure they are accessible and welcoming to everyone who needs to use them."
+summary: ""
+guide: accessibility-for-teams
+primary_image: accessibility-for-teams-guide
+summary_box: true
+topics:
+ - accessibility
+ - product-and-project-management
+ - user-experience
+layout: single
+---
+
+## Getting started
+
+**How to use this guide:**
+
+- We recommend conducting accessibility testing throughout the design and development processes.
+- If you have project-specific questions, ask your agency’s accessibility team.
+
+## Plain language
+
+Can you quickly understand the main points of the content?
+
+### Why it's important
+
+- Karin is not a native English speaker and she sometimes has trouble decoding legal or bureaucratic language.
+- John has a developmental disability and has difficulty interpreting content written above a sixth-grade reading level.
+- Kai has low tech literacy and often doesn’t understand highly technical language.
+
+### Steps to take
+
+1. Refer to the [plain language section](https://pages.18f.gov/content-guide/plain-language/) of 18F’s Content Guide for general guidance, lists of words to avoid, and links to plain-language resources.
+2. As you’re writing, consider the tech literacy level of your target audience. Define technical terms that may be unfamiliar, and use a product or service’s full name before using its acronym or abbreviation. You may also consider [adding a glossary](https://github.com/18F/glossary) if your content contains many potentially unfamiliar terms. Include in-line definitions for scientific, legal, or technical terms that you must use.
+4. Avoid using idiomatic language.
+5. Test the readability of your content using [Hemingway App](http://www.hemingwayapp.com/), [Readable.io](https://readable.io/), or a similar tool.
+
+### Resources
+
+- [PlainLanguage.gov Federal plain language guidelines](https://www.plainlanguage.gov/guidelines/)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+ - [3.1 Readable (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/#meaning)
+ - [3.1.3 Unusual Words](https://www.w3.org/WAI/WCAG20/quickref/#meaning-idioms)
+ - [3.1.4 Abbreviations](https://www.w3.org/WAI/WCAG20/quickref/#meaning-located)
+ - [3.1.5 Reading Level](https://www.w3.org/WAI/WCAG20/quickref/#meaning-supplements)
+
+
+## Reference materials
+
+Can you easily access supplementary information clarifying the content?
+
+### Why it's important
+
+- Gilbert reads at a twelfth-grade level but isn’t familiar with the nuances of a site’s subject matter; to fully understand the site content, he needs easy-to-access contextual information.
+
+### Steps to take
+
+1. Consider defining technical or other potentially unfamiliar terms in=line; this creates a much more continuous reading experience for the user.
+2. If you find that you need to define a large number of terms within your content, consider adding a separate glossary page.
+3. Use hyperlinks or a tooltip rather than footnotes to direct users to definitions. Footnotes can create a jarring reading experience, and they may not render correctly on mobile devices.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [3.1.3 Unusual Words](https://www.w3.org/WAI/WCAG20/quickref/#meaning-idioms)
+
+
+## Easy-to-parse graphic elements
+
+Can you easily interpret content associated with graphic elements?
+
+### Why it's important
+
+- Marisa primarily uses her mobile device to browse websites and has trouble interpreting visualizations with small text.
+
+### Steps to take
+
+1. Include visual elements in line with text rather than separated from it; a graphic’s proximity to associated content helps reinforce the relationship between the visual and its written description.
+2. Make sure all graphics have descriptive captions (if necessary). Also make sure that captions share a common form and voice.
+3. Include meaningful information describing each graphic element in the alt text.
+4. Use null (empty) alt text when text describing the graphic element is already on the page (`alt=""`).
+5. If the graphic element is decorative and you don’t want the screen reader to announce it at all, use null (empty) alt text (`alt=""`).
+6. Consider presenting dense technical language in a format other than as part of a graphic. When compressed to mobile view (in other words, a harder-to-read format), graphs and charts with technical language can be tough to interpret.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1 Text Alternatives (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview&tags=images%2Cimages-of-text%2Ctext-alternatives#text-equiv)
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#text-equiv-all)
+- [1.4.5 Images of Text](https://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation)
+
+
+## Scannable content
+
+Can you scan the page without having to pause for long passages? Can you quickly grasp the meaning of a section based on its heading?
+
+### Why it's important
+
+- Jerrold has a cognitive disability that makes it difficult for him to read long, uninterrupted passages of text.
+- Sharon reads most online content using her mobile device and finds it difficult to navigate long paragraphs.
+
+### Steps to take
+
+1. Use short sentences, whenever possible. Varying sentence length can add interest to a piece, but whenever possible, avoid unnecessarily long sentences — these can present obstacles to people who have difficulty reading. They can also be harder to skim on mobile devices.
+2. Likewise, keep your paragraphs short and focused. Short paragraphs, like short sentences, are easier to scan on mobile devices.
+3. Use precise and descriptive [headings](https://content-guide.18f.gov/headings-and-titles/) to help readers grasp the main points of a piece without reading it in its entirety.
+4. Check the continuity between sections. Paragraphs that don’t have clear thematic links from one to the next can cause difficulties for some readers.
+
+### Resources
+
+- [18F Content Guide: Headings and titles](https://content-guide.18f.gov/headings-and-titles/)
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [2.4.6 Headings and Labels](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#navigation-mechanisms-descriptive)
+- [3.1.5 Reading Level](https://www.w3.org/WAI/WCAG20/quickref/#meaning-supplements)
+
+
+## Images
+
+Do your images have descriptive alternative ("alt") text?
+
+### Why it's important
+
+- Carmen’s page didn’t load all the way and didn’t get to download the images.
+- Amanda is blind and uses a braille reader to understand the contents of images.
+- John is looking for information with a search engine and needs help being directed to the right content (descriptive alt tags will improve search).
+
+### Steps to take
+
+1. Include meaningful information describing each image in the alt text.
+2. Use null (empty) alt text when text describing the image is already on the page (`alt=""`).
+3. Don’t start the alt text with _Image of_ or _Photo of_ – the screen reader already announces that images are images.
+4. If the image is decorative and you don’t want the screen reader to announce it at all, use null (empty) alt text (`alt=""`).
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1 Text Alternatives (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview&tags=images%2Cimages-of-text%2Ctext-alternatives#text-equiv)
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#text-equiv-all)
+- [1.4.5 Images of Text](https://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation)
+
+Video tutorial:
+
+- Text alternatives
+
+{{< youtube id="XCa6U1BllCY" title="Text Alternatives" >}}
+
+
+## Links
+
+Do all links have proper descriptive text?
+
+### Why it's important
+
+- Jerry is blind and uses a screen reader to navigate the web. He often uses the `tab` key to quickly scan a page by reading out only the text links without the surrounding copy.
+
+### Steps to take
+
+1. Make sure the voice and tone of your link text match those of the rest of the content to create a more continuous user experience. Folks using screen readers and those reading page copy won’t be jarred from their experience if all text reflects the same voice and tone guidelines.
+2. Create link text that’s as specific as possible. For example, instead of using Click here (which may not make sense for folks using screen readers), consider instead something like Download the full report. Descriptive links provide all users more information about an action they may undertake.
+3. Include information about what a link leads to; this is especially important for folks who use mobile devices. If you’re linking to a PDF, say so.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#text-equiv-all)
+- [2.4.4 Link Purpose (In Context)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-refs)
+
+
+## Information architecture
+
+Is your site organized such that everyone can navigate it easily?
+
+### Why it's important
+
+- Beth has a lower tech literacy level and needs a site’s layout to be clear.
+- Julian has low vision and uses a screen reader to navigate the web. Kendra has a newborn and her attention is often divided; she needs to be able to understand a site’s contents at a glance.
+- Lyle is undergoing a crisis and needs to quickly find just the content pertinent to him.
+
+### Steps to take
+
+1. Write descriptive page titles. Users who rely on assistive technologies like screen readers may not be able to use visual cues to determine a page’s purpose. Make sure your page titles concisely convey each page’s focus.
+2. Make sure users can navigate a site in multiple ways. Some strategies include providing a table of contents, providing a sitemap, linking between pages, and including sitewide search.
+3. Indicate changes in language (for example, when including a foreign word in a predominantly English text). This will help people using screen readers, people with cognitive disabilities, and folks using braille translation software to fully understand your content.
+4. Use a screen reader or simulator to make sure you can land on controls and that they’re announcing things as they should.
+5. Determine whether the HTML document has a language attribute so that screen readers will read it with the correct accent and pronunciation. For example: ``. (Note: If you’re not comfortable taking this step, feel free to ask another designer on your project team to help.)
+6. If forms are present, make sure the screen reader reads labels and instructions.
+
+### Use VoiceOver screen reader on Mac
+
+- **Turn VoiceOver on**: command (⌘) + F5
+- **Go into web area**: control + alt + shift + down arrow (⬇)
+- **Navigate right**: control + alt + right arrow (➡️️)
+- **Navigate by heading**: control + alt + command (⌘) + H
+- **Click**: control + alt + spacebar
+
+Use rotor to browse pages. The rotor lists common elements like headings, links, and images, and lets you navigate directly to the element of your choosing.
+
+- **Turn on rotor**: control + alt + U
+- **Navigate rotor**: left and right, up and down arrows
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#content-structure-separation-programmatic)
+- [2.4.1 Bypass Blocks](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-skip)
+
+
+## Video and multimedia
+
+Is everyone able to access your multimedia content?
+
+### Why it's important
+
+- Blake is hearing-impaired and cannot rely on audio.
+- Sandra is a non-native English speaker and has difficulty understanding video.
+
+### Steps to take
+
+1. Make sure that captions are synchronized to appear around the same time that they would be heard in the audio.
+2. Captions do not need to be a word-for-word version of the audio, but should be a concise equivalent.
+3. Use a modern video player that supports captions.
+4. If you've captioned your video, provide a transcript as one of the optional output formats produced by the closed captioning process.
+ - To make the transcript available, link to it from your web page, wherever you link to or display the associated video.
+5. Audio description is required when important information is visually shown on the screen that cannot be observed by a blind or vision-impaired individual.
+
+### About transcripts
+
+A transcript is a text version of the media content. A transcript should capture all the spoken audio, plus on-screen text and descriptions of key visual information that wouldn’t otherwise be accessible without seeing the video. Transcripts make video content accessible to everyone, including people who are unable to view the video due to accessibility problems or technical limitations. They are also helpful for people who want to quickly scan or search a video’s content but do not have the time to watch the entire video.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1 Text Alternatives (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview&tags=images%2Cimages-of-text%2Ctext-alternatives#text-equiv)
+- [1.2.2 Captions (Prerecorded)](https://www.w3.org/WAI/WCAG21/quickref/#captions-prerecorded)
+- [1.2.4 Captions (Live)](https://www.w3.org/WAI/WCAG21/quickref/#captions-live)
+
+---
+
+**Disclaimer**: All references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.
diff --git a/content/guides/accessibility-for-teams/front-end-development.md b/content/guides/accessibility-for-teams/front-end-development.md
new file mode 100644
index 0000000000..ad600285c2
--- /dev/null
+++ b/content/guides/accessibility-for-teams/front-end-development.md
@@ -0,0 +1,260 @@
+---
+date: 2018-07-09 09:00:00 -0500
+title: "Accessibility for front-end developers"
+deck: ""
+summary: ""
+guide: accessibility-for-teams
+primary_image: accessibility-for-teams-guide
+summary_box: true
+topics:
+ - accessibility
+ - product-and-project-management
+ - user-experience
+layout: single
+---
+
+## Getting started
+
+Accessible front-end development ensures people with different abilities can access, understand, and navigate web content, regardless of how they're accessing it. Front-end developers collaborate with other members of a cross-functional team to implement a robust user experience.
+
+**How to use this guide:**
+
+- We recommend conducting accessibility testing throughout the design and development processes.
+- A good place to start testing is on high-touch pages, critical user paths, and site-wide templates.
+- If you have project-specific questions, ask your agency’s accessibility team.
+
+## Keyboard access
+
+Can you reach anything that’s interactive using the tab key?
+
+### Why it's important
+
+- Maria has tendonitis and is unable to use a mouse; instead, she uses the keyboard to navigate the web.
+
+### Steps to take
+
+1. Use the keyboard to navigate through the page using the `tab` key.
+2. Make sure you can reach all interactive elements and trigger them with the `spacebar`, `enter` key, or arrow keys.
+ - Use semantic HTML elements that are accessible by default (For example: buttons, labeled inputs, etc.). If you must use divs for interactions, ensure they are focusable and labeled appropriately.
+3. Check to see that focus is always visible and appears in logical order.
+4. Make sure that no content gets focused offscreen or is hidden from view.
+5. Check to see that the page includes a skip navigation link (if navigation is present before the main content). This will allow users to skip past navigation to reach the page’s main content.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [2.1 Keyboard Accessible (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#keyboard-operation)
+- [2.1.1 Keyboard](https://www.w3.org/WAI/WCAG20/quickref/#keyboard-operation-keyboard-operable)
+- [2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG20/quickref/#keyboard-operation-trapping)
+- [2.4.3 Focus Order](https://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms-focus-order)
+- [2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms-focus-visible)
+
+Video tutorial:
+
+- How I do an accessibility check
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility check" >}}
+
+
+## Screen reader
+
+Can you use a screen reader to access the page content?
+
+### Why it's important
+
+- Devonte is blind and uses a screen reader to navigate the web.
+
+### Steps to take
+
+1. Use a screen reader to make sure you can land on controls and that they’re announcing things as they should.
+2. Determine whether the HTML document has a language attribute so that screen readers will read it with the correct accent and pronunciation. For example: ``.
+3. If forms are present, make sure the screen reader reads labels and instructions.
+4. Make sure that all links are properly descriptive. For example, the link text "Read More" provides no context about where the user will go if they click it, while "Read more about dinosaurs" describes what’s on the other side of the link.
+
+### Use VoiceOver screen reader on Mac
+
+- **Turn VoiceOver on**: command (⌘) + F5
+- **Go into web area**: control + alt + shift + down arrow (⬇)
+- **Navigate right**: control + alt + right arrow (➡️️)
+- **Navigate by heading**: control + alt + command (⌘) + H
+- **Click**: control + alt + spacebar
+
+Use rotor to browse pages. The rotor lists common elements like headings, links, and images, and lets you navigate directly to the element of your choosing.
+
+- **Turn on rotor**: control + alt + U
+- **Navigate rotor**: left and right, up and down arrows
+
+### Resources
+
+- [Download NVDA screen reader (NV Access)](https://www.nvaccess.org/download/)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#content-structure-separation-programmatic)
+
+Video tutorials:
+
+- Screen Reader Basics: VoiceOver
+
+{{< youtube id="5R-6WvAihms" title="Screen Reader Basics: VoiceOver" start_time="145" >}}
+
+- Video tutorial: How I do an accessibility check (screen reader)
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility check (screen reader)" start_time="145" >}}
+
+
+## Headings
+
+Are you using accurate headings on your page?
+
+### Why it's important
+
+- Lalit is blind and uses a screen reader to navigate the web. She hears an outline of the page's main ideas, then backtracks to read the parts she's most interested in.
+
+### Steps to take
+
+1. Headings briefly describe the section it introduces. Headings represent an outline of the content.
+2. Use `h1`–`h6` to define your section headings, where `h1` is the highest section level and `h6` is the lowest.
+3. Avoid skipping heading levels: Always start with `h1`, use `h2` next, and so on.
+4. Use only one `h1` per page for the page title.
+
+{{< note >}}
+While HTML5 allows you to reset headings to `h1` on new section elements, some screen reader users will have difficulty discerning the structure of pages with multiple h1s. For this reason, it’s best to include only one h1 per page.
+{{< /note >}}
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [2.4.6 Headings and Labels](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#navigation-mechanisms-descriptive)
+
+Video tutorials:
+
+- Using headings
+
+{{< youtube id="ZHWcs5d9IqA" title="Using Headings" >}}
+
+- How I do an accessibility check (page structure)
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility check (screen reader)" start_time="381" >}}
+
+
+## Page structure
+
+Are you using semantic elements and roles?
+
+### Why it's important
+
+- Carlos is low-sighted and navigates pages by jumping to the page section he wants to get to.
+
+### Steps to take
+
+1. Use sectioning elements to create a broad outline of your page content; examples of these elements include `header`, `nav`, `main`, and `footer`. Use content sectioning elements like `section`, `article`, and `aside` to organize the document content into logical pieces.
+2. Add `role="banner"` to your masthead and `role="contentinfo"` to your page footer once per page to define landmark elements.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#content-structure-separation-programmatic)
+- [2.4.1 Bypass Blocks](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-skip)
+
+Video tutorial:
+
+- Landmarks
+
+{{< youtube id="bww3IaktlRY" title="Landmarks" start_time="12" >}}
+
+
+## Images
+
+Do images have good alt text?
+
+### Why it's important
+
+- Carmen’s page didn’t load all the way and didn’t get to download the images.
+- Amanda is blind and has to read the alt text to understand the contents of the image.
+- John is looking for information with a search engine and needs help being directed to the right content (descriptive alt text will improve search).
+
+### Steps to take
+
+1. Include meaningful information describing each image in the alt text.
+2. Use null (empty) alt text when text describing the image is already on the page (`alt=""`).
+3. Don’t start the alt text with _Image of_ or _Photo of_ – the screen reader already announces that images are images.
+4. If the image is decorative and you don’t want the screen reader to announce it at all, use null (empty) alt text (`alt=""`) or CSS background images.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1 Text Alternatives (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview&tags=images%2Cimages-of-text%2Ctext-alternatives#text-equiv)
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#text-equiv-all)
+- [1.4.5 Images of Text](https://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation)
+
+
+## Color and contrast
+
+### Why it's important
+
+Is there enough contrast between text and its background color?
+
+- Rohit has low vision and needs content to have enough contrast to read it.
+- Esther is red-green colorblind and can’t make sense of information conveyed with color alone.
+
+### Steps to take
+
+1. Use a [color contrast](http://webaim.org/resources/contrastchecker/) tool and test that the contrast between the text and background is greater than or equal to 4.5:1.
+2. Use an [automated tool](http://wave.webaim.org/) to quickly scan for color contrast problems.
+3. Don’t use color alone to convey meaning. Use icons, text, and other visual elements to reinforce the meaning of the content.
+
+### Resources
+
+- [WebAIM Color Contrast Checker](https://webaim.org/resources/contrastchecker/)
+- [Accessible Colors](http://accessible-colors.com/)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.4.3 Contrast (Minimum)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#visual-audio-contrast-contrast)
+
+Video tutorials:
+
+- Meeting contrast requirements
+
+{{< youtube id="gH1JieTZQ1k" title="Meeting Contrast Requirements" >}}
+
+- How I do an accessibility check (contrast)
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility checks" start_time="516" >}}
+
+
+## Automated testing
+
+Did your accessibility testing tools provide accurate results?
+
+### Why it's important
+
+Including automated accessibility testing throughout the development process can help quickly catch [many accessibility errors](https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/), but can’t guarantee that your site is accessible.
+
+Always combine automated testing with ongoing manual testing. Manual testing is the most reliable method to assess accessibility.
+
+### Steps to take
+
+1. **Quick check**: Use a tool to quickly check for common errors in your browser. You can use [HTML CodeSniffer](http://squizlabs.github.io/HTML_CodeSniffer/), [aXe](https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US), [Lighthouse Accessibility Audit](https://developers.google.com/web/tools/lighthouse/), [Accessibility Insights](https://accessibilityinsights.io/), or [WAVE](http://wave.webaim.org/extension/).
+2. **Build process**: Integrate a tool like [axe-core](https://github.com/dequelabs/axe-core), [jsx-a11y](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y), [Lighthouse Audits](https://github.com/GoogleChrome/lighthouse/blob/master/docs/readme.md#using-programmatically), or [AccessLint.js](https://github.com/accesslint/accesslint.js/tree/master) into your project to programmatically add accessibility tests and catch errors as you build out your website.
+3. **Continuous integration**: Use a tool like [AccessLint](https://www.accesslint.com/) to find accessibility issues in your GitHub pull requests.
+4. **Simulate impairments**: Use tools to simulate color blindness, low vision, zoom, low contrast, high contrast, and more.
+
+### Resources
+
+- [GOV.UK: What we found when we tested tools on the world’s least-accessible webpage](https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/)
+
+Video tutorial:
+
+- How I do an accessibility check (tools and extensions)
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility checks" start_time="537" >}}
+
+---
+
+**Disclaimer**: All references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.
diff --git a/content/guides/accessibility-for-teams/product-management.md b/content/guides/accessibility-for-teams/product-management.md
new file mode 100644
index 0000000000..36cd9b47a6
--- /dev/null
+++ b/content/guides/accessibility-for-teams/product-management.md
@@ -0,0 +1,97 @@
+---
+date: 2018-07-09 09:00:00 -0500
+title: "Accessibility for product managers"
+deck: ""
+summary: ""
+guide: accessibility-for-teams
+primary_image: accessibility-for-teams-guide
+summary_box: true
+topics:
+ - accessibility
+ - product-and-project-management
+ - user-experience
+layout: single
+---
+
+## Getting started
+
+Product managers play a vital role in communicating accessibility requirements early in the project lifecycle, ensuring each team member knows their responsibility, and keeping the team accountable for building accessible products. Following these steps, you’ll make sure you’re not only following legal requirements, but making your product more usable for everyone.
+
+### Why you should care
+
+Any product released by the government must conform to the standards of [Section 508](https://www.section508.gov/) (which aligns with the [W3C Web Content Accessibility Guidelines (WCAG) 2.0, Level AA](https://www.w3.org/WAI/WCAG22/quickref/?versions=2.0¤tsidebar=%23col_overview&levels=a%2Caaa)), a law that ensures all web content is accessible to anybody with a disability. Not following these requirements poses significant legal risks for any government entity.
+
+If you have project-specific questions, ask your agency’s accessibility team.
+
+
+## Accessibility basics
+
+Learn the basics of accessibility and what your team does to make content accessible.
+
+### Steps to take
+
+1. Familiarize yourself with the high-level accessibility roles for each member of your team:
+ - [Front-end development]({{< link "/guides/accessibility-for-teams/front-end-development" >}}): Ensure front-end code is written accessibly and conducts manual and automated testing.
+ - [Visual design]({{< link "/guides/accessibility-for-teams/visual-design" >}}): Ensure that designs are accessible, pages are laid out in a logical order, and content meets color contrast requirements.
+ - [UX design]({{< link "/guides/accessibility-for-teams/ux-design" >}}): Ensure that overall experience is built and designed in an accessible fashion, conduct usability testing with people who need accessibility features.
+2. Ensure your team members know where to find the accessibility guidelines for their role and follow them from the start of a project. The guides are located here: [front-end]({{< link "/guides/accessibility-for-teams/front-end-development" >}}), [content design]({{< link "/guides/accessibility-for-teams/content-design" >}}), [ux design]({{< link "/guides/accessibility-for-teams/ux-design" >}}), and [visual design]({{< link "/guides/accessibility-for-teams/visual-design" >}}).
+3. Take an introductory-level class to get a baseline knowledge of accessibility.
+4. Learn how to [navigate a webpage using only your keyboard]({{< link "/guides/accessibility-for-teams/visual-design/#keyboard-access" >}}) and [learn how to use VoiceOver]({{< link "/guides/accessibility-for-teams/visual-design" >}}) so you can spot check new features when necessary.
+
+### Resources
+
+- [An introduction to accessibility](https://digital.gov/resources/an-introduction-to-accessibility/)
+- [Section508.gov accessibility training, tools, and events](https://www.section508.gov/training/)
+
+
+## Diverse users
+
+Consider how everyone will use the product.
+
+### Steps to take
+
+1. **Don’t assume that your users don’t have accessibility needs.** Even if your product serves a small subset of users, any one individual may experience disabilities that are situational (working in a loud environment) or temporary (having an arm in a cast), or develop a permanent one.
+2. **Consider inclusion in your research and usability testing with a range of people** across ages, races, locations, devices, interests, abilities, languages, English proficiency, gender identities, sexual orientations, and access to reliable internet.
+3. **Consider testing your product with people in their own context**, such as people who use alternative reading devices, have color blindness impairments, or motor impairments.
+4. **Set a regular cadence** for testing accessibility scenarios.
+
+### Resources
+
+- [Personas for Accessible UX](https://prod.rm.gfolkdev.net/a-web-for-everyone/personas-for-accessible-ux/)
+
+
+## Project workflow
+
+Build accessibility into your project workflow rather than retrofitting it at the end.
+
+### Steps to take
+
+1. Encourage the team to account for accessibility when creating and estimating stories.
+2. Add accessibility as an acceptance criteria or definition of *done* for each story or new feature.
+3. Add accessibility testing into each development sprint or quality assurance (QA) check.
+4. Work with your front end developers to choose an [automated testing plan]({{< link "/guides/accessibility-for-teams/front-end-development" >}}).
+ - Including automated accessibility testing throughout the development process can help quickly catch [many accessibility errors](https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/), but can’t guarantee that your site is accessible. Always combine automated testing with ongoing manual testing.
+5. When a new accessibility issue arises that you may have missed, prioritize those issues appropriately against other development concerns:
+ - Consider whether the error is [critical, less critical, or minor](https://pages.18f.gov/accessibility/checklist/).
+ - Critical issues will cause serious problems and/or stop most users of assistive technology from using the site.
+ - Less critical issues may cause problems or increased frustration for certain users.
+ - Minor issues will cause problems or frustration for a small number of users.
+ - Consider prioritizing the issue if it appears on high-touch pages, critical user paths, or site-wide templates.
+
+
+## Final review
+
+Request a final review from an accessibility expert.
+
+### Steps to take
+
+1. In most cases, you may request a manual accessibility review from the accessibility team at your agency at least two weeks before a public launch. This ensures there’s enough time to conduct the review and make necessary changes. Since you've been manually testing throughout the project, this should be quick.
+2. Depending on your project’s requirements, you may also choose to hire an outside firm to conduct testing as part of your QA.
+
+### Resources
+
+- [Find your agency's 508 Program Manager](https://www.section508.gov/tools/program-manager-listing/)
+
+---
+
+**Disclaimer**: All references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.
diff --git a/content/guides/accessibility-for-teams/ux-design.md b/content/guides/accessibility-for-teams/ux-design.md
new file mode 100644
index 0000000000..2c8002c709
--- /dev/null
+++ b/content/guides/accessibility-for-teams/ux-design.md
@@ -0,0 +1,243 @@
+---
+date: 2018-07-09 09:00:00 -0500
+title: "Accessibility for user experience designers"
+deck: ""
+summary: ""
+guide: accessibility-for-teams
+primary_image: accessibility-for-teams-guide
+summary_box: true
+topics:
+ - accessibility
+ - product-and-project-management
+ - user-experience
+layout: single
+---
+
+## Getting started
+
+Accessibility is usability for people who interact with products differently. Your role is to help the team approach accessibility as a facet of user experience rather than checklist of requirements.
+
+**How to use this guide:**
+
+* If you have project-specific questions, ask your agency’s accessibility team.
+
+
+## Inclusive design
+
+Adopt an [inclusive design](https://inclusivedesignprinciples.org/) mentality
+
+1. Celebrate accessibility requirements as a set of design constraints that help you create a better product for all users.
+2. Gain a basic understanding of the main categories of disabilities, limitations, or constraints that affect how people use digital services:
+ - Vision disabilities – such as blindness, low vision, or color blindness
+ - Hearing disabilities – such as deafness, low hearing, or tinnitus
+ - Motor problems – such as hand tremors, physical deformities, or amputations
+ - Cognitive disorders – such as dyslexia, dementia, or being sleep deprived
+3. Understand that almost everyone experiences some type of disability either permanently, temporarily, or situationally. For example: having only one arm is a permanent condition, having an arm in a cast is temporary, and holding a baby in one arm is situational – but in each case you’re restricted to completing tasks with one arm.
+4. Look for ways that making your product easier to use for folks with disabilities also improves the experience for everyone.
+5. Design for progressive enhancement by making sure every person is able to use your product using the most basic technologies, while layering on better experiences for those who can use them.
+6. When conducting user research, make sure the diversity of your participants reflects the diverse abilities, circumstances, and backgrounds of your actual users.
+
+### Resources
+
+- [Microsoft’s Inclusive Design Manual](https://www.microsoft.com/design/inclusive/)
+- [Microsoft’s Inclusive Design Toolkit (PDF, 22 MB, 32 pages)](https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-4417-8f28-d60703d672ed/inclusive_toolkit_manual_final.pdf)
+- [Personas for Accessible UX](https://prod.rm.gfolkdev.net/a-web-for-everyone/personas-for-accessible-ux/)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3 Adaptable (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#content-structure-separation)
+- [1.3.3 Sensory Characteristics](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#content-structure-separation-understanding)
+
+
+## Assistive technology
+
+Get familiar with the basic ways people use assistive technology (AT).
+
+- Some assistive technologies are likely only going to be used by people with specific, long-term disabilities. These include screen readers, switch devices, screen magnifiers, and others. Other kinds of assistive technologies may be more familiar to you and include voice control on your cell phone, ergonomic keyboards, or a browser’s native zoom function. People have different skill levels in how they use these technologies.
+- To get a baseline knowledge of accessibility, take an "Accessibility 101" class, such as [Udacity’s Web Accessibility class](https://www.udacity.com/course/web-accessibility--ud891).
+- Learn how to [navigate a webpage using only your keyboard]({{< link "/guides/accessibility-for-teams/front-end-development/" >}}) and learn how to use a screen reader, [such as VoiceOver on your Mac]({{< link "/guides/accessibility-for-teams/front-end-development/#use-voiceover-screen-reader-on-mac" >}}) so you can spot check new features when necessary. This can help you understand the technology itself, but keep in mind that folks who use it every day will often have their own strategies for using these tools.
+- Observe people using assistive technology (AT) on your product or others. In some cases you may be able to find videos demonstrating how people use different strategies to interact with digital products.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3 Adaptable (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#content-structure-separation)
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#content-structure-separation-programmatic)
+
+
+## Humanize accessibility
+
+Humanize accessibility for your team:
+
+- Cover accessibility and inclusive design issues when conducting user research. Consider the native language, [literacy](http://contentsmagazine.com/articles/the-audience-you-didnt-know-you-had/), digital literacy, and digital access of your users as well as potential visual, hearing, motor, and cognitive disabilities.
+- Incorporate accessibility considerations in your personas, user archetypes, or user stories. This could take the form of swapping out [accessibility issues in your personas](https://www.perpendicularangel.com/portfolio/publications/published-on-the-pastry-box/an-alphabet-of-accessibility-issues/) or creating standalone user stories focused on accessibility.
+- Help your team learn about the experience of using your product with assistive technology. (Keep in mind that the way a person with a disability uses assistive tools may be very different from your experience of the tools.) This could include:
+ - Ask each person on your team to turn off their mouse and trackpad and navigate the product using only their keyboard.
+ - Under your computer's settings, look for the accessibility settings to change the display (Mac) or color filters (Windows) and switch to `grayscale` to explore your site without color to simulate color blindness.
+ - Find an appropriate [empathy prompt](https://empathyprompts.net/#diminished-problem-solving-skills) and walk your team through it.
+- When possible, include users with disabilities in user research. During usability testing, make sure to allow them to use their own equipment (which has their own settings already in place).
+
+### Resources
+
+- [Personas for Accessible UX](https://prod.rm.gfolkdev.net/a-web-for-everyone/personas-for-accessible-ux/)
+
+
+## Tab order
+
+Do your wireframes or design mockups indicate a logical tab order for people using a keyboard, or other assistive technology, to navigate?
+
+### Why it's important
+
+- Maria has tendonitis and is unable to use a mouse; instead, she uses the keyboard to navigate the web. When focus jumps randomly around the page she gets confused.
+
+Here are some other best practices for tab order.
+
+- A user should be able to use the tab key to navigate to every interactive element on a page.
+- For links, users should be able to activate them with the enter key.
+- For buttons, users should be able to activate them with either the spacebar or the enter key.
+- Users should be able to tab through interactive items in a logical order, usually from left to right and top to bottom. Sometimes a logical order will be obvious to your front end team based on a simple layout, but in more complicated layouts you may need to identify the tab order in your wireframes or mockups.
+- Each interactive element should have a visible focus state, work with your visual designer to make sure you’ve accounted for these.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3.2 Meaningful Sequence](https://www.w3.org/WAI/WCAG20/quickref/#content-structure-separation-sequence)
+- [2.4.3 Focus Order](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-focus-order)
+- [2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-focus-visible)
+
+
+## Focus
+
+Have you designed for logical focus behavior on interactive elements?
+
+### Why it's important
+
+- Jiang is blind and uses a screen reader to navigate the web. When a modal pops up and doesn’t receive focus, he may not even know it’s there.
+
+### Steps to take
+
+Work with your front-end designer to identify any interactions on the page that require JavaScript or that can’t be created using default HTML elements. You should intentionally design how focus flows through these interactions.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [2.4.3 Focus Order](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-focus-order)
+- [2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-focus-visible)
+- [3.2.1 On Focus](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#consistent-behavior-receive-focus)
+
+
+## Navigation shortcuts
+
+Have you included navigation shortcuts for screen reader and keyboard users?
+
+### Why it's important
+
+- Rasheed is blind and uses a screen reader to navigate the web; he uses landmark elements to quickly navigate through sections of a webpage.
+- Li’s vision is fine but has trouble using a mouse, so he navigates the web using only his keyboard – he hates having to tab through all the links in the header navigation to get to the main content of a page.
+
+### Steps to take
+
+1. Work with your front end designer to identify the [basic landmark elements](https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html) in your wireframes, particularly for complex layouts. Landmark elements are identified either through HTML5 semantic markers or through ARIA roles when HTML can’t identify something. You don’t need to be an expert on HTML or ARIA, as long as you know the basics.
+ - header
+ - nav
+ - main
+ - footer
+ - search
+ - form
+2. Include a “Skip to main content” link before the header for keyboard users. Keyboard users can’t take advantage of landmark navigation so a skip link helps them navigate more quickly. This link can be visually hidden but [should become visible when it has focus](http://webaim.org/techniques/skipnav/#hidden).
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#content-structure-separation-programmatic)
+- [2.4.1 Bypass Blocks](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#navigation-mechanisms-skip)
+
+
+## Forms
+
+Can all users understand and fill out forms?
+
+### Why it's important
+
+- Esther is beginning to show signs of dementia and has trouble with short term memory loss, she needs context clues and instructions to stay visible on the screen or she loses her place.
+- Jerome uses a screen magnifier and when validation messages are shown off to the side he can easily miss them.
+
+### Steps to take
+
+1. Make sure all inputs have descriptive labels that remain visible even after a field has been filled in.
+2. Try to use HTML form elements as much as possible, and test any custom interactions for use with screen readers and keyboard only.
+3. Use a straw or make a narrow window with your fist and view the page through that, scanning vertically but not horizontally. This can help you discover if content is hidden from users using screen magnifiers.
+4. Minimize the number of responses overall and that are displayed on a single page, but provide context clues throughout for people who might easily lose their place.
+
+### Resources
+
+- [USWDS - Form component](https://designsystem.digital.gov/components/form/)
+- [USWDS - Form templates](https://designsystem.digital.gov/templates/form-templates/)
+- [UK.gov Government Digital Service (GDS) guidance on form structure](https://www.gov.uk/service-manual/design/form-structure)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/#text-equiv-all)
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/#content-structure-separation-programmatic)
+- [3.2.1 On Focus](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#consistent-behavior-receive-focus)
+- [3.3.2 Labels or Instructions](https://www.w3.org/WAI/WCAG20/quickref/#minimize-error-cues)
+- [4.1.2 Name, Role, Value](https://www.w3.org/WAI/WCAG20/quickref/#ensure-compat-rsv)
+
+
+## Images
+
+Have you identified which images are meaningful and which images are decorative in mockups?
+
+### Why it's important
+
+- Carmen’s page didn’t load all the way and didn’t get to download the images.
+- Amanda is blind and uses a braille reader to understand the content of images.
+- John is looking for information with a search engine and needs help being directed to the right content (descriptive alt tags will improve search).
+
+### Steps to take
+
+1. Images that are purely decorative shouldn’t be announced by the screenreader, work with your front-end developer to make sure they’re coded correctly.
+2. Images that have meaning should include alt text and possibly a longer description, work with the content designer on your team to create these.
+3. Making sure any text in images of text is at least 14 points and has good contrast.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1 Text Alternatives (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=11%2C111#text-equiv)
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#text-equiv-all)
+- [1.4.5 Images of Text](https://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation)
+
+
+## Touch targets
+
+Are your touch targets large enough and easy to reach?
+
+### Why it's important
+
+- Harold has gigantism due to a tumor on his pituitary gland during childhood. He has very large hands which makes small links, or links that are too close together difficult to tap on his phone.
+- Rosa checks the latest news on her phone during her morning commute on a jostling bus, often while sipping from the coffee cup in her other hand.
+
+### Steps to take
+
+1. Make sure you can reach primary actions easily with either right or left thumbs, even on larger phones. Items on the bottom of the screen tend to be easier to reach.
+2. Make touch targets at least 44 px (pixels) or 10 mm (millimeters). This will allow the target to be tapped by the average adult finger pad, which measures 10 mm. The icons may be smaller and you can work with your developer to extend padding past the icon. Pay particular attention to how [line-height affects touch target size](https://digital.gov/guides/mobile-principles/tap-targets/).
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [2.5.5 Touch Target (WCAG 2.1)](https://www.w3.org/WAI/WCAG21/Understanding/target-size.html)
+
+Mobile Accessibility: How WCAG 2.0 and Other World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) Guidelines Apply to Mobile:
+
+- [3.2 Touch Target Size and Spacing](https://www.w3.org/TR/mobile-accessibility-mapping/#touch-target-size-and-spacing)
+- [3.5 Placing buttons where they are easy to access](https://www.w3.org/TR/mobile-accessibility-mapping/#h-placing-buttons-where-they-are-easy-to-access)
+
+---
+
+**Disclaimer**: All references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.
diff --git a/content/guides/accessibility-for-teams/visual-design.md b/content/guides/accessibility-for-teams/visual-design.md
new file mode 100644
index 0000000000..fcc691f615
--- /dev/null
+++ b/content/guides/accessibility-for-teams/visual-design.md
@@ -0,0 +1,330 @@
+---
+date: 2018-07-09 09:00:00 -0500
+title: "Accessibility for visual designers"
+deck: ""
+summary: ""
+guide: accessibility-for-teams
+primary_image: accessibility-for-teams-guide
+summary_box: true
+topics:
+ - accessibility
+ - product-and-project-management
+ - user-experience
+layout: single
+---
+
+## Getting started
+
+Everyone benefits from designs that are easier to see. People with different visual abilities see your designs in varying ways—the diverse nature of impairments creates a wide variation in how your designs are perceived. A clean and clear visual presentation helps everyone make sense of a website's information and functionality.
+
+**How to use this guide:**
+
+- We recommend planning for accessibility in your design process and regularly conducting accessibility testing throughout the design and development processes.
+- If you have project-specific questions, ask your agency’s accessibility team.
+
+## Color and Contrast
+
+### Is there enough contrast between text and its background color?
+
+#### Why it’s important
+
+- Esther has low vision and needs content to have enough contrast to read it.
+
+#### Steps to take
+
+1. Provide good contrast. Make sure the contrast between the text and background is greater than or equal to 4.5:1 for small text and 3:1 for large text.
+ - Test your color palette for accessible combinations with [Accessible Color Palette Builder](https://toolness.github.io/accessible-color-matrix/) or [Contrast Grid](http://contrast-grid.eightshapes.com/).
+ - Measure the contrast between text and backgound colors with tools like [WebAIM's Color Contrast Checker](http://webaim.org/resources/contrastchecker/) or a [Sketch plugin](https://github.com/getflourish/Sketch-Color-Contrast-Analyser).
+2. Exceptions:
+ - Color contrast ratio requirements apply to text and graphics that are essential for understanding the content or functionality. You don’t need to meet color contrast requirements for logos or incidental graphic elements.
+ - Text that is part of a disabled control's state or disabled buttons does not need to meet the minimum contrast ratio.
+ - Text that is part of a logo has no minimum contrast requirement.
+3. Slightly temper the contrast between your text and background color. For example: don’t use pure black text on a pure white background. Stark contrast can result in blurred or moving text for people with Irlen syndrome.
+4. To use text over images, add a solid background behind the text or a dark overlay to the image.
+
+#### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [Guideline 1.4.3 – Contrast (Minimum)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#visual-audio-contrast-contrast)
+
+Video tutorials:
+
+- Meeting contrast requirements
+
+{{< youtube id="gH1JieTZQ1k" title="Meeting Contrast Requirements" >}}
+
+- How I do an accessibility check (contrast)
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility check" >}}
+
+
+### Can you still understand everything the design is communicating without depending on color?
+
+#### Why it’s important
+
+- Joel is red-green colorblind and can’t reliably make sense of information conveyed with color alone.
+
+#### Steps to take
+
+1. Don’t use color alone to convey meaning. Use icons, written content, and other visual elements to reinforce clear communication of the content.
+2. Test what it’s like to view your designs through a [color blindness simulator](http://www.color-blindness.com/coblis-color-blindness-simulator/).
+
+#### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+[1.4.1 Use of Color](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#visual-audio-contrast-without-color)
+
+
+## Layout and Hierarchy
+
+Can you quickly understand the meaning of the page and complete your task?
+
+### Why it's important
+
+- Avi is distracted and needs to fill out an important web form
+- Benny has attention deficit disorder and has trouble staying focused on busy pages
+- Juanita doesn’t feel confident about using technology because she previously wasn’t able to find what she was looking for.
+
+### Steps to take
+
+1. Make sure key information is discernable at a glance. Design minimally and intentionally so that the user can get as much info as quickly as possible.
+2. Create a clear hierarchy of importance by placing items on the screen according to their relative level of importance. For example, place important actions at the top or bottom of the screen (reachable with shortcuts).
+3. Plan heading structure early. Ensure all content and design fits into a logical heading structure.
+4. Consider reading order. The reading order should be the same as the visual order.
+5. Group related items in proximity to one another to help those who have low vision or trouble focusing on the screen.
+
+### Resources
+
+- [Accessibility - Material Design](https://m2.material.io/design/usability/accessibility.html)
+- [WebAIM: Web Accessibility for Designers](http://webaim.org/resources/designers/)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3.2 Meaningful Sequence](https://www.w3.org/WAI/WCAG20/quickref/#content-structure-separation-sequence)
+- [2.4.6 Headings and Labels](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#navigation-mechanisms-descriptive)
+
+
+## Typography
+
+Can you easily read and comprehend textual information on the page?
+
+### Why it's important
+
+- Zelda has low vision and has trouble reading small text.
+- Yulia’s eyes are strained after a long day of working on a computer.
+
+### Steps to take
+
+1. **Use a large enough font size for body text so that people can comfortably read.** Use at least an effective size of 16px, but this can vary depending on the design of the font.
+2. **Maintain a line length that promotes comfortable reading.** Don’t make lines too long or too short: 45-75 characters per line is acceptable and approximately 66 characters per line is comfortable. Shorter pieces of text are fine for captions, marginal text, and forms.
+3. **Choose a typeface that emphasizes clarity and legibility.**
+ - Factors to consider:
+ - It performs well when it’s small or large.
+ - It has a large x-height.
+ - The character is large for its point size.
+ - The metrics (such as x-height) are consistent between letterforms.
+ - Individual letterforms are distinct in shape and can’t they be confused with others. For example: I, l, and 1 are distinct. 0 and O are distinct.
+ - The typeface supports all of the characters and font styles that are needed.
+ - Some designers recommend sans-serif faces for UIs and serif faces for longform reading, but these are not hard-and-fast rules.
+ - For an easy place to get started, the [U.S. Web Design Standards](https://designsystem.digital.gov/) (USWDS) [Typography page](https://designsystem.digital.gov/components/typography/) includes a set of [open source typeface recommendations](https://designsystem.digital.gov/components/typography/#included-typefaces) that emphasize legibility.
+4. **Use headings to communicate hierarchy.** Ensure heading styles differ from paragraph text by some combination of size, weight, face, or color. This ensures they’re distinct from paragraph text but are related to each other with some consistency, which helps with scanning.
+5. **Use your type size and line width to determine a line height that people can comfortably read.** The larger the type size and line width, the larger the line height should be. For running/body text, that’s usually around 1.4-1.65, headings at around 1-1.3, and captions or short lines at around 1.3. Lines that are leaded too tightly or loosely can diminish readability by making it harder for the eye to know where to return to when the line breaks.
+
+### Resources
+
+- [U.S. Web Design System (USWDS) research report: Inclusive design patterns](https://designsystem.digital.gov/together/)
+- [Better Web Type by Matej Latin](https://betterwebtype.com/)
+- [Text legibility - Material Design](https://material.io/design/color/text-legibility.html)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.4.8 Visual Presentation](https://www.w3.org/WAI/WCAG20/quickref/#visual-audio-contrast-visual-presentation)
+
+
+## Graphics and images
+
+Can you easily understand content associated with graphics, icons, and images?
+
+### Why it's important
+
+- Marisa primarily uses her mobile device to browse websites and has trouble interpreting visualizations with small text.
+
+### Steps to take
+
+1. Make sure all graphics have descriptive captions written in plain language.
+2. Avoid using graphics when written content could communicate the same thing.
+3. Use icons as helpful visual cues to connect to concepts. Only use icons purposefully and not for decoration. Use familiar icons that people are accustomed to associating with common actions, like a trash can to represent deleting something.
+4. To use text over images, add a solid background behind the text or a dark overlay to the image.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1 Text Alternatives (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview&tags=images%2Cimages-of-text%2Ctext-alternatives#text-equiv)
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#text-equiv-all)
+- [1.4.5 Images of Text](https://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation)
+
+
+## Data visualizations
+
+Can you understand the overall trend of the graph? Can you quickly grasp the relationship between parts of the data?
+
+### Why it's important
+
+- Kwame has trouble reading graphs with small text.
+
+### Steps to take
+
+1. Follow data visualization best practices: allow the data and your communication goals for the visualization to dictate the format and visual style, instead of the latest aesthetic trend.
+2. Support the visuals with a brief description of the overall trend that’s generated by the chart to give context.
+3. Ensure the data and variables are clearly labeled.
+4. Make sure there’s sufficient contrast between graph colors so people with color blindness can distinguish the colors.
+5. Consider complementing the graph with a table of information so that it can be read more easily by screen reader users and when compressed to mobile.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1 Text Alternatives (Guideline)](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=11%2C111#text-equiv)
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=14%2C128¤tsidebar=%23col_overview#text-equiv-all)
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/#content-structure-separation-programmatic)
+- [1.4.1 Use of Color](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#visual-audio-contrast-without-color)
+
+
+## Forms
+
+Are forms as simple as possible and only ask what’s needed to complete the task? Can you successfully complete the form?
+
+### Why it's important
+
+- Mateo is in a hurry to fill out a medical insurance form for his sick daughter.
+- Janet has dementia and needs to validate her identification to request a new social security card.
+
+### Steps to take
+
+1. **Present fields in a single-column layout.** This keeps visual momentum moving down the page so users don’t have to reorient themselves with multiple columns. (Exceptions to this rule are short, logical fields that may be presented on the same row like _City_, _State_, and _Zip code_.)
+2. **Ensure form fields are visibly labeled.**
+3. **Make sure form fields have clearly defined boundaries** or outlines so that people with cognitive disabilities know the size and location of the click target.
+4. **Do not use placeholder text in form fields.** Placeholder text causes usability issues because it disappears when content is entered into the form field. Hints and instructions should be persistent and placed outside of the field.
+5. **Provide highly visible and specific error states.** Use multiple cues like color, icons, bold font weight, heavy border or outline, and helpful text to make sure users don’t overlook this critical information.
+
+### Resources
+
+- [USWDS - Form component](https://designsystem.digital.gov/components/form/)
+- [USWDS - Form templates](https://designsystem.digital.gov/templates/form-templates/)
+- [Nielsen Norman Group: Website Forms Usability: Top 10 Recommendations](https://www.nngroup.com/articles/web-form-design/)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG20/quickref/#text-equiv-all)
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/#content-structure-separation-programmatic)
+- [3.2.1 On Focus](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#consistent-behavior-receive-focus)
+- [3.3.2 Labels or Instructions](https://www.w3.org/WAI/WCAG20/quickref/#minimize-error-cues)
+- [4.1.2 Name, Role, Value](https://www.w3.org/WAI/WCAG20/quickref/#ensure-compat-rsv)
+
+
+## Mobile
+
+Can you understand key information and perform critical tasks on a mobile device?
+
+### Why it's important
+
+- Miyako just lost her job and canceled her home internet to stretch her budget. She only uses her cell phone to browse the internet.
+- Reza is recovering from a stroke and slowly relearning how to use his arm. He uses his phone to help him find information on the web.
+
+### Steps to take
+
+1. Make sure you can reach primary actions easily with either right or left thumbs.
+2. Make touch targets at least 48px. This will allow the target to be tapped by the average adult finger pad, which measures 10mm. The icons may be smaller and you can work with your developer to extend padding past the icon.
+3. In most cases, touch targets are separated by 8px of space or more to ensure users don't select the wrong action.
+
+### Resources
+
+Mobile Accessibility: How WCAG 2.0 and Other World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) Guidelines Apply to Mobile:
+
+- [3.2 Touch Target Size and Spacing](https://www.w3.org/TR/mobile-accessibility-mapping/#touch-target-size-and-spacing)
+- [3.5 Placing buttons where they are easy to access](https://www.w3.org/TR/mobile-accessibility-mapping/#placing-buttons-where-they-are-easy-to-access)
+
+
+## Keyboard access
+
+Can you reach anything that’s interactive using the tab key?
+
+### Why it's important
+
+- Maria has tendonitis and is unable to use a mouse; instead, she uses the keyboard to navigate the web.
+
+### Steps to take
+
+1. Using only your keyboard, navigate through the page using the `tab` key.
+2. Make sure you can reach all interactive elements and trigger them with the `spacebar`, `enter` key, or arrow keys, and ensure that you have designed intentional styles for these states: focus, hover, active, and visited.
+3. Check to see that focus is always visible and that interactive items on the page appear in logical order. Make sure that no content gets focused offscreen or is hidden from view.
+4. Check to see that the page includes a skip navigation link (if navigation is present before the main content). This will allow users to skip past navigation to reach the page’s main content.
+
+### Resources
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [2.1.1 Keyboard](https://www.w3.org/WAI/WCAG20/quickref/#keyboard-operation-keyboard-operable)
+- [2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG20/quickref/#keyboard-operation-trapping)
+- [2.4.3 Focus Order\| WCAG 2.0](https://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms-focus-order)
+- [2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms-focus-visible)
+
+Video tutorial:
+
+- How I do an accessibility check
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility check" >}}
+
+
+## Screen reader
+
+Can you use a screen reader to access the page content?
+
+### Why it's important
+
+- Aisha is blind and uses a screen reader to navigate the web.
+
+### Steps to take
+
+1. Use a screen reader to make sure you can land on controls and that they’re announcing content in the appropriate order and context (i.e. labels before form fields, headers before content, etc.).
+2. If forms are present, make sure the screen reader reads labels and instructions.
+3. Make sure that all links are properly descriptive. For example, the link text “Read More” provides no context about where the user will go if they click it, while “Read more about dinosaurs” describes what’s on the other side of the link.
+
+### Use VoiceOver screen reader on Mac
+
+- **Turn VoiceOver on**: command (⌘) + F5
+- **Go into web area**: control + alt + shift + down arrow (⬇)
+- **Navigate right**: control + alt + right arrow (➡️️)
+- **Navigate by heading**: control + alt + command (⌘) + H
+- **Click**: control + alt + spacebar
+
+Use rotor to browse pages. The rotor lists common elements like headings, links, and images, and lets you navigate directly to the element of your choosing.
+
+- **Turn on rotor**: control + alt + U
+- **Navigate rotor**: left and right, up and down arrows
+
+### Resources
+
+- [Download NVDA screen reader (NV Access)](https://www.nvaccess.org/download/)
+
+Web Content Accessibility Guidelines (WCAG) 2.0 references:
+
+- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=128%2C14¤tsidebar=%23col_overview#content-structure-separation-programmatic)
+
+
+Video tutorials:
+
+- Screen Reader Basics: VoiceOver
+
+{{< youtube id="5R-6WvAihms" title="Screen Reader Basics: VoiceOver" >}}
+
+- How I do an accessibility check (screen reader)
+
+{{< youtube id="cOmehxAU_4s" title="How I do an accessibility check" >}}
+
+---
+
+**Disclaimer**: All references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.
diff --git a/content/news/2024/02/2024-02-09-timeless-top-10-best-practices-for-great-government-websites.md b/content/news/2024/02/2024-02-09-timeless-top-10-best-practices-for-great-government-websites.md
index 81b8b9dc74..88e077b8f7 100644
--- a/content/news/2024/02/2024-02-09-timeless-top-10-best-practices-for-great-government-websites.md
+++ b/content/news/2024/02/2024-02-09-timeless-top-10-best-practices-for-great-government-websites.md
@@ -28,10 +28,10 @@ weight: 1
---
-As the saying goes, the more things change, the more they stay the same.
-
{{< img-right src="web-content-gov-top-ten-list-clipboard" >}}
+As the saying goes, the more things change, the more they stay the same.
+
Digital.gov — celebrating its 10th anniversary on February 14, 2024 — used to be called [WebContent.gov](https://web.archive.org/web/20040101000000*/webcontent.gov). In the mid-2000s, the WebContent.gov team published the [top 10 best practices for great government websites](https://web.archive.org/web/20070610235006/http://www.usa.gov/webcontent/reqs_bestpractices/checklist/criticaltasks.shtml). In those days, they printed this list on a clipboard so every web manager across the government could have it at their fingertips, on their desks.
Despite a significant amount of change in federal websites and digital services over the past two decades, the fundamental aspects in how they are managed have remained the same.
diff --git a/content/news/2024/04/2024-04-01-how-usagov-uses-data-to-improve-content.md b/content/news/2024/04/2024-04-01-how-usagov-uses-data-to-improve-content.md
new file mode 100644
index 0000000000..dc4a5dc35a
--- /dev/null
+++ b/content/news/2024/04/2024-04-01-how-usagov-uses-data-to-improve-content.md
@@ -0,0 +1,26 @@
+---
+# Originally published at the following URL
+source_url: https://blog.usa.gov/how-usagov-uses-data-to-improve-content
+source: usagov
+date: 2024-04-01
+title: How USAGov uses data to improve content
+deck: Each month, USAGov’s content designers spend many hours ensuring that the content on USA.gov and USAGov en Español is up-to-date, accurate, and meets user needs. Learn how their team does holistic reviews of each topic section based on a rolling calendar with the goal of updating all content at least every 6 months.
+summary: Each month, USAGov’s content designers spend many hours ensuring that the content on USA.gov and USAGov en Español is up-to-date, accurate, and meets user needs. Learn how their team does holistic reviews of each topic section based on a rolling calendar with the goal of updating all content at least every 6 months.
+# See all topics at https://digital.gov/topics
+topics:
+ - Analytics
+ - best-practices
+ - content-strategy
+ - user-centered-design
+ - design
+ - search
+ - research
+ - multilingual
+ - accessibility
+ - plain-language
+slug: how-usagov-uses-data-to-improve-content
+# Controls how this page appears across the site
+# 0 -- hidden
+# 1 -- visible
+weight: 1
+---
diff --git a/content/resources/accessibility-for-teams.md b/content/resources/accessibility-for-teams.md
index 65e4cf2360..afba649ae1 100644
--- a/content/resources/accessibility-for-teams.md
+++ b/content/resources/accessibility-for-teams.md
@@ -8,13 +8,7 @@ summary: "A guide to making products more accessible for everyone."
# What is the URL for this product or service?
# Note: We'll add a ?dg to the end of the URL in the code for tracking purposes
-source_url: "https://accessibility.digital.gov/"
-
-# Images need to be 200x200px with a transparent background
-# Upload new images to Github in the /static/logos/ folder
-# https://github.com/GSA/digitalgov.gov/tree/master/static/promos/
-# The filename should reflect the name of the product or service (e.g., challenge-gov.png)
-icon: "accessibility.png"
+source_url: "https://www.digital.gov/guides/accessibility-for-teams"
# Weight: control how services appear across the site
# 2 == will be part of the rotation on the homepage
diff --git a/content/resources/bilingual-glossaries-dictionaries-style-guides.md b/content/resources/bilingual-glossaries-dictionaries-style-guides.md
index 37999ffd52..5cf2442654 100644
--- a/content/resources/bilingual-glossaries-dictionaries-style-guides.md
+++ b/content/resources/bilingual-glossaries-dictionaries-style-guides.md
@@ -94,11 +94,14 @@ The U.S. Election Assistance Commission offers translations of Glossary of Elect
The Bureau has more than 1,200 words and terms in five languages:
-- [Glossary of English-Chinese Financial Terms (PDF, 999 kb, 72 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_chinese-style-guide-glossary.pdf)
-- [Glossary of English-Spanish Financial Terms (PDF, 705 kb, 78 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_spanish-style-guide-glossary.pdf)
-- [Glossary of English-Vietnamese Financial Terms (PDF, 875 kb, 73 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_vietnamese-style-guide-glossary.pdf)
-- [Glossary of English-Korean Financial Terms (PDF, 947 kb, 72 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_korean-style-guide-glossary.pdf)
-- [Glossary of English-Tagalog Financial Terms (PDF, 674 kb, 82 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_tagalog-style-guide-glossary.pdf)
+- [Arabic-English glossary of financial terms (PDF, 983 KB, 81 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_arabic-style-guide-glossary.pdf)
+- [Chinese-English glossary of financial terms (PDF, 1.4 MB, 81 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_chinese-style-guide-glossary.pdf)
+- [Haitian Creole-English glossary of financial terms (PDF, 772 KB, 81 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_hatiancreole-style-guide-glossary.pdf)
+- [Korean-English glossary of financial terms (PDF, 970 KB, 81 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_korean-style-guide-glossary.pdf)
+- [Russian-English glossary of financial terms (PDF, 926 KB, 82 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_russian-style-guide-glossary.pdf)
+- [Spanish-English glossary of financial terms (PDF, 852 KB, 86 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_spanish-style-guide-glossary.pdf)
+- [Tagalog-English glossary of financial terms (PDF, 782 KB, 83 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_tagalog-style-guide-glossary.pdf)
+- [Vietnamese-English glossary of financial terms (PDF, 971 KB, 82 pages)](https://files.consumerfinance.gov/f/documents/cfpb_adult-fin-ed_vietnamese-style-guide-glossary.pdf)
#### Federal Housing Finance Agency (FHFA)
diff --git a/content/resources/requirements-for-improving-the-management-of-federal-programs-and-projects.md b/content/resources/requirements-for-improving-the-management-of-federal-programs-and-projects.md
index faef508a67..fe2b35b517 100644
--- a/content/resources/requirements-for-improving-the-management-of-federal-programs-and-projects.md
+++ b/content/resources/requirements-for-improving-the-management-of-federal-programs-and-projects.md
@@ -72,13 +72,13 @@ The third strategy uses a new or updated job series, or a job identifier, to bet
These strategies focus on clarifying key roles and responsibilities for program management, identifying principles-based standards, holding managers accountable for results, and building a capable program management workforce.
{{< ring title="OMB Memo M-18-19">}}
- In part, this memo provides further policy guidance to help agencies fully implement the PMIAA.
+ In part, this memo provides further policy guidance to help agencies fully implement the PMIAA.
[Explore OMB Memo M-18-19: Improving the Management of Federal Programs and Projects through Implementing the PMIAA (PDF, 1.8 MB, 30 pages)](https://www.whitehouse.gov/wp-content/uploads/2018/06/M-18-19.pdf)
{{< /ring >}}
-{{< note >}}
+{{< note >}}
Digital.gov provides information and resources for federal agencies related to web and digital policies. However, we cannot interpret the statutes or specific requirements.
- Contact OMB’s Office of Performance and Personnel Management at [performance@omb.eop.gov](mailto:performance@omb.eop.gov) with any questions about interpretations of the law and guidance.
+ Contact OMB’s Office of Performance and Personnel Management at [performance@omb.eop.gov](mailto:performance@omb.eop.gov) with any questions about interpretations of the law and guidance.
{{< /note >}}
diff --git a/content/services/service_federalist.md b/content/services/service_federalist.md
index 5270d833d1..c284c84ad9 100644
--- a/content/services/service_federalist.md
+++ b/content/services/service_federalist.md
@@ -1,21 +1,21 @@
---
# What is the name of the product or service?
-title: "Federalist"
+title: "Pages"
# Keep it short — should be no longer than 10 words.
summary: "A publishing platform that helps federal partners launch, maintain and manage Government websites."
# Will this point to an external source URL?
# Note: We'll add a ?dg to the end of the URL in the code for tracking purposes
-source_url: "https://federalist.18f.gov/"
+source_url: "https://cloud.gov/pages/documentation/why-use-pages/"
# Images need to be 200x200px with a transparent background
# Upload new images to Github in the /static/logos/ folder
# https://github.com/GSA/digitalgov.gov/tree/master/static/promos/
# The filename should reflect the name of the product or service (e.g., challenge-gov.png)
-logo: "federalist"
+logo: "pages"
-contact: federalist-inquiries@gsa.gov
+contact: inquiries@cloud.gov
# Weight — controls how services appear across the site
# 2 == will appear as related service (ADs) on blog posts and event pages
diff --git a/content/topics/accessibility/_index.md b/content/topics/accessibility/_index.md
index e57ced6417..0cbe24c6c5 100644
--- a/content/topics/accessibility/_index.md
+++ b/content/topics/accessibility/_index.md
@@ -15,7 +15,6 @@ aliases:
- /topics/508/
- /topics/americans-with-disabilities-act/
- /topics/section-508/
- - /guides/accessibility-for-teams
# Weight
weight: 2
@@ -37,20 +36,19 @@ featured_communities:
featured_links:
title: "Accessibility: essential knowledge"
resources:
- - title: "Section508.gov"
- summary: "This site provides guidance for federal agencies on several topics in IT accessibility, including creating accessible websites and documents, accessibility testing, accessibility training, and accessibility in contracting and procurement."
- href: "https://www.section508.gov"
- - title: "Best practices for writing for the accessible web"
- summary: "Tips for making online information accessible for those with auditory and visual needs."
- href: "https://digital.gov/resources/best-practices-writing-for-accessible-web"
- - title: "An advanced approach to accessibility"
- summary: "Accessibility is one of the most important values underlying all the work that we do. This is a deeper look into accessibility: what to do, how to do it, and why it matters, especially in government."
- href: "https://digital.gov/resources/advanced-accessibility"
- - title: "Accessibility: Usability for every ability"
- summary: "Incorporate accessibility from the start and celebrate accessibility guidelines that help build better products and services for all users."
- href: "https://designsystem.digital.gov/documentation/accessibility/#what-project-teams-should-do"
- - title: "Accessibility for Teams"
- summary: "A quick-start guide for embedding accessibility and inclusive design practices into your team’s workflow."
- href: "https://accessibility.digital.gov"
-
+ - title: "Section508.gov"
+ summary: "This site provides guidance for federal agencies on several topics in IT accessibility, including creating accessible websites and documents, accessibility testing, accessibility training, and accessibility in contracting and procurement."
+ href: "https://www.section508.gov"
+ - title: "Best practices for writing for the accessible web"
+ summary: "Tips for making online information accessible for those with auditory and visual needs."
+ href: "https://digital.gov/resources/best-practices-writing-for-accessible-web"
+ - title: "An advanced approach to accessibility"
+ summary: "Accessibility is one of the most important values underlying all the work that we do. This is a deeper look into accessibility: what to do, how to do it, and why it matters, especially in government."
+ href: "https://digital.gov/resources/advanced-accessibility"
+ - title: "Accessibility: Usability for every ability"
+ summary: "Incorporate accessibility from the start and celebrate accessibility guidelines that help build better products and services for all users."
+ href: "https://designsystem.digital.gov/documentation/accessibility/#what-project-teams-should-do"
+ - title: "Accessibility for Teams"
+ summary: "A quick-start guide for embedding accessibility and inclusive design practices into your team’s workflow."
+ href: "https://digital.gov/guides/accessibility-for-teams"
---
diff --git a/data/guidenav/accessibility-for-teams.yml b/data/guidenav/accessibility-for-teams.yml
new file mode 100644
index 0000000000..535392b590
--- /dev/null
+++ b/data/guidenav/accessibility-for-teams.yml
@@ -0,0 +1,15 @@
+showNextPrevious: true
+showInPageNav: false
+nav:
+ - title: "Overview"
+ path: "/guides/accessibility-for-teams/_index.md"
+ - title: "Product management"
+ path: "/guides/accessibility-for-teams/product-management.md"
+ - title: "Content design"
+ path: "/guides/accessibility-for-teams/content-design.md"
+ - title: "UX design"
+ path: "/guides/accessibility-for-teams/ux-design.md"
+ - title: "Visual design"
+ path: "/guides/accessibility-for-teams/visual-design.md"
+ - title: "Front-end development"
+ path: "/guides/accessibility-for-teams/front-end-development.md"
diff --git a/data/images/accessibility-for-teams-guide.yml b/data/images/accessibility-for-teams-guide.yml
new file mode 100644
index 0000000000..059bdecfd8
--- /dev/null
+++ b/data/images/accessibility-for-teams-guide.yml
@@ -0,0 +1,12 @@
+
+ # https://s3.amazonaws.com/digitalgov/accessibility-for-teams-guide.jpg
+ # Image shortcode: {{< img src=accessibility-for-teams-guide >}}'
+ date : 2024-04-02 14:00:29 -0400
+ uid : accessibility-for-teams-guide
+ width : 5800
+ height : 3379
+ format : jpg
+ credit :
+ caption : "Color_life/iStock via Getty Images"
+ alt : "Illustration of seven people in a meeting in office. One is standing, six, using laptops, are seated at a conference table. One employee is in a wheelchair."
+
diff --git a/static/logos/federalist-icon.png b/static/logos/pages-icon.png
similarity index 100%
rename from static/logos/federalist-icon.png
rename to static/logos/pages-icon.png
diff --git a/static/logos/federalist-logo.png b/static/logos/pages-logo.png
similarity index 100%
rename from static/logos/federalist-logo.png
rename to static/logos/pages-logo.png
diff --git a/themes/digital.gov/layouts/events/card-event.html b/themes/digital.gov/layouts/events/card-event.html
index 51743555a5..89168fa71a 100644
--- a/themes/digital.gov/layouts/events/card-event.html
+++ b/themes/digital.gov/layouts/events/card-event.html
@@ -51,13 +51,6 @@
{{- end -}}
- {{- if .Params.host -}}
-
- Hosted by Digital.gov and the
- {{ .Params.host }}
-
- {{- end -}}
-
{{ if $isPastEvent }}
{{- partial "core/get_authors_short.html" . -}}
{{ end }}
diff --git a/themes/digital.gov/layouts/partials/core/topics-button.html b/themes/digital.gov/layouts/partials/core/topics-button.html
new file mode 100644
index 0000000000..4c46d8c775
--- /dev/null
+++ b/themes/digital.gov/layouts/partials/core/topics-button.html
@@ -0,0 +1,52 @@
+{{/* Renders a topics button with the name of the topic and has two display options.
+
+ 1. Primary - Styled button with a hover effect.
+ 2. Count - Link followed by the amount of pages that use the topic.
+
+ @param {url} link - String path to a topic page.
+ @param {string} title - Topic name.
+ @param {number} tag_count - Number of times the topic tag is used.
+ @param {boolean} has_tag_count - Checks if `tag_count` number is present.
+*/}}
+
+{{ $link := .link }}
+{{ $title := .title }}
+{{ $tag_count := .tag_count }}
+{{ $has_tag_count := false }}
+
+{{ if ne $tag_count nil }}
+ {{ $has_tag_count = true }}
+{{ end }}
+
+
+
diff --git a/themes/digital.gov/layouts/resources/list.html b/themes/digital.gov/layouts/resources/list.html
index a988f866f8..6a5eb1cbeb 100644
--- a/themes/digital.gov/layouts/resources/list.html
+++ b/themes/digital.gov/layouts/resources/list.html
@@ -119,49 +119,34 @@ All Resources by Topic
-