-
Notifications
You must be signed in to change notification settings - Fork 306
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into ss-resource-updates-on-ai-topic
- Loading branch information
Showing
36 changed files
with
946 additions
and
112 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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> |
Oops, something went wrong.