Section 508 concerns access to information and communication technology used by US federal agencies. For a buyer or project team, the practical task is to connect the applicable requirements to the actual system being purchased, developed or maintained. Start with its users and functions, document the requirements, and carry them through evaluation, acceptance and operation.
Establish which requirements apply
The US Access Board's Revised 508 Standards cover ICT developed, procured, maintained or used by federal agencies. Their scope reaches beyond public websites to such things as software, electronic documents and hardware. The standards incorporate WCAG 2.0 Level A and AA criteria where specified, alongside other scoping, hardware, software and support requirements.
Build a short inventory: public interface, staff interface, downloadable output, mobile app, authentication, support documentation and connected third-party service. Identify who performs each task and which functions the agency will actually use. Ask the agency's Section 508 program and acquisition staff to resolve scope and any claimed exception, with the required documentation.
WCAG is a technical standard; Section 508 is a federal legal framework that incorporates particular requirements. Other organizations may have duties under the ADA, Section 504, state law or a contract. Use the applicable authority and edition rather than treating “WCAG,” “ADA” and “508” as interchangeable labels. A voluntary target such as WCAG 2.2 AA can guide additional improvements while the procurement records still identify their exact mandatory baseline.
Make requirements part of the purchase
GSA's accessible procurement guidance places accessibility throughout market research, solicitation, evaluation and contract administration. Translate a general goal into deliverables that can be inspected. For example, specify the supported workflow, relevant standards, evidence to be supplied, test environment, handling of defects and responsibilities for updates.
- Describe the complete service. Include login, account recovery, search, editing, exports and help, as applicable.
- Request matching evidence. Ask for the exact product version, modules, deployment mode and report date.
- Evaluate important tasks. Arrange a demonstration and controlled testing of representative workflows using the intended configuration.
- Define acceptance. State what evidence the agency will review, how discrepancies are handled and who signs off.
- Plan operation. Establish how updates, user reports and unresolved barriers are tracked after delivery.
A third-party component belongs in this conversation even when it is hosted elsewhere. A usable main page does little for a visitor who cannot pass the authentication step that precedes it.
Read a conformance report as evidence
An Accessibility Conformance Report (ACR) describes a product's conformance. A VPAT is a reporting template often used to prepare it. Review the report's scope, testing methods, remarks and limitations. Ask for explanation where a claim is unsupported, ambiguous or concerns a different version.
Useful questions include: Which browsers and assistive technologies were used? Were administrative and learner roles both assessed? Which features have partial support? Can the supplier reproduce a reported barrier in the proposed configuration? Who maintains the evidence when the product changes? Treat a report as an input to evaluation, with verification proportionate to the acquisition.
Document decisions and provide access
Exceptions and determinations such as undue burden or commercial nonavailability have specific conditions in the Revised 508 Standards. They require the responsible agency process; a supplier's preference or a project's tight schedule does not establish one. Where the standards require alternative means of access, plan that access as a real service with an owner, a usable contact route and the ability to meet the identified need.
Keep the evaluation record with the product: requirements, version, report, task tests, decisions, unresolved issues and acceptance evidence. That record helps the next team understand what was assessed and what has changed.
Check the service after acceptance
Retest important journeys after a platform upgrade, a new document template or a change to sign-in. Provide a visible way to report an access problem and connect those reports to the same issue-tracking process used for technical findings. Track completed repairs with retest evidence. A release date, a vendor report and a successful user task are different pieces of information; retaining all three makes later decisions more reliable.