diff --git a/_data/sidenav.yaml b/_data/sidenav.yaml index a8760bd09..77507fb80 100644 --- a/_data/sidenav.yaml +++ b/_data/sidenav.yaml @@ -1,9 +1,9 @@ # We can add any kind of data in this _data folder and this file. -# In this example, we create a simple array of options and then in the _pages/collections.md file we -# Reference this data file in 'datafile' in the Front Matter and _layouts/list.html renders it +# In this example, we create a simple array of options and then in the _pages/collections.md file we +# Reference this data file in 'datafile' in the Front Matter and _layouts/list.html renders it # This is simple, hopefully provides you with a good enough example to make changes as needed manage: - - name: Policy and Management + - name: Policy and Management url: manage/ - name: Management url: '#' @@ -356,13 +356,22 @@ acquisition: url: 'buy/solicitation-review-tool/' - name: 508 Standards and Exceptions Chart & Examples url: 'buy/standards-exceptions/' + - name: Open Accessibility Conformance Reports (OpenACR) + url: 'openacr/' - name: Sell url: '#' children: - name: Sell Accessible Products and Services url: sell/ - - name: Voluntary Product Accessibility Template (VPAT) - url: sell/vpat/ + - name: Open Accessibility Conformance Reports (OpenACR) + url: 'openacr/' + grandchildren: + - name: Why OpenACR + url: openacr/about/ + - name: OpenACR initiative + url: openacr/initiative/ + - name: Creating an OpenACR report + url: openacr/create-report/ create: - name: Content Creation url: 'create/' @@ -411,4 +420,4 @@ create: - name: Video, Audio, Social url: 'create/video-social/' - name: Electronic Signature - url: 'create/electronic-signatures/' \ No newline at end of file + url: 'create/electronic-signatures/' diff --git a/_pages/acquisition/2018-05-02-buy-sell.md b/_pages/acquisition/2018-05-02-buy-sell.md index 01c7188d5..6f91f5334 100644 --- a/_pages/acquisition/2018-05-02-buy-sell.md +++ b/_pages/acquisition/2018-05-02-buy-sell.md @@ -3,7 +3,7 @@ layout: page sidenav: true permalink: buy-sell/ type: acquisition -title: 'Buy or Sell Accessible ICT' +title: Buy or Sell Accessible ICT created: 1525317857 --- @@ -11,32 +11,24 @@ All information and communication technology (ICT) procured, developed, maintain {: .text-gray-50 }
-
\ No newline at end of file + diff --git a/_pages/acquisition/2018-05-24-buy-define-accessibility-criteria.md b/_pages/acquisition/2018-05-24-buy-define-accessibility-criteria.md index fdbcb8ff9..7c320474b 100644 --- a/_pages/acquisition/2018-05-24-buy-define-accessibility-criteria.md +++ b/_pages/acquisition/2018-05-24-buy-define-accessibility-criteria.md @@ -3,60 +3,34 @@ layout: page sidenav: true permalink: buy/define-accessibility-criteria/ type: acquisition -title: 'Define Accessibility Criteria in Contracts' +title: Define Accessibility Criteria in Contracts created: 1527181796 --- When preparing solicitations, statements of work, or other procurement documents, clearly define your criteria to ensure the information and communication technology (ICT) your agency buys or builds is accessible and conforms to the [Revised 508 Standards][1]. Use the sample language below in your procurement documents to mitigate Section 508 compliance risk in IT procurement and development. - * Tailor these provisions and clauses to meet your needs. - * Carefully assess the risk of implementing inaccessible ICT items. - * Only use provisions and clauses that are appropriate for the ICT items you're purchasing. - * Where an exception does not apply to some or all components of an ICT item, these provisions and clauses may apply. - * Use of these provisions and clauses may increase the cost of an award. Ask offerors to separate out these costs in their proposals, particularly if your agency anticipates that conformance to particular provisions of the Revised 508 Standards may warrant an exception for undue burden. +- Tailor these provisions and clauses to meet your needs. +- Carefully assess the risk of implementing inaccessible ICT items. +- Only use provisions and clauses that are appropriate for the ICT items you're purchasing. +- Where an exception does not apply to some or all components of an ICT item, these provisions and clauses may apply. +- Use of these provisions and clauses may increase the cost of an award. Ask offerors to separate out these costs in their proposals, particularly if your agency anticipates that conformance to particular provisions of the Revised 508 Standards may warrant an exception for undue burden. Navigate through the sections below to find sample language you can cut and paste into your procurement documents. - +- [Provisions and Clauses](#provisions) + - [Custom ICT Development Services](#custom-ict) + - [Installation, Configuration & Integration Services](#installation) + - [Maintenance Upgrades & Replacements](#maintenance) + - [Service Personnel](#service) + - [Hosting Services](#hosting) + - [Validation for ICT Items](#validation) + - [Documentation](#documentation) +- [Acceptance Criteria](#acceptance) + + - [Conformance Reporting](#conformance) + - [Non-Compliance](#non-compliance)

@@ -64,8 +38,6 @@ Navigate through the sections below to find sample language you can cut and past

- -

Custom ICT Development Services @@ -82,7 +54,7 @@ When the offeror provides custom ICT development services pursuant to this contr

- Installation, Configuration & Integration Services + Installation, Configuration & Integration Services

@@ -96,7 +68,7 @@ When the offeror provides installation, configuration or integration services fo

- Maintenance Upgrades & Replacements + Maintenance Upgrades & Replacements

@@ -150,9 +122,9 @@ When purchasing ICT where 508 validation is not possible prior to award (e.g., t The contractor shall test and validate the ICT solution for conformance to the Revised 508 Standards, in accordance with the required testing methods. - * For web and software, WCAG Level A and AA Conformance Test Results must be based on the [Harmonized Testing Process for Section 508 Compliance: Baseline Tests for Software and Web Accessibility][2]. - * For Microsoft Office and PDF documents, WCAG Level A and AA Conformance test results must be based on the Harmonized Testing Guidance from the AED ACOP. - * For ICT Items that are not electronic content, the offeror shall validate conformance to the applicable Revised 508 Standards using a defined testing process. The offeror must describe test process and provide the testing results to the agency. +- For web and software, WCAG Level A and AA Conformance Test Results must be based on the [Harmonized Testing Process for Section 508 Compliance: Baseline Tests for Software and Web Accessibility][2]. +- For Microsoft Office and PDF documents, WCAG Level A and AA Conformance test results must be based on the Harmonized Testing Guidance from the AED ACOP. +- For ICT Items that are not electronic content, the offeror shall validate conformance to the applicable Revised 508 Standards using a defined testing process. The offeror must describe test process and provide the testing results to the agency.

@@ -188,16 +160,16 @@ Use for ICT items that are developed, updated, configured for the agency, and wh **Sample language:** -Before acceptance, the contractor shall provide an **Accessibility Conformance Report (ACR)** for each ICT item that is developed, updated, configured for the agency, and when product substitutions are offered. The ACR should be based on the latest version of the [Voluntary Product Accessibility Template (VPAT)][3]provided by the [Industry Technology Industry Council (ITIC)][4]. To be considered for award, an ACR must be submitted for each ICT Item, and must be completed according to the instructions provided by ITIC. +Before acceptance, the contractor shall provide an **Accessibility Conformance Report (ACR)** for each ICT item that is developed, updated, configured for the agency, and when product substitutions are offered. The ACR should be based on the latest version of OpenACR. If an OpenACR report is not available, a procurement team may decide to accept a legacy [Voluntary Product Accessibility Template (VPAT™)][3]provided by the [Industry Technology Industry Council (ITIC)][4]. To be considered for award, an ACR must be submitted for each ICT Item, and must be completed according to the instructions provided in the ACR. Before acceptance, when the contractor is required to perform testing to validate conformance to the agency's accessibility requirements, the vendor shall provide a **Supplemental Accessibility Conformance Report (SAR)** that contains the following information: - * Accessibility test results based on the required test methods. - * Documentation of features provided to help achieve accessibility and usability for people with disabilities. - * Documentation of core functions that cannot be accessed by persons with disabilities. - * Documentation on how to configure and install the ICT item to support accessibility. - * When an ICT item is an authoring tool that generates content (including documents, reports, videos, multimedia productions, web content, etc.)., provide information on how the ICT item enables the creation of accessible electronic content that conforms to the Revised 508 Standards, including the range of accessible user interface elements the tool can create. - * Before final acceptance, the contractor shall provide a fully working demonstration of the completed ICT Item to demonstrate conformance to the agency's accessibility requirements. The demonstration shall expose where such conformance is and is not achieved. +- Accessibility test results based on the required test methods. +- Documentation of features provided to help achieve accessibility and usability for people with disabilities. +- Documentation of core functions that cannot be accessed by persons with disabilities. +- Documentation on how to configure and install the ICT item to support accessibility. +- When an ICT item is an authoring tool that generates content (including documents, reports, videos, multimedia productions, web content, etc.)., provide information on how the ICT item enables the creation of accessible electronic content that conforms to the Revised 508 Standards, including the range of accessible user interface elements the tool can create. +- Before final acceptance, the contractor shall provide a fully working demonstration of the completed ICT Item to demonstrate conformance to the agency's accessibility requirements. The demonstration shall expose where such conformance is and is not achieved. Before acceptance, the agency reserves the right to perform independent testing to validate that the ICT solution provided by the contractor conforms to the applicable Revised 508 Standards. @@ -215,11 +187,9 @@ Consider using this language only when you know the offeror has the ability to e Before final acceptance of any ICT item, including updates and replacements, if the offeror claims its products or services satisfy the applicable Revised 508 Standards specified in the statement of work, and the contracting officer determines that any furnished ICT item is not in compliance with such requirements, the contracting officer will promptly inform the offeror in writing of the noncompliance. The offeror shall, at no cost to the agency, repair or replace the non-compliant products or services within the period specified by the contracting officer. +**Reviewed/Updated:** March 2022 -**Reviewed/Updated:** May 2018 - - - [1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule - [2]: https://www.dhs.gov/compliance-test-processes - [3]: {{site.baseurl}}/sell/vpat - [4]: http://www.itic.org/policy/accessibility \ No newline at end of file +[1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule +[2]: https://www.dhs.gov/compliance-test-processes +[3]: {{site.baseurl}}/sell/vpat +[4]: http://www.itic.org/policy/accessibility diff --git a/_pages/acquisition/2018-05-29-buy-determine-ict-exceptions.md b/_pages/acquisition/2018-05-29-buy-determine-ict-exceptions.md index 6da8d2ffe..e6fd390b1 100644 --- a/_pages/acquisition/2018-05-29-buy-determine-ict-exceptions.md +++ b/_pages/acquisition/2018-05-29-buy-determine-ict-exceptions.md @@ -7,70 +7,46 @@ title: 'Step 2: Determine ICT Exceptions' created: 1527569078 --- - - Identifying whether you can claim an exception for information and communication technology (ICT) items in your Federal IT procurement or development project is the second step in determining how the [Revised 508 Standards][1] apply. (The first step is to [conduct an inventory][2].) This is important to ensure that any technology your agency buys or builds will be accessible. A full list of exceptions is detailed in the Standards under [E202 General Exceptions][3]. Use the [Revised 508 Standards Applicability Checklist][4] (MS-Word, April 2018) to document ICT exceptions. -Refer to your agency’s Accessibility policy to identify when formal approval by an agency representative is required to claim any of the following exceptions. +Refer to your agency's Accessibility policy to identify when formal approval by an agency representative is required to claim any of the following exceptions. ## **Exceptions** - - -

- E202.2 Legacy ICT Exception -

- -Agencies may claim a ”Safe Harbor” for existing ICT that was accessible and compliant with the earlier standard on or before January 18, 2018 and has not been subsequently changed to affect interoperability, the user interface, or access to information or data. This safe harbor applies on a component basis (each component or portion of existing ICT must be assessed separately). For federal government ICT, this exception can only be claimed by federal agencies and components. +- [E202.2 Legacy ICT Exception](#e2022-legacy-ict-exception) +- [E202.3 National Security Systems Exception](#1e2023-national-security-systems-exception) +- [E202.4 Federal Contracts Exception](#e2024-federal-contracts-exception) +- [E202.5 ICT Functions Located in Maintenance or Monitoring Spaces Exception](#e2025-ict-functions-located-in-maintenance-or-monitoring-spaces-exception) +- [E202.6 Undue Burden or Fundamental Alteration Exception](#e2026-undue-burden-or-fundamental-alteration-exception) + + - [Evaluating Undue Burden](#evaluating-undue-burden) + - [Evaluating Fundamental Alteration](#evaluating-fundamental-alteration) + +- [E202.7 Best Meets Exception](#e2027-best-meets-exception) + +## **E202.2 Legacy ICT Exception** + +Agencies may claim a "Safe Harbor" for existing ICT that was accessible and compliant with the earlier standard on or before January 18, 2018 and has not been subsequently changed to affect interoperability, the user interface, or access to information or data. This safe harbor applies on a component basis (each component or portion of existing ICT must be assessed separately). For federal government ICT, this exception can only be claimed by federal agencies and components. If all these conditions apply, legacy ICT components do not need to be remediated to conform to the Revised 508 Standards: - * The legacy ICT was deployed, altered, or procured within the government on or before January 18, 2018; - * The legacy ICT conformed to the [Electronic and Information Technology Accessibility Standards as originally published][5] on December 21, 2000, or qualified for an exception under these Standards before January 18, 2018; - * No changes were made to the legacy ICT affecting interoperability, the user interface, or access to information or data after January 18, 2018. +- The legacy ICT was deployed, altered, or procured within the government on or before January 18, 2018; +- The legacy ICT conformed to the [Electronic and Information Technology Accessibility Standards as originally published][5] on December 21, 2000, or qualified for an exception under these Standards before January 18, 2018; +- No changes were made to the legacy ICT affecting interoperability, the user interface, or access to information or data after January 18, 2018. ### **Decision Questions** -If the answer to all questions is ”yes”, this exception applies. +If the answer to all questions is "yes", this exception applies. - 1. Did your agency deploy, maintain, or use the ICT on or before January 18, 2018? - 2. Is the ICT known to have conformed to the [Electronic and Information Technology Accessibility Standards as originally published][5], prior to January 18, 2018? - 3. Since January 18, 2018, has the ICT remained unchanged regarding interoperability, the user interface, or access to information and data? +1. Did your agency deploy, maintain, or use the ICT on or before January 18, 2018? +2. Is the ICT known to have conformed to the [Electronic and Information Technology Accessibility Standards as originally published][5], prior to January 18, 2018? +3. Since January 18, 2018, has the ICT remained unchanged regarding interoperability, the user interface, or access to information and data? -Return to Top +[Return to Top](#content-section) -

- E202.3 National Security Systems Exception -

+## **E202.3 National Security Systems Exception** This exception applies to ICT operated by agencies as part of a national security system, as defined by 40 U.S.C. 11103(a). For federal government ICT, this exception can only be claimed by federal agencies and components. This exception cannot be claimed by vendors and contractors. @@ -78,197 +54,190 @@ This exception applies to ICT operated by agencies as part of a national securit If any of the following apply, your ICT may qualify for this exception: - 1. Involves intelligence activities; - 2. Involves cryptologic activities related to national security; - 3. Involves command and control of military forces; - 4. Involves equipment that is an integral part of a weapon or weapons system; or - 5. Is critical to the direct fulfillment of military or intelligence missions (does not include routine administrative and business applications such as payroll, finance, logistics, and personnel management). +1. Involves intelligence activities; +2. Involves cryptologic activities related to national security; +3. Involves command and control of military forces; +4. Involves equipment that is an integral part of a weapon or weapons system; or +5. Is critical to the direct fulfillment of military or intelligence missions (does not include routine administrative and business applications such as payroll, finance, logistics, and personnel management). -Return to Top +[Return to Top](#content-section) -

- E202.4 Federal Contracts Exception -

+## **E202.4 Federal Contracts Exception** This exception applies to ICT acquired by a contractor incidental to a contract. For federal government ICT, this exception can only be claimed by federal agencies and components. This exception does not apply, IF: - * The ICT will revert to government ownership; - * The government directly procures the ICT; or - * Members of the public or government employees use the ICT. +- The ICT will revert to government ownership; +- The government directly procures the ICT; or +- Members of the public or government employees use the ICT. ### **Decision Questions** -If the answer to all questions is ”yes”, this exception applies. +If the answer to all questions is "yes", this exception applies. - 1. Is the vendor or contractor procuring the ICT? - 2. Will ONLY vendor or contractor personnel access or use the ICT? - 3. Will ownership of the ICT remain with the vendor or contractor upon completion of the contract? +1. Is the vendor or contractor procuring the ICT? +2. Will ONLY vendor or contractor personnel access or use the ICT? +3. Will ownership of the ICT remain with the vendor or contractor upon completion of the contract? -Return to Top +[Return to Top](#content-section) -

- E202.5 ICT Functions Located in Maintenance or Monitoring Spaces Exception -

+## **E202.5 ICT Functions Located in Maintenance or Monitoring Spaces Exception** -This exception applies to status indicators and operable parts for ICT functions located in spaces that are frequented only by service personnel for maintenance, repair, or occasional equipment monitoring. (Similar to the ”Back Office Exception” allowed under the original 508 Standards, but scope is more limited.) For federal government ICT, this exception can only be claimed by federal agencies and components. +This exception applies to status indicators and operable parts for ICT functions located in spaces that are frequented only by service personnel for maintenance, repair, or occasional equipment monitoring. (Similar to the "Back Office Exception" allowed under the original 508 Standards, but scope is more limited.) For federal government ICT, this exception can only be claimed by federal agencies and components. ### **Decision Questions** -If the answer to all questions is ”yes”, this exception applies. +If the answer to all questions is "yes", this exception applies. - 1. Does the ICT have status indicators or operable parts (i.e., physical controls)? - 2. Is the ICT located in spaces that are frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment (i.e., on a rack mounted in a wiring closet)? +1. Does the ICT have status indicators or operable parts (i.e., physical controls)? +2. Is the ICT located in spaces that are frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment (i.e., on a rack mounted in a wiring closet)? -Return to Top +[Return to Top](#content-section) -

- E202.6 Undue Burden or Fundamental Alteration Exception -

+## **E202.6 Undue Burden or Fundamental Alteration Exception** Conformance to the Revised 508 Standards is required only when it does not impose an undue burden, or result in a fundamental alteration in the nature of the ICT. This exception is available only to federal agencies and components. - * E202.6.1 Basis for a Determination of Undue Burden - Consider the extent to which conformance would impose significant difficulty or expense, including availability of resources. - * E202.6.2 Required Documentation - Document in writing an explanation of why and to what extent it’s an undue burden on the agency, or would result in a fundamental alteration in the nature of the ICT. - * E202.6.3 Alternative Means - Provide individuals with disabilities access to, and use of, information and data by an alternative means that meet identified needs. +- E202.6.1 Basis for a Determination of Undue Burden - Consider the extent to which conformance would impose significant difficulty or expense, including availability of resources. +- E202.6.2 Required Documentation - Document in writing an explanation of why and to what extent it's an undue burden on the agency, or would result in a fundamental alteration in the nature of the ICT. +- E202.6.3 Alternative Means - Provide individuals with disabilities access to, and use of, information and data by an alternative means that meet identified needs. -

- Evaluating Undue Burden -

+### **Evaluating Undue Burden** Use this exception only in rare circumstances, where the cost to make ICT fully conform with the Standards would consume a significant amount of available program resources, or when conformance would present substantial difficulty. When acquiring, developing or customizing ICT, evaluate for applicability of this exception: - * Off-the-shelf (COTS/GOTS) ICT products, services or upgrades - After performing market research to understand the applicability of the Standards and alternatives available. - * Custom designed ICT - After the business needs for the new functionality and features are defined. +- Off-the-shelf (COTS/GOTS) ICT products, services or upgrades - After performing market research to understand the applicability of the Standards and alternatives available. +- Custom designed ICT - After the business needs for the new functionality and features are defined. The undue burden exception applies only to the specific features or functions of the ICT that cannot be made to conform to the Revised 508 Standards without imposing an undue burden on the agency or component. - * To claim this exception for the entire ICT item, you must determine that ALL features and functions of the ICT product or service cannot conform to the Revised 508 Standards without imposing an undue burden (significant difficulty or expense). - * If only SOME features and functions of the ICT product or service would impose an undue burden (significant difficulty or expense), you can only claim the exception for those features and functions. You must support compliance for the remaining items. +- To claim this exception for the entire ICT item, you must determine that ALL features and functions of the ICT product or service cannot conform to the Revised 508 Standards without imposing an undue burden (significant difficulty or expense). +- If only SOME features and functions of the ICT product or service would impose an undue burden (significant difficulty or expense), you can only claim the exception for those features and functions. You must support compliance for the remaining items. The federal agency or component that owns (or will own) the ICT product or service must: - * Decide that conformance to the Standards would impose an undue burden; - * Assess costs relative to resources if claiming the exception based on expense; and - * Assess the difficulties in achieving conformance to claim the exception based on difficulty. +- Decide that conformance to the Standards would impose an undue burden; +- Assess costs relative to resources if claiming the exception based on expense; and +- Assess the difficulties in achieving conformance to claim the exception based on difficulty. Contact the US Access Board for guidance on how to evaluate the applicability of an exception for undue burden. You may also want to consult with legal staff who are familiar with case law involving Undue Burden claims under Section 508 or related civil rights laws. For federal government ICT, this exception can only be claimed by federal agencies and components. ### **Decision Questions** -If the answer to all questions is ”yes”, your ICT may warrant this exception. +If the answer to all questions is "yes", your ICT may warrant this exception. + +1. Have you determined that conformance for some or all features and functions of the ICT item would result in an undue burden on your agency or component? +2. Have you quantified the resources available to the program or component for which the ICT is to be procured, developed, maintained, or used? +3. Has the responsible agency official documented in writing how the difficulty or expense is significant, relative to the resources available? For example: + + 1. What % of the expense equals total budget available? + 2. Explain exactly what is significantly difficult, and why. - 1. Have you determined that conformance for some or all features and functions of the ICT item would result in an undue burden on your agency or component? - 2. Have you quantified the resources available to the program or component for which the ICT is to be procured, developed, maintained, or used? - 3. Has the responsible agency official documented in writing how the difficulty or expense is significant, relative to the resources available? For example: - 1. What % of the expense equals total budget available? - 2. Explain exactly what is significantly difficult, and why. - 4. Does your documentation address whether the exception is being claimed for the entire ICT Item, or only specific features and functions? - 5. Will the agency provide an alternative means for users with disabilities for the features and functions for which you are claiming this exception? +4. Does your documentation address whether the exception is being claimed for the entire ICT Item, or only specific features and functions? +5. Will the agency provide an alternative means for users with disabilities for the features and functions for which you are claiming this exception? -

- Evaluating Fundamental Alteration -

+### **Evaluating Fundamental Alteration** -Use this exception only when conformance to the Revised 508 Standards would alter the inherent design of the ICT to the extent that it no longer adequately meets the agency’s business need. +Use this exception only when conformance to the Revised 508 Standards would alter the inherent design of the ICT to the extent that it no longer adequately meets the agency's business need. When acquiring, developing or customizing ICT, evaluate for applicability of this exception: - * Off-the-shelf (COTS/GOTS) ICT products, services or upgrades - After performing market research to understand the alternatives available. - * Custom designed ICT - After outlining the intended purpose of the ICT and developing the preliminary design. +- Off-the-shelf (COTS/GOTS) ICT products, services or upgrades - After performing market research to understand the alternatives available. +- Custom designed ICT - After outlining the intended purpose of the ICT and developing the preliminary design. The exception for fundamental alteration applies only to the specific features or functions of the ICT that cannot conform to the Revised 508 Standards without fundamentally altering the nature of the ICT. For federal government ICT, this exception can only be claimed by federal agencies and components. - * In order to claim the fundamental alteration exception for the entire ICT you must determine that ALL the features and functions of the ICT cannot conform to the Revised 508 Standards without fundamentally altering the nature of the ICT. - * If only SOME features and functions cannot conform without fundamentally altering the nature of the ICT, you can only claim the exception for those features and functions that would be fundamentally altered. You must support compliance for the remaining items. +- In order to claim the fundamental alteration exception for the entire ICT you must determine that ALL the features and functions of the ICT cannot conform to the Revised 508 Standards without fundamentally altering the nature of the ICT. +- If only SOME features and functions cannot conform without fundamentally altering the nature of the ICT, you can only claim the exception for those features and functions that would be fundamentally altered. You must support compliance for the remaining items. ### **Decision Questions** -If the answer to all questions is ”yes”, your ICT may warrant this exception. +If the answer to all questions is "yes", your ICT may warrant this exception. - 1. Have you determined that conformance to the Standards would fundamentally alter some or all of the features and functions, such that the ICT would not meet the agency’s business needs? - 2. Has the responsible agency official documented in writing the basis for determining that conformance would result in a fundamental alteration in the nature of the ICT? - 3. Does your documentation address whether the exception is being claimed for the entire ICT, or only specific features and functions of the ICT? - 4. Will the agency provide an alternative means for users with disabilities for the features and functions for which you are claiming this exception? +1. Have you determined that conformance to the Standards would fundamentally alter some or all of the features and functions, such that the ICT would not meet the agency's business needs? +2. Has the responsible agency official documented in writing the basis for determining that conformance would result in a fundamental alteration in the nature of the ICT? +3. Does your documentation address whether the exception is being claimed for the entire ICT, or only specific features and functions of the ICT? +4. Will the agency provide an alternative means for users with disabilities for the features and functions for which you are claiming this exception? -Return to Top +[Return to Top](#content-section) -

- E202.7 Best Meets Exception -

+## **E202.7 Best Meets Exception** -When ICT that fully conforms to the Revised 508 Standards is not commercially available, procure ICT that conforms best with the Standards, consistent with meeting the agency’s business needs. For federal government ICT, this exception can only be claimed by federal agencies and components. +When ICT that fully conforms to the Revised 508 Standards is not commercially available, procure ICT that conforms best with the Standards, consistent with meeting the agency's business needs. For federal government ICT, this exception can only be claimed by federal agencies and components. - * E202.7.1 Required Documentation - The responsible agency official must document in writing: - * The non-availability of ICT that fully conforms to the Standards, including a description of market research performed and which provisions cannot be met; and - * The basis for determining that the ICT to be procured best meets the Standards consistent with meeting agency business needs. +- E202.7.1 Required Documentation - The responsible agency official must document in writing: - * E202.7.2 Alternative Means - Provide individuals with disabilities access to and use of information and data by an alternative means that meets identified needs. + - The non-availability of ICT that fully conforms to the Standards, including a description of market research performed and which provisions cannot be met; and + - The basis for determining that the ICT to be procured best meets the Standards consistent with meeting agency business needs. -The best meets exception provides a mechanism to help agencies balance business needs and obligations to procure ICT Items that conform to the Revised 508 Standards when an alternative that fully conforms is not available. Similar to ”commercial non availability” in the original 508 Standards, but now formally addressed as an exception. +- E202.7.2 Alternative Means - Provide individuals with disabilities access to and use of information and data by an alternative means that meets identified needs. + +The best meets exception provides a mechanism to help agencies balance business needs and obligations to procure ICT Items that conform to the Revised 508 Standards when an alternative that fully conforms is not available. Similar to "commercial non availability" in the original 508 Standards, but now formally addressed as an exception. In determining best meets, consider the use of an equivalent design or technology to address the Standards when assessing overall conformance. Refer to [E101.2 of the Revised Standards][6] to learn how to assess the role of equivalent facilitation. - * During a technical evaluation: - * If one or more alternatives fully conform to the Revised 508 Standards, select one of these alternatives when making selection(s) for award. - * If no alternative fully conforms, select the alternative that best meets the Standards when making an award; the best meets determination is based on the relative degree of conformance of the ICT item offered. +- During a technical evaluation: + + - If one or more alternatives fully conform to the Revised 508 Standards, select one of these alternatives when making selection(s) for award. + - If no alternative fully conforms, select the alternative that best meets the Standards when making an award; the best meets determination is based on the relative degree of conformance of the ICT item offered. + +- Where multiple ICT products, services, or components are bundled into a single ICT item, a best meets determination should compare one combined solution or item with another, unless the agency can select individual ICT products, services, or components from separate offers. Refer to "considerations for complex solicitations" in [Step 1][2]. - * Where multiple ICT products, services, or components are bundled into a single ICT item, a best meets determination should compare one combined solution or item with another, unless the agency can select individual ICT products, services, or components from separate offers. Refer to "considerations for complex solicitations" in [Step 1][2]. +- When selecting an alternative that only partially conforms, the responsible agency official must: - * When selecting an alternative that only partially conforms, the responsible agency official must: - * Document the basis for the determination, including market research conducted and why the selected ICT best meets the Revised 508 Standards. Provide information on: - * What ICT alternatives were evaluated; - * The lack of a fully conforming solution that meets the business needs; - * The degree of 508 conformance of the ICT selected, as compared to the degree of conformance of the ICT that were not selected; and, - * The steps taken to evaluate the degree of conformance (e.g., 508 expert VPAT™ review, vendor 508 test results, or vendor test results) - * Provide an alternative means that meets the identified needs of people with disabilities not supported by the ICT Item(s). + - Document the basis for the determination, including market research conducted and why the selected ICT best meets the Revised 508 Standards. Provide information on: - * For ”brand name or equivalent” COTS or GOTS solicitations, the supporting documentation used to justify the acquisition may be sufficient to fulfil the documentation requirements. If the ”brand name” ICT item does not fully support the Revised 508 Standards, the agency is still responsible for providing individuals with disabilities access to the non-conforming functions and features of the ICT Item through an alternative means that meets their identified needs. + - What ICT alternatives were evaluated; + - The lack of a fully conforming solution that meets the business needs; + - The degree of 508 conformance of the ICT selected, as compared to the degree of conformance of the ICT that were not selected; and, + - The steps taken to evaluate the degree of conformance (e.g., 508 expert, ACR review, vendor 508 test results, or vendor test results) + + - Provide an alternative means that meets the identified needs of people with disabilities not supported by the ICT Item(s). + +- For "brand name or equivalent" COTS or GOTS solicitations, the supporting documentation used to justify the acquisition may be sufficient to fulfil the documentation requirements. If the "brand name" ICT item does not fully support the Revised 508 Standards, the agency is still responsible for providing individuals with disabilities access to the non-conforming functions and features of the ICT Item through an alternative means that meets their identified needs. ### **Decision Questions** -If the answer to all questions is ”yes”, your ICT item may warrant this exception. +If the answer to all questions is "yes", your ICT item may warrant this exception. - 1. Have you completed market research addressing Section 508 compliance for the ICT Item? - 2. Did you evaluate Accessibility Conformance Reports or test results to validate 508 conformance claims? - 3. Did you document the market research performed to validate 508 conformance claims? - 4. Of the ICT items which met business needs, were there no options that fully conformed to the Revised 508 Standards? - 5. Are you purchasing the ICT Item that best meets the Revised 508 Standards? - 6. Will the agency provide an alternative means for users with disabilities for the features and functions that do not conform to the Revised 508 Standards? +1. Have you completed market research addressing Section 508 compliance for the ICT Item? +2. Did you evaluate Accessibility Conformance Reports or test results to validate 508 conformance claims? +3. Did you document the market research performed to validate 508 conformance claims? +4. Of the ICT items which met business needs, were there no options that fully conformed to the Revised 508 Standards? +5. Are you purchasing the ICT Item that best meets the Revised 508 Standards? +6. Will the agency provide an alternative means for users with disabilities for the features and functions that do not conform to the Revised 508 Standards? -Return to Top +[Return to Top](#content-section) -## **What’s Next?** +## **What's Next?** See the other steps in this process: - * [Process Overview][7] - * [Step 1: Inventory Your ICT][2] - * Step 2: Determine ICT Exceptions (you are here) - * [Step 3: Determine Which Standards Apply][8] +- [Process Overview][7] +- [Step 1: Inventory Your ICT][2] +- Step 2: Determine ICT Exceptions (you are here) +- [Step 3: Determine Which Standards Apply][8] ## **Related Resources** - * [Revised 508 Standards Applicability Checklist][4] (MS-Word, April 2018) - Use this checklist to document your accessibility requirements for ICT items - * [Accessibility Requirements Tool][9] - Automates the Revised 508 Standards Applicability Checklist; generates an accessibility reporting requirements template and customizable accessibility solicitation language. - * Original Guidance Document - Developed by the U.S. Federal Government Revised 508 Standards Transition Workgroup; members include the U.S. Federal CIO Council Accessibility Community of Practice, the U.S. Access Board, and the General Services Administration. - -Contact your agency’s [Section 508 Coordinator][10] or email us at with questions. +- [Revised 508 Standards Applicability Checklist][4] (MS-Word, April 2018) - Use this checklist to document your accessibility requirements for ICT items +- [Accessibility Requirements Tool][9] - Automates the Revised 508 Standards Applicability Checklist; generates an accessibility reporting requirements template and customizable accessibility solicitation language. +- Original Guidance Document - Developed by the U.S. Federal Government Revised 508 Standards Transition Workgroup; members include the U.S. Federal CIO Council Accessibility Community of Practice, the U.S. Access Board, and the General Services Administration. -**Updated/Reviewed**: May 2018 +Contact your agency's [Section 508 Coordinator][10] or email us at [section.508@gsa.gov](mailto:section.508@gsa.gov) with questions. -  +**Reviewed/Updated:** March 2022 - [1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines - [2]: {{site.baseurl}}/buy/inventory-your-ict - [3]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#E202-general-exceptions - [4]: https://assets.section508.gov/files/508-standards-applicability-checklist.docx - [5]: https://www.federalregister.gov/documents/2000/12/21/00-32017/electronic-and-information-technology-accessibility-standards - [6]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#E101-general - [7]: {{site.baseurl}}/buy/determine-508-standards-exceptions - [8]: {{site.baseurl}}/buy/determine-ict-standards - [9]: {{site.baseurl}}/buy/accessibility-requirements-tool - [10]: {{site.baseurl}}/tools/coordinator-listing \ No newline at end of file +[1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines +[10]: {{site.baseurl}}/tools/coordinator-listing +[2]: {{site.baseurl}}/buy/inventory-your-ict +[3]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#E202-general-exceptions +[4]: https://assets.section508.gov/files/508-standards-applicability-checklist.docx +[5]: https://www.federalregister.gov/documents/2000/12/21/00-32017/electronic-and-information-technology-accessibility-standards +[6]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#E101-general +[7]: {{site.baseurl}}/buy/determine-508-standards-exceptions +[8]: {{site.baseurl}}/buy/determine-ict-standards +[9]: {{site.baseurl}}/buy/accessibility-requirements-tool diff --git a/_pages/acquisition/2018-05-29-buy-request-accessibility-information.md b/_pages/acquisition/2018-05-29-buy-request-accessibility-information.md index a7cb9030c..096ec0a6a 100644 --- a/_pages/acquisition/2018-05-29-buy-request-accessibility-information.md +++ b/_pages/acquisition/2018-05-29-buy-request-accessibility-information.md @@ -3,7 +3,7 @@ layout: page sidenav: true permalink: buy/request-accessibility-information/ type: acquisition -title: 'Request Accessibility Information from Vendors & Contractors' +title: Request Accessibility Information from Vendors & Contractors created: 1527567946 --- @@ -11,8 +11,8 @@ When purchasing software, hardware, electronic content, or support documentation The information you should request from offerors will differ depending on whether the ICT item is _Standard_ or _Customized_. - * **Standard ICT** - Commercial or government off-the-shelf (COTS/GOTS) - * **Customized ICT** - Customized or developed based on agency requirements +- **Standard ICT** - Commercial or government off-the-shelf (COTS/GOTS) +- **Customized ICT** - Customized or developed based on agency requirements ## **Process Overview** @@ -22,94 +22,83 @@ Follow this process to determine and document requirements and exceptions to the **Step 2: Identify** requirements and exceptions - * Use the [Revised 508 Standards Applicability Checklist][2] (MS-Word, May 2018) to identify requirements and exceptions. - * Complete a checklist for **EACH ICT item**. - * [Determine 508 Standards and Exceptions][3] - Follow these step-by-step instructions guidance on how to complete the Checklist. +- Use the [Revised 508 Standards Applicability Checklist][2] (MS-Word, May 2018) to identify requirements and exceptions. + + - Complete a checklist for **EACH ICT item**. + - [Determine 508 Standards and Exceptions][3] - Follow these step-by-step instructions guidance on how to complete the Checklist. **Step 3: Document** requirements and exceptions - * Use the [Applicable 508 Standards and Exceptions Chart - Template][4] (MS-Word, September 2017) to document requirements and exceptions. - * You may want to complete a chart for each ICT item, and paste the chart(s) directly into your solicitation documentation. - * See these instructions and examples on how to complete the [508 Standards and Exceptions Chart & Examples][5] +- Use the [Applicable 508 Standards and Exceptions Chart - Template][4] (MS-Word, September 2017) to document requirements and exceptions. + + - You may want to complete a chart for each ICT item, and paste the chart(s) directly into your solicitation documentation. + - See these instructions and examples on how to complete the [508 Standards and Exceptions Chart & Examples][5] **Step 4: Explain** how offerors should respond - * Provide written instructions to offerors on how to respond to the requirements you’ve identified - * Describe any additional items they should include in their report. Consider the acquisition size, complexity, and impact on users with disabilities, when determining which items are needed. - * Clarify whether any, or all, requirements must be provided in order to be considered for award. +- Provide written instructions to offerors on how to respond to the requirements you've identified + + - Describe any additional items they should include in their report. Consider the acquisition size, complexity, and impact on users with disabilities, when determining which items are needed. + - Clarify whether any, or all, requirements must be provided in order to be considered for award. ## **Documentation** Find guidance on required and recommended documentation for both Standard and Customized ICT Items below. - - -

- Required for Standard ICT Items -

+- [Required for Standard ICT Items](#required-for-standard-ict-items) +- [Recommended for Standard ICT Items](#recommended-for-standard-ict-items) +- [Required for Customized ICT Items](#required-for-customized-ict-items) +- [Recommended for Customized ICT Items](#recommended-for-customized-ict-items) + +## **_Required_** **for Standard ICT Items** For **EACH Standard COTS/GOTS ICT item**, REQUIRE the offeror to provide: - * **Accessibility Conformance Report (ACR)** - A written ACR for each ICT item, based on the product’s [Voluntary Product Accessibility Template (VPAT)][6]. To be considered for award, the ACR must be complete, and submitted according to the instructions. - * **Supplemental Accessibility Report (SAR)** - A written SAR containing: - * Description of evaluation methods used to produce the ACR, to demonstrate due diligence in supporting conformance claims; - * Documentation of features that help achieve accessibility and usability for persons with disabilities; - * Information on core functions that can’t be used by persons with disabilities; - * Information on how to configure and install the ICT item to support accessibility; and - * Information on how the ICT item enables the creation of accessible electronic content that conforms to the Revised 508 Standards, including the range of accessible user interface elements the tool can create. (only required for authoring tools that generate content (documents, reports, videos, multimedia, web content, etc.) +- **Accessibility Conformance Report (ACR)** - A written ACR for each ICT item, based on the product's OpenACR (or legacy [Voluntary Product Accessibility Template (VPAT)][6]™. To be considered for award, the ACR must be complete, and submitted according to the instructions. +- **Supplemental Accessibility Report (SAR)** - A written SAR containing: + + - Description of evaluation methods used to produce the ACR, to demonstrate due diligence in supporting conformance claims; + - Documentation of features that help achieve accessibility and usability for persons with disabilities; + - Information on core functions that can't be used by persons with disabilities; + - Information on how to configure and install the ICT item to support accessibility; and + - Information on how the ICT item enables the creation of accessible electronic content that conforms to the Revised 508 Standards, including the range of accessible user interface elements the tool can create. (only required for authoring tools that generate content (documents, reports, videos, multimedia, web content, etc.) -

- Recommended for Standard ICT Items -

+## **_Recommended_** **for Standard ICT Items** For EACH Standard COTS/GOTS ICT item, _consider_ requiring the offeror to provide the following info. Note, the information in this section is RECOMMENDED, not required. - * A demonstration of some or all items in the solicitation that conform to the agency’s accessibility requirements; - * Remediation plans for features that don’t fully conform to the Revised 508 Standards; - * Accessibility improvement plans related to the ICT products or services they’re offering; - * A description of training they can provide to users on the accessibility features of the ICT products and services, as well as any associated training costs not included in the baseline proposal; - * When an ICT item is an authoring tool(s) that generates content (documents, reports, videos, multimedia, web content, etc.), provide the following: - * Samples of accessible electronic content produced by the tool(s). Consider requesting samples that include a full range of user interface elements generated by the tool. - * A demonstration of how the commercially available tool(s) support creating accessible content. - * Information on the documentation available for authors on how the tool(s) can produce and validate accessible electronic content; +- A demonstration of some or all items in the solicitation that conform to the agency's accessibility requirements; +- Remediation plans for features that don't fully conform to the Revised 508 Standards; +- Accessibility improvement plans related to the ICT products or services they're offering; +- A description of training they can provide to users on the accessibility features of the ICT products and services, as well as any associated training costs not included in the baseline proposal; +- When an ICT item is an authoring tool(s) that generates content (documents, reports, videos, multimedia, web content, etc.), provide the following: - * State that the agency reserves the right, prior to making an award decision, to perform testing on some or all of the offeror’s proposed ICT items to ensure the accuracy of their response. State that if the agency requests the opportunity to perform hands-on testing, the offeror shall provide the following: - * Final commercially available release versions in terms of functionality and features. - * Accessibility Test Plan illustrating ”typical” user scenarios and tasks to ensure fair and accurate testing of offered solutions. This test plan can be used to help the agency perform its testing of the ICT product or service being offered. + - Samples of accessible electronic content produced by the tool(s). Consider requesting samples that include a full range of user interface elements generated by the tool. + - A demonstration of how the commercially available tool(s) support creating accessible content. + - Information on the documentation available for authors on how the tool(s) can produce and validate accessible electronic content; - * Consider also stating: - * Trial versions of ICT products or services won’t be considered for testing purposes, since some features or functionality may not yet be available, and would likely not deliver accurate testing results. - * Upon award, any ICT product provided for testing by all unsuccessful offerors will be returned at the offeror’s expense. The successful offeror’s ICT product(s) will be kept and accounted for in any resultant order, if applicable. If an order isn’t imminent, the successful offeror’s ICT product shall also be returned, at the offeror’s expense. +- State that the agency reserves the right, prior to making an award decision, to perform testing on some or all of the offeror's proposed ICT items to ensure the accuracy of their response. State that if the agency requests the opportunity to perform hands-on testing, the offeror shall provide the following: + + - Final commercially available release versions in terms of functionality and features. + - Accessibility Test Plan illustrating "typical" user scenarios and tasks to ensure fair and accurate testing of offered solutions. This test plan can be used to help the agency perform its testing of the ICT product or service being offered. + +- Consider also stating: + + - Trial versions of ICT products or services won't be considered for testing purposes, since some features or functionality may not yet be available, and would likely not deliver accurate testing results. + - Upon award, any ICT product provided for testing by all unsuccessful offerors will be returned at the offeror's expense. The successful offeror's ICT product(s) will be kept and accounted for in any resultant order, if applicable. If an order isn't imminent, the successful offeror's ICT product shall also be returned, at the offeror's expense. If a maximum page count is required for submissions, exclude the accessibility information from the page count limitation, to allow offerors to report complete supporting data. -

- Required for Customized ICT Items -

+## **_Required_** **for Customized ICT Items** For **EACH Customized ICT item**, REQUIRE the offeror to provide: - * **Accessibility Conformance Report (ACR)** - A written ACR for each ICT item, describing how the item(s) will fully address the accessibility requirements outlined in the solicitation; and - * A description of the evaluation methods the offeror will use to validate for conformance to the Revised 508 Standards. +- **Accessibility Conformance Report (ACR)** - A written ACR for each ICT item, describing how the item(s) will fully address the accessibility requirements outlined in the solicitation; and +- A description of the evaluation methods the offeror will use to validate for conformance to the Revised 508 Standards. Advise offerors that each requirement must be fully addressed in order to be considered for award. -

- Recommended for Customized ICT Items -

+## **_Recommended_** **for Customized ICT Items** For EACH Customized ICT item, _consider_ requiring the offeror to provide the following info. Note, the information in this section is RECOMMENDED, not required. @@ -117,42 +106,41 @@ For EACH Customized ICT item, _consider_ requiring the offeror to provide the fo Consider requiring the offeror to provide additional information for each ICT item customized or developed in-house: - * A description of training they can provide on how to use the accessibility features of the ICT product and services, as well as any associated training costs not included in the baseline proposal; and - * Their approaches to incorporating universal design principles to ensure their ICT products or services are designed to support all users. +- A description of training they can provide on how to use the accessibility features of the ICT product and services, as well as any associated training costs not included in the baseline proposal; and +- Their approaches to incorporating universal design principles to ensure their ICT products or services are designed to support all users. ### **Customized COTS/GOTS** -If the offeror’s proposed items are substantially comprised of COTS/GOTS ICT products or services that will be configured or modified to meet contract requirements, consider requiring the offeror to provide: +If the offeror's proposed items are substantially comprised of COTS/GOTS ICT products or services that will be configured or modified to meet contract requirements, consider requiring the offeror to provide: - * **Accessibility Conformance Report (ACR)** - A written ACR for each ICT item, based on the product’s [Voluntary Product Accessibility Template (VPAT)][6] for COTS items that will be configured or modified to meet contract requirements. To be considered for award, the ACR must be complete, and submitted according to the instructions. - * A demonstration of the COTS items that will be configured or modified to meet contract requirements. Request the offeror to demonstrate how they will configure or maintain the solution to ensure support for the agency’s accessibility requirements. - * When the solicitation requires ICT items that will be used to generate electronic content (documents, reports, videos, multimedia, web content, etc.), and the offeror may use COTS authoring tools as a substantial component in their solution, consider requiring the offeror to provide: +- **Accessibility Conformance Report (ACR)** - A written ACR for each ICT item, based on the product's OpenACR (or legacy [Voluntary Product Accessibility Template (VPAT)][6]™ for COTS items that will be configured or modified to meet contract requirements. To be considered for award, the ACR must be complete, and submitted according to the instructions. +- A demonstration of the COTS items that will be configured or modified to meet contract requirements. Request the offeror to demonstrate how they will configure or maintain the solution to ensure support for the agency's accessibility requirements. +- When the solicitation requires ICT items that will be used to generate electronic content (documents, reports, videos, multimedia, web content, etc.), and the offeror may use COTS authoring tools as a substantial component in their solution, consider requiring the offeror to provide: - * * Samples of accessible electronic content produced by the authoring tools. - * A demonstration of how the commercially available authoring tools will enable the creation of accessible content ”out of the box”, including a full range of user interface elements that can be generated by the tool. + - Samples of accessible electronic content produced by the authoring tools. + - A demonstration of how the commercially available authoring tools will enable the creation of accessible content "out of the box", including a full range of user interface elements that can be generated by the tool. - * State that the agency reserves the right to perform testing on COTS items that will be configured or modified to meet contract requirements. - * Consider requiring the offeror to provide commercially available release versions (full functionality and features). - * Consider also stating that upon award, any ICT product provided for testing by all will be returned at the offeror’s expense. +- State that the agency reserves the right to perform testing on COTS items that will be configured or modified to meet contract requirements. + + - Consider requiring the offeror to provide commercially available release versions (full functionality and features). + - Consider also stating that upon award, any ICT product provided for testing by all will be returned at the offeror's expense. If a maximum page count is required for submissions, exclude the accessibility information from the page count limitation to allow offerors to provide complete supporting data. ## **Related Resources** - * [Buy Accessible Products and Services][7] - * [Accessibility Requirements Tool (ART)][8] - ART can help you determine which accessibility requirements and exceptions apply when purchasing ICT products and services +- [Buy Accessible Products and Services][7] +- [Accessibility Requirements Tool (ART)][8] - ART can help you determine which accessibility requirements and exceptions apply when purchasing ICT products and services _These best practices were developed by the U.S. Federal Government Revised 508 Standards Transition Workgroup. Members include the U.S. Federal CIO Council Accessibility Community of Practice, the U.S. Access Board, and the General Services Administration._ - -**Reviewed/Updated**: May 2018 - +**Reviewed/Updated:** March 2022 - [1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines - [2]: https://assets.section508.gov/files/508-standards-applicability-checklist.docx - [3]: {{site.baseurl}}/buy/determine-508-standards-exceptions - [4]: https://assets.section508.gov/files/standards-exceptions-chart.docx - [5]: {{site.baseurl}}/buy/standards-exceptions - [6]: {{site.baseurl}}/sell/vpat - [7]: {{site.baseurl}}/buy - [8]: {{site.baseurl}}/buy/accessibility-requirements-tool \ No newline at end of file +[1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines +[2]: https://assets.section508.gov/files/508-standards-applicability-checklist.docx +[3]: {{site.baseurl}}/buy/determine-508-standards-exceptions +[4]: https://assets.section508.gov/files/standards-exceptions-chart.docx +[5]: {{site.baseurl}}/buy/standards-exceptions +[6]: {{site.baseurl}}/sell/vpat +[7]: {{site.baseurl}}/buy +[8]: {{site.baseurl}}/buy/accessibility-requirements-tool diff --git a/_pages/acquisition/2018-05-29-buy.md b/_pages/acquisition/2018-05-29-buy.md index f29d2cb04..40ba723c6 100644 --- a/_pages/acquisition/2018-05-29-buy.md +++ b/_pages/acquisition/2018-05-29-buy.md @@ -3,7 +3,7 @@ layout: page sidenav: true permalink: buy/ type: acquisition -title: 'Buy Accessible Products and Services' +title: Buy Accessible Products and Services created: 1527567726 --- @@ -11,107 +11,89 @@ Section 508 requirements should be included from the beginning of the ICT procur **Table of Contents** - * [Legal Requirements][1] - * [Business Needs][2] - * [Six Steps for Managing ICT Accessibility in Acquisition][3] - * [Pre-Award Phase][4] - * [Procuring ICT Development Services][5] - * [Award Phase][6] - * [Post-Award Phase][7] - * [Learn More][8] +- [Legal Requirements][1] +- [Business Needs][2] +- [Six Steps for Managing ICT Accessibility in Acquisition][3] - + - [Pre-Award Phase][4] + - [Procuring ICT Development Services][5] + - [Award Phase][6] + - [Post-Award Phase][7] + +- [Learn More][8] + +## **Legal Requirements** {#legal} Before getting started it is important to understand the legal requirements for accessibility in context of your business requirement, and the consequences for non-conformance. Conformance to the [Revised 508 Standards][9] for information and communications technology (ICT) products and services is mandatory for Executive Branch Federal agencies, including the US Postal Service, subject to Section 508 of the Rehabilitation Act of 1973, as amended ([29 U.S.C. 794d][10]). Refer to the information below for buying accessible products and services, including developing requirements. Reach out to your agency [Section 508 Program Manager][11] or to the [government-wide IT Accessibility Program][12] if you still have questions. -

- Business Needs -

+## **Business Needs** {#business} The ICT solution selected (or developed under contract for the government) must meet the requirements of a well-defined business need which includes being accessible to Federal employees and members of the public who need access to information and services. Section 508 requirements should be included from the beginning of the procurement lifecycle and continue through development and testing. FAR 7.103 (q) identifies specific agency-head responsibilities to consider Section 508 requirements as part of the requirements planning phase for proposed procurements. -[Section E202.7 Best Meets][13] of the Revised 508 Standards states that if one cannot find an accessible commercial solution, an agency should procure the ICT solution that _best meets_ the standards consistent with business needs. If no technically acceptable alternative fully conforms to the Revised 508 Standards, select the alternative that best meets the standards when making an award, and request a “best meets” exception. Where product features or components are not fully accessible, the agency is required to make available, upon request, an alternative means of accessing the information or functions supported by the ICT. +[Section E202.7 Best Meets][13] of the Revised 508 Standards states that if one cannot find an accessible commercial solution, an agency should procure the ICT solution that _best meets_ the standards consistent with business needs. If no technically acceptable alternative fully conforms to the Revised 508 Standards, select the alternative that best meets the standards when making an award, and request a "best meets" exception. Where product features or components are not fully accessible, the agency is required to make available, upon request, an alternative means of accessing the information or functions supported by the ICT. Once the business needs have been established and indicate that ICT is needed to fulfil the business needs, follow the below 6 Step Process when planning an acquisition involving ICT. Section 508 is enforced through the FAR requirements that govern each of the basic procurement phases: Pre-Award, Award, and Post-Award. Six steps are recommended for managing ICT Accessibility throughout these three procurement phases. (Note: for micropurchases these steps are further simplified.) -

- Six Steps for Managing ICT Accessibility in Acquisition -

+## **Six Steps for Managing ICT Accessibility in Acquisition** {#six-steps} -

- Pre-Award Phase -

+**Pre-Award Phase** - * Step 1 - [Determine Accessibility Requirements][14] - * Step 2 - [Conduct Market Research][15] - * Step 3 - [Develop Solicitation Language][16] - * Step 4 - [Request Accessibility Information From Vendors][17] +- Step 1 - [Determine Accessibility Requirements][14] +- Step 2 - [Conduct Market Research][15] +- Step 3 - [Develop Solicitation Language][16] +- Step 4 - [Request Accessibility Information From Vendors][17] **Award Phase** - * Step 5 - [Evaluate Proposals][18] +- Step 5 - [Evaluate Proposals][18] **Post-Award Phase** - * Step 6 - [Validate Contractor Compliance][19] +- Step 6 - [Validate Contractor Compliance][19] -* * * +-------------------------------------------------------------------------------- -

- Pre-Award Phase -

+### **Pre-Award Phase** {#pre-award} -

- Step 1 - Determine Accessibility Requirements -

+#### **Step 1 - Determine Accessibility Requirements** {#requirements} All technology your agency buys, builds, maintains or uses, including software, hardware, electronic content, and support documentation and services, must conform to the [Revised 508 Standards][9]. These standards contain scoping and technical requirements to help your agency ensure ICT is accessible and usable by individuals with disabilities. To begin, you must determine if accessibility requirements apply to your procurement using the following steps: - 1. Determine if the ICT needed for the business is subject to Section 508. If the answer is yes, continue to the next step. - 2. Determine and document if [General Exceptions][13] apply. It is important that any Section 508 exceptions be documented and justified during requirements development. Reference [Section E202][13], General Exceptions for any needed clarification. Exceptions include: - * Legacy ICT - * National security systems - * ICT incidental to a contract - * Functions located in maintenance or monitoring spaces - * Undue burden or fundamental alteration - * Best meets - 3. If no exceptions apply, the next step is to define the accessibility requirements. - - - - - - - -
-

- Tip: Your Agency should define who is authorized to grant an exception on the behalf of the organization. -

-
- -##### **_Define the Accessibility Requirements_** +1. Determine if the ICT needed for the business is subject to Section 508\. If the answer is yes, continue to the next step. +2. Determine and document if [General Exceptions][13] apply. It is important that any Section 508 exceptions be documented and justified during requirements development. Reference [Section E202][13], General Exceptions for any needed clarification. Exceptions include: + - Legacy ICT + - National security systems + - ICT incidental to a contract + - Functions located in maintenance or monitoring spaces + - Undue burden or fundamental alteration + - Best meets +3. If no exceptions apply, the next step is to define the accessibility requirements. + +
+
+

TIP: Your Agency should define who is authorized to grant an exception on the behalf of the organization.

+
+
+ +##### **_Define the Accessibility Requirements_** You have three options to conduct either a manual or automated review to define accessibility requirements for your solicitation. - * **Option 1 - Use predefined solicitation language from Section 508.gov for your accessibility requirements, if appropriate.** The [Accessibility Requirements Tool (ART) Resources][20] page contains downloadable pre-determined accessibility requirements and solicitation language for over 40 standard ICT procurement categories. - * **Option 2 - Build custom accessibility requirements using Accessibility Requirements Tool (ART).** Use [ART][21], which automates the Standards Applicability Checklist and generates customized solicitation language to build your accessibility requirements. - * **Option 3 - Manually determine accessibility requirements.** Follow this step-by-step guidance on how to Determine 508 Standards and Exceptions and complete the [Standards Applicability Checklist][22]. Use the [508 Standards and Exceptions Chart & Examples][23] template to clearly communicate which standards and exceptions apply to each item in a solicitation that contains ICT. +- **Option 1 - Use predefined solicitation language from Section 508.gov for your accessibility requirements, if appropriate.** The [Accessibility Requirements Tool (ART) Resources][20] page contains downloadable pre-determined accessibility requirements and solicitation language for over 40 standard ICT procurement categories. +- **Option 2 - Build custom accessibility requirements using Accessibility Requirements Tool (ART).** Use [ART][21], which automates the Standards Applicability Checklist and generates customized solicitation language to build your accessibility requirements. +- **Option 3 - Manually determine accessibility requirements.** Follow this step-by-step guidance on how to Determine 508 Standards and Exceptions and complete the [Standards Applicability Checklist][22]. Use the [508 Standards and Exceptions Chart & Examples][23] template to clearly communicate which standards and exceptions apply to each item in a solicitation that contains ICT. Failing to include the applicable Section 508 technical requirements increases the risk of your project having schedule/cost overruns or possible remediation after the product has been delivered and accepted. Not developing Section 508 conformant deliverables also puts your agency at a higher risk of being sued. -

+

Return to List of Six Steps -

- -

- Step 2 - Conduct Market Research -

+
+ +#### **Step 2 - Conduct Market Research** {#market} Market research is tracked throughout the procurement process, beginning with the mission needs statement. The level of specificity and scope varies at different points, but market research is a continuous process throughout the procurement lifecycle. @@ -119,165 +101,138 @@ Market research, done early in the procurement process, provides information abo Early in the procurement process, it is possible to compare the user's need to the capabilities of the commercial market to determine the: - * Availability of products to meet the requirement - * Ability of suppliers to modify their products to meet the user's requirement - * Flexibility of users to modify their requirements to allow the purchase of commercial items, commercial services, or non-developmental items +- Availability of products to meet the requirement +- Ability of suppliers to modify their products to meet the user's requirement +- Flexibility of users to modify their requirements to allow the purchase of commercial items, commercial services, or non-developmental items -##### **_Market Research Process_** +##### **_Market Research Process_** As you develop your accessibility requirements, conduct market research to determine if solutions exist that include the accessibility features and functionality you need, as defined in your accessibility requirements. - 1. Determine your business need; what functionality do you require? - 2. Conduct market research to find possible solutions that could meet your business needs. Sources to consider: - * Search the internet for existing Accessibility Conformance Reports (ACR) for the ICT being sought. These are often referred to as [Voluntary Product Accessibility Template][24] (VPAT). A VPATTM is the industry standard template to be used for making product accessibility claims. You will then evaluate these ACRs or VPATsTM against the 508 standards for your ICT. - * Ask colleagues at your agency, or within the CIO Council Accessibility Community of Practice (ACOP) or other relevant community - * Visit the [Acquisition Gateway][25] (requires OMB MAX ID) and use the [Solutions Finder][26] - * Visit GSA's [e-Tools for Purchasing Officers][27] - * Review any existing ACRs or product [VPAT TM][28] - * Ask your agency contracting office for help. - 3. Try to find at least two possible solutions. - 4. Document your research to compare solutions and find one that is the best fit. Include (at a minimum) vendor name, version, and model number, and describe how the solution will meet (or not) your business need. - 5. Document your justification for the solution you select and explain why other possible solutions were not chosen. +1. Determine your business need; what functionality do you require? +2. Conduct market research to find possible solutions that could meet your business needs. Sources to consider: + + - Search the internet for existing Accessibility Conformance Reports (ACR) for the ICT being sought. These are often referred to as [Voluntary Product Accessibility Template][24] (VPAT™). Look for new ACRs produced with the new industry standard OpenACR format. You will then evaluate these ACRs against the 508 standards for your ICT. + + - Ask colleagues at your agency, or within the CIO Council Accessibility Community of Practice (ACOP) or other relevant community + + - Visit the [Acquisition Gateway][25] (requires OMB MAX ID) and use the [Solutions Finder][26] + - Visit GSA's [e-Tools for Purchasing Officers][27] + - Review any existing ACRs or product [VPAT™][28] + + - Ask your agency contracting office for help. + +3. Try to find at least two possible solutions. + +4. Document your research to compare solutions and find one that is the best fit. Include (at a minimum) vendor name, version, and model number, and describe how the solution will meet (or not) your business need. + +5. Document your justification for the solution you select and explain why other possible solutions were not chosen. A note about exceptions: - * If there are technically acceptable solutions available in the marketplace, you must select one of those solutions ([FAR 39.203(c)(1)][29]). You cannot choose a different solution and claim an exception (e.g., "best meets" or "undue burden"). - - - - - - - -
-

- NOTE: If in the process of determining business needs, it is determined that no commercial or government of-the-shelf products will meet the need, then the task may be to procure development services. -

-

- When procuring ICT development services, there will be no upfront ICT products to assess for accessibility. In these cases, the market research should focus on identifying potential vendors with experience and maturity in developing accessible solutions. -

-
- -

- Return to List of Six Steps -

+- If there are technically acceptable solutions available in the marketplace, you must select one of those solutions ([FAR 39.203(c)(1)][29]). You cannot choose a different solution and claim an exception (e.g., "best meets" or "undue burden"). -

- Step 3 - Develop Solicitation Language -

+
+
+

NOTE: If in the process of determining business needs, it is determined that no commercial or government of-the-shelf products will meet the need, then the task may be to procure development services.

+

When procuring ICT development services, there will be no upfront ICT products to assess for accessibility. In these cases, the market research should focus on identifying potential vendors with experience and maturity in developing accessible solutions.

+
+
+ +
+ Return to List of Six Steps +
+ +#### **Step 3 - Develop Solicitation Language** {#solicitation} The next step is to develop the solicitation language to accompany the Section 508 requirements you established in Step 2 to set the stage for how accessibility is managed throughout the life of the contract. This will include contract/solicitation language to define all accessibility provisions, clauses, and acceptance criteria. Section508.gov has resources to help you [define accessibility criteria in contracts][30]. Review the sample language that you can use to properly document provisions, clauses, and acceptance criteria when preparing solicitations, statements of work, or other procurement documents. Include these accessibility requirements in your solicitation. - - - - - - -
-

- TIP: If purchased through an existing government-wide contract vehicle, adapt these requirements for a Task Order level purchase request. -

-
- -

- Procuring ICT Development Services -

+
+
+

TIP: If purchased through an existing government-wide contract vehicle, adapt these requirements for a Task Order level purchase request.

+
+
+ +### **Procuring ICT Development Services** {#services} When procuring ICT development services (vs Commercial off-the-shelf or COTS/Government off- the-shelf or GOTS), the contract terms and conditions will differ and should specify: - * Accessibility requirements of the future delivered ICT products, - * Expectations for how, by whom, and when accessibility testing should be conducted during the contracting development process, and before receipt by the government of the final deliverable. - * A demonstration of the vendor’s capability to develop accessible solutions +- Accessibility requirements of the future delivered ICT products, +- Expectations for how, by whom, and when accessibility testing should be conducted during the contracting development process, and before receipt by the government of the final deliverable. +- A demonstration of the vendor's capability to develop accessible solutions -

+

Return to List of Six Steps -

- -

- Step 4 - Request Accessibility Information From Vendors -

+
+ +#### **Step 4 - Request Accessibility Information From Vendors** {#vendor-info} The final pre-award step is to request accessibility information from vendors and contractors. Clearly communicate accessibility requirements and contract terms and conditions to vendors, so they can provide the information you need to perform a 508 technical evaluation. - * For COTS/GOTS, Request an ACR/VPATTM) or other evidence of accessibility testing, for each ICT item that is to be developed, updated, configured for the agency, and when product substitutions are offered. The ACR should be based on the latest version of the VPATTM provided by the [Information Technology Industry Council (ITIC)][31]. - * For ICT development service contracts, request potential vendors to provide: - * A plan for accessibility testing and evaluation during the development life cycle of the future delivered ICT products, as defined in Step 3 above. - * Define how, by whom, and when accessibility testing should be conducted during the contracting development process, and before receipt by the government of the final deliverable. - * Evidence of the vendor’s capability to develop accessible solutions. +- For COTS/GOTS, Request an ACR) or other evidence of accessibility testing, for each ICT item that is to be developed, updated, configured for the agency, and when product substitutions are offered. The ACR should be based on OpenACR, although for some projects legacy VPAT™ may be acceptable. +- For ICT development service contracts, request potential vendors to provide: -##### **Refer vendors to** [**https://section508.gov/sell**][32] **for guidance on using ACRs and VPATsTM** + - A plan for accessibility testing and evaluation during the development life cycle of the future delivered ICT products, as defined in Step 3 above. + - Define how, by whom, and when accessibility testing should be conducted during the contracting development process, and before receipt by the government of the final deliverable. + - Evidence of the vendor's capability to develop accessible solutions. -

- Return to List of Six Steps -

+##### **Refer vendors to** [**https://section508.gov/sell**][32] **for guidance on using ACRs. -

- Award Phase -

+
+ Return to List of Six Steps +
+ +### **Award Phase** {#award} -

- Step 5 - Evaluate Proposals -

+#### **Step 5 - Evaluate Proposals** {#proposal} -After you issue the solicitation, you’ll receive proposals from vendors. Evaluate each proposal to validate vendor claims against your stated accessibility requirements. +After you issue the solicitation, you'll receive proposals from vendors. Evaluate each proposal to validate vendor claims against your stated accessibility requirements. Trust but verify: before awarding a contract or deploying custom-developed deliverables, conduct accessibility testing to validate that the technology products and services in question are fully accessible. -
+
- Accessibility Conformance Report Review -
- + Accessibility Conformance Report Review +

- +
- Section 508 Testing Requirements -
- + Section 508 Testing Requirements + - +
- Section 508 Testing Approaches -
- + Section 508 Testing Approaches +

In order to validate full conformance, hands-on testing using a repeatable, systematic testing methodology is needed. Section 508 testing should be a continuous process during development. Technical conformance testing is broken down into two areas:

- - +

For organizations that test for Section 508 conformance following practices other than the Trusted Tester protocol, the toolset and approaches utilized must be aligned with the ICT Testing Baseline to ensure consistency in testing practices across agencies.

@@ -285,83 +240,73 @@ Trust but verify: before awarding a contract or deploying custom-developed deliv -

+

Return to List of Six Steps -

- -

- Post-Award Phase -

+
+ +### **Post-Award Phase** {#post-award} -

- Step 6 - Validate Contractor Compliance -

+#### **Step 6 - Validate Contractor Compliance** ICT must remain accessible throughout the contract period of performance, so as products and software are updated or modified, you should re-test conformance of each new version and/or product against the terms and conditions originally established in the contract. -* * * +-------------------------------------------------------------------------------- -

- Learn More -

+## **Learn More** {#learn} - * [Micro-Purchases and Section 508 Requirements][33] - How to make accessible micro-purchases; covers how accessibility requirements apply to micro-purchases of hardware, software, and other ICT. - * [Procuring Section 508 Conformant ICT Products and Services][34] - Basic overview of the Federal acquisition process as it relates to procuring accessible ICT. - * [Requiring Business Partners to Provide Accessible Documents][35] - Guidance to ensure business partners produce accessible content. - * [Accessibility for Teams][36] - Embed accessibility and inclusive design practices in your team's workflow. - * [U.S. Web Design System][37] - A design system to quickly prototype and deploy accessible digital products. - * [Market Research][38] - Definition of market research, with an explanation of how to conduct generic market research. - -  +- [Micro-Purchases and Section 508 Requirements][33] - How to make accessible micro-purchases; covers how accessibility requirements apply to micro-purchases of hardware, software, and other ICT. +- [Procuring Section 508 Conformant ICT Products and Services][34] - Basic overview of the Federal acquisition process as it relates to procuring accessible ICT. +- [Requiring Business Partners to Provide Accessible Documents][35] - Guidance to ensure business partners produce accessible content. +- [Accessibility for Teams][36] - Embed accessibility and inclusive design practices in your team's workflow. +- [U.S. Web Design System][37] - A design system to quickly prototype and deploy accessible digital products. +- [Market Research][38] - Definition of market research, with an explanation of how to conduct generic market research.
- Before You Go -

+ Before You Go +

We're always working to improve the information and resources on this website. To suggest a new resource for this or another page, please contact us.

-
+
-**Reviewed/Updated:** October 2020 - -  - - [1]: #legal - [2]: #business - [3]: #six-steps - [4]: #pre-award - [5]: #services - [6]: #award - [7]: #post-award - [8]: #learn - [9]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines - [10]: http://www.gpo.gov/fdsys/pkg/USCODE-2011-title29/html/USCODE-2011-title29-chap16-subchapV-sec794d.htm - [11]: {{site.baseurl}}/tools/coordinator-listing - [12]: mailto:section.508@gsa.gov - [13]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#E202-general-exceptions - [14]: #requirements - [15]: #market - [16]: #solicitation - [17]: #vendor-info - [18]: #proposal - [19]: #contractor - [20]: {{site.baseurl}}/buy/accessibility-requirements-tool - [21]: {{site.baseurl}}/art/ - [22]: https://assets.section508.gov/files/508-standards-applicability-checklist.docx - [23]: {{site.baseurl}}/buy/standards-exceptions - [24]: https://www.itic.org/policy/accessibility/vpat - [25]: https://www.gsa.gov/tools/supply-procurement-etools/acquisition-gateway - [26]: https://hallways.cap.gsa.gov/app/#/solutionsfinder - [27]: https://www.gsa.gov/tools/technology-etools - [28]: {{site.baseurl}}/sell/vpat - [29]: https://www.acquisition.gov/content/39203-applicability - [30]: {{site.baseurl}}/buy/define-accessibility-criteria - [31]: http://www.itic.org/policy/accessibility - [32]: {{site.baseurl}}/sell - [33]: https://s3.amazonaws.com/training.section508.gov/508-training/courses/micro-purchase-new/lesson1/index.html - [34]: https://s3.amazonaws.com/training.section508.gov/508-training/courses/procurement-new/index.html - [35]: {{site.baseurl}}/content/requiring-business-partners-provide-accessible-documents - [36]: https://accessibility.digital.gov/ - [37]: https://standards.usa.gov/ - [38]: https://www.entrepreneur.com/encyclopedia/market-research \ No newline at end of file +**Reviewed/Updated:** March 2022 + +[1]: #legal +[10]: http://www.gpo.gov/fdsys/pkg/USCODE-2011-title29/html/USCODE-2011-title29-chap16-subchapV-sec794d.htm +[11]: {{site.baseurl}}/tools/coordinator-listing +[12]: mailto:section.508@gsa.gov +[13]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#E202-general-exceptions +[14]: #requirements +[15]: #market +[16]: #solicitation +[17]: #vendor-info +[18]: #proposal +[19]: #contractor +[2]: #business +[20]: {{site.baseurl}}/buy/accessibility-requirements-tool +[21]: {{site.baseurl}}/art/ +[22]: https://assets.section508.gov/files/508-standards-applicability-checklist.docx +[23]: {{site.baseurl}}/buy/standards-exceptions +[24]: https://www.itic.org/policy/accessibility/vpat +[25]: https://www.gsa.gov/tools/supply-procurement-etools/acquisition-gateway +[26]: https://hallways.cap.gsa.gov/app/#/solutionsfinder +[27]: https://www.gsa.gov/tools/technology-etools +[28]: {{site.baseurl}}/sell/vpat +[29]: https://www.acquisition.gov/content/39203-applicability +[3]: #six-steps +[30]: {{site.baseurl}}/buy/define-accessibility-criteria +[31]: http://www.itic.org/policy/accessibility +[32]: {{site.baseurl}}/sell +[33]: https://s3.amazonaws.com/training.section508.gov/508-training/courses/micro-purchase-new/lesson1/index.html +[34]: https://s3.amazonaws.com/training.section508.gov/508-training/courses/procurement-new/index.html +[35]: {{site.baseurl}}/content/requiring-business-partners-provide-accessible-documents +[36]: https://accessibility.digital.gov/ +[37]: https://standards.usa.gov/ +[38]: https://www.entrepreneur.com/encyclopedia/market-research +[4]: #pre-award +[5]: #services +[6]: #award +[7]: #post-award +[8]: #learn +[9]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines diff --git a/_pages/acquisition/2018-05-29-sell-vpat.md b/_pages/acquisition/2018-05-29-sell-vpat.md index 32eb5e2fc..23f659313 100644 --- a/_pages/acquisition/2018-05-29-sell-vpat.md +++ b/_pages/acquisition/2018-05-29-sell-vpat.md @@ -3,31 +3,33 @@ layout: page sidenav: true permalink: sell/vpat/ type: acquisition -title: 'Voluntary Product Accessibility Template (VPAT)' +title: Voluntary Product Accessibility Template (VPAT) — Legacy created: 1527569659 --- -A Voluntary Product Accessibility Template (VPAT) is a document that explains how information and communication technology (ICT) products such as software, hardware, electronic content, and support documentation meet (conform to) the [Revised 508 Standards][1] for IT accessibility. VPAT™ help Federal agency contracting officials and government buyers to assess ICT for accessibility when doing market research and evaluating proposals. +A Voluntary Product Accessibility Template (VPAT™) is the most commonly used Accessibility Conformance Report (ACR). The VPAT™ was designed to support a broad range of information and communication technology (ICT) products. The VPAT was developed by the [Information Technology Industry Council (ITI)](https://www.itic.org/policy/accessibility/) to provide a common format for vendors to make accessibility claims for software, hardware, electronic content, and support documentation. For the US Federal government, these align with [Revised 508 Standards][1] for IT accessibility. ACRs allow agency contracting officials and government buyers to assess ICT for accessibility when doing market research and evaluating proposals. -Government solicitations which include ICT will specify accessibility requirements, indicating which provisions are required to ensure the deliverable is accessible. A VPAT™ is a good way to address the accessibility requirements defined in the solicitation. +The GSA has developed a new ACR format which is based on the VPAT™ template. This is a machine-readable format called [OpenACR](/openacr/), which is designed to overcome some of the challenges that are caused by the older format. Watch for contracts from the GSA that ask for an OpenACR formatted report, rather than a VPAT™. RFP's that ask for a VPAT™, can submit an OpenACR HTML report instead. The the HTML report was modelled on the latest VPAT™. -We recommend that vendors generate a VPAT™ for any ICT that’s intended to be marketed to the Federal government. Use the VPAT™ to make specific statements in simple recommended language to demonstrate how the features and functional characteristics of your product meet the [Revised 508 Standards][1]. -  +Government solicitations which include ICT will specify accessibility requirements, indicating which provisions are required to ensure the deliverable is accessible. The new OpenACR format is now recognized as the best way to address the accessibility requirements defined in the solicitation. - * [Download the current VPAT™ template][2] from the Information Technology Industry Council (ITI) website.  - * Make it easy to find your product’s VPAT™ on your company’s website (e.g., link to it on the product description page). +We recommend that vendors generate an OpenACR for any ICT that's intended to be marketed to the Federal government. Legacy VPAT™ may not be valid in the future. Use OpenACR to make specific statements in simple recommended language to demonstrate how the features and functional characteristics of your product meet the [Revised 508 Standards][1].
+ +- Include a link to your OpenACR reports from your Accessibility Statement. For many products, this might simply be a link to a git repository where it can be kept under version control. +- Your product description page should also clearly link to the relevant OpenACR report. +- To see the [legacy VPAT™ template][2] from the Information Technology Industry Council (ITI) website. ## Related Resources - * [Sell Accessible Products and Services][3] - * [Request Accessibility Information from Vendors and Contractors][4] - Guidance for agencies on how to develop and document accessibility requirements - * Introducing VPAT® 2.0, the More Stringent Accessibility Reporting Tool Required for Government IT Procurement - * Navigating VPAT® 2.0: A Guide for Vendors - * Win More Business! Report Product & Service Accessibility using VPAT® 2.1 (MS PPT, March 2018) +- [Sell Accessible Products and Services][3] +- [Request Accessibility Information from Vendors and Contractors][4] - Guidance for agencies on how to develop and document accessibility requirements +- [Introducing VPAT® 2.0, the More Stringent Accessibility Reporting Tool Required for Government IT Procurement](https://www.microassist.com/digital-accessibility/introducing-vpat-2-0-accessible-gov-procurement/) +- [Navigating VPAT® 2.0: A Guide for Vendors](https://www.levelaccess.com/resources/navigating-vpat-2-0-guide-vendors/) +- [Win More Business! Report Product & Service Accessibility using VPAT® 2.1](https://s3.amazonaws.com/storage.pardot.com/487581/58790/Win_More_Business_VPAT_2.1_FINAL.pptx) (MS PPT, March 2018) -**Reviewed/Updated**: April 2018 +**Reviewed/Updated:** March 2022 - [1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule - [2]: https://www.itic.org/policy/accessibility/vpat - [3]: {{site.baseurl}}/sell - [4]: {{site.baseurl}}/buy/request-accessibility-information \ No newline at end of file +[1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule +[2]: https://www.itic.org/policy/accessibility/vpat +[3]: {{site.baseurl}}/sell +[4]: {{site.baseurl}}/buy/request-accessibility-information diff --git a/_pages/acquisition/2018-05-29-sell.md b/_pages/acquisition/2018-05-29-sell.md index b9a27b563..3877c45fe 100644 --- a/_pages/acquisition/2018-05-29-sell.md +++ b/_pages/acquisition/2018-05-29-sell.md @@ -3,7 +3,7 @@ layout: page sidenav: true permalink: sell/ type: acquisition -title: 'Sell Accessible Products and Services' +title: Sell Accessible Products and Services created: 1527569547 --- @@ -13,54 +13,53 @@ If you manufacture, build, design, create, teach, or resell ICT products or serv ## Products -The easiest way to showcase information about product accessibility to government buyers is to provide a Voluntary Product Accessibility Template (VPAT). +The easiest way to showcase information about product accessibility to government buyers is to provide an OpenACR. Many procurements will still accept legacy Voluntary Product Accessibility Template (VPAT™) files, but make sure to check if OpenACR is specifically requested. - * [Voluntary Product Accessibility Template (VPAT)][2] - Learn about VPAT and download the template. +- Learn about the [OpenACR format](openacr/) and check out the [OpenACR Editor](https://gsa.github.io/openacr-editor/) ## Services Here are some suggestions on how to showcase the accessibility of your services to government buyers. - * **Provide a concise accessibility statement** outlining your accessibility approach or capability. - * **Address functional performance criteria** either directly or through support for appropriate assistive technologies, including technologies or components where there is no specific requirement under the technical standards. - * **Identify accessibility for additional ICT features** beyond the identified program requirements. +- **Provide a concise accessibility statement** outlining your accessibility approach or capability. +- **Address functional performance criteria** either directly or through support for appropriate assistive technologies, including technologies or components where there is no specific requirement under the technical standards. +- **Identify accessibility for additional ICT features** beyond the identified program requirements. ## Responding to Solicitations In your solicitation response, provide language to demonstrate your understanding of the regulations and requirements, and how well your product or service complies with the [Revised 508 Standards][1]. -Government solicitations that involve ICT will include a list of requirements to ensure that the deliverable will be accessible. (Note, this list used to be called a GPAT.) When these requirements are included with a solicitation, your proposed solution must explain how you will address them. +Government solicitations that involve ICT will include a list of requirements to ensure that the deliverable will be accessible. (Legacy formats now include both GPAT and VPAT™) When these requirements are included with a solicitation, your proposed solution must explain how you will address them. - * Provide a written **Accessibility Conformance Report (ACR)** for each ICT item, based on product VPATs for commercial off-the-shelf (COTS) items that will be configured or modified to meet contract requirements. The ACR must be complete and submitted according to the instructions in the VPATto be considered for award. +- Provide a written **Accessibility Conformance Report (ACR)** for each ICT item, based on product OpenACR report for commercial off-the-shelf (COTS) items that will be configured or modified to meet contract requirements. The ACR must be a validated OpenACR format which follows the instructions in the OpenACR Editor considered for award. -### Additional Documentation +## Additional Documentation In your response, consider also providing the following: - * A written **Supplemental Accessibility Report (SAR)** which documents evaluation methods used to produce the ACR, highlights features in your solution that improve accessibility and usability, and explains how to configure and install the ICT item to support accessibility. - * A **demonstration** of the COTS items you’re proposing to use to meet contract requirements. During the demonstration, show how you will configure or maintain the solution to support the agency’s accessibility requirements. +- A written **Supplemental Accessibility Report (SAR)** which documents evaluation methods used to produce the ACR, highlights features in your solution that improve accessibility and usability, and explains how to configure and install the ICT item to support accessibility. +- A **demonstration** of the COTS items you're proposing to use to meet contract requirements. During the demonstration, show how you will configure or maintain the solution to support the agency's accessibility requirements. When the solicitation requires ICT items that will be used to generate electronic content (documents, reports, videos, multimedia, web content, etc.), and you plan to use COTS authoring tools as a substantial component in your solution, consider providing: - * **Samples** of accessible electronic content produced by the authoring tools. - * A **demonstration** of how the COTS authoring tools enable the creation of accessible content ”out of the box,” including a full range of user interface elements that can be generated by the tool. +- **Samples** of accessible electronic content produced by the authoring tools. +- A **demonstration** of how the COTS authoring tools enable the creation of accessible content "out of the box," including a full range of user interface elements that can be generated by the tool. -When bidding on contracts to develop IT, when there is no product yet to evaluate, consider providing a statement on your company’s approach to accessibility. +When bidding on contracts to develop IT, when there is no product yet to evaluate, consider providing a statement on your company's approach to accessibility. - * Learn about [Policy-Driven Adoption for Accessibility (PDAA)][3] from the National Association of State Chief Information Officers (NASCIO). - * [Procurement for accessible IT products and services][4] - PDAA tool and guidance developed by the NASCIO workgroup and hosted by the State of Minnesota to help vendors measure internal support for accessibility. +- Learn about [Policy-Driven Adoption for Accessibility (PDAA)][3] from the National Association of State Chief Information Officers (NASCIO). +- [Procurement for accessible IT products and services][4] - PDAA tool and guidance developed by the NASCIO workgroup and hosted by the State of Minnesota to help vendors measure internal support for accessibility. ## Related Resources - * [Voluntary Product Accessibility Template (VPAT)][2] - * [Request Accessibility Information from Vendors and Contractors][5] - Guidance for agencies on how to develop and document accessibility requirements - * [Acquisition Gateway][6] - A workspace for acquisition professionals and federal buyers to connect with resources, tools and each other to improve acquisition government-wide. -**Reviewed/Updated**: May 2018 +- [Request Accessibility Information from Vendors and Contractors][5] - Guidance for agencies on how to develop and document accessibility requirements +- [Acquisition Gateway][6] - A workspace for acquisition professionals and federal buyers to connect with resources, tools and each other to improve acquisition government-wide. +**Reviewed/Updated:** March 2022 - [1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule - [2]: {{site.baseurl}}/sell/vpat - [3]: https://www.nascio.org/resource-center/resources/accessibility-in-it-procurement-part-1/ - [4]: https://mn.gov/mnit/programs/accessibility/it-procurement.jsp - [5]: {{site.baseurl}}/buy/request-accessibility-information - [6]: https://www.gsa.gov/tools/supply-procurement-etools/acquisition-gateway \ No newline at end of file +[1]: https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule +[2]: {{site.baseurl}}/sell/vpat +[3]: https://www.nascio.org/resource-center/resources/accessibility-in-it-procurement-part-1/ +[4]: https://mn.gov/mnit/programs/accessibility/it-procurement.jsp +[5]: {{site.baseurl}}/buy/request-accessibility-information +[6]: https://www.gsa.gov/tools/supply-procurement-etools/acquisition-gateway diff --git a/_pages/acquisition/2022-03-9-openacr-about.md b/_pages/acquisition/2022-03-9-openacr-about.md new file mode 100644 index 000000000..9848dea5a --- /dev/null +++ b/_pages/acquisition/2022-03-9-openacr-about.md @@ -0,0 +1,64 @@ +--- +layout: page +sidenav: true +permalink: openacr/about/ +type: acquisition +title: Why OpenACR +created: 1527569659 +--- + +OpenACR is a modern and effective way for people to create, evaluate, and compare Accessibility Conformance Reports (ACRs). These reports are used to measure how well a digital product or service meets accessibility standards (such as those required by [Section 508](https://www.section508.gov/about-us/)). The goal is to make sure people with disabilities can access government websites and services. + +## The challenge + +But there are problems with the way ACRs are typically created. In the procurement process, vendors often use a Voluntary Product Accessibility Template (VPAT) to provide information to buyers about how well their offering meets accessibility requirements. It is usually in a Word document or PDF, and often is not an accurate representation of product accessibility. + +Traditional ACRs make it difficult to effectively evaluate accessibility because they are: + +- Inconsistently structured (each one can look different, with no common standard) +- Private documents (hard to track down a specific ACR or get in touch with the writers) +- Not searchable (difficult to quickly locate specific information or requirements) +- Static (showing only a snapshot of accessibility at the time of ACR writing) +- Paper-based (with no way to easily update as the product evolves) + +All of this makes it hard for evaluators to compare accessibility claims across multiple products, or even to be sure the ACR they are reading conforms to a validated standard. It's also tedious and difficult for the people tasked with writing the reports, which can result in poor quality information that is not useful to evaluators. + +The whole process is disempowering to organizations that truly care about providing accessible services. Finding, sharing, and maintaining accurate data about product accessibility should be simple for everyone. + +## The solution + +OpenACR helps to solve these problems by providing a machine-readable, highly structured format that people can use to create modern, digital ACRs. It starts with a [step-by-step editor](https://gsa.github.io/openacr-editor/) that walks people through each part of the accessibility reporting process, and ends with a validated Accessibility Conformance Report that can be viewed as a YAML file or simply as a web page (HTML). Both of these formats are useful to the people responsible for evaluating accessibility conformance. + +A conformance report generated through OpenACR is: + +- Standardized (each is consistently structured and held to a baseline format) +- Findable (a public repository makes it easy to locate a report for any product) +- Searchable (saving time and resources for evaluators) +- Comparable (making it easier to see which solution best meets organizational needs) +- Updatable (version control allows the report to be updated as the product evolves) + +OpenACR is built on existing standards for accessibility compliance. + +- Addresses all conformance requirements from Section 508 +- Reports are built using the VPAT® framework from the Information Technology Industry Council (ITI) because it is widely recognized +- Aligns with specifications of the Web Content Accessibility Guidelines (WCAG) 2.0 + +## Who benefits from OpenACR? + +Bringing Accessibility Conformance Reports into the digital age helps everyone involved in choosing, building, and using government products. + +Procurement officials can find, search, and compare accessibility reports (with greater confidence in their accuracy) Vendors can more easily create useful ACRs and keep them up to date Managers and team leaders can better understand which products may pose limitations to staff with disabilities Government organizations can reference and contribute to a growing library of ACRs that can serve as a reliable resource for everyone Agencies that test conformance claims can share their findings back to the vendors (improving the accuracy of that ACR) People with disabilities (and allies) will benefit from and can contribute to a process that actually works to enforce accessibility regulations and promote awareness + +## Where did OpenACR come from? + +OpenACR is an initiative by the General Services Administration (GSA) to modernize and standardize Accessibility Conformance Reports (ACRs). The vision is to improve the use and effectiveness of ACRs in evaluating accessibility of digital products, tools, and services. + +This is an open source project that aims to create an open standard that can be continuously improved. Anyone is welcome to: + +- Learn more about this initiative +- View the [OpenACR project in GitHub](https://github.com/GSA/openacr) +- Give feedback or [contribute](https://github.com/GSA/openacr/blob/main/CONTRIBUTING.md) +- Explore the [OpenACR editor tool](https://gsa.github.io/openacr-editor) +- View the [editor tool in GitHub](https://github.com/GSA/openacr-editor) + +**Reviewed/Updated:** March 2022 diff --git a/_pages/acquisition/2022-03-9-openacr-create-report.md b/_pages/acquisition/2022-03-9-openacr-create-report.md new file mode 100644 index 000000000..c4af0a24d --- /dev/null +++ b/_pages/acquisition/2022-03-9-openacr-create-report.md @@ -0,0 +1,141 @@ +--- +layout: page +sidenav: true +permalink: openacr/create-report +type: acquisition +title: Creating an OpenACR report +created: 1527569659 +--- + +An Accessibility Conformance Report (ACR) is a document that explains how well a digital product meets certain standards for accessibility. Agencies request ACRs from vendors during the procurement process because they want to ensure that government services and platforms are usable by everyone. + +Instead of a traditional PDF or document format, OpenACR allows you to generate a report in a machine-readable format which helps everyone - from procurement teams to accessibility experts and vendors - get a clearer understanding of the true accessibility conformance of a digital product. It's also easier to update as your product evolves. + +Here is the process for creating an OpenACR report. + +## Step 1: Product review with your team + +You will need to audit your product's accessibility in a number of areas before filling out the sections for the report. Many people can work together to evaluate accessibility: product owners, developers, designers, and accessibility subject matter experts (SMEs). Seeking input from an external organization that specializes in accessibility is often helpful. + +## Step 2: Go to the OpenACR editor tool + +The [OpenACR editor tool](https://gsa.github.io/openacr-editor/) is a free online platform that walks you step-by-step through the requirements for a validated ACR. The tool structure is based on the widely-known [VPAT template](https://en.wikipedia.org/wiki/Voluntary_Product_Accessibility_Template), so it should look familiar if you have completed an ACR before. + +When you have finished all the steps, you will be able to export your report in YAML (machine-readable data) or as a zip file with both YAML and a readable HTML (web page) format. You can also import your report to Microsoft Word or print as a PDF if needed. + +Read all the sections on the [Overview page](https://gsa.github.io/openacr-editor) to learn about the editor tool's structure, tips for using it, and how to choose your level of conformance for each criteria. + +## Step 3: Complete the About page + +On the [About page](https://gsa.github.io/openacr-editor/about), you will provide an overall summary of the product or tool you are submitting the report for. It includes information like: + +- Company name +- Name of your product (and version number, if applicable) +- Report date (month and year) +- Description of the product +- Contact information +- Additional notes (if any) +- Evaluation methods: + + - how your product was tested (manual, automated, both), + - testing tools used + - testing with people with disabilities, etc. + +### Hiding sections + +On the About page, or on any section of the report, you have the option to "hide" sections that are not relevant to your product. For example, if your product is not subject to the Web Content Accessibility Guidelines (WCAG), you won't need to fill out the sections labeled A, AA, and AAA. (Review the steps below to learn more about sections and their requirements.) + +Select the checkbox to "Hide section?" if the section is not relevant and you don't need it to appear in your report. You can also re-enable sections at any time. + +For any hidden section, it's important to add an explanation in the Notes box to show evaluators why the section is not relevant to your product. + +## Step 4: Choose levels of conformance + +When filling out all sections of the report that are relevant to your product or tool, you will select a level of conformance to show how well your product meets that particular criteria. The levels are: + +### Supports + +The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation. + +### Partially Supports + +Some functionality of the product does not meet the criterion. + +### Does Not Support + +The majority of product functionality does not meet the criterion. + +### Not Applicable + +The criterion is not relevant to the product. + +### Not Evaluated + +The product has not been evaluated against the criterion. (This option may ONLY be used for section AAA, because this is the only criteria section that is not required to be evaluated.) + +**Note** boxes are available for you to type remarks and explanations, which are required if the product either "partially supports" or "does not support" the guideline. Use that space to give evaluators more information about how and why the product does not fully meet the standards. + +For areas where your product "fully supports" the standards, no remarks are required – but they are encouraged! The more information you provide, the easier it is for your product to be accurately evaluated. + +As you go through the sections evaluating your product's conformance, you will find links in each criteria that point to the official guidelines and standards for that criteria. This makes it easier for you to assess how well your product meets the standards. + +## Step 5: Complete sections (A) and (AA) if applicable + +The sections labeled A, AA, and AAA measure how well your product meets the Web Content Accessibility Guidelines (WCAG) 2.x guidelines. If your product has one or more of the following categories, then these sections apply to you: + +- Web Content +- Electronic Documents +- Software +- Authoring Tool + +If your product does not fall under any of these four categories, you may click the checkbox to "Hide section" – but remember to add an explanation in the Notes box of each hidden section to show evaluators why the section is not relevant. + +Only Level A and Level AA are required for an ACR for a product that must meet WCAG success criteria. But if your product does satisfy some (or all) criteria for Level AAA, it is worth completing that table as well. Showing where and how you meet AAA conformance can provide extra motivation for organizations to choose your product. + +## Step 6: Complete following sections as applicable. + +The remaining sections of the report measure how well your product meets the [U.S. Revised Section 508](https://www.section508.gov/about-us/) standards for accessibility. For any section that is not applicable to your product, (...) + +Remember to add notes wherever possible to give more information about how your product does (or does not) fully meet each criteria. + +The sections are: + +### [Functional Performance Criteria (FPC)](https://gsa.github.io/openacr-editor/chapter/functional_performance_criteria) + +If your product has any accessibility barriers or features that are NOT covered elsewhere in your report, describe them here. + +It can be useful to fill out all other sections first, then return to this one to summarize accessibility features that are described in more detail throughout the report. The key is to include as much information as possible to make your product easier to evaluate. + +### [Hardware](https://gsa.github.io/openacr-editor/chapter/hardware) + +Complete this section if your product contains Hardware (physical components such as central processing unit (CPU), keyboard, webcam, monitor, etc.) + +### [Software](https://gsa.github.io/openacr-editor/chapter/software) + +Complete this section if your product contains Software (digital components such as applications, programs, electronic data, etc.) + +### [Support Documentation and Services](https://gsa.github.io/openacr-editor/chapter/support_documentation_and_services) + +Complete this section to show how well people with disabilities will be able to access support services or documentation for your product. (For example, if you have documentation in PDFs or Word documents, those need to meet certain accessibility standards). Review all criteria in this section to see which parts are applicable to your product. + +## Step 7: Finishing up + +Now you can go to the [Report section](https://gsa.github.io/openacr-editor/report) to review your completed OpenACR. If everything looks good, you can export it as a YAML (machine-readable) file or as a zip file with both YAML and a readable HTML (web page) format. You can also import your report to Microsoft Word or print as a PDF if needed. + +## Final checklist + +- Are you using the correct version? Make sure you are using the latest version of OpenACR to build your report. If you have an older OpenACR file (ending with a .yaml extension) you should be able to load it into the OpenACR Editor to verify that it still validates. +- Save the OpenACR report to your computer (we don't store it on our servers). You will need the YAML file to edit the report in the future, +- Make sure you have added Notes to any sections where: + + - You have "hidden" a section because it is not relevant to your product + - Your product "partially supports" or "does not support" a criterion + - Anywhere else you can add information to help evaluators understand your product + +- Publish links to your OpenACR report from the product page of your site. If you have an Accessibility Statement on your site, outlining your commitment & processes for accessibility, consider including links to it there as well. + +- Consider posting it to a public git repository so that people can easily find and subscribe to updates as they occur. Some teams will proactively include a copy of their OpenACR with their codebase so it is easy to find. ... + +This content was adapted from NASA's 2021 guide, [Demystifying Section 508: An Industry Guide to Understanding Section 508 of the Rehabilitation Act (PDF)](https://sewp.nasa.gov/documents/Section_508_Guide_111821.pdf). + +**Reviewed/Updated:** March 2022 diff --git a/_pages/acquisition/2022-03-9-openacr-initiative.md b/_pages/acquisition/2022-03-9-openacr-initiative.md new file mode 100644 index 000000000..41103bd6a --- /dev/null +++ b/_pages/acquisition/2022-03-9-openacr-initiative.md @@ -0,0 +1,52 @@ +--- +layout: page +sidenav: true +permalink: openacr/initiative/ +type: acquisition +title: OpenACR initiative +created: 1527569659 +--- + +OpenACR is an initiative by the General Services Administration (GSA) to modernize and standardize Accessibility Conformance Reports (ACRs). The vision of this project is to improve the use and effectiveness of ACRs in evaluating accessibility of digital products, tools, and services. + +This page explains the OpenACR project approach, tools and technologies, standards, and roadmap. For an overview of what OpenACR is and why it is important, visit []"Why OpenACR"](openacr/about/). + +## Project approach + +The OpenACR team is creating an open standard that will allow all ACRs to have a common structure, making them easier to find, create, update, and manage. Many people and organizations have contributed to this project. + +### Frameworks + +OpenACR is built on the [VPAT®](https://en.wikipedia.org/wiki/Voluntary_Product_Accessibility_Template) framework from the Information Technology Industry Council (ITI) because VPATs are widely recognized. The project is using VPAT version 2.4Rev 508 (March 07, 2020) (Word) and aligns with Web Content Accessibility Guidelines (WCAG) 2.0 specifications. + +### Format + +A digital ACR should be highly structured and machine-readable so that its functionality can be extended (for example, a comparison tool or search features could be added). The chosen format is [YAML, or Yet Another Markup Language](https://en.wikipedia.org/wiki/YAML), because it allows the text to be human-readable. Earlier attempts at producing a machine-readable ACR used Extensible Markup Language (XML). + +Although YAML is human-readable, most people will view an OpenACR as an accessible HTML document in a web browser, as they view a web page. This will look much like a current VPAT® document. However, its functionality and practicality will exceed the traditional VPAT. + +### Styling + +Vendors will likely want to customize the look and feel of their ACR to include their branding. So the HTML output of an OpenACR is built to allow vendors to edit it later and add style elements using CSS. + +However, the reports will also be produced in a format that allows procurement officers to compare various documents without presentation getting in the way. The ultimate goal is to create a standard that more easily shows the differences between reports (and thus, between the accessibility of different products). + +## Public examples of OpenACRs + +Part of the goal of this project is to build ACRs with version control in a repository like GitHub or Gitlab. That makes it easier to see the history of each report, note where accessibility has improved, and track changes over time. This is also important for ensuring that accessibility barriers are addressed. + +You can find several [example OpenACR YAML files](https://github.com/GSA/openacr/tree/main/openacr) in the GitHub repository. Over time, more OpenACRs could be stored in a common location for easier sharing of important accessibility information. + +## OpenACR editor tool + +The [OpenACR editor tool](https://gsa.github.io/openacr-editor/) walks ACR authors through a step-by-step form that addresses all the aspects of accessibility for digital products. Alternatively, the report results can be written in YAML. Either way, the resulting document must validate against the [JSON Schema](https://github.com/GSA/openacr/tree/main/schema) that we have published in the central [GitHub repository](https://github.com/GSA/openacr/). + +The OpenACR editor is a work-in-progress, and we [invite feedback](https://github.com/GSA/openacr/issues). It is built on a tool from the Web Accessibility Initiative (WAI) called the [ATAG Report Tool](https://wai-atag-report-tool.netlify.app/), which evaluates the accessibility of authoring tools. Building on this existing standard allows OpenACR to align with [Web Accessibility Initiatives (WAI)](https://www.w3.org/WAI/) from the [Word Wide Web Consortium (W3C)](https://www.w3.org/), and allows the editor tool to be extended in the future. Every effort has been made to make the editor tool itself accessible (which is fitting, given the nature of this project). + +The editor is built with JavaScript, and allows you to either build an OpenACR file from scratch, or import one that has already been written. Then you can save the resulting OpenACR in both a YAML and HTML format. You can experiment with editing files by downloading the [Drupal YAML file](https://github.com/GSA/openacr/blob/main/openacr/drupal-9.yaml) and then loading it into the editor. + +This is a stand-alone JavaScript application. Any changes are stored exclusively in your browser. You will need to save the YAML file to your computer in order to access this information in the future. We recommend saving it into a git repository so that changes can be effectively tracked over time. + +Learn more about [creating an OpenACR report here](openacr/create-report). + +**Reviewed/Updated:** March 2022 diff --git a/_pages/acquisition/2022-03-9-openacr.md b/_pages/acquisition/2022-03-9-openacr.md new file mode 100644 index 000000000..fc70fbe6e --- /dev/null +++ b/_pages/acquisition/2022-03-9-openacr.md @@ -0,0 +1,42 @@ +--- +layout: page +sidenav: true +permalink: openacr/ +type: acquisition +title: Open Accessibility Conformance Reports (OpenACR) +created: 1527569659 +--- + +## A simple, modern way to report and evaluate accessibility conformance + +OpenACR makes it easier for your team to meet Section 508 requirements. + +### Get started with a better ACR + +OpenACR makes it easier for everyone to build, maintain, validate, and compare accessibility reports – for procurement and beyond. + +[Start my report](https://gsa.github.io/openacr-editor/) + +## How does OpenACR help me? + +### Procurement team + +OpenACR keeps accessibility information on digital tools current and accurate, helping you choose smart and accessible solutions for your organization's needs. + +### Accessibility Subject Matter Experts (SME) + +OpenACR provides a common way to share information about conformance claims, making it easier for you to support vendors and agencies with accessibility review or feedback. + +### Vendors + +To show that your software is the best fit for a potential client, you need to prove that it meets Section 508 standards for accessibility. OpenACR simplifies the process. + +### Advocates + +People with lived disabilities and others who advocate for accessibility can use OpenACR to advance awareness about whether accessibility claims match reality. + +## Learn More + +- [Why OpenACR]({{site.baseurl}}/openacr/about) +- [OpenACR initiative]({{site.baseurl}}/openacr/initiative) +- [Creating an OpenACR report]({{site.baseurl}}/openacr/create-report) diff --git a/_pages/contact-us.md b/_pages/contact-us.md index 8ae3a8f55..bb7224302 100644 --- a/_pages/contact-us.md +++ b/_pages/contact-us.md @@ -1,21 +1,29 @@ --- permalink: /contact-us/ type: page -title: 'Contact Us' +title: Contact Us layout: page sidenav: false --- -

Have a Question or Comment?

-

Before you contact us, please review the resources below, which highlight some of the common tasks on this website. They may answer your question more quickly than waiting for a return email.

- -

If these resources don’t answer your question, or you wish to report an issue with this website, please contact us via email at section.508@gsa.gov. Thank you!

-

Accessibility Standards

-

If you have questions about the Revised 508 Standards, contact the U.S. Access Board:

-

Access Board Contact Us page
Email: 508@access-board.gov
Phone: (800) 872-2253
TTY: (800) 993-2822

+## **Have a Question or Comment?** + +Before you contact us, please review the resources below, which highlight some of the common tasks on this website. They may answer your question more quickly than waiting for a return email. + +- [Find your agency's IT Accessibility Program Manager]({{site.baseurl}}/tools/coordinator-listing) +- [Learn how to create accessible content and websites]({{site.baseurl}}/create) +- [Find training on IT accessibility]({{site.baseurl}}/training) +- [Review IT accessibility policy]({{site.baseurl}}/manage/laws-and-policies) + +If these resources don't answer your question, or you wish to report an issue with this website, please contact us via email at section.508@gsa.gov. Thank you! + +## **Accessibility Standards** + +If you have questions about the [Revised 508 Standards](https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines), contact the U.S. Access Board: + +[Access Board Contact Us page](https://www.access-board.gov/contact/)
+Email: 508@access-board.gov + +
+Phone: (800) 872-2253
+TTY: (800) 993-2822 diff --git a/_pages/content-pages/2020-02-27-content-glossary.md b/_pages/content-pages/2020-02-27-content-glossary.md index 7c84391ce..b6039a0fd 100644 --- a/_pages/content-pages/2020-02-27-content-glossary.md +++ b/_pages/content-pages/2020-02-27-content-glossary.md @@ -3,545 +3,380 @@ layout: page sidenav: false permalink: content/glossary/ type: page -title: 'Glossary of Section 508 Terms' +title: Glossary of Section 508 Terms created: 1582828796 ---
-

- A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W -

- +

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

- A -

- + A + - +

- B -

- + B + - +

- C -

- + C + - +

- D -

- + D + - +

- E -

- + E + - +
  • Electronic and Information Technology (EIT): Superseded by Information and Communication Technology (ICT)
  • +

    - F -

    - + F + - +

    - G -

    - + G + - +

    - H -

    - + H + - +

    - I -

    - + I + - +

    - J -

    - + J + - +

    - K -

    - + K + - +

    - L -

    - + L + - +

    - M -

    - + M + - +

    - N -

    - + N + - +

    - O -

    - + O + - +

    - P -

    - + P + - +

    - Q -

    - + Q + - +

    - R -

    - + R + - +

    - S -

    - + S + - +

    - T -

    - + T + - +

    - U -

    - + U + - +

    - V -

    - + V + - +

    - W -

    - + W + - + +

    + Y +

    +
    -
    - Before You Go
    -

    +

    Before You Go +

    We're always working to improve the information and resources on this website. To suggest a new resource for this or another page, please contact us. -

    -
    -
    - +

    +

    - Updated: February 2020 +

    +

    Updated: March 2022

    - \ No newline at end of file + diff --git a/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play02.md b/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play02.md index f641caaaa..f5d710fb0 100644 --- a/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play02.md +++ b/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play02.md @@ -6,92 +6,102 @@ title: 'Play 2: Assess your Section 508 program maturity' created: 1526408495 --- -Some agencies have not established a formal Section 508 compliance program. Other agencies are just beginning to establish a Section 508 program, and they need to establish policies, procedures, training and communications to build awareness of what is required and who is responsible for addressing compliance needs. Agencies further along may have dedicated resources to perform testing to validate Section 508 conformance claims, but do not have a systematic approach to perform testing. Mature agencies demonstrate the ability to measure and monitor conformance to policies and actual compliance levels, and they use data to drive decision making to improve the effectiveness of their overall Section 508 program. Section 508 activities appropriate for mature organizations may not be appropriate for less mature organizations that do not have an adequate foundation to build upon. Therefore, an assessment of your agency’s Section 508 program maturity is essential to gauge where you are, and to determine what steps are necessary to improve your program. +Some agencies have not established a formal Section 508 compliance program. Other agencies are just beginning to establish a Section 508 program, and they need to establish policies, procedures, training and communications to build awareness of what is required and who is responsible for addressing compliance needs. Agencies further along may have dedicated resources to perform testing to validate Section 508 conformance claims, but do not have a systematic approach to perform testing. Mature agencies demonstrate the ability to measure and monitor conformance to policies and actual compliance levels, and they use data to drive decision making to improve the effectiveness of their overall Section 508 program. Section 508 activities appropriate for mature organizations may not be appropriate for less mature organizations that do not have an adequate foundation to build upon. Therefore, an assessment of your agency's Section 508 program maturity is essential to gauge where you are, and to determine what steps are necessary to improve your program. ## Key Questions - * What is the current maturity of your agency’s Section 508 compliance program? - * How is your program’s maturity enabling or inhibiting your agency’s ability to provide accessible digital services and technology solutions? +- What is the current maturity of your agency's Section 508 compliance program? +- How is your program's maturity enabling or inhibiting your agency's ability to provide accessible digital services and technology solutions? ## Section 508 Program Maturity Levels In the Government-wide Section 508 Strategic Plan, OMB requires agencies to assess their Section 508 program maturity using the following criteria: - * Ad Hoc: No formal policies, processes, or procedures defined. -
    Your agency has not established a framework for the consistent management of Section 508 compliance requirements for the technology it buys, builds maintains and uses.
    +- Ad Hoc: No formal policies, processes, or procedures defined. - * Planned: Policies, processes, and procedures defined and communicated. -
    Your agency’s approach to ensuring technology is Section 508 compliant is defined and integrated into its policies and procedures. Section 508 policies and procedures sufficiently address all technology your agency buys, builds maintains and uses, as scoped by the Section 508 standards.
    + > Your agency has not established a framework for the consistent management of Section 508 compliance requirements for the technology it buys, builds maintains and uses. - * Resourced: Resources committed and/or staff trained to implement policies, processes, and procedures. -
    Your agency’s leadership and staff understand and support the Section 508 policies and procedures, and know how to implement them. Your agency has dedicated sufficient resources to implement your Section 508 policies and procedures.
    +- Planned: Policies, processes, and procedures defined and communicated. - * Measured: Validation is performed; results are measured and tracked. -
    Your agency tests and validates agency digital services and technology solutions to ensure they conform to the Section 508 standards. You are able to determine whether your policies and procedures are actually being followed. You measure the effectiveness of your Section 508 policies and procedures, and are able to use your measures to manage risk and prioritize opportunities for improving your compliance program.
    + > Your agency's approach to ensuring technology is Section 508 compliant is defined and integrated into its policies and procedures. Section 508 policies and procedures sufficiently address all technology your agency buys, builds maintains and uses, as scoped by the Section 508 standards. + +- Resourced: Resources committed and/or staff trained to implement policies, processes, and procedures. + + > Your agency's leadership and staff understand and support the Section 508 policies and procedures, and know how to implement them. Your agency has dedicated sufficient resources to implement your Section 508 policies and procedures. + +- Measured: Validation is performed; results are measured and tracked. + + > Your agency tests and validates agency digital services and technology solutions to ensure they conform to the Section 508 standards. You are able to determine whether your policies and procedures are actually being followed. You measure the effectiveness of your Section 508 policies and procedures, and are able to use your measures to manage risk and prioritize opportunities for improving your compliance program. ## Section 508 Program Maturity Domains In the Government-wide Section 508 Strategic Plan, OMB requires agencies to assess their Section 508 program maturity in each of the following domains: - * Acquisition: Conduct validation of procurement solicitations to ensure incorporation of Section 508 contract language into Statements of Work and Performance Work Statements. -
    When purchasing technology, you must ensure the acquisition process addresses section 508 requirements.  Solicitation language must clearly state what standards apply to the digital service or technology solution, and require potential vendors to demonstrate they can meet the requirements.
    - - * Agency technology life cycles: Conduct validation of Section 508 requirements to ensure incorporation into agency life cycle activities, including enterprise architecture, design, development, testing, deployment, and ongoing maintenance activities. -
    Enterprise life cycles are used to define the end-to-end approach to approving, building, deploying, and supporting agency technology. The least effective and most expensive approach to supporting compliance is to treat Section 508 requirements as an afterthought in response to test results, or worse in response to complaints from people with disabilities. The most effective and least expensive approach is to consider Section 508 requirements at all stages of the enterprise life cycle. This is analogous to the saying “it’s cheaper and easier to use an eraser to modify an architectural drawing than a sledgehammer to tear down a wall.”
    - - * Testing and Validation: Testing and validation of Section 508 conformance claims. -
    While a review of Voluntary Product Accessibility Templates (VPAT) provided by a vendor or contractor is a starting point, sometimes testing may be required to validate assertions of Section 508 compliance, to inform remediation planning, and to monitor agency progress with achieving Section 508 compliance. In addition, testing may be required on an ongoing basis to validate the technology developed, maintained, and used by an agency is compliant with the applicable 508 standards as components are updated or replaced.
    - - * Complaint Management: Track and resolve incoming Section 508 complaints. -
    A clear process for addressing and tracking Section 508 complaints is necessary to provide for effective communication with complainants, to validate Section 508 non-compliance claims, to support an appropriate agency response aimed at minimizing legal exposure, costs, and loss of administrative time, and to serve as input into decisions related to resource and work planning.
    - - * Training: Training for stakeholders on roles and responsibilities related to Section 508 compliance. -
    Successful Section 508 programs rely on personnel with skills and expertise. Relevant resources need to be identified and trained. Mandatory training needs to be established and tracked. This includes, but is not limited to, training for web and software developers, acquisition professionals, human resource employees and communications specialists.
    - -## Basic Checklist - - * Evaluate how existing agency policies, practices, and procedures support each maturity area. - * Technology Processes: Technology Domains, Processes, Activities, - * Technology Resources: Applications, Information, Infrastructure, People, and - * Business Requirements: Effectiveness, Efficiency, Confidentiality, Integrity, Availability, Compliance, Reliability. - * Identify strengths and weaknesses of the organization’s current accessibility processes. - * Review Section 508 compliance challenges raised in previous complaints. - * Determine overall maturity level ratings using the OMB Agency Section 508 Reporting Template and instructions. - * Use data from maturity assessments to inform the agency’s response to the biennial Department of Justice Section 508 Survey. - -## Advanced Checklist - - * Identify how the maturity of the current Section 508 program prepares you to transition to the new 508 standards. - * Assess the maturity of the Section 508 Program Team’s collaboration with offices that support: - * Internal technology design, development, configuration, deployment, and maintenance, - * Accommodations (Section 504 and 501), - * Equal Opportunity Office, - * Enterprise Architecture, - * Investment Management, - * Acquisition Management, - * Enterprise Life Cycle Governance, - * User Experience Design, - * Help Desk and Customer Support, - * Communications, Public Affairs, and Advocacy Group Outreach, - * Security & Privacy, and - * Legal. - -## Resources - - * [Strategic Plan: Improving Management of Section 508 of the Rehabilitation Act][1] - * [Training - How to Measure Your Agency's 508 Program Training][2] - * [Section 508 OMB Dashboard/Reporting Template][3] - * [Section 508 OMB Dashboard/Reporting Template Instructions][4] - * [Digital Service Contracting Professional Training and Development Program][5] - * [IT Dashboard.gov for E-gov act accessibility related comments][6] - * [Agile Governance reality or dream in the US and UK Governments?][7] (includes OMB participation link to GAO Schedule Assessment Guide) - -  - - [1]: https://assets.section508.gov/files/strategic-plan-508-compliance.pdf - [2]: https://assets.section508.gov/files/FINAL_16to9_OMB_YOUR_PROGRAM_MEASURES.PPTX - [3]: https://assets.section508.gov/files/S508TEMPLATE120816EXT2_1.pdf - [4]: {{site.baseurl}}/manage/reporting - [5]: https://www.challenge.gov/challenge/digital-service-contracting-professional-training-and-development-program-challenge/ - [6]: https://itdashboard.gov/ - [7]: https://www.youtube.com/watch?list=PLQzq_ylfBVzKM1ZC_900nvea6uxkeAOVS&v=Wp92Vq3yTrU \ No newline at end of file +- Acquisition: Conduct validation of procurement solicitations to ensure incorporation of Section 508 contract language into Statements of Work and Performance Work Statements. + + > When purchasing technology, you must ensure the acquisition process addresses section 508 requirements. Solicitation language must clearly state what standards apply to the digital service or technology solution, and require potential vendors to demonstrate they can meet the requirements. + +- Agency technology life cycles: Conduct validation of Section 508 requirements to ensure incorporation into agency life cycle activities, including enterprise architecture, design, development, testing, deployment, and ongoing maintenance activities. + + > Enterprise life cycles are used to define the end-to-end approach to approving, building, deploying, and supporting agency technology. The least effective and most expensive approach to supporting compliance is to treat Section 508 requirements as an afterthought in response to test results, or worse in response to complaints from people with disabilities. The most effective and least expensive approach is to consider Section 508 requirements at all stages of the enterprise life cycle. This is analogous to the saying "it's cheaper and easier to use an eraser to modify an architectural drawing than a sledgehammer to tear down a wall." + +- Testing and Validation: Testing and validation of Section 508 conformance claims. + + > While a review of ACR provided by a vendor or contractor is a starting point, sometimes testing may be required to validate assertions of Section 508 compliance, to inform remediation planning, and to monitor agency progress with achieving Section 508 compliance. In addition, testing may be required on an ongoing basis to validate the technology developed, maintained, and used by an agency is compliant with the applicable 508 standards as components are updated or replaced. + +- Complaint Management: Track and resolve incoming Section 508 complaints. + + > A clear process for addressing and tracking Section 508 complaints is necessary to provide for effective communication with complainants, to validate Section 508 non-compliance claims, to support an appropriate agency response aimed at minimizing legal exposure, costs, and loss of administrative time, and to serve as input into decisions related to resource and work planning. + +- Training: Training for stakeholders on roles and responsibilities related to Section 508 compliance. + + > Successful Section 508 programs rely on personnel with skills and expertise. Relevant resources need to be identified and trained. Mandatory training needs to be established and tracked. This includes, but is not limited to, training for web and software developers, acquisition professionals, human resource employees and communications specialists. + +## Basic Checklist {#basic} + +- Evaluate how existing agency policies, practices, and procedures support each maturity area. + + - Technology Processes: Technology Domains, Processes, Activities, + - Technology Resources: Applications, Information, Infrastructure, People, and + - Business Requirements: Effectiveness, Efficiency, Confidentiality, Integrity, Availability, Compliance, Reliability. + +- Identify strengths and weaknesses of the organization's current accessibility processes. +- Review Section 508 compliance challenges raised in previous complaints. +- Determine overall maturity level ratings using the OMB Agency Section 508 Reporting Template and instructions. +- Use data from maturity assessments to inform the agency's response to the biennial Department of Justice Section 508 Survey. + +## Advanced Checklist {#advanced} + +- Identify how the maturity of the current Section 508 program prepares you to transition to the new 508 standards. +- Assess the maturity of the Section 508 Program Team's collaboration with offices that support: + + - Internal technology design, development, configuration, deployment, and maintenance, + - Accommodations (Section 504 and 501), + - Equal Opportunity Office, + - Enterprise Architecture, + - Investment Management, + - Acquisition Management, + - Enterprise Life Cycle Governance, + - User Experience Design, + - Help Desk and Customer Support, + - Communications, Public Affairs, and Advocacy Group Outreach, + - Security & Privacy, and + - Legal. + +## Resources {#resources} + +- [Strategic Plan: Improving Management of Section 508 of the Rehabilitation Act][1] +- [Training - How to Measure Your Agency's 508 Program Training][2] +- [Section 508 OMB Dashboard/Reporting Template][3] +- [Section 508 OMB Dashboard/Reporting Template Instructions][4] +- [Digital Service Contracting Professional Training and Development Program][5] +- [IT Dashboard.gov for E-gov act accessibility related comments][6] +- [Agile Governance reality or dream in the US and UK Governments?][7] (includes OMB participation link to GAO Schedule Assessment Guide) + +[1]: https://assets.section508.gov/files/strategic-plan-508-compliance.pdf +[2]: https://assets.section508.gov/files/FINAL_16to9_OMB_YOUR_PROGRAM_MEASURES.PPTX +[3]: https://assets.section508.gov/files/S508TEMPLATE120816EXT2_1.pdf +[4]: {{site.baseurl}}/manage/reporting +[5]: https://www.challenge.gov/challenge/digital-service-contracting-professional-training-and-development-program-challenge/ +[6]: https://itdashboard.gov/ +[7]: https://www.youtube.com/watch?list=PLQzq_ylfBVzKM1ZC_900nvea6uxkeAOVS&v=Wp92Vq3yTrU diff --git a/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play08.md b/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play08.md index f49cf1042..28f8e6acd 100644 --- a/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play08.md +++ b/_pages/training/playbooks/2018-05-15-tools-playbooks-technology-accessibility-playbook-intro-play08.md @@ -2,7 +2,9 @@ permalink: tools/playbooks/technology-accessibility-playbook-intro/play08/ type: training layout: page -title: 'Play 8: Integrate accessibility needs into market research and acquisition processes' +title: >- + Play 8: Integrate accessibility needs into market research and acquisition + processes created: 1526408818 --- @@ -10,76 +12,85 @@ The following play identifies how to ensure accessibility needs are identified a ## Key Questions - * How does your agency ensure Section 508 legal compliance requirements are properly included in solicitation language? - * What steps does your agency take to validate Section 508 conformance claims? Is the level of due diligence adequate to mitigate the potential compliance risk? - * How does your agency ensure it supports legal obligations to purchase digital services and technology solutions that “meet or best meets” the Section 508 requirements. +- How does your agency ensure Section 508 legal compliance requirements are properly included in solicitation language? +- What steps does your agency take to validate Section 508 conformance claims? Is the level of due diligence adequate to mitigate the potential compliance risk? +- How does your agency ensure it supports legal obligations to purchase digital services and technology solutions that "meet or best meets" the Section 508 requirements. ## Basic Checklist -General Preparation: - - * Study the FAR, particularly parts that specifically address 508 (Sections 10, 11, 12.2, and 39.2). - * Identify and understand your agency’s acquisition policies and procedures used to acquire technology. - * Determine if adequate consideration of Section 508 Standards is already included in these policies and procedures – if not work with the appropriate stakeholders to change this. - * Develop criteria for when and how accessibility and Section 508 requirements, exceptions, terms and conditions, evaluation methods, acceptance criteria, and related proposal response requirements are included in solicitations. - * Ensure Contracting Officers know what to expect from the Requiring Officials related to Section 508 requirements. - * Ensure the Requiring Office includes the appropriate accessibility requirements in the solicitation language. - * Ensure Requiring Officials know when and who to contact for accessibility guidance. - * Establish a formal Section 508 compliance determination process. Use the process to document compliance decisions. Support decisions with relevant Section 508 artifacts (Market Research, VPATs™, Section 508 Exceptions, test results, and “best meets” determinations.) - * Provide for independent expert reviews of Section 508 exception and vendor accessibility claims prior to award. - * Use a risk based model to determine when independent testing is required to validate vendor conformance claims. - * Provide authority to the Section 508 Program Team to stop any contract or application that puts the agency at significant risk. - * Create a governance process to ensure Section 508 conformance is an evaluation factor in award decisions. - * Provide a process to track and monitor accessibility assurance activities and Section 508 compliance determinations for all agency technology procurements. - * Develop a process for planning and implementing an “alternative means” when a fully accessible solution is not procured. - -For each technology procurement: - - * Work with Program Managers or Requiring Officials to define, review, and approve determinations of applicable Section 508 standards and/or exceptions when they apply. - * Consider accessibility needs in market research. - * Draft Section 508 contract language and accessibility terms and conditions when needed. Refer to Play 7 for information on defining applicable Section 508 standards and additional requirements needed to address access by individuals with disabilities). - * Ensure contract evaluation plans include accessibility, and define the Section 508 subject matter expert role on the Technical Evaluation Panel. - * Require vendors to provide detailed responses to accessibility requirements in the Statement of Work. - * Validate Section 508 accessibility conformance claims in bid proposals through expert review or testing. - * If another agency claims a product is Section 508 conformant, ask if the agency used Section 508 test processes endorsed by the CIO Council Accessibility Community of Practice, and where applicable using testers certified through the DHS trusted tester program. If these conditions are met, consider accepting the other agency’s Section 508 determination to streamline the evaluation process. - * Validate vendor Section 508 conformance claims through expert analysis. Example documentation for conformance claims includes Voluntary Product Accessibility Templates (VPATs™) Government Product Accessibility Templates (GPATs) for conformance. - * When testing is warranted, perform testing prior to award for commercially available digital services and technology solutions, and prior to deployment for solutions that are developed, customized, and/or integrated with other technology components post award. For more information on testing, see play 10. - * Provide documentation of Section 508 conformance claims, expert analysis and test findings to the Contracting Official. - * Ensure Section 508 requirements are addressed in award decisions. If no product(s) fully meets the applicable Section 508 standards, document which product(s) “best meet” the applicable Section 508 standards [[2]][1]. - * Conduct an alternative means assessment when purchased products do not meet standards. - * Ensure post-award contract acceptance activities established in the solicitation are followed. - * Develop and track the provision of an alternative means or remediation/accommodation plan when a fully accessible solution is not procured. + + General Preparation: + + +- Study the FAR, particularly parts that specifically address 508 (Sections 10, 11, 12.2, and 39.2). +- Identify and understand your agency's acquisition policies and procedures used to acquire technology. +- Determine if adequate consideration of Section 508 Standards is already included in these policies and procedures – if not work with the appropriate stakeholders to change this. +- Develop criteria for when and how accessibility and Section 508 requirements, exceptions, terms and conditions, evaluation methods, acceptance criteria, and related proposal response requirements are included in solicitations. + + - Ensure Contracting Officers know what to expect from the Requiring Officials related to Section 508 requirements. + - Ensure the Requiring Office includes the appropriate accessibility requirements in the solicitation language. + - Ensure Requiring Officials know when and who to contact for accessibility guidance. + +- Establish a formal Section 508 compliance determination process. Use the process to document compliance decisions. Support decisions with relevant Section 508 artifacts (Market Research, ACRs, Section 508 Exceptions, test results, and "best meets" determinations.) + + - Provide for independent expert reviews of Section 508 exception and vendor accessibility claims prior to award. + - Use a risk based model to determine when independent testing is required to validate vendor conformance claims. + - Provide authority to the Section 508 Program Team to stop any contract or application that puts the agency at significant risk. + +- Create a governance process to ensure Section 508 conformance is an evaluation factor in award decisions. + +- Provide a process to track and monitor accessibility assurance activities and Section 508 compliance determinations for all agency technology procurements. +- Develop a process for planning and implementing an "alternative means" when a fully accessible solution is not procured. + + + For each technology procurement: + + +- Work with Program Managers or Requiring Officials to define, review, and approve determinations of applicable Section 508 standards and/or exceptions when they apply. +- Consider accessibility needs in market research. +- Draft Section 508 contract language and accessibility terms and conditions when needed. Refer to Play 7 for information on defining applicable Section 508 standards and additional requirements needed to address access by individuals with disabilities). +- Ensure contract evaluation plans include accessibility, and define the Section 508 subject matter expert role on the Technical Evaluation Panel. +- Require vendors to provide detailed responses to accessibility requirements in the Statement of Work. +- Validate Section 508 accessibility conformance claims in bid proposals through expert review or testing. + + - If another agency claims a product is Section 508 conformant, ask if the agency used Section 508 test processes endorsed by the CIO Council Accessibility Community of Practice, and where applicable using testers certified through the DHS trusted tester program. If these conditions are met, consider accepting the other agency's Section 508 determination to streamline the evaluation process. + - Validate vendor Section 508 conformance claims through expert analysis. Example documentation for conformance claims includes OpenACRs (or legacy Voluntary Product Accessibility Templates (VPATs™) or Government Product Accessibility Templates (GPATs)). + - When testing is warranted, perform testing prior to award for commercially available digital services and technology solutions, and prior to deployment for solutions that are developed, customized, and/or integrated with other technology components post award. For more information on testing, see play 10. + +- Provide documentation of Section 508 conformance claims, expert analysis and test findings to the Contracting Official. + +- Ensure Section 508 requirements are addressed in award decisions. If no product(s) fully meets the applicable Section 508 standards, document which product(s) "best meet" the applicable Section 508 standards [][1][2]. +- Conduct an alternative means assessment when purchased products do not meet standards. +- Ensure post-award contract acceptance activities established in the solicitation are followed. +- Develop and track the provision of an alternative means or remediation/accommodation plan when a fully accessible solution is not procured. ## Advanced Checklist - * Provide contract language to ensure penalties are applied when accessibility standards are not met, or require remediation at contractor expense. - * Establish language and processes for Blanket Purchase agreements and other Task Order-based vehicles. - * Establish processes for assessing the maturity of vendor’s accessibility program during market research and proposal evaluations. - * Conduct post procurement reviews and audits to validate conformance to accessibility procedures and use data to improve the procurement process for accessible products. - * Engage in vendor outreach through the CIO Council Accessibility Community of Practice. - * Engage peers in the Section 508 community regarding other agencies’ experiences with the product or vendor. +- Provide contract language to ensure penalties are applied when accessibility standards are not met, or require remediation at contractor expense. +- Establish language and processes for Blanket Purchase agreements and other Task Order-based vehicles. +- Establish processes for assessing the maturity of vendor's accessibility program during market research and proposal evaluations. +- Conduct post procurement reviews and audits to validate conformance to accessibility procedures and use data to improve the procurement process for accessible products. +- Engage in vendor outreach through the CIO Council Accessibility Community of Practice. +- Engage peers in the Section 508 community regarding other agencies' experiences with the product or vendor. ## Resources - * [Section 508 Standards][2] - * [OMB Government-wide Section 508 Strategic Plan][4] - * Section 508 and the Federal Acquisition Regulations (FAR) - * [GSA’s Guidance on Creating Section 508 Compliant Solicitations][5] - * [GSA’s Guidance on Acquisition for Accessible EIT][6] +- [Section 508 Standards][2] +- [OMB Government-wide Section 508 Strategic Plan][3] +- Section 508 and the Federal Acquisition Regulations (FAR) +- [GSA's Guidance on Creating Section 508 Compliant Solicitations][4] +- [GSA's Guidance on Acquisition for Accessible EIT][5]
    -
    - +
    -

    - [2] According to the Section 508 standards, part 1194.2, “ (b) When procuring a product, each agency shall procure products which comply with the provisions in this part when such products are available in the commercial marketplace or when such products are developed in response to a Government solicitation.  Agencies cannot claim a product as a whole is not commercially available because no product in the marketplace meets all the standards.  If products are commercially available that meet some but not all of the standards, the agency must procure the product that best meets the standards.” +

    2 According to the Section 508 standards, part 1194.2, “ (b) When procuring a product, each agency shall procure products which comply with the provisions in this part when such products are available in the commercial marketplace or when such products are developed in response to a Government solicitation.  Agencies cannot claim a product as a whole is not commercially available because no product in the marketplace meets all the standards.  If products are commercially available that meet some but not all of the standards, the agency must procure the product that best meets the standards.”

    -
    +
    - [1]: #Footnote2 - [2]: https://www.federalregister.gov/documents/2000/12/21/00-32017/electronic-and-information-technology-accessibility-standards - [3]: {{site.baseurl}} - [4]: https://obamawhitehouse.archives.gov/sites/default/files/omb/procurement/memo/strategic-plan-508-compliance.pdf - [5]: https://assets.section508.gov/files/guidance-on-508-compliant-solicitations-20150921.docx - [6]: https://assets.section508.gov/files/Guidance-on-Acquisition-for-Accessible-EIT-20150921.docx \ No newline at end of file +[1]: #Footnote2 +[2]: https://www.federalregister.gov/documents/2000/12/21/00-32017/electronic-and-information-technology-accessibility-standards +[3]: https://obamawhitehouse.archives.gov/sites/default/files/omb/procurement/memo/strategic-plan-508-compliance.pdf +[4]: https://assets.section508.gov/files/guidance-on-508-compliant-solicitations-20150921.docx +[5]: https://assets.section508.gov/files/Guidance-on-Acquisition-for-Accessible-EIT-20150921.docx diff --git a/_posts/2017-12-13-blog-Universal-Design-What-is-it.md b/_posts/2017-12-13-blog-Universal-Design-What-is-it.md index 68b97741f..35162a999 100644 --- a/_posts/2017-12-13-blog-Universal-Design-What-is-it.md +++ b/_posts/2017-12-13-blog-Universal-Design-What-is-it.md @@ -5,57 +5,58 @@ type: article title: 'Universal Design: What is it?' created: 1513216986 tags: Design-and-Develop -description: Part one of a two-part series about Universal Design The year is 2017. The advancement of technology, led by key players in the private sector, has introduced innovations that have made applications more accessible for people with disabilities. +description: >- + Part one of a two-part series about Universal Design The year is 2017. The + advancement of technology, led by key players in the private sector, has + introduced innovations that have made applications more accessible for people + with disabilities. --- _Part one of a two-part series about Universal Design_ -The year is 2017. The advancement of technology, led by key players in the private sector, has introduced innovations that have made applications more accessible for people with disabilities. +The year is 2017\. The advancement of technology, led by key players in the private sector, has introduced innovations that have made applications more accessible for people with disabilities. Companies have pledged to implement accessible technology, pushing the technology industry to prioritize accessibility. Examples of this commitment include: - * **Creating** **design toolkits and activities checklists** to help businesses shift their design thinking toward more universal solutions and applications. - * For individuals with color vision impairment and color blindness, **using** [**Color Universal Design (CUD)**][1] to help users edit images and ensure graphical information is conveyed accurately. - * **Launching accessibility initiatives** **so that customers can learn** about accessible products through whitepapers and demos, understand how to configure products to achieve an accessible output, and view Voluntary Product Accessibility Templates (VPATs™) to reinforce how products meet Section 508 and [WCAG 1.0][2] and [WCAG 2.0][3] guidelines. +- **Creating** **design toolkits and activities checklists** to help businesses shift their design thinking toward more universal solutions and applications. +- For individuals with color vision impairment and color blindness, **using** [**Color Universal Design (CUD)**][1] to help users edit images and ensure graphical information is conveyed accurately. +- **Launching accessibility initiatives so that customers can learn** about accessible products through white papers and demos, understand how to configure products to achieve an accessible output, and view OpenACR reports to reinforce how products meet Section 508 and [WCAG 2.0][3] guidelines. With nearly [1 in 8][4] people in the U.S. known to have a disability, there is a huge incentive for businesses, and the government, to invest in accessible technology to ensure that working environments are inclusive and available to all user groups. However, organizations often overlook key design areas related to accessibility when implementing these new technologies, which leads to overspending in the long term to rectify early design decisions. -The solution? [Universal Design][5]! This approach ensures that the complete user experience is captured at every stage of the implementation process, and it’s gaining widespread popularity in the private sector. The result is a solution designed with all users in mind. +The solution? [Universal Design][5]! This approach ensures that the complete user experience is captured at every stage of the implementation process, and it's gaining widespread popularity in the private sector. The result is a solution designed with all users in mind. -_Universal Design is the design and composition of an environment so that it can be accessed, understood and used to the greatest extent possible by all people regardless of their age, size, ability or disability_ +_![Universal Design is the design and composition of an environment so that it can be accessed, understood and used to the greatest extent possible by all people regardless of their age, size, ability or disability](https://lh5.googleusercontent.com/ajzgJj0-GdBRY2wDetdTOUq_0gJkmWjri-xTmFIGmAX6Ic5hfPnc8_Q-jXvDFq-eaFU6ukh3EGaJk3dut1e5kUlOKTLHLSEbKMXfecN9ZtS0zlPOo6v74wZJkzwj7DCbZ-31kaSO)_
    - While Universal Design can be applied to any product, whether that be a building, service or tool, solutions designed using this approach serve not only the needs of a single minority group, but create an environment that is accessible and convenient for all. All in all, Universal Design is a good design. -
    + While Universal Design can be applied to any product, whether that be a building, service or tool, solutions designed using this approach serve not only the needs of a single minority group, but create an environment that is accessible and convenient for all. All in all, Universal Design is a good design. Universal Design is based on these [7 Principles][6]: -**1)** [**Equitable Use**][7] - The design is useful and marketable to people with diverse abilities. -**2)** [**Flexibility in Use**][8] - The design accommodates a wide range of individual preferences and abilities. -**3)** [**Simple and Intuitive Use**][9] - Use of the design is easy to understand, regardless of the user's experience, knowledge, language skills or current concentration level. -**4)** [**Perceptible Information**][10] - The design communicates necessary information effectively to the user, regardless of ambient conditions or the user's sensory abilities. -**5)** [**Tolerance for Error**][11] - The design minimizes hazards and the adverse consequences of accidental or unintended actions. -**6)** [**Low Physical Effort**][12] - The design can be used efficiently and comfortably and with a minimum of fatigue. +**1)** [**Equitable Use**][7] - The design is useful and marketable to people with diverse abilities.
    +**2)** [**Flexibility in Use**][8] - The design accommodates a wide range of individual preferences and abilities.
    +**3)** [**Simple and Intuitive Use**][9] - Use of the design is easy to understand, regardless of the user's experience, knowledge, language skills or current concentration level.
    +**4)** [**Perceptible Information**][10] - The design communicates necessary information effectively to the user, regardless of ambient conditions or the user's sensory abilities.
    +**5)** [**Tolerance for Error**][11] - The design minimizes hazards and the adverse consequences of accidental or unintended actions.
    +**6)** [**Low Physical Effort**][12] - The design can be used efficiently and comfortably and with a minimum of fatigue.
    **7)** [**Size and Space for Approach and Use**][13] - Appropriate size and space is provided for approach, reach, manipulation, and use regardless of user's body size, posture, or mobility. The Revised 508 standards, in line with the [WCAG 2.0 guidelines][14], offer an opportunity for agencies to define and revamp approaches towards accessible technology using Universal Design principles. Key players, such as federal Chief Information Officers (CIO), can help to prioritize and shape this strategy within agencies, and push existing practices beyond compliance. -To learn more about Universal Design and how executives and agencies can benefit from incorporating Universal Design into their digital accessibility strategy, check out part two of the series: [Universal Design: What’s in it for me?][15]. - -  - - [1]: https://webcube-general.s3.amazonaws.com/eizo/media/contentassets/2015/10/09/handbook.pdf - [2]: https://www.w3.org/TR/WCAG10/ - [3]: https://www.w3.org/TR/WCAG20/ - [4]: https://disabilitycompendium.org/sites/default/files/user-uploads/2016_AnnualReport.pdf - [5]: http://universaldesign.ie/What-is-Universal-Design/ - [6]: http://universaldesign.ie/What-is-Universal-Design/The-7-Principles/7-Principals-.pdf - [7]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p1 - [8]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p2 - [9]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p3 - [10]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p4 - [11]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p5 - [12]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p6 - [13]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p7 - [14]: https://www.w3.org/WAI/intro/wcag - [15]: {{site.baseurl}}/blog/universal-design-whats-in-it-for-me \ No newline at end of file +To learn more about Universal Design and how executives and agencies can benefit from incorporating Universal Design into their digital accessibility strategy, check out part two of the series: [Universal Design: What's in it for me?][15]. + +[1]: https://webcube-general.s3.amazonaws.com/eizo/media/contentassets/2015/10/09/handbook.pdf +[10]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p4 +[11]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p5 +[12]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p6 +[13]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p7 +[14]: https://www.w3.org/WAI/intro/wcag +[15]: {{site.baseurl}}/blog/universal-design-whats-in-it-for-me +[2]: https://www.w3.org/TR/WCAG10/ +[3]: https://www.w3.org/TR/WCAG20/ +[4]: https://disabilitycompendium.org/sites/default/files/user-uploads/2016_AnnualReport.pdf +[5]: http://universaldesign.ie/What-is-Universal-Design/ +[6]: http://universaldesign.ie/What-is-Universal-Design/The-7-Principles/7-Principals-.pdf +[7]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p1 +[8]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p2 +[9]: http://universaldesign.ie/what-is-universal-design/the-7-principles/the-7-principles.html#p3 diff --git a/_posts/2018-04-20-blog-how-read-vpat-.md b/_posts/2018-04-20-blog-how-read-vpat-.md index 40db58288..f3ee6fb96 100644 --- a/_posts/2018-04-20-blog-how-read-vpat-.md +++ b/_posts/2018-04-20-blog-how-read-vpat-.md @@ -2,83 +2,89 @@ layout: post permalink: blog/Building-Accessibility-into-your-Procurement-Process/ type: article -title: 'Building Accessibility into Your Procurement Process' +title: Building Accessibility into Your Procurement Process created: 1524275406 tags: Acquisition Design-and-Develop -description: What comes to mind when you hear the word “accessibility”? If it's “compliance,” then you're not alone. While compliance is important, and a legal requirement, consider thinking about accessible IT from a universal design standpoint first. +description: >- + What comes to mind when you hear the word “accessibility”? If it's + “compliance,” then you're not alone. While compliance is important, and a + legal requirement, consider thinking about accessible IT from a universal + design standpoint first. --- -What comes to mind when you hear the word “accessibility”? If it's “compliance,” then you're not alone. While compliance is important, and a legal requirement, consider thinking about accessible IT from a universal design standpoint first. Shifting your mindset to buy solutions that are accessible for all starts with the procurement process. Chief Information Officers (CIOs) and Chief Acquisition Officers (CAOs) are responsible for defining and communicating accessibility and usability needs to vendors. This post explores why it's important for CIOs and CAOs to ensure vendors provide the most accessible solutions, by approaching procurement from a “universal design” perspective. +What comes to mind when you hear the word "accessibility"? If it's "compliance," then you're not alone. While compliance is important, and a legal requirement, consider thinking about accessible IT from a universal design standpoint first. Shifting your mindset to buy solutions that are accessible for all starts with the procurement process. Chief Information Officers (CIOs) and Chief Acquisition Officers (CAOs) are responsible for defining and communicating accessibility and usability needs to vendors. This post explores why it's important for CIOs and CAOs to ensure vendors provide the most accessible solutions, by approaching procurement from a "universal design" perspective. ## Why Keep Universal Design in Mind For Procurement? -[Universal design][1] is the concept that products and environments are designed to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design. Universally designed products are more adaptive and easier to maintain. They cost less over time because they eliminate the need to make inaccessible products accessible. To develop tools and solutions designed for all users, it’s imperative that your agency’s IT strategy addresses accessibility and usability in the procurement process. If you involve different user communities early on, you’ll gain a clear understanding of their usability needs, and can account for them during the procurement process. Add statements in solicitations that outline requirements of your entire user base to make accessibility functionality clear to vendors. Highlighting accessibility requirements at the procurement stage demonstrates that agencies prioritize accessibility and understand it is an essential part of the customer experience journey. CIOs and CAOs need to communicate a clear commitment to accessibility in their digital and procurement strategy, to set the expectation that this is a _best practice_ when it comes to purchasing decisions. +[Universal design][1] is the concept that products and environments are designed to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design. Universally designed products are more adaptive and easier to maintain. They cost less over time because they eliminate the need to make inaccessible products accessible. To develop tools and solutions designed for all users, it's imperative that your agency's IT strategy addresses accessibility and usability in the procurement process. If you involve different user communities early on, you'll gain a clear understanding of their usability needs, and can account for them during the procurement process. Add statements in solicitations that outline requirements of your entire user base to make accessibility functionality clear to vendors. Highlighting accessibility requirements at the procurement stage demonstrates that agencies prioritize accessibility and understand it is an essential part of the customer experience journey. CIOs and CAOs need to communicate a clear commitment to accessibility in their digital and procurement strategy, to set the expectation that this is a _best practice_ when it comes to purchasing decisions. -If you understand your accessibility and usability needs, it’s easier to search for products that meet your standards, and incorporating these needs from the outset becomes part of your agency's standard operating procedure for federal procurement. +If you understand your accessibility and usability needs, it's easier to search for products that meet your standards, and incorporating these needs from the outset becomes part of your agency's standard operating procedure for federal procurement. ## How to Buy the Most Accessible Products -### 1. Research, research, research! +### 1\. Research, research, research! -Technology companies spend more on [research and development][2] than any other industry in the US. Given the rapid advancements in technology today, it’s important to research vendors to understand what their products offer. You should also request accessibility templates, such as a Voluntary Product Accessibility Template (VPAT™), from vendors to show how their products meet relevant Section 508 standards and accessibility guidelines. [Section508.gov][3] has great resources to help you in this step of your procurement process. +Technology companies spend more on [research and development][2] than any other industry in the US. Given the rapid advancements in technology today, it's important to research vendors to understand what their products offer. You should also request an Accessibility Conformance Report (ACR), like OpenACR (link to OpenACR page), from vendors to show how their products meet relevant Section 508 standards and accessibility guidelines. If an OpenACR is not available, you may choose to accept a legacy Voluntary Product Accessibility Template (VPAT™). [Section508.gov][3] has great resources to help you in this step of your procurement process. Resources include: - * How to Conduct Accessibility Market Research on vendors using the Vendor Accessibility Resource Center (VARC); - * How to [Request Accessibility Information from Vendors and Contractors][4]; and - * Guidance on [Acquisition for Accessible IT][5] (MS-Word, September 2015) +- How to Conduct Accessibility Market Research on vendors using the Vendor Accessibility Resource Center (VARC); +- How to [Request Accessibility Information from Vendors and Contractors][4]; and +- Guidance on [Acquisition for Accessible IT][5] (MS-Word, September 2015) ### 2 Include clear accessibility requirements in your solicitations When writing solicitations and procurement documents, clearly define your accessibility and usability requirements. Resources include: - * [How to Define Accessibility Provisions, Clauses, and Acceptance Criteria][6]; - * [Revised 508 Standards Applicability Checklist][7] (MS-Word, April 2018) - Use this checklist to document your accessibility requirements for ICT items - * [Applicable 508 Standards and Exceptions Chart][8], a sample template for reporting standards and exceptions in solicitations. +- [How to Define Accessibility Provisions, Clauses, and Acceptance Criteria][6]; +- [Revised 508 Standards Applicability Checklist][7] (MS-Word, April 2018) - Use this checklist to document your accessibility requirements for ICT items +- [Applicable 508 Standards and Exceptions Chart][8], a sample template for reporting standards and exceptions in solicitations. -Additionally, the [Partnership on Employment and Accessible Technology][9] (PEAT) hosts a one-stop shop to help employers and purchasing teams build accessibility and usability into their IT procurement processes. [BuyIT!][10] details eight steps in the planning, solicitation and post-award phases to ensure that employers have clear requirements. Communicate these requirements to vendors to ensure your organization buys the solution that’s most accessible for all. +Additionally, the [Partnership on Employment and Accessible Technology][9] (PEAT) hosts a one-stop shop to help employers and purchasing teams build accessibility and usability into their IT procurement processes. This is a great guide will be updated. [BuyIT!][10] details eight steps in the planning, solicitation and post-award phases to ensure that employers have clear requirements. Communicate these requirements to vendors to ensure your organization buys the solution that's most accessible for all. - * Planning - * [Step 1: Setting Procurement Priorities][11] - * [Step 2: Preparing to Buy][12] +- Planning - * Solicitation - * [Step 3: Issuing Your Solicitation][13] - * [Step 4: Evaluating Proposals & VPATs™][14] - * ​Post-Award - * [Step 5: Negotiating Contracts][15] - * [Step 6: Testing & Validation][16] - * [Step 7: Managing Performance & Relationships][17] - * [Step 8: Reviewing & Learning][18] + - [Step 1: Setting Procurement Priorities][11] + - [Step 2: Preparing to Buy][12] -PEAT also provides some useful tips on [how to communicate with vendors][19] about accessible technology, to help solidify your commitment to accessibility and build collaborative relationships with vendors. +- Solicitation + + - [Step 3: Issuing Your Solicitation][13] + - [Step 4: Evaluating Proposals & ACRs][14] + +- ​Post-Award + + - [Step 5: Negotiating Contracts][15] + - [Step 6: Testing & Validation][16] + - [Step 7: Managing Performance & Relationships][17] + - [Step 8: Reviewing & Learning][18] + +PEAT also provides some useful tips on [how to communicate with vendors][19] about accessible technology, to help solidify your commitment to accessibility and build collaborative relationships with vendors. In addition to these resources PEAT provides about procurement with accessibility, OpenACR is a new initiative which is yet to be incorporated. ## Accessible IT is More than Compliance -For agencies, being “accessible” should be more than adhering to standards. To ensure you’re buying the most accessible solution and achieving your accessibility goals, you must research products and know how to communicate your requirements to vendors. +For agencies, being "accessible" should be more than adhering to standards. To ensure you're buying the most accessible solution and achieving your accessibility goals, you must research products and know how to communicate your requirements to vendors. CIOs and CAOs -- make this easier by committing to accessibility and usability in your digital strategy, and embed this mindset into your procurement process. -For more information, contact - -  - - [1]: https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities/article-2-definitions.html - [2]: https://www.recode.net/2017/9/1/16236506/tech-amazon-apple-gdp-spending-productivity - [3]: {{site.baseurl}}/ - [4]: {{site.baseurl}}/buy/request-accessibility-information - [5]: https://assets.section508.gov/files/Guidance-on-Acquisition-for-Accessible-EIT-20150921.docx - [6]: {{site.baseurl}}/buy/define-accessibility-criteria - [7]: https://assets.section508.gov/files/Revised%20508%20Standards%20Applicability%20Checklist%20%287%29.docx - [8]: {{site.baseurl}}/buy/standards-exceptions - [9]: https://www.peatworks.org/ - [10]: http://www.peatworks.org/Buy-IT - [11]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-1-setting-procurement-priorities/ - [12]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-2-preparing-to-buy/ - [13]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-3-issuing-your-solicitation/ - [14]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-4-evaluating-proposals-vpats/ - [15]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-5-negotiating-contracts/ - [16]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-6-testing-validation/ - [17]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-7-managing-performance-relationships/ - [18]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-8-reviewing-learning/ - [19]: https://www.peatworks.org/communication-matters-how-to-talk-to-technology-providers-about-accessibility/ +For more information, contact [section.508@gsa.gov](mailto:section.508@gsa.gov) + +[1]: https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities/article-2-definitions.html +[10]: http://www.peatworks.org/Buy-IT +[11]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-1-setting-procurement-priorities/ +[12]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-2-preparing-to-buy/ +[13]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-3-issuing-your-solicitation/ +[14]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-4-evaluating-proposals-vpats/ +[15]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-5-negotiating-contracts/ +[16]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-6-testing-validation/ +[17]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-7-managing-performance-relationships/ +[18]: https://www.peatworks.org/digital-accessibility-toolkits/buy-it/step-8-reviewing-learning/ +[19]: https://www.peatworks.org/communication-matters-how-to-talk-to-technology-providers-about-accessibility/ +[2]: https://www.recode.net/2017/9/1/16236506/tech-amazon-apple-gdp-spending-productivity +[3]: {{site.baseurl}}/ +[4]: {{site.baseurl}}/buy/request-accessibility-information +[5]: https://assets.section508.gov/files/Guidance-on-Acquisition-for-Accessible-EIT-20150921.docx +[6]: {{site.baseurl}}/buy/define-accessibility-criteria +[7]: https://assets.section508.gov/files/Revised%20508%20Standards%20Applicability%20Checklist%20%287%29.docx +[8]: {{site.baseurl}}/buy/standards-exceptions +[9]: https://www.peatworks.org/ diff --git a/_posts/2022-03-08-blog-2022-OpenACR.md b/_posts/2022-03-08-blog-2022-OpenACR.md new file mode 100644 index 000000000..26edf5714 --- /dev/null +++ b/_posts/2022-03-08-blog-2022-OpenACR.md @@ -0,0 +1,14 @@ +--- +layout: post +permalink: blog/introducing-openacr/ +type: article +title: 'Introducing OpenACR' +created: March 8, 2022 +tags: Acquisition Design-and-Develop +description: The GSA is proud to announce OpenACR, the first open source, machine-readable ACR. +--- + +The GSA is proud to announce the launch of [OpenACR](https://github.com/gsa/openacr), the first open source, machine-readable ACR. +OpenACR is the result of a one year project to build an open document standard for OpenACR, create an editor to support the creation of the machine-readable documents, and document the process for the GSA. + +**Reviewed/Updated**: March 2022