Section 508 requirements should be included from the beginning of the ICT procurement lifecycle process and continue through the development and testing lifecycle processes. In doing so, there should be no surprises during or after implementation.
Table of Contents
- Legal Requirements
- Business Needs
- Six Steps for Managing ICT Accessibility in Acquisition
- Learn More
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 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). Refer to the information below for buying accessible products and services, including developing requirements. Reach out to your agency Section 508 Program Manager or to the government-wide IT Accessibility Program if you still have questions.
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 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
- Step 1 - Determine Accessibility Requirements
- Step 2 - Conduct Market Research
- Step 3 - Develop Solicitation Language
- Step 4 - Request Accessibility Information From Vendors
- Step 5 - Evaluate Proposals
- Step 6 - Validate Contractor Compliance
Step 1 - Determine Accessibility 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. 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:
- Determine if the ICT needed for the business is subject to Section 508. If the answer is yes, continue to the next step.
- Determine and document if General Exceptions apply. It is important that any Section 508 exceptions be documented and justified during requirements development. Reference Section E202, 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
- 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 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, 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. Use the 508 Standards and Exceptions Chart & Examples 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.
Step 2 - Conduct Market Research
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.
Market research, done early in the procurement process, provides information about commercial practices that is used to shape the procurement strategy, support and test plans, product description, statement of work, evaluation factors, and contract terms and conditions.
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
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.
- Determine your business need; what functionality do you require?
- 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 (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 (requires OMB MAX ID) and use the Solutions Finder
- Visit GSA’s e-Tools for Purchasing Officers
- Review any existing ACRs or product VPAT TM
- Ask your agency contracting office for help.
- Try to find at least two possible solutions.
- 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.
- 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)). 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.
Step 3 - Develop Solicitation Language
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. 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
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
Step 4 - Request Accessibility Information From Vendors
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).
- 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.
Refer vendors to https://section508.gov/sell for guidance on using ACRs and VPATsTM
Step 5 - Evaluate Proposals
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
- Review the Accessibility Conformance Report (ACR) and/or product VPAT TM to determine how well the product conforms to the Revised 508 Standards. Vendors often post this information on their website, typically on their accessibility or product description page.
- Test for Accessibility - The Revised Section 508 Standards mandates the use of Web Content Accessibility Guidelines (WCAG) 2.0 A & AA criteria for development and testing of software, websites, documents, multimedia, applications and other applicable ICT.
Section 508 Testing Requirements
- As per the FAR (39.2023(b)(3)), testing must be performed regardless of the source, including COTS, open source, or custom-built technology by your agency, a vendor, or another agency to ensure supplies or services meet the applicable accessibility standards.
- While an expert review of Section 508 conformance claims may provide an indication of accessibility, rigorous testing is required to validate these claims. The government reserves the right to request such testing in the pre-solicitation phase, but this testing is typically done in the post-solicitation phase. Agencies should specify by whom the accessibility will be conducted in the solicitation terms and conditions. Will the government do the testing or will the selected contractor be expected to have the testing done by an independent third party?
- In order to validate full conformance, hands-on testing using a repeatable, systematic testing methodology is needed. This may be augmented by informal reviews by Section 508 experts and automated testing throughout the development process to identify potential issues before the technology is ready for full Section 508 conformance testing.
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:
- Automated Testing – There are many automated testing tools available in the marketplace. Consult with the Agency Section 508 Program Manager for available options and best practices. Agencies are encouraged to use them, providing they remain aware of their limitations.
- Manual Testing – Manual testing addresses accessibility issues that must be validated using manual or code review techniques on a page-by-page (module-by-module) basis.
- Trusted Tester - The Trusted Tester Protocol is the standardized approach for manual inspection of Web content for conformance with the Revised Section 508 Standards established by the Department of Homeland Security (DHS). DHS maintains an open-to-all Trusted Tester Certification Program. While the current version focuses on web content only, it is strongly recommended that all ICT products and services be tested by a Certified Section 508 Trusted Tester.
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.
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.
- Micro-Purchases and Section 508 Requirements - 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 - Basic overview of the Federal acquisition process as it relates to procuring accessible ICT.
- Requiring Business Partners to Provide Accessible Documents - Guidance to ensure business partners produce accessible content.
- Accessibility for Teams - Embed accessibility and inclusive design practices in your team’s workflow.
- U.S. Web Design System - A design system to quickly prototype and deploy accessible digital products.
- Market Research - Definition of market research, with an explanation of how to conduct generic market research.
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