Skip to content

Commit

Permalink
Merge branch 'main' into ss-resource-updates-on-ai-topic
Browse files Browse the repository at this point in the history
  • Loading branch information
ToniBonittoGSA authored Jun 24, 2024
2 parents a1fcd21 + 2509dc8 commit adc1201
Show file tree
Hide file tree
Showing 36 changed files with 946 additions and 112 deletions.
4 changes: 2 additions & 2 deletions content/about/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,11 +69,11 @@ Our roadmap is an up-to-date report on the work we’re doing to improve Digital
</tr>
<tr>
<th scope="row">Migrate the accessibility.digital.gov microsite to Digital.gov as a guide</th>
<td>In progress</td>
<td>Complete</td>
</tr>
<tr>
<th scope="row">Plan and host the Spring 2024 Digital.gov Community Summit</th>
<td>In progress</td>
<td>Complete</td>
</tr>
<tr>
<th scope="row">Share more agency case studies and success stories with community members</th>
Expand Down
82 changes: 41 additions & 41 deletions content/about/lost-and-found-mapping-page.md

Large diffs are not rendered by default.

Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ And it's fast. We've updated to the newest [sass-embedded] (https://www.npmjs.co

**Slide 25:** USWDS 3.0 is the foundation of a more modular design system. One that lets teams define the parts of USWDS they want to use, customize their implementations, and update at their own pace.

**Slide 26:** We think it's going to deliver a lot, with just a little bit of upgrade and migration effort. We think that most teams will be able to move from USWDS 2 to USWDS 3 in a matter of hours, not days or weeks. And if you're thinking of migrating, USWDS Compile could be your friend. We think more teams should use it, and we want to make it as useful as possible. So if you have feedback, let us know, either in an issue or a discussion. We're putting the [github discussion link] (https://github.com/uswds/uswds/discussions/4587)to the most recent 3.0 Beta release in the chat.
**Slide 26:** We think it's going to deliver a lot, with just a little bit of upgrade and migration effort. We think that most teams will be able to move from USWDS 2 to USWDS 3 in a matter of hours, not days or weeks. And if you're thinking of migrating, USWDS Compile could be your friend. We think more teams should use it, and we want to make it as useful as possible. So if you have feedback, let us know, either in an issue or a discussion. We're putting the [github discussion link](https://github.com/uswds/uswds/discussions/4587) to the most recent 3.0 Beta release in the chat.

**Slide 27:** Above all, we're working to deliver a simple migration process — not just for USWDS 3.0, but that 3.0 is the platform that will begin to deliver simpler updates and migrations going forward. We think that teams should make the effort to move to USWDS 3.0 and we'll help you get there.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,8 @@ primary_image: 2024-uswds-monthly-call-june-title-card

---

{{< asset-static file="uswds-monthly-call-june-2024.pptx" label="View the slides (Powerpoint presentation, 3 MB, 33 slides)">}}

Join the U.S. Web Design System (USWDS) team to see their progress toward developing web components for the design system. They’ll demo early working prototypes of a few components, and talk about some of the design questions they’re trying to answer through the prototyping process.

In this online session with the USWDS team, you will:
Expand Down
3 changes: 3 additions & 0 deletions content/guides/dap/add-your-site-dap.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
---
date: 2019-07-31 09:00:00 -0500

expirydate: "2024-06-14"

title: "Add your site to DAP"
deck: ""
summary: "The best ways to participate in DAP and add analytics code to federal websites."
Expand Down
3 changes: 3 additions & 0 deletions content/guides/dap/common-questions-about-dap.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
---
date: 2019-07-31 09:00:00 -0500

expirydate: "2024-06-14"

title: "Common questions about DAP"
summary: "The most common questions about implementing, customizing, and utilizing the DAP program."
guide: dap
Expand Down
3 changes: 3 additions & 0 deletions content/guides/dap/gaining-access-to-dap-data.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
---
date: 2019-07-31 09:00:00 -0500

expirydate: "2024-06-14"

title: "Gaining access to the data"
deck: ""
summary: "The best way to register for access to the DAP reporting interface."
Expand Down
3 changes: 3 additions & 0 deletions content/guides/dap/guidelines-for-sharing-dap-data.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
---
date: 2019-07-31 09:00:00 -0500

expirydate: "2024-06-14"

title: "Guidelines for sharing DAP data"
deck: ""
summary: "Your responsibilities in sharing and managing DAP data. "
Expand Down
78 changes: 78 additions & 0 deletions content/guides/public-policy/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
---
date: 2024-06-14 09:00:00 -0500
title: "Building by the rules: A crash course for federal technologists"
deck: ""
summary: "A guide for web and digital practitioners on why public policy matters."
guide: public-policy
image: guide-public-policy
primary_image: guide-public-policy

# See all authors at https://digital.gov/authors
authors:
- chizobam-nwagwu
- trey-gordner
# See all topics at https://digital.gov/topics
topics:
- customer-experience
- user-experience
- product-and-project-management
- policy
- design
- innovation
- information-collection
- accessibility
- privacy
- security

weight: 2
layout: single

---

Shipping user-centered products in government requires understanding public policy. [U.S. Digital Corps](https://digitalcorps.gsa.gov/) Fellows, who quickly learned how policy impacted the work led by their teams and other technology teams across the federal government, created this six-part guide, “Building by the rules: A crash course for federal technologists,” to explore why public policy matters, share the different types of public policy, and discuss a case study for navigating three key federal policies most relevant for web and digital teams across government.

## Why public policy matters

When you think about it, we all have rules that we live by. For example, some rules we live by include, “I always drink oat milk” or “I never sleep past 10 a.m.” In short, the rules for your life can govern your diet, budget, relationships, and much more.

In general, our “private policies” help to:

- Make our behavior intelligible and predictable
- Help us translate goals into action
- Organize our options to inform a course of action
- Set expectations and clarify our responsibilities with other parties

**Public policy** is similar, but at a much larger scale. It is:

- What the government chooses to do or not do about **a shared problem**
- Made on behalf of the public and meant to apply **generally**
- Directed towards **a goal or ideal state**

## Public policy as opposing forces

When government technology teams consider a change to a government service or information technology system, policy may be a force for or against that change. There are many frameworks for understanding this concept, including Kurt Lewin’s force field analysis <sup><a aria-describedby="footnote-label" href="#fn1" id="footnotes-ref1">[1]</a></sup>. The diagram below is a high-level adaptation of Lewin’s analysis.

{{< img src="public-policy-opposing-forces-force-field-analysis" >}}

Public policy as a force for change grants permission to innovate or improve. For example:

- The [21st Century Integrated Digital Experience Act](https://digital.gov/resources/delivering-digital-first-public-experience/) (21st Century IDEA) requires executive branch agencies to modernize their websites, digitize services and forms, accelerate the use of e-signatures, improve customer experience, and standardize and transition to centralized shared services.
- [Executive Order 14058, Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government](https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government) directs agencies to employ a customer experience approach that ensures the public is able to do basic tasks with the government in a manner that is simple, seamless, and secure.

Public policy as a force *against* change places constraints or conditions on how innovation takes place, often in a tradeoff with other important considerations. For example:

- The [Privacy Act of 1974](https://www.justice.gov/opcl/overview-privacy-act-1974-2020-edition) protects personally identifiable information (PII) and prohibits disclosure of protected information without consent. For instance, this may preclude use of software tools available to the private sector or limit access to data for secondary or experimental uses.
- The [Paperwork Reduction Act of 1995](https://pra.digital.gov/about/) requires that agencies obtain Office of Management and Budget (OMB) approval before requesting most types of information from the public. As public servants, we must make sure the data we collect from the public is accurate, helpful, and a good fit for its proposed use.

Overall, public policy plays a vital role in how federal agencies serve the public. There are hundreds of [requirements for federal websites and digital services](https://digital.gov/resources/checklist-of-requirements-for-federal-digital-services/). As web and digital practitioners in government, we need to keep in mind different circumstances where policy serves as a potential accelerator or blocker to innovation.

Keep reading to learn more about the different [types of policies](https://digital.gov/guides/public-policy/policy-types/#content-start) and useful frameworks for understanding how they work.

---

<footer>
<h3 id="footnote-label">Footnotes</h3>
<ol>
<li id="fn1">University of Cambridge. 2016. “Force Field Analysis.” Cam.ac.uk. University of Cambridge. 2016. <a href="https://www.ifm.eng.cam.ac.uk/research/dstools/force-field-analysis/">https://www.ifm.eng.cam.ac.uk/research/dstools/force-field-analysis/</a>. <a href="#footnotes-ref1" aria-label="Back to content">↩</a></li>
</ol>
<footer>
168 changes: 168 additions & 0 deletions content/guides/public-policy/accessibility.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,168 @@
---
date: 2024-06-14 09:00:00 -0500
title: "Accessibility"
deck: ""
summary: "An introduction to Section 508 of the Rehabilitation Act of 1973, and related laws and policies."
guide: public-policy
primary_image: guide-public-policy

---

In the [previous section](https://digital.gov/guides/public-policy/information-collection/#content-start), we discussed the Paperwork Reduction Act (PRA) — specifically why it exists, when it applies, tips for designing research studies with PRA in mind, and user research insights from the FindSupport.gov team. Now, we will touch on Section 508 of the Rehabilitation Act of 1973 and the importance of building accessible digital products.

{{< note >}}
This information is best practices based on our own experience. We encourage you to [get in touch with your agency’s Section 508 program manager](https://www.section508.gov/tools/program-manager-listing/) to answer any specific accessibility-related questions.
{{< /note >}}

## Why is accessibility important?

Tim Berners Lee, credited as the founder of the internet, once said “The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.” <sup><a aria-describedby="footnote-label" href="#fn1" id="footnotes-ref1">[1]</a></sup> In short, accessibility ensures all users can access a product or service.

## Why Section 508 exists

The Rehabilitation Act of 1973 is a federal law that prohibits federal discrimination based on disability status. [Section 508](https://www.section508.gov/manage/laws-and-policies/) requires that all federal agencies make all information and communication technology accessible to people with disabilities. This includes, but is not limited to, the following:

- Government websites
- Applications
- Emails
- Multimedia
- Electronic media

Consider Section 508 as part of a collection of federal policies that maximize the accessibility of government. This includes but is not limited to the following:

- [Section 503 of the Rehabilitation Act of 1973](https://www.dol.gov/agencies/ofccp/section-503/law)
- [Sections 501 and 505 of the Rehabilitation Act of 1973](https://www.eeoc.gov/statutes/rehabilitation-act-1973#:~:text=Section%20501%20prohibits%20employment%20discrimination,attorney's%20fees%20under%20Section%20501.)
- [Americans with Disabilities Act of 1990, as amended](https://www.ada.gov/law-and-regs/ada/)
- [Section 255 of the Telecommunications Act of 1996](https://www.access-board.gov/ict/guide/2555_guide.md.html)
- [Assistive Technology Act of 1998](https://www.congress.gov/bill/105th-congress/senate-bill/2432)
- [Plain Language Act of 2010](https://www.plainlanguage.gov/law/)
- [Agency accessibility policies](https://www.section508.gov/manage/laws-and-policies/update-agency-policies/)

## Design for all users

As web and digital practitioners in government, it is important to consider all users when building products or services.

Disability is a mismatch between a person and their environment. For the person who isn’t able to do something, it’s this mismatch that impairs an individual. It’s important to understand that everyone experiences some form of disability and [reframe our idea of disability](https://digital.gov/resources/advanced-accessibility/#reframing-our-idea-of-disability).

See the below table for a short list of disability types.

<table class="usa-table usa-table--striped">
<caption></caption>
<thead>
<tr style="text-align: left; vertical-align: top;">
<th scope="col">Type of disability</th>
<th scope="col">Description</th>
</tr>
</thead>
<tbody>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Mobility or physical</th>
<td>Weakness or limited ability and inability to independently use one’s body or one or more of their extremities</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Hearing</th>
<td>Mild to moderate hearing loss (hard of hearing). Substantial to uncorrectable hearing loss (deafness)</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Vision</th>
<td>Low vision (short- or long-sightedness, blurred vision), total blindness, or color blindness</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Cognitive, learning, or neurological</th>
<td>Impacts how a person hears and/or understands information, moves, sees, and/or speaks</td>
</tr>
</tbody>
</table>

## Design for all situations

See the below table for a short list of different types of situations to consider when building and designing products in government. Although these conditions are not explicitly outlined in Section 508, they remain important barriers to consider when building products in government.

<table class="usa-table usa-table--striped">
<caption></caption>
<thead>
<tr style="text-align: left; vertical-align: top;">
<th scope="col">Barriers to access</th>
<th scope="col">Description</th>
</tr>
</thead>
<tbody>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Broadband access</th>
<td>How well does your product work in low-bandwidth areas?</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Language</th>
<td>How many languages does your product support (and at what proficiency)?</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Technology access</th>
<td>Can your product be accessed on a mobile phone, laptop, or both?</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Subject matter expertise</th>
<td>Is your content at an appropriate reading level? Do you know your audience and what they need?</td>
</tr>
</tbody>
</table>

## Design for accessible and successful experiences

When it comes to accessible digital experiences, the Web Content Accessibility Guide 2.0 (WCAG 2.0) outlines four principles for designing accessible web content. The guidelines state that all web content must be perceivable, operable, understandable, and robust—otherwise, users with disabilities cannot access the web. Embracing these principles aligns with Section 508 requirements.

<table class="usa-table usa-table--striped">
<caption></caption>
<thead>
<tr style="text-align: left; vertical-align: top;">
<th scope="col">WCAG 2.0 Principles</th>
<th scope="col">Description</th>
</tr>
</thead>
<tbody>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Perceivable</th>
<td>Users must be able to perceive the information being presented (it can't be invisible to all of their senses)</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Operable</th>
<td>Users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Understandable</th>
<td>Users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)</td>
</tr>
<tr style="text-align: left; vertical-align: top;">
<th scope="row">Robust</th>
<td>Users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)</td>
</tr>
</tbody>
</table>

## Explore accessibility resources

Overall, accessible design represents the first step to [universal design](https://www.section508.gov/develop/universal-design/). By accounting for all types of disabilities and circumstances, government web and digital practitioners can improve how their products serve the public. [Section508.gov](https://www.section508.gov/) offers information on [accessibility policies](https://www.section508.gov/manage/), [acquisition resources](https://www.section508.gov/buy-sell/), and [content creation tools](https://www.section508.gov/create/).

For more information about how different product team roles play in making federal resources accessible and inclusive, browse the [Accessibility for Teams guide](https://digital.gov/guides/accessibility-for-teams/) on Digital.gov. Additionally, the [Technology Accessibility Playbook](https://www.section508.gov/manage/playbooks/technology-accessibility-playbook-intro/) on Section508.gov offers 12 key plays for ensuring that U.S. government technology is accessible for people with disabilities.

{{< ring title="Case study">}}
**Baking accessibility into FindSupport.gov**

The FindSupport team frequently tested with people with disabilities to ensure [FindSupport.gov](https://www.samhsa.gov/find-support) met Section 508 requirements.

Focusing on our product roadmap, the Substance Abuse and Mental Health Administration (SAMHSA) and Centers for Medicare and Medicaid Services (CMS) teams took the following steps to center accessible experiences into the site’s design and functionality. This included:

- Creating automated and manual testing plans
- Setting regular cadence for testing accessibility
- Accounting for accessibility when creating and estimating user stories
- Prioritizing new accessibility issues
- Outlining team accessibility roles
{{< /ring >}}

---

<footer>
<h3 id="footnote-label">Footnotes</h3>
<ol>
<li id="fn1">“World Wide Web Consortium Launches International Program Office for Web Accessibility Initiative.” 1997. W3C. October 22, 1997. <a href="https://www.w3.org/press-releases/1997/ipo-announce/">https://www.w3.org/press-releases/1997/ipo-announce/</a>. <a href="#footnotes-ref1" aria-label="Back to content">↩</a></li>
</ol>
<footer>
Loading

0 comments on commit adc1201

Please sign in to comment.