What Is 508 Compliance? Requirements, Examples, and How to Achieve It

Section 508 applies primarily to federal agencies in the United States. It requires the information and communication technology they develop, procure, maintain, or use to provide people with disabilities access comparable to that available to people without disabilities.

This can include:

• Public and internal websites
• Web applications
• Software
• Mobile applications
• Electronic documents
• Videos and multimedia
• Computers and telecommunications equipment
• Digital forms
• Information kiosks
• Copiers and multifunction machines
• Online training materials
• Digital services used by federal employees

The requirement affects more than federal government websites. It can also influence private companies, software providers, contractors, and vendors that sell digital products or services to federal agencies.

A business may therefore be asked to demonstrate that its software, website, documents, or technology conforms to the Section 508 standards before it can win or retain a federal contract.

What Is Section 508?

Section 508 is part of the Rehabilitation Act, a federal civil rights law intended to prevent discrimination against people with disabilities.

It requires federal agencies to make their information and communication technology accessible to employees and members of the public with disabilities. The goal is to provide access to information and data that is comparable to the access available to people without disabilities, subject to limited exceptions.

Section 508 applies when federal agencies:

• Develop technology
• Purchase or procure technology
• Maintain technology
• Use technology

The U.S. Access Board explains that covered information and communication technology can include computers, software, telecommunications equipment, websites, electronic documents, information kiosks, printers, copiers, and transaction machines.

The law is supported by technical accessibility standards developed by the U.S. Access Board. These standards define how agencies and technology providers should evaluate whether covered technology is accessible.

What Does 508 Compliance Mean?

508 compliance means that covered information and communication technology satisfies the accessibility requirements applicable under the Revised Section 508 Standards.

In practical terms, digital information and services should be usable by people who may:

• Be blind or have low vision
• Be deaf or hard of hearing
• Have limited mobility
• Be unable to use a mouse
• Have speech disabilities
• Have cognitive or learning disabilities
• Use assistive technologies
• Need enlarged text or stronger contrast
• Navigate using a keyboard
• Use captions, transcripts, or audio descriptions

An accessible website, for example, should allow a person using a screen reader to understand the page structure, identify links and buttons, complete forms, interpret error messages, and access meaningful alternatives for images.

A keyboard user should be able to move through the interface, activate controls, close dialogs, submit forms, and determine which element currently has focus without using a mouse.

A deaf or hard-of-hearing user should have access to captions or an equivalent text alternative for meaningful audio content.

508 compliance is therefore not achieved by adding a single accessibility widget or running one automated scan. It requires accessibility to be considered throughout design, content creation, development, procurement, testing, and maintenance.

Who Must Comply With Section 508?

Section 508 directly applies to federal agencies and the information and communication technology they develop, procure, maintain, or use.

This includes federal departments, agencies, and organizations that provide digital information or services to employees and members of the public.

Private businesses are not automatically covered by Section 508 simply because they operate a website in the United States.

However, private organizations may be affected when they:

• Sell software to a federal agency
• Develop a federal government website
• Provide digital services under a federal contract
• Create electronic documents for an agency
• Supply telecommunications or office equipment
• Offer cloud software used by federal employees
• Respond to a federal procurement request
• Serve as a subcontractor on a federal project

Federal procurement requirements may require vendors to explain how their product satisfies applicable accessibility standards.

As a result, technology providers often need to evaluate accessibility and provide supporting documentation before their product can be purchased by a federal agency.

State and local governments, schools, universities, healthcare organizations, private employers, and commercial websites may also have accessibility responsibilities under other laws or contractual requirements. Those responsibilities should not automatically be described as Section 508 compliance unless Section 508 genuinely applies.

What Is Information and Communication Technology?

Section 508 uses the term information and communication technology, commonly shortened to ICT.

ICT covers technology used to create, convert, duplicate, store, display, transmit, receive, or otherwise manage information and data.

Examples include:

• Websites
• Intranets
• Web portals
• Desktop software
• Cloud applications
• Mobile applications
• Electronic forms
• PDF documents
• Word documents
• Spreadsheets
• Presentations
• Email communications
• Video and audio
• Online courses
• Computers
• Telephones
• Printers
• Copiers
• Self-service kiosks
• Transaction machines
• Digital signage

Section 508 is therefore broader than website accessibility. A federal agency could have an accessible public website while still having inaccessible internal software, employee documents, training videos, or procurement systems.

The U.S. Access Board states that the standards cover ICT developed, procured, maintained, or used by federal agencies and include requirements intended to support people with physical, sensory, and cognitive disabilities.

Section 508 and WCAG

The Web Content Accessibility Guidelines, or WCAG, are technical accessibility guidelines developed by the World Wide Web Consortium.

WCAG provides testable criteria for making web content more accessible to people with visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

The Revised Section 508 Standards incorporate WCAG 2.0 Level A and Level AA success criteria for web content. The standards also apply those criteria to certain non-web electronic documents and software.

This connection is why 508 compliance assessments often include testing against WCAG 2.0 Level A and AA.

WCAG is organized around four accessibility principles:

Perceivable

Information and interface components must be presented in ways users can perceive.

This includes requirements related to:

• Text alternatives for images
• Captions
• Audio descriptions
• Adaptable content
• Color contrast
• Text resizing
• Meaningful visual presentation

Operable

Users must be able to operate the interface.

This includes:

• Keyboard accessibility
• Sufficient time to complete tasks
• Avoiding content that may cause seizures
• Clear navigation
• Visible focus indicators
• Descriptive page titles and headings

Understandable

Information and controls must be understandable.

This includes:

• Predictable navigation
• Clear labels
• Consistent components
• Helpful form instructions
• Error identification
• Error-prevention mechanisms

Robust

Content must work reliably with current and future technologies, including assistive technologies.

This includes using valid structures, accessible names, roles, values, and status messages that can be interpreted by browsers and assistive software.

Although WCAG 2.1 and WCAG 2.2 add further accessibility criteria, the current Revised Section 508 Standards specifically incorporate WCAG 2.0 Level A and AA. Organizations may voluntarily use later WCAG versions to strengthen accessibility, but they should not incorrectly state that Section 508 currently incorporates every WCAG 2.1 or 2.2 criterion.

Section 508 vs. ADA Compliance

Section 508 and the Americans with Disabilities Act are different laws.

Section 508

Section 508 focuses on information and communication technology developed, procured, maintained, or used by federal agencies.

The ADA

The Americans with Disabilities Act is a broader civil rights law addressing discrimination against people with disabilities in areas such as employment, public services, transportation, public accommodations, and telecommunications.

Website and digital accessibility obligations may arise under the ADA, particularly for state and local governments and businesses providing goods or services to the public.

However, “ADA compliant” and “508 compliant” should not be used as interchangeable terms.

A federal agency may have Section 508 obligations. A private retailer may face accessibility obligations under the ADA but may not be directly subject to Section 508. A technology vendor selling to a federal agency may need to meet contractual Section 508 requirements even though it is a private company.

Organizations should determine which law, regulation, contract, or procurement standard applies before selecting the accessibility criteria they will use.

Section 508 vs. WCAG

Section 508 is a U.S. federal legal requirement.

WCAG is a technical accessibility standard developed by the W3C.

Section 508 incorporates selected WCAG criteria, but the two are not identical.

Section 508	WCAG
U.S. federal accessibility law	International technical guidelines
Primarily applies to federal agency ICT	Can be used by any organization
Covers websites, software, documents and hardware	Primarily addresses web and digital content accessibility
Incorporates WCAG 2.0 Level A and AA	Available in versions 2.0, 2.1 and 2.2
Includes procurement and hardware requirements	Does not itself create a legal obligation
May include functional performance criteria	Uses testable accessibility success criteria

Meeting WCAG 2.0 Level AA is an important part of Section 508 conformance for web content, but it may not address every applicable Section 508 requirement.

The product may also need to satisfy requirements related to software, hardware, documentation, support services, interoperability, or functional performance.

Key 508 Compliance Requirements

The requirements that apply depend on the type of ICT being evaluated.

A website will not have the same complete set of requirements as a printer, telecommunications product, electronic document, or desktop application.

However, several accessibility areas appear frequently.

Text alternatives

Meaningful images, icons, charts, and graphical controls should have text alternatives that communicate their purpose or content.

Decorative images should generally be hidden from assistive technologies so they do not create unnecessary noise.

A useful alternative should communicate meaning rather than merely describe appearance.

For example, the alternative text for a chart should communicate the important finding or provide access to the underlying data, rather than simply say “bar chart.”

Keyboard accessibility

Users must be able to operate interactive content without relying on a mouse.

This includes:

• Menus
• Links
• Buttons
• Form fields
• Date pickers
• Tabs
• Modals
• Tooltips
• Dropdowns
• Data tables

Keyboard focus should move in a logical order, remain visible, and not become trapped inside a component.

Captions and media alternatives

Videos with meaningful spoken content should provide synchronized captions.

Audio-only content may require transcripts or another equivalent alternative.

Video content may also require audio descriptions when important visual information is not communicated through the main audio track.

Automatically generated captions should be reviewed because they can misrepresent names, technical terminology, punctuation, or speaker changes.

Color and contrast

Text and meaningful interface elements must have sufficient contrast against their backgrounds.

Color should not be the only method used to communicate meaning.

For example, a required field should not be identified only by red text. A status dashboard should not depend only on green, yellow, and red indicators without labels, icons, patterns, or other identifying information.

Accessible forms

Forms should include:

• Programmatically associated labels
• Clear instructions
• Accessible required-field indicators
• Logical keyboard order
• Understandable error messages
• Suggestions for correcting errors
• Accessible confirmation messages

Placeholder text should not be used as the only label because it may disappear when a user begins typing and may not be communicated reliably.

Headings and structure

Pages and documents should use headings in a meaningful hierarchy.

Lists should be marked as lists. Tables should identify appropriate headers. Landmarks and page regions should be programmatically available where appropriate.

Visual appearance alone is insufficient. A line of large bold text is not necessarily recognized as a heading by a screen reader unless the correct structural markup is used.

Link and button purpose

Links and controls should communicate their purpose.

Repeated vague links such as “click here” or “learn more” can be difficult to understand when read outside the surrounding context.

Buttons should have accessible names that match or clearly describe the action they perform.

Page titles and language

Web pages should have descriptive titles.

The primary language of a page should be identified programmatically. Changes in language within the page may also need to be marked where they affect pronunciation or interpretation.

Accessible documents

PDFs, presentations, spreadsheets, and word-processing documents may require:

• A defined reading order
• Document titles
• Language settings
• Tagged headings
• Proper lists
• Accessible tables
• Alternative text
• Descriptive links
• Sufficient contrast
• Accessible form fields
• Bookmarks for longer documents

A document that looks visually clear may still be inaccessible to someone using a screen reader.

The federal ICT Testing Baseline for Documents provides minimum tests and evaluation guidance agencies can use when assessing non-web electronic documents under Section 508.

Software accessibility

Desktop, mobile, cloud, and web-based applications should be usable with assistive technologies.

Users may need to:

• Navigate without a mouse
• Read controls with a screen reader
• Magnify content
• use speech-input software
• Adjust visual presentation
• Understand system notifications
• Access error messages
• Complete tasks without precise motor movements

Section508.gov states that federal software, whether developed, used, maintained, or procured, must be accessible to people with disabilities.

Status messages

Users of assistive technology should be informed when an important status changes without requiring them to move focus.

Examples include:

• “Form submitted successfully”
• “Three search results found”
• “Item added to cart”
• “Upload failed”
• “Password requirements satisfied”

Documentation and support

Product documentation and support materials should also be accessible.

An accessible application can still create barriers if its user guides, training materials, support portal, or help videos are inaccessible.

What Is a VPAT?

A Voluntary Product Accessibility Template, or VPAT, is a standardized format used by technology vendors to describe how a product conforms to accessibility standards.

When completed, the resulting document is commonly called an Accessibility Conformance Report, or ACR.

An ACR may explain whether each applicable criterion is:

• Supported
• Partially supported
• Not supported
• Not applicable

It should also include remarks explaining the product’s behavior, limitations, testing scope, and known accessibility issues.

Federal buyers may request an ACR when evaluating software or technology.

A VPAT is not:

• A government certification
• Automatic proof of compliance
• A substitute for accessibility testing
• A guarantee that every feature is accessible
• A one-time document that never needs updating

An inaccurate or overly optimistic ACR can create procurement, contractual, and reputational risk.

Organizations should prepare an ACR using evidence from a thorough accessibility evaluation. It should identify limitations honestly and be updated after material product changes or remediation.

Is There an Official 508 Certification?

Section 508 compliance is often discussed as if a federal authority issues a general certification or seal of approval.

That is usually not how the process works.

A product may be tested by internal specialists, consultants, federal agencies, procurement teams, or independent accessibility professionals. The vendor may publish an ACR or other accessibility documentation.

However, passing an automated scan or receiving a certificate from a private testing company does not guarantee complete legal compliance or future accessibility.

Accessibility can change when:

• New features are released
• Components are redesigned
• Content is added
• Documents are replaced
• Third-party integrations change
• Code libraries are updated
• User workflows are modified

508 compliance should therefore be managed as an ongoing process rather than a permanent certification.

Start your 21-day free trial and experience how VComply helps you with your policy management and compliance maturity.

How to Achieve 508 Compliance

1. Determine whether Section 508 applies

Begin by identifying the legal, procurement, and contractual requirements affecting the product or organization.

Ask:

• Is the organization a federal agency?
• Is the technology being developed for a federal agency?
• Will a federal agency procure or use the product?
• Does the contract contain Section 508 requirements?
• Which ICT categories are involved?
• Are any exceptions being considered?
• Which accessibility standards must be tested?

A private company should not claim that every website must comply with Section 508. The applicability assessment should be accurate.

2. Define the scope

Identify the products and content covered by the assessment.

The scope may include:

• Public pages
• Authenticated application pages
• Administrative interfaces
• Mobile apps
• Electronic documents
• Videos
• Support content
• Email templates
• User documentation
• Hardware interfaces
• Third-party components

Include critical user journeys, not only the homepage.

For a software platform, important workflows might include:

• Signing in
• Resetting a password
• Creating a user
• Completing a form
• Uploading a document
• Reviewing a report
• Approving a request
• Exporting data
• Changing account settings
• Contacting support

3. Establish an accessibility standard

Document the technical baseline that teams will use.

For formal Section 508 evaluations, this commonly includes the applicable Revised Section 508 Standards and WCAG 2.0 Level A and AA criteria incorporated by reference.

Organizations may also test against WCAG 2.1 or 2.2 to address newer accessibility needs, provided they remain clear about which criteria are legally required under Section 508 and which are adopted as additional best practices.

4. Assign responsibility

Accessibility should have identifiable owners.

Responsibilities may involve:

• Section 508 program managers
• Procurement teams
• Product managers
• Designers
• Developers
• Content writers
• Document authors
• Quality assurance testers
• Legal teams
• Compliance teams
• Vendor managers
• Executive sponsors

Federal guidance emphasizes the role of Section 508 program management in helping agencies ensure ICT accessibility.

Accessibility fails when everyone assumes another team is responsible.

5. Include accessibility in procurement

Agencies and contractors should define accessibility requirements before selecting a product.

Procurement teams may:

• Identify applicable provisions
• Request an ACR
• Review the vendor’s testing methods
• Ask about known limitations
• Include accessibility in demonstrations
• Test critical workflows
• Establish remediation obligations
• Include accessibility acceptance criteria
• Require updated documentation after releases

Section508.gov provides an Accessibility Requirements Tool to help generate applicable Section 508 requirements for ICT procurements.

An ACR should be reviewed critically rather than accepted without validation.

6. Design accessible interfaces

Accessibility should begin during planning and design.

Designers should consider:

• Color contrast
• Text size
• Keyboard interaction
• Focus states
• Error presentation
• Form labels
• Touch-target size
• Heading hierarchy
• Responsive layouts
• Content order
• Zoom and reflow
• Alternatives for gestures
• Clear language

Retrofitting accessibility after development is usually less efficient than incorporating it into design standards and reusable components.

7. Develop with semantic code

Developers should use native HTML elements whenever possible.

A real button typically provides better built-in accessibility than a generic element made to behave like a button.

Semantic code helps browsers and assistive technologies understand:

• Headings
• Buttons
• Links
• Lists
• Tables
• Forms
• Navigation regions
• Dialogs
• Alerts
• Status messages

Accessible Rich Internet Applications attributes may be useful for complex components, but they should not replace correct native elements unnecessarily.

8. Create accessible content

Content teams should be trained to produce accessible:

• Web pages
• PDFs
• Reports
• Presentations
• Spreadsheets
• Emails
• Images
• Charts
• Videos
• Training materials

Accessibility can be broken by content changes even when the underlying software is accessible.

For example, a content editor can upload an untagged PDF, use vague link text, skip heading levels, add an image without an alternative, or publish a video without captions.

9. Use automated testing

Automated accessibility tools can quickly identify certain problems, including:

• Missing alternative text
• Empty form labels
• Some contrast failures
• Duplicate IDs
• Missing page titles
• Incorrect structural relationships
• Certain ARIA errors

Automated testing is useful for regular scanning and development pipelines.

However, it cannot reliably determine whether:

• Alternative text is meaningful
• Keyboard order is logical
• Error messages are understandable
• A screen-reader experience makes sense
• Captions are accurate
• A workflow is cognitively understandable
• Focus is managed correctly in every interaction

Automated testing should be one layer of a wider evaluation.

10. Perform manual testing

Manual testing should evaluate real interaction and content quality.

It may include:

• Keyboard-only testing
• Screen-reader testing
• Zoom and magnification testing
• Color and contrast review
• Form-error testing
• Document reading-order review
• Caption-quality review
• Mobile accessibility testing
• Speech-input testing
• Cognitive accessibility review

Section508.gov describes the testing lifecycle as beginning with planning and scoping, followed by the use of testing methodologies and tools to identify accessibility defects.

11. Involve people with disabilities

Testing by people with disabilities can reveal barriers that conformance checklists may miss.

Users can help evaluate whether:

• Workflows are practical
• Instructions are understandable
• Navigation is predictable
• Assistive technologies work reliably
• Error recovery is manageable
• Content communicates the intended meaning

Standards-based testing and user testing serve different purposes. Organizations benefit from using both.

12. Prioritize and remediate issues

Accessibility defects should be prioritized based on factors such as:

• User impact
• Frequency
• Workflow importance
• Number of affected users
• Legal or contractual exposure
• Availability of a workaround
• Whether the issue blocks task completion

A missing label on a rarely used optional field may not have the same urgency as an inaccessible login page or a payment form that cannot be completed with a keyboard.

Remediation should address root causes. Fixing one inaccessible button is not enough when the same broken component appears throughout the product.

13. Document conformance

Maintain evidence such as:

• Test plans
• Testing results
• Issue logs
• Remediation records
• Accessibility acceptance criteria
• User-testing findings
• Procurement documentation
• Updated ACRs
• Exception decisions
• Training records
• Release-testing evidence

Documentation should accurately represent the tested version and scope.

14. Monitor accessibility continuously

Accessibility should be integrated into:

• Product requirements
• Design reviews
• Code reviews
• Content publishing
• Procurement
• Quality assurance
• Release management
• Vendor oversight
• Employee training
• Compliance reporting

Recurring scans and periodic manual testing help detect regression.

Common 508 Compliance Mistakes

Relying only on an accessibility overlay

A third-party overlay or accessibility widget generally cannot repair every issue in the underlying code, content, documents, and workflows.

Testing only the homepage

Users need complete journeys to be accessible, including authentication, forms, reports, errors, and account settings.

Relying only on automated tools

Automated tools identify only a portion of accessibility barriers.

Treating a VPAT as certification

An ACR is a disclosure document, not automatic proof that a product is fully accessible.

Ignoring internal content

Section 508 covers more than public websites. Internal software, documents, training, and communications may also be in scope.

Forgetting third-party components

Payment tools, chat systems, embedded videos, document viewers, authentication services, and analytics dashboards can introduce barriers.

Making accessibility a final review

Testing immediately before launch leaves little time to redesign inaccessible components.

Failing to retest

A product that conformed when assessed can become inaccessible after updates.

Benefits of 508 Compliance

Meeting Section 508 requirements supports more than procurement.

It can help organizations:

• Give employees equitable access to workplace technology
• Improve public access to government services
• Reduce barriers in critical digital workflows
• Qualify for federal procurement opportunities
• Improve usability across devices and environments
• Build clearer and more structured content
• Reduce the cost of late accessibility remediation
• Strengthen product quality
• Demonstrate responsible technology governance
• Reduce contractual and compliance risk

Accessibility improvements can benefit users who do not identify as disabled as well.

Captions help people in noisy environments. Keyboard support helps power users and people with temporary injuries. Clear labels and error messages help everyone complete tasks more successfully.

508 Compliance Checklist

Use this checklist as a starting point:

• Determine whether Section 508 applies.
• Identify all covered ICT.
• Document applicable accessibility requirements.
• Assign accessibility owners.
• Include requirements in procurement.
• Review vendor ACRs.
• Test critical user workflows.
• Verify keyboard accessibility.
• Check visible focus indicators.
• Provide meaningful alternative text.
• Caption videos accurately.
• Provide alternatives for audio content.
• Maintain sufficient color contrast.
• Avoid communicating through color alone.
• Use meaningful headings and page titles.
• Label form controls correctly.
• Provide understandable errors.
• Create accessible PDFs and documents.
• Test with screen readers.
• Use automated and manual testing.
• Record and prioritize defects.
• Verify remediation.
• Update accessibility documentation.
• Retest after product changes.
• Train designers, developers, and content creators.
• Monitor accessibility continuously.

Build Accessibility Into the Technology Lifecycle

508 compliance is not simply a website test or a document completed during procurement.

It is an ongoing discipline that should shape how technology is planned, designed, purchased, developed, tested, published, and maintained.

An effective Section 508 program connects:

• Governance
• Procurement
• Product design
• Software development
• Content creation
• Document accessibility
• Testing
• Issue remediation
• Vendor oversight
• Employee training
• Conformance reporting
• Continuous monitoring

Organizations that address accessibility early can prevent barriers instead of repairing them after users encounter problems.

The goal is not merely to pass a test. It is to ensure that employees and members of the public with disabilities can access information, complete tasks, and use digital services with a level of independence comparable to other users.

Frequently Asked Questions (FAQs)

What is 508 compliance in simple terms?

508 compliance means ensuring that covered federal information and communication technology can be accessed and used by people with disabilities in accordance with Section 508 of the Rehabilitation Act.

Does Section 508 apply to every website?

No. Section 508 applies primarily to information and communication technology developed, procured, maintained, or used by federal agencies. Other organizations may have accessibility duties under different laws, contracts, or procurement requirements.

Do federal contractors need to comply with Section 508?

Federal contractors and technology vendors may need to satisfy Section 508 requirements when providing ICT to a federal agency. The exact requirements depend on the contract, procurement, technology, and applicable standards.

Is WCAG 2.1 required for Section 508 compliance?

The Revised Section 508 Standards incorporate WCAG 2.0 Level A and AA. WCAG 2.1 or 2.2 may be adopted as an additional accessibility baseline, but organizations should distinguish those later recommendations from the criteria formally incorporated into Section 508.

Is a VPAT required?

A federal buyer may request an Accessibility Conformance Report based on the VPAT format. The specific procurement determines what documentation must be supplied.

Can automated software prove 508 compliance?

No. Automated tools are useful but cannot evaluate every accessibility requirement. Manual testing and human judgment are necessary.

Are PDFs covered by Section 508?

Electronic documents used or provided by federal agencies may be covered. PDFs may need proper tags, reading order, headings, alternatives, table structures, language settings, and accessible forms.

Does 508 compliance require captions?

Meaningful prerecorded audio in video content generally requires synchronized captions under applicable accessibility criteria. Other media alternatives may also be required depending on the content.

How often should 508 compliance be tested?

Accessibility should be tested during development, before release, after significant changes, and periodically after launch. High-use and high-risk systems may require more frequent testing.

Is there a penalty for Section 508 noncompliance?

Section 508 includes enforcement mechanisms for federal ICT procurement and accessibility complaints. Noncompliance can also lead to procurement delays, contract issues, remediation costs, complaints, and reduced access for users with disabilities.