Website Accessibility Requirements: Section 508 & WCAG

Website accessibility helps ensure that people with disabilities can access information, navigate digital services, complete forms and interact with online content.

It is also a legal and operational responsibility for many federal agencies, state and local governments, educational institutions, healthcare organizations, government contractors and private businesses.

However, website accessibility requirements can be confusing. Section 508, the Americans with Disabilities Act, Section 504 of the Rehabilitation Act and the Web Content Accessibility Guidelines are related, but they are not interchangeable.

WCAG provides the technical standards used to evaluate accessibility. Federal laws and regulations determine which organizations must follow those standards, which versions apply and when compliance is required.

This guide explains the major website accessibility requirements, how Section 508 and WCAG work together and what organizations should consider when designing, maintaining or migrating a website.

What Are Website Accessibility Requirements?

Website accessibility requirements are technical, legal and organizational standards designed to make websites and digital services usable by people with disabilities.

Accessible websites should support users who may:

• Navigate with a keyboard instead of a mouse
• Use a screen reader
• Enlarge text or zoom the page
• Have low vision or color vision deficiencies
• Be deaf or hard of hearing
• Use voice-control technology
• Have limited mobility
• Have cognitive or learning disabilities
• Use alternative input devices

Accessibility applies to more than the visible design of a website. It can also affect:

• Navigation
• Page templates
• Forms
• Search tools
• Videos
• Images
• PDFs
• Spreadsheets
• Presentations
• Mobile applications
• Authentication systems
• Payment portals
• Third-party integrations
• Internal intranets and employee systems

An accessible website must be designed, developed, written and tested with these different methods of interaction in mind.

Website Accessibility Laws and Standards

Several laws and technical standards may apply to a website depending on the organization that owns it, the services it provides and the funding it receives.

Organizations may be subject to more than one accessibility requirement.

For example, a public university may have obligations under ADA Title II and Section 504. A private healthcare provider may be affected by ADA Title III, HHS funding requirements and state accessibility laws.

What Is Section 508?

Section 508 is part of the Rehabilitation Act of 1973. It requires federal agencies to make their information and communication technology accessible to people with disabilities.

Section 508 applies to technology that federal agencies develop, purchase, maintain or use.

This can include:

• Public websites
• Internal websites
• Intranets
• Software applications
• Electronic documents
• Mobile applications
• Digital forms
• Online training
• Information kiosks
• Telecommunications systems

Federal contractors and vendors may also need to meet Section 508 requirements when providing technology, websites, applications or documents to a federal agency.

The Revised Section 508 Standards incorporate WCAG 2.0 Level A and Level AA requirements. Section 508 also covers certain electronic documents and non-web technologies that may not be addressed by a conventional website audit alone.

Section 508 requirements are already in effect. There is not one future deadline at which federal websites suddenly become subject to the law.

Accessibility should be considered throughout federal technology procurement, website development, content creation and maintenance.

Does Section 508 Apply to Every Website?

No. Section 508 primarily applies to federal agencies and organizations supplying technology to them.

It does not automatically apply to every state government, private business, nonprofit or commercial website.

Other organizations may instead be covered by:

• ADA Title II
• ADA Title III
• Section 504
• State civil rights laws
• State accessibility requirements
• Funding agreements
• Government contracts
• Procurement requirements
• Industry-specific regulations

Although Section 508 may not directly apply, WCAG is frequently used as the technical benchmark for determining whether a website is accessible.

What Is WCAG?

WCAG stands for the Web Content Accessibility Guidelines.

WCAG is developed by the World Wide Web Consortium through its Web Accessibility Initiative. It provides technical success criteria for making websites and digital content more accessible.

WCAG is organized around four principles. Accessible content should be:

1. Perceivable: Users must be able to perceive the information being presented.
2. Operable: Users must be able to navigate and interact with the interface.
3. Understandable: Content and controls must be clear and predictable.
4. Robust: Content must work with browsers, assistive technologies and different devices.

These principles are often abbreviated as POUR.

WCAG Conformance Levels

WCAG includes three levels of conformance.

Level A

Level A addresses fundamental accessibility barriers. A website that does not meet Level A may be impossible for some users to navigate or understand.

Level AA

Level AA addresses the most common and significant accessibility barriers.

Most laws, policies and organizational accessibility standards target Level AA. When an organization refers to “WCAG compliance,” it usually means meeting both Level A and Level AA requirements.

Level AAA

Level AAA contains more advanced accessibility criteria.

It is not generally required for an entire website because some types of content cannot reasonably satisfy every Level AAA criterion. However, individual AAA requirements may still be adopted as organizational best practices.

WCAG 2.0 vs. WCAG 2.1 vs. WCAG 2.2

Different laws and regulations reference different versions of WCAG.

WCAG 2.0

WCAG 2.0 is incorporated into the Revised Section 508 Standards. It remains the formal technical baseline for federal Section 508 compliance.

WCAG 2.1

WCAG 2.1 added criteria addressing mobile accessibility, low vision and users with cognitive or learning disabilities.

WCAG 2.1 Level AA is the standard adopted by the Department of Justice for covered state and local government websites and mobile applications under ADA Title II.

It is also used under the HHS Section 504 accessibility requirements for covered recipients of federal financial assistance.

WCAG 2.2

WCAG 2.2 is the newest version in the WCAG 2 series.

It adds accessibility requirements involving:

• Focus visibility
• Focus not being obscured
• Dragging movements
• Target sizes
• Consistent help
• Redundant data entry
• Accessible authentication

For a new website, redesign or migration, targeting WCAG 2.2 Level AA can provide a more future-focused accessibility foundation, even when the applicable regulation currently references WCAG 2.0 or WCAG 2.1.

WCAG 2.2 was designed to build on the earlier standards. A website that conforms to WCAG 2.2 generally also conforms to WCAG 2.1 and WCAG 2.0.

ADA Title II Website Accessibility Requirements

ADA Title II applies to state and local governments.

The Department of Justice has adopted WCAG 2.1 Level AA as the technical accessibility standard for covered state and local government websites and mobile applications.

Covered organizations may include:

• State agencies
• Counties
• Cities and towns
• Public schools
• School districts
• Public universities
• Public libraries
• Courts
• Police and fire departments
• Transit authorities
• Water districts
• Election offices
• Parks and recreation departments
• Special district governments

The requirements can apply to digital services provided directly by a public entity and to services operated by contractors or third-party vendors on its behalf.

Examples of covered content may include:

• Government website pages
• Public forms
• Permit applications
• Tax documents
• Utility payment portals
• Public meeting materials
• Election information
• Emergency notices
• Employment applications
• Public records
• Mobile applications
• Videos
• PDFs
• Online maps and directories

ADA Title II compliance deadlines

The current compliance deadlines are:

• April 26, 2027: State and local governments serving 50,000 or more people
• April 26, 2028: State and local governments serving fewer than 50,000 people
• April 26, 2028: Special district governments

The deadline determines when covered web content and mobile applications must meet the technical standard. It should not be treated as the date on which an organization begins its accessibility review.

Large government websites can contain thousands of pages, documents, forms and third-party systems. Auditing and remediating those systems may require an extended implementation period.

Section 504 Website Accessibility Requirements

Section 504 prohibits disability discrimination by programs and activities receiving federal financial assistance.

Organizations receiving funding from the Department of Health and Human Services may be required to make covered websites and mobile applications conform to WCAG 2.1 Level AA.

Depending on their funding arrangements, affected organizations may include:

• Hospitals
• Community health centers
• Medical providers
• Nursing facilities
• Behavioral health providers
• Human services organizations
• Public health programs
• Healthcare nonprofits
• Other HHS funding recipients

Current HHS compliance deadlines include:

• May 11, 2027: Recipients with 15 or more employees
• May 10, 2028: Recipients with fewer than 15 employees

Organizations should consult qualified legal counsel to determine whether a particular funding source, program or digital service is covered.

ADA Title III and Private Business Websites

ADA Title III applies to private businesses and nonprofit organizations that qualify as places of public accommodation.

Examples may include:

• Retailers
• Restaurants
• Hotels
• Medical offices
• Educational organizations
• Entertainment venues
• Financial institutions
• Professional service providers
• Fitness facilities
• Online businesses connected to public-facing goods and services

There is not currently one detailed federal ADA Title III website regulation assigning every private business a specific WCAG version and universal compliance deadline.

However, the Department of Justice has consistently taken the position that the ADA applies to goods and services offered through websites.

Private businesses may also be affected by state laws, contractual requirements, procurement standards and accessibility-related litigation.

For many organizations, WCAG 2.1 Level AA or WCAG 2.2 Level AA serves as the most practical technical benchmark.

Core WCAG Website Requirements

WCAG contains detailed success criteria, but most accessibility projects involve several common areas.

Keyboard Accessibility

Users must be able to access website functionality without using a mouse.

Keyboard users should be able to:

• Navigate menus
• Activate links and buttons
• Complete forms
• Open and close dialogs
• Use tabs and accordions
• Access dropdown menus
• Operate media controls
• Move through interactive content

Keyboard focus should be clearly visible and move in a logical order.

A keyboard user should not become trapped inside a menu, modal or other component.

Accessible Navigation

Navigation should be consistent, predictable and understandable.

Common requirements include:

• Descriptive menu labels
• Logical tab order
• Skip navigation links
• Accessible mobile menus
• Properly labeled landmarks
• Clear breadcrumbs
• Consistent page structure
• Descriptive page titles

Users relying on assistive technology should be able to understand where they are and move efficiently through the website.

Alternative Text for Images

Meaningful images need text alternatives that communicate their purpose or content.

Examples include:

• Informational photographs
• Icons
• Charts
• Diagrams
• Infographics
• Linked images
• Image-based controls

Decorative images should generally be hidden from screen readers so that they do not add unnecessary noise.

Alternative text must be meaningful. Automatically inserting a file name or generic phrase such as “image” does not make an image accessible.

Color Contrast

Text must have sufficient contrast against its background.

WCAG Level AA generally requires:

• A contrast ratio of at least 4.5:1 for normal text
• A contrast ratio of at least 3:1 for large text
• Sufficient contrast for meaningful interface components and graphical objects

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

For example, a form error should not be identified only by turning the field border red. It should also include text or another programmatic indication of the problem.

Heading Structure

Headings should communicate the organization of a page.

A well-structured page typically includes:

• One clear primary heading
• Logical subheadings
• Proper nesting
• Headings that describe their sections

Headings should not be selected only because of their visual size.

Skipping heading levels or using bold paragraphs in place of actual headings can make a page harder to navigate with a screen reader.

Accessible Forms

Forms must provide clear labels, instructions and error handling.

Accessible form requirements may include:

• Programmatically associated labels
• Clear required-field indicators
• Understandable instructions
• Accessible validation
• Error summaries
• Suggestions for correcting errors
• Properly grouped checkboxes and radio buttons
• Keyboard-accessible controls
• Status messages announced to assistive technology

Placeholder text should not be used as the only label for a field.

Links and Buttons

Links and buttons should clearly communicate what they do.

Avoid repeated links such as:

• Click here
• Read more
• Learn more
• View details

When possible, link text should make sense when read outside the surrounding paragraph.

Buttons should be used for actions, while links should generally be used for navigation.

Custom clickable elements should not rely on mouse interaction alone.

Video and Audio Accessibility

Multimedia content may require:

• Synchronized captions
• Transcripts
• Audio descriptions
• Accessible media controls
• Keyboard operation
• Clear identification of audio-only content

Automatically generated captions should be reviewed for accuracy, particularly for names, technical terms and important instructions.

Responsive Design, Reflow and Zoom

Users should be able to enlarge text and zoom the website without losing content or functionality.

Content should remain usable when:

• Text size is increased
• The browser is zoomed
• The website is viewed on a mobile device
• The screen is oriented differently
• A user applies custom text spacing

Users should not be forced to scroll horizontally to read ordinary text at supported viewport sizes.

Accessible Tables

Data tables should use proper HTML structure.

Accessibility requirements can include:

• Table headers
• Associations between headers and data cells
• Captions where helpful
• Logical reading order
• Avoiding tables for visual page layout
• Explanations for complex data relationships

Tables that rely only on visual position can be difficult or impossible for screen-reader users to understand.

Accessible PDFs and Documents

Website accessibility extends beyond HTML pages.

Downloadable content may also need remediation, including:

• PDFs
• Word documents
• Excel spreadsheets
• PowerPoint presentations
• Online publications
• Application forms
• Board meeting materials
• Reports

Accessible documents may require:

• Proper heading tags
• Logical reading order
• Alternative text
• Accessible tables
• Document titles
• Language settings
• Bookmarks
• Tagged lists
• Labeled form fields

Posting an inaccessible PDF on an otherwise accessible website can still prevent users from accessing important information.

Accessible Authentication

Login and authentication systems should not create unnecessary barriers.

Accessibility considerations include:

• Labeled login fields
• Keyboard accessibility
• Clear error messages
• Password manager support
• Alternatives to cognitive function tests
• Accessible multifactor authentication
• Alternatives to inaccessible CAPTCHA tools

WCAG 2.2 includes additional requirements intended to make authentication more accessible to users with cognitive and motor disabilities.

Third-Party Website Services

Organizations frequently rely on outside platforms for:

• Payments
• Scheduling
• Forms
• Maps
• Document viewing
• Job applications
• Event registration
• Learning management
• Customer portals
• Video hosting
• Live chat
• Authentication

Using a third-party vendor does not necessarily remove the organization’s accessibility responsibility.

Public entities in particular should review whether vendor-operated systems are part of the services they provide to the public.

Accessibility should be included in procurement requirements, contracts, testing and vendor evaluations.

Are Accessibility Overlays Enough?

Accessibility overlays and automated remediation tools are often marketed as fast compliance solutions.

These tools may identify or change certain website elements, but they do not replace accessible design, development, content and testing.

An overlay generally cannot reliably determine:

• Whether alternative text is accurate
• Whether headings reflect the page structure
• Whether form instructions are understandable
• Whether keyboard interaction is logical
• Whether a custom application works with a screen reader
• Whether an error message provides enough guidance
• Whether a document has a meaningful reading order

Organizations should not rely on an overlay as their entire accessibility strategy.

Is Automated Accessibility Testing Enough?

Automated scans are useful, but they cannot confirm complete WCAG conformance.

Automated tools can detect issues such as:

• Missing alternative text
• Empty links
• Duplicate IDs
• Missing form labels
• Some contrast problems
• Invalid HTML attributes
• Missing page language

Manual testing is still needed to evaluate areas such as:

• Keyboard usability
• Screen-reader behavior
• Focus management
• Alternative text quality
• Heading logic
• Form instructions
• Dynamic content
• Mobile interactions
• Error recovery
• Third-party tools

A website can receive a high automated score and still contain serious accessibility barriers.

How to Test a Website for Accessibility

A comprehensive accessibility review should combine several testing methods.

Automated testing

Automated tools can efficiently identify recurring technical issues across a large website.

They are especially useful for monitoring templates, detecting regressions and locating pages that need manual review.

Keyboard testing

Every interactive feature should be tested without a mouse.

Testers should review:

• Focus order
• Focus visibility
• Menus
• Forms
• Dialogs
• Tabs
• Accordions
• Search tools
• Carousels
• Media controls

Screen-reader testing

Screen-reader testing helps evaluate semantic structure and interactive behavior.

Common testing combinations include:

• NVDA with Chrome or Firefox
• JAWS with Chrome
• VoiceOver with Safari
• TalkBack on Android

Not every website must be tested with every possible combination, but representative assistive-technology testing is important.

Mobile accessibility testing

Mobile testing should evaluate:

• Touch target sizes
• Screen orientation
• Zoom
• Reflow
• Mobile navigation
• Form controls
• Screen-reader interaction
• Gestures and dragging actions

Document testing

PDFs and other downloadable files should be evaluated separately from web pages.

Document accessibility often requires specialized remediation and quality assurance.

Website Accessibility Is an Ongoing Process

Accessibility is not a one-time project or permanent certification.

Websites constantly change as organizations:

• Add new pages
• Upload documents
• Install plugins
• Replace vendors
• Publish videos
• Redesign components
• Change branding
• Add forms
• Update navigation
• Launch new digital services

An accessible website can become inaccessible when new content or functionality is introduced without appropriate standards and testing.

An ongoing accessibility program should include:

• Documented design standards
• Development requirements
• Content-editor training
• Accessible document templates
• Vendor accessibility requirements
• Regular automated monitoring
• Periodic manual audits
• User feedback procedures
• Regression testing
• Clear ownership and accountability

How to Create a Website Accessibility Plan

Organizations should approach accessibility as a structured program rather than a collection of isolated fixes.

1. Inventory Digital Content

Identify all websites, applications, portals, documents and third-party systems.

The inventory should include:

• Primary websites
• Microsites
• Subdomains
• Intranets
• Mobile apps
• PDFs
• Videos
• Forms
• Payment systems
• Authentication platforms
• Archived content
• Vendor-operated services

2. Audit Representative Content

Review representative templates and important user journeys.

Priority areas may include:

• Public safety
• Healthcare
• Education
• Employment
• Payments
• Benefits
• Elections
• Public records
• Registration
• Contact and support

3. Prioritize Barriers

Accessibility issues should be prioritized based on:

• User impact
• Frequency
• Legal exposure
• Page traffic
• Importance of the service
• Number of affected pages
• Remediation complexity

Fixing a shared navigation or form component may resolve an issue across hundreds of pages.

4. Remediate Templates and Components

Shared components should usually be addressed before individual pages.

Examples include:

• Headers
• Footers
• Menus
• Search forms
• Buttons
• Accordions
• Tabs
• Tables
• Modals
• Carousels
• Alerts
• Calendars

5. Remediate Content and Documents

After shared templates are improved, organizations can address:

• Heading structures
• Link text
• Image descriptions
• Tables
• Videos
• PDFs
• Forms
• Outdated markup
• Duplicate or unnecessary content

6. Validate the Results

Remediation should be followed by manual and automated testing.

Organizations should verify that fixes work in real user scenarios and do not create new barriers.

7. Establish Governance

Accessibility responsibilities should be incorporated into normal operations.

Organizations may need policies covering:

• Design
• Development
• Content publishing
• Document creation
• Procurement
• Vendor selection
• Quality assurance
• User feedback
• Ongoing monitoring

Website Accessibility During a CMS Migration

A content management system migration is an ideal time to improve accessibility.

Older websites often contain:

• Outdated HTML
• Inconsistent headings
• Inaccessible page builders
• Unlabeled forms
• Poor link text
• Missing image descriptions
• Inaccessible documents
• Custom components that do not support keyboards or screen readers

Migrating that content without an accessibility strategy can carry the same problems into the new website.

Accessibility can be built into a migration by:

• Creating accessible templates
• Standardizing heading structures
• Rebuilding forms
• Replacing inaccessible components
• Transforming legacy HTML
• Mapping image alternative text
• Reviewing document libraries
• Testing third-party integrations
• Establishing accessible Gutenberg blocks
• Adding accessibility checks to migration quality assurance

Accessibility should be considered during content mapping, development and migration testing rather than postponed until after launch.

Migrating Inaccessible Websites

In some cases, repairing a legacy website may be less effective than replacing it.

A website migration or redesign may be appropriate when:

• The CMS no longer supports modern accessibility practices
• Templates contain widespread structural problems
• The website relies on inaccessible page-building tools
• Content is inconsistent across thousands of pages
• Third-party systems cannot be remediated
• Editors cannot create accessible content reliably
• The website is already scheduled for redesign or replatforming

A migration allows accessibility to be addressed at the template, component and content-model levels.

The goal should not be to copy inaccessible content into a newer platform. The migration process should improve the structure and usability of the website.

Frequently Asked Questions

Build Accessibility Into Your Website Strategy

Website accessibility is more than a checklist. It affects design systems, content workflows, vendor relationships, documents, development practices and long-term website governance.

Organizations should determine which laws apply, establish an appropriate WCAG target and build accessibility into ongoing website operations.

For organizations planning a redesign or CMS migration, accessibility should be incorporated from the beginning. Addressing accessibility during migration can improve templates, content structure, forms, documents and reusable components before the new website launches.

WordHerd helps organizations migrate complex websites and structured content into modern content management systems. Our migration process can incorporate accessibility considerations throughout content discovery, transformation, development, quality assurance and launch preparation.

By addressing accessibility as part of a broader website strategy, organizations can create a stronger digital foundation and provide a better experience for every user.

This article provides general information and is not legal advice. Organizations should consult qualified legal counsel to determine which accessibility laws and requirements apply to their specific circumstances.