generated from cloud-gov/pages-uswds-jekyll
-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This should include the latest roles (#49)
* Initial add for documentation on how to create an OpenACR All based on GSA/openacr#233 * Lots of little changes to the pages Adding hero image to home page. Trying to change the menu page. Adding faq, resources & roadmap. * removing unneeded page * Name change * Adding content for roles & more Including info on vpat, acr & accessibility statement * I had lost the navigation. Adding it back * This should stay as VPAT * an to a * Removing outdated references * removing space * removing space * fixing email. * adding space * This should be a separate issue. it wasn't working locally and I shouldn't have committed it. * Updating highlights to include links & align with content * Missing </a> * adding {{ site.baseurl }} to footer link * Adding base url {{ site.baseurl }} * Update _config.yml Samples was wrong, and it shouldn't be first. Examples is better. * Adding {{ site.baseurl }} * Adding {{ site.baseurl }} * Exampless isn't a word you say... * Nobody likes innovative spelling - Corected Vendor Also ajusted to Others / others * As far as others/other Let's make it consistent now and right later * vendors changing url * Move to advocates * Change to advocates and adding others so it isn't just PwD * filename change to advocates.md * Adding ® * Switching to VPAT® * Change to VPAT® * adding VPAT® * I think that's the last advocates switch * Simplifying URL
- Loading branch information
Showing
13 changed files
with
256 additions
and
20 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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
--- | ||
title: Accessibility Subject Matter Expert (SME) | ||
layout: page | ||
sidenav: false | ||
permalink: /accessibility-expert/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
The role of the Accessibility SME varies slightly depending on their role in the procurement process. Ultimately though, the guidelines and standards used should support independent varification. Furthermore, the goal of the Accessibility SME should be fundamentally to remove barriers and support the adoption of inclusive best practices. | ||
|
||
Accessibility SMEs may be brought in to the process to write the ACR, interpret the results, and verify the findings. In places where there is not agreement, the Accessibility SME may be required to provide justification. | ||
|
||
The goal should be a good customer experience for everyone, not simply conforming to the regulations. Section 508 should be the basis, and accessibility teams should be striving to exceed those minimum requrirements. | ||
|
||
## Vendor | ||
|
||
The vendor's Accessibility SME may be involved in engaging an agency and reviewing their findings. Barriers that are identified will need to be included in whatever issue tracking system the firm uses to manage their development. Barriers that have already been identified in the issue queue should be included in the OpenACR until they are included in a release. | ||
|
||
Smaller firms may choose to write the OpenACRs with their own internal accessibility experts. This is acceptable, but software reviewed by 3rd parties will carry more weight with procurement officers. We have built the [OpenACR Editor](https://gsa.github.io/openacr-editor/) to help make this easier for smaller vendors. | ||
|
||
The vendor is responsible for ensuring that the OpenACR is maintained in a cadence which roughly aligns with release cycles for the product or service. Software with active releases should have timely updates. | ||
|
||
## Procurement | ||
|
||
Organizations buying software may be producing their own OpenACRs. These may be for software that they build internally, or for digital products/services that they are seeking to buy. OpenACR is a format which can effectively relay concerns about a vendors products and services. Organizations may also wish to share OpenACR reviews that they have made with other teams. OpenACR documents can also be extended if teams which to collaborate on a review of common software. The [OpenACR Editor](https://gsa.github.io/openacr-editor/) can be used to facilitate this. | ||
|
||
More commonly though, Accessibility SMEs will be reviewing the OpenACR documents which the Procurement Contracting Officer (PCO) has collected. In this case, their experience will be required to both understand the impact that the Requiring officials (requestor) is organizing. The HTML reports will allow simple comparisons, but it will be important for the SME to evaluate the credibility of the claims for the vendor. Are the barriers sufficiently explained in the comments? Have a sufficient range of techniques been used in the evaluation for the ACR? | ||
|
||
## Agency or Contractor | ||
|
||
There are many digital agencices that develop VPAT® reports and can also develop OpenACR reports. There is no need to use the [OpenACR Editor](https://gsa.github.io/openacr-editor/) however, valid OpenACRs must validate against the schema as decribed in the [technical documentation](https://github.com/GSA/openacr/tree/main/docs). |
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,42 @@ | ||
--- | ||
title: Accessibility Statement | ||
description: Website accessibility statement and feedback document. | ||
layout: page | ||
sidenav: false | ||
permalink: /accessibility/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
## Our goals | ||
|
||
The OpenACR Accessibility website is still an MVP, and we are following accessibility best practices as we develop the site. | ||
|
||
We strive to meet the latest W3C Recommendation of the WCAG guidelines (currently [WCAG 2.1 AA](https://www.w3.org/TR/WCAG21/)). | ||
|
||
## Design framework | ||
|
||
The design framework for this website is built primarily leveraging the [U.S. Web Design System](https://designsystem.digital.gov/) which has undergone extensive accessibility testing. By leveraging open source best practices, we can benefit from much larger teams which have done extensive testing of their patterns. | ||
|
||
## Color | ||
|
||
The website color palette is based on the GSA's and has been tested to meet color contrast requirements. | ||
|
||
## Technology | ||
|
||
The pages on this website are primarily written in Markdown which substantially reduces the range of errors available in HTML. These are then compiled using [Jekyll](https://jekyllrb.com/) and presented to the user as structured HTML5\. | ||
|
||
We use [axe-core](https://github.com/dequelabs/axe-core) with [Pa11y](https://github.com/pa11y) to evaluate that every page follows basic accessibility best practices. | ||
|
||
## Known issues | ||
|
||
- [Website accessibility issues can be found on the website](https://github.com/GSA/openacr-website/issues) | ||
- We can control the accessibility of the site, but not the accessibility of GitHub. GitHub is reasonably accessible, but is not currently seeking to be as accessible as this site. | ||
|
||
## Feedback | ||
|
||
If you run into any accessibility barriers with this website, please contact us: | ||
|
||
- Email: [[email protected]](mailto:[email protected]) | ||
- [Submit an issue](https://github.com/GSA/openacr-website/issues) | ||
- [Submit a pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) |
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,16 @@ | ||
--- | ||
title: Accessibility Conformance Report (ACR) | ||
layout: page | ||
sidenav: false | ||
permalink: /acr/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
A report for Information and Communication Technology (ICT), describing how the they will fully address the accessibility requirements outlined in the solicitation; | ||
|
||
This should include a description of the evaluation methods the offeror will use to validate for conformance to the Revised 508 Standards. | ||
|
||
Section508.gov also has additional information on how to [best sell accessible products and services](https://www.section508.gov/sell/). | ||
|
||
ACRs should only be completed after products have been evaluated for conformance. It is not possible to create an ACR on a project which has not already been built. |
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,26 @@ | ||
--- | ||
title: Advocates for Inclusion | ||
layout: page | ||
sidenav: false | ||
permalink: /advocates/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
## People with Disabilities (and Allies) | ||
|
||
Many people who have disabilities and advocates may review an ACR to help understand how well their needs will be supported. It is important to note that accessibility is a journey, the expectation is that technology evolves with the needs of the users and the ecosystem in which it works. | ||
|
||
## Chief Accessibility Officers (CAO) / Chief Diversity Officer (CDO) | ||
|
||
CAO's & CDOs often play a key role in ensuring that staff are able to get the support that they need to do their jobs. Understanding the key barriers in a organization's digital infrastructure is a key part of that. | ||
|
||
## Chief Information Officers (CIO) / Chief Technical Officers (CTO) | ||
|
||
Often the responsibility evaluate enterprise-wide accessibility falls on the CIO or CTO. Often the role of assessing if an organizations technical infrastructure is able to to effectively support users with permanent, temporary and situational disabilities falls as a responsibility of the CIO or CTO. | ||
|
||
# Affinity Groups | ||
Many organizations have affinity groups for people with disabilities to support each other in getting the support they need. They may not be able to understand the technical elements of an ACR, but should be able to understand the barriers that people with different disabilities will face. | ||
|
||
# Accessibility Organizations | ||
There are a range of accessibility organizations who are looking to support people with disabilities. They may have examples of good/bad practices which affect people with specific disabilities. |
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,43 @@ | ||
--- | ||
title: Procurement Team | ||
layout: page | ||
sidenav: false | ||
permalink: /procurement/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
Different organizations may have different definitions and termonilogy, but for larger organizations there are distinct roles involved in procurement. More information on various roles is available on [Acquisition.gov](https://www.acquisition.gov/). | ||
|
||
## Requiring officials (requestor) | ||
|
||
The goal of the requestor is to see that the project is sustainable, interoperable, and easier to implement for their department. | ||
|
||
The requestor is usually the internal agency lead for the project. They will likely defer to one of the other roles to ensure that Section 508 requirements are met. | ||
|
||
## Procurement Contracting Officer (PCO) | ||
|
||
The goal of the PCO is to document that accessibility has been properly considred for accessibility. This emeans either evaluating conformance claims and choosing the technology that reasonably claims to be accessible or if that is an option, choosing one that meets the [best meets exceptions](https://www.section508.gov/buy/determine-ict-exceptions/#7) to avoid bid protests. | ||
|
||
PCOs have historically looked for or asked vendors for VPAT® reports. The process is similar with OpenACRs, however an OpenACR can list: | ||
|
||
- a public Git repository, which will make it easier to update | ||
- additional people who are responsible for maintaining the reporting | ||
|
||
OpenACRs also default to a Creative Commons license to make it easier to identify how content can be shared across the organization. If an OpenACR has a permissive license it can be confidently published on a government site for recommended vendors. | ||
|
||
PCOs are encouraged demonstrate a preference for permissive licenses with open Git repositories in most instances. This will make it easier to for enterprise-wide evaluations. | ||
|
||
The [Accessibility Requirements Tool (ART)](https://www.section508.gov/buy/accessibility-requirements-tool/) can support PCOs in ensuring that the proper procurement language is used. | ||
|
||
Standard ICT Items are required to provide a [Supplemental Accessibility Report (SAR)](https://www.section508.gov/buy/request-accessibility-information/#0). The SAR provides additional information on how to better support persons with disabilities. | ||
|
||
## Contracting Officer's Representative (COR) | ||
|
||
CORs are responsible for seeing that the contractual needs are met. Looking at the results of the ART docuementation that was developed by the PCO, were expectations met? | ||
|
||
A COR will want to look at the vendor's claims with the ACR that they submitted or released in their git repository. If those claims are deemed inadequate or misleading from the Accessibility SME, then they may need to engage with the vendor. | ||
|
||
## Accessibility Subject Matter Expert (SME) | ||
|
||
The role of the [Accessibility SME]({{ site.baseurl }}/accessibility-expert) is defined on its own page. |
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,10 @@ | ||
--- | ||
title: OpenACRs and Me | ||
layout: page | ||
sidenav: false | ||
permalink: /roles/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
Procurment is complex, and there are many roles involved. We have tried to break These into several broad categories to help people quickly find the informaton that they need. |
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,32 @@ | ||
--- | ||
title: Vendor Team | ||
layout: page | ||
sidenav: false | ||
permalink: /vendors/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
## Sales | ||
|
||
ACRs are part of the sales process, but one goal of OpenACR is to move responsibility from sales to development and design. Accessibility should be built into the process of developing digital products/services, so should happen earlier in the process. | ||
|
||
Sales teams will still be contacted for procurement opportunities and will need to ensure that the prospective clients have the ACRs that they have requested. It is important to note the version number of the product/service being considered. | ||
|
||
If a vendor chooses to not release their OpenACR files through a public git repository, then the sales team will be contacted more regularly with requests. Note that some clients will request an version with a permissive license or a open git repository. Vendors who invest in accessibility will be benefit from sharing ACRs highlighting their work to comply. | ||
|
||
The HTML version of the OpenACR report is the easiest to read. If you want to highlight the report on your website, it can be easily styled with an external CSS file. | ||
|
||
## Legal | ||
|
||
Accessibility perfection is not expected as part of Section 508\. Standards and environments change over time, particularly with devices connected to the internet. OpenACRs can be used to demonstrate that your products are getting more accessible over time. This does require a committment to making sure that accessibility is maintained, and regular reviews to see that they are meeting the current best practice. | ||
|
||
## Developers/Designers | ||
|
||
Ideally the issue tracker will be organzied so that accessibility barriers align with the Section 508 requirements. This should allow for draft summaries to be easily pulled from the issue queue to ensure that known barriers are identified in the OpenACR. It is also important to update the OpenACR when issues have been fixed in a given release. | ||
|
||
You will want to have the language for this reviewed by sales and possibly legal to ensure that the tone is appropriate for a prospective client. The OpenACR format can be extended to include information which ties into other systems or corporate metadata. Additional information should not break the validation of the OpenACR file, however you may not wish to share it publically. | ||
|
||
## Accessibility Subject Matter Expert (SME) | ||
|
||
The role of the [Accessibility SME]({{ site.baseurl }}/accessibility-expert) is defined on its own page. |
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,21 @@ | ||
--- | ||
title: Voluntary Product Accessibility Template (VPAT®) | ||
layout: page | ||
sidenav: false | ||
permalink: /vpat/ | ||
--- | ||
|
||
# **{{page.title}}** | ||
|
||
The [Information Technology Industry Council](https://www.itic.org) built and had maintained the [Voluntary Product Accessibility Template® (VPAT®)](https://www.itic.org/policy/accessibility/vpat). | ||
|
||
VPAT® Version 2.4 (February 2020) comes in four editions: | ||
|
||
- WCAG edition - For reporting compliance to the W3C Web Content Accessibility Guidelines (WCAG) 2.1. | ||
- 508 edition - For reporting compliance to the U.S. Revised Section 508 standards | ||
- EU edition - The European edition used for reporting compliance to the EN 301 549 standard | ||
- INT edition - The international edition used for reporting compliance to all three standards | ||
|
||
The ITI also developed [VPAT® Training videos & slides](https://www.itic.org/policy/accessibility/vpat-training) which can be an important source of information. | ||
|
||
The OpenACR format is presently based on the 508 edition version of VPAT® Version 2.4\. If a procurement opportunity calls for a VPAT®, you should be able to submit an HTML or PDF version of your OpenACR. In most cases the HTML report can either be either imported into Microsoft Word simply printed to PDF. The default HTML version will likely be the most accessible version. |