Section 508

Section 508 of the Rehabilitation Act requires United States federal agencies to
make covered information and communication technology accessible to people with
disabilities.

The requirement applies to ICT that federal agencies develop, procure, maintain
or use. Depending on the context, this can include websites, intranets, software,
electronic documents, multimedia, mobile applications, telecommunications products
and workplace technologies.

Section 508 is not a general law requiring every private website in the United States
to comply. However, private companies may need to address Section 508 when they sell
technology or digital services to federal agencies, deliver work under a federal
contract or support a covered federal system.

What is Section 508?

Section 508 is part of the Rehabilitation Act of 1973. It requires federal agencies
to provide people with disabilities access to information and data that is comparable
to the access available to people without disabilities, unless an applicable exception
or limitation applies.

The law covers both members of the public and federal employees who use agency ICT.
Accessibility therefore matters for public websites, internal systems, training,
documents, software, procurement and workplace tools.

What are the Revised Section 508 Standards?

The U.S. Access Board published revised accessibility standards for ICT in 2017.
Federal agencies began applying the updated requirements in 2018.

The revised standards were designed to modernise the original requirements and
harmonise them with internationally recognised accessibility frameworks.

A central part of the revision was the incorporation by reference of WCAG 2.0
Level A and Level AA success criteria and conformance requirements.

What ICT can be covered?

Section 508 can apply to a broad range of information and communication technology,
including:

• Public federal websites.
• Federal intranets and extranets.
• Web applications and portals.
• Mobile applications.
• Desktop and cloud software.
• Electronic forms.
• PDF, Word, Excel and PowerPoint documents.
• Online training and learning platforms.
• Video, audio and multimedia.
• Telecommunications products.
• Hardware and office equipment.
• Internal employee systems.
• Procured technology and digital services.

The exact requirements depend on the type of ICT, its functionality, how it is used
and whether a specific exception applies.

Who must comply with Section 508?

The direct legal obligation applies to federal departments and agencies.

Section 508 responsibilities may also affect:

• Federal employees who create or publish electronic content.
• Agency procurement and contracting teams.
• Federal developers, designers and content teams.
• Vendors supplying ICT to federal agencies.
• Contractors developing or maintaining federal systems.
• Software and platform providers responding to federal solicitations.
• Consultants performing accessibility testing or remediation.

A private organisation does not become generally subject to Section 508 merely
because it operates a website. Its obligations usually arise through federal
procurement, contracting or delivery of covered ICT.

Who benefits from Section 508?

Section 508 is intended to support comparable access for:

• Federal employees with disabilities.
• Job applicants using federal recruitment systems.
• Members of the public using agency websites and services.
• Contractors and partners accessing federal ICT.
• People using assistive technologies to access federal information.

Accessibility can affect whether users are able to complete forms, receive benefits,
apply for jobs, access public information, complete training or perform workplace
responsibilities.

How WCAG relates to Section 508

The Revised Section 508 Standards incorporate WCAG 2.0 Level A and Level AA success
criteria and conformance requirements for covered web content.

The standards also apply many of those WCAG criteria to non-web electronic content
and software, with specific exceptions and additional requirements depending on the
technology.

Learn more about the
Web Content Accessibility Guidelines.

The four WCAG principles

Section 508 and federal websites

Public-facing federal web content generally needs to conform to the applicable
Revised Section 508 Standards.

Common website requirements include:

• Keyboard-operable navigation and controls.
• Meaningful page titles and heading structure.
• Text alternatives for informative images.
• Sufficient color contrast.
• Accessible forms, labels and error messages.
• Captions and alternatives for multimedia.
• Logical focus order and visible focus.
• Compatibility with assistive technologies.
• Accessible documents offered through the site.

Internal systems and employee technology

Section 508 is not limited to public agency websites. Internal systems used by
federal employees may also be covered.

Examples include:

• Human-resources portals.
• Time-reporting systems.
• Procurement tools.
• Learning-management systems.
• Document repositories.
• Collaboration software.
• Project-management platforms.
• Internal dashboards.
• Authentication and account-management systems.

An employee should not be prevented from performing essential work because a system
cannot be used with a keyboard, screen reader, magnification or another assistive
technology.

Electronic documents

Covered electronic content can include PDFs, word-processing documents,
spreadsheets, presentations and other files used for official agency communication.

Accessible document review may include:

• Document title and language.
• Logical heading structure.
• Correct reading order.
• Alternative text for meaningful images.
• Accessible tables.
• Descriptive links.
• Form-field labels and instructions.
• Sufficient contrast.
• Keyboard-operable interactive content.

A document should not be considered accessible merely because it opens in a common
application or can be visually read.

Multimedia and training

Video, audio and online training may require:

• Accurate captions.
• Audio description where necessary.
• Accessible media-player controls.
• Transcripts when appropriate.
• Keyboard-operable course interactions.
• Accessible quizzes and assessments.
• Content that does not rely only on visual or auditory information.

Software accessibility

Software accessibility involves more than checking visible web pages. Applications
must expose usable names, roles, states and values to assistive technologies and
support expected keyboard interaction.

Relevant areas can include:

• Keyboard access to all functionality.
• Programmatic names and labels.
• Logical focus management.
• Accessible status and error messages.
• Support for platform accessibility APIs.
• User-interface contrast and visual focus.
• Compatibility with screen readers and magnification.

Section 508 and federal procurement

Accessibility should be considered when an agency plans, evaluates, purchases and
accepts ICT.

Procurement activities may involve:

• Identifying which standards apply to the product or service.
• Including accessibility requirements in solicitations.
• Requesting accessibility documentation from vendors.
• Reviewing Accessibility Conformance Reports.
• Testing the product rather than relying only on vendor claims.
• Documenting exceptions and decisions.
• Verifying accessibility before final acceptance.

Accessibility should be addressed before a purchase is completed, not only after
employees or members of the public report barriers.

What is a VPAT or Accessibility Conformance Report?

Vendors often provide a Voluntary Product Accessibility Template, commonly called
a VPAT, to describe how a product supports applicable accessibility criteria.

The completed report is generally referred to as an Accessibility Conformance
Report.

A useful report should:

• Identify the product and version evaluated.
• State the standards included in the assessment.
• Describe the testing methods used.
• Explain whether each criterion is supported.
• Describe known limitations clearly.
• Avoid unsupported claims of complete compliance.
• Be updated when the product changes significantly.

A VPAT is not proof that a product is fully accessible. Agencies may need to review
the evidence, test the product and assess whether it meets the requirements of the
intended use.

Exceptions and limitations

The Revised Section 508 Standards contain specific exceptions and limitations.
Depending on the circumstances, these may include areas such as:

• National-security systems.
• ICT acquired incidental to a contract.
• Certain maintenance or monitoring spaces.
• Undue burden.
• Fundamental alteration.
• Legacy ICT covered by the safe-harbor provision.

Exceptions should not be assumed automatically. Agencies should document the
analysis and determine whether alternative access must be provided.

What is the safe-harbor provision?

Certain existing ICT that complied with the original Section 508 Standards and has
not been altered may continue to be covered by the safe-harbor provision.

When a component or page is altered, the updated portion generally needs to conform
to the Revised Section 508 Standards. Agencies should review the official rules when
determining whether safe harbor applies.

Section 508 testing

Section 508 evaluation should use repeatable methods and should cover the functions
that users need to perform.

Automated testing

Automated tools can identify many technical issues such as missing labels, invalid
markup, contrast failures and structural problems.

Manual testing

Manual review is necessary for areas such as keyboard interaction, focus management,
meaningful alternative text, form instructions and dynamic behavior.

Assistive-technology testing

Important workflows may need to be tested with screen readers, magnification,
speech input or other assistive technologies.

Functional testing

Testing should confirm that users can complete the intended task, not merely that
individual elements pass isolated checks.

Common Section 508 barriers

• Forms without programmatically associated labels.
• Keyboard-inaccessible menus or controls.
• Dialogs with incorrect focus management.
• PDFs without tags or logical reading order.
• Training videos without captions.
• Software controls without accessible names.
• Insufficient text or component contrast.
• Tables without correct headers and associations.
• Dynamic updates that are not announced.
• Vendor products with incomplete accessibility documentation.

How to build a Section 508 compliance workflow

1. Define the ICT scope:
   identify websites, software, documents, training, hardware and services that may
   be covered.
2. Determine applicable standards:
   map the product or content type to the relevant Revised Section 508 requirements.
3. Test representative functionality:
   combine automated, manual, functional and assistive-technology testing.
4. Document findings:
   record the affected component, user impact, criterion and evidence.
5. Assign remediation:
   route issues to development, design, content, procurement or the vendor.
6. Verify corrections:
   retest completed work before closing findings.
7. Review procurement evidence:
   assess VPATs, Accessibility Conformance Reports and product demonstrations.
8. Maintain records:
   retain testing results, exceptions, decisions and verification history.
9. Monitor future changes:
   retest after releases, upgrades and vendor updates.

How vendors can prepare for federal customers

Technology providers seeking federal business should treat accessibility as a
product requirement rather than a documentation exercise.

• Include accessibility in design and development requirements.
• Test each supported product version.
• Correct repeated component-level barriers.
• Maintain an accurate Accessibility Conformance Report.
• Provide clear remediation plans for known limitations.
• Train sales and implementation teams not to overstate compliance.
• Retest after major releases.
• Preserve evidence supporting accessibility claims.

How Pluro supports Section 508 accessibility work

Pluro is an accessibility workflow platform that helps teams organise findings from
detection through verified remediation.

Agencies, vendors and accessibility teams can use Pluro to centralise automated and
manual findings, preserve behavioral evidence, assign responsibilities, support
developers and document verification.

Pluro is not a legal adviser and does not replace formal Section 508 assessment,
procurement review or expert testing. It provides workflow infrastructure for
managing accessibility work across websites, software, documents and teams.

Section 508 checklist

• Identify covered ICT and users.
• Determine which Revised Section 508 requirements apply.
• Use WCAG 2.0 A and AA where incorporated by the standards.
• Test public and internal functionality.
• Review documents, software and multimedia.
• Include accessibility in procurement requirements.
• Evaluate vendor accessibility documentation.
• Document exceptions and alternative access.
• Assign and verify remediation work.
• Retest after product and content changes.

Important notice

This page provides general information and does not constitute legal or procurement
advice. Section 508 applicability can depend on the agency, ICT type, contract,
functionality and applicable exceptions. Review the official standards and obtain
qualified advice for specific procurement or compliance decisions.

Read the official

Section 508 laws and policies
.

Explore the Pluro accessibility scanner
or
start a 14-day free trial
with no credit card required.