ADA Website Compliance: What Businesses Should Know in 2026

For businesses, the phrase ADA website compliance often arrives at the worst possible moment: a demand letter, a customer complaint, a failed procurement review, or the discovery that a revenue-critical form cannot be completed with a keyboard or screen reader. The natural reaction is to find a fast test, fix the visible errors, and ask whether the site is now “compliant.” That framing is understandable, but technically incomplete.

A website is a changing software product. Templates evolve. Marketing teams add pages. Plugins update. Third-party scheduling, payment, chat, map, and consent tools enter the experience. A clean audit on Tuesday does not control what ships on Friday. The useful business question is therefore not “Can someone certify this site forever?” It is “What evidence shows that our important digital services are accessible now, and what controls will keep them accessible as the site changes?”

After two decades working across search, analytics, conversion strategy, web design, and development, I view accessibility as both a civil-rights responsibility and an engineering-quality discipline. It belongs in the same operating conversation as security, privacy, performance, and conversion reliability. Each requires standards, ownership, testing, defect triage, and continuous maintenance. None can be solved by installing a badge.

What ADA Website Compliance Means in 2026

“ADA compliant website” is common shorthand, but it can create false precision. The Americans with Disabilities Act is a civil-rights law. WCAG is a technical accessibility standard. An automated scanner is a testing aid. An accessibility overlay is a software layer. A conformance report is evidence about a defined scope at a defined time. These are related concepts, not interchangeable ones.

The Department of Justice guidance on web accessibility and the ADA explains that inaccessible web content can deny people with disabilities equal access to information, programs, goods, and services. It also says businesses and state and local governments can choose how to meet their ADA obligations, with WCAG and the federal Section 508 standards serving as useful technical guidance.

For a business, a defensible accessibility program has five properties:

1. Defined scope. The organization knows which websites, subdomains, mobile experiences, documents, media, components, and third-party services customers use.
2. Recognized technical target. Teams build and test against explicit criteria, typically WCAG 2.2 AA for modern web work.
3. Functional evidence. Testing covers complete user tasks, interactive states, responsive behavior, and assistive-technology operation, not just static URLs.
4. Prioritized remediation. Barriers are fixed according to severity, reach, journey criticality, and recurrence rather than whichever scanner count is easiest to reduce.
5. Operational controls. Accessibility is part of design review, coding standards, content publishing, vendor selection, quality assurance, release gates, and feedback handling.

ADA Title III, ADA Title II, and WCAG Are Not the Same Thing

One of the most damaging mistakes in accessibility planning is copying a rule from one legal context into another without identifying who it governs. The 2026 landscape requires a clean distinction between private businesses, public entities, federal agencies, and organizations bound by contracts or state law.

Private businesses and ADA Title III

ADA Title III covers businesses open to the public, referred to as public accommodations, and requires equal access to their goods and services. DOJ’s web guidance states that the ADA applies to the goods, services, privileges, or activities businesses offer on the web. Court approaches to particular website claims and the connection between a website and a physical location have not been uniform, which is one reason a business should not treat a general article as a substitute for legal advice.

DOJ has not established a detailed Title III website rule that says every private business must meet a specific WCAG version by a universal date. That absence does not mean private business websites have no accessibility obligation. It means the legal duty and the technical method should be discussed accurately: Title III supplies the nondiscrimination obligation; WCAG supplies a widely recognized way to define and test accessible web behavior.

State and local governments and ADA Title II

Title II governs state and local government entities. DOJ’s 2024 web and mobile accessibility rule adopted WCAG 2.1 Level AA as the technical standard for covered web content and mobile apps, subject to specified exceptions. In 2026, DOJ issued an interim final rule that changed the compliance dates. The rule became effective April 20, 2026.

• Public entities serving populations of 50,000 or more generally have until April 26, 2027.
• Public entities serving fewer than 50,000 people and special district governments generally have until April 26, 2028.

Those federal dates are important for governments and vendors serving governments. They are not a newly created universal 2026 deadline for every private business website. See DOJ’s Title II rule fact sheet, the 2026 interim final rule, and the small entity compliance guide for the governing details.

Other obligations can raise the floor

Federal ADA analysis may be only one layer. State civil-rights or consumer laws, federal funding requirements, procurement rules, education or healthcare obligations, settlement terms, and customer contracts can impose additional requirements. A vendor may be contractually required to meet WCAG 2.1 AA or WCAG 2.2 AA even when the contract language is more specific than a generally applicable statute.

The operational response is straightforward: maintain an obligations register. For each digital property, record the owning entity, customer type, jurisdictions, public-sector relationships, contractual standard, accessibility target, responsible owner, and review date. This prevents a legal label from becoming an engineering guess.

WCAG 2.2 AA Is the Practical Modern Engineering Target

The Web Content Accessibility Guidelines 2.2 are organized around testable success criteria at Levels A, AA, and AAA. Level AA means satisfying every applicable Level A and Level AA criterion. It does not mean earning an average score or passing most criteria. WCAG 2.2 extends WCAG 2.1 and is designed to be backward compatible, so work that genuinely conforms to 2.2 also addresses the retained 2.1 criteria.

For new business websites and major redesigns, WCAG 2.2 AA is the sensible engineering target because it adds criteria that address real modern interaction problems, including visible and unobscured focus, alternatives to dragging, minimum target sizing, consistent help, redundant entry, and accessible authentication. A contract or regulation may still name WCAG 2.1 AA. Teams should record the legally or contractually required baseline and the internal build target separately.

Conformance applies to full pages and complete processes

A page does not conform if an essential part of it fails. A checkout process does not become accessible because the product page passes. WCAG conformance requirements apply to full pages, and when a page is part of a complete process, all pages in that process must conform at the stated level. A business should therefore test the route from entry to outcome: search, compare, configure, add to cart, create an account, authenticate, pay, confirm, and recover from an error.

Responsive variants also matter. A desktop menu and mobile drawer can expose different focus behavior. A table that works at 1440 pixels can become a two-dimensional trap at 320 CSS pixels. A sticky header can cover focused controls only after zoom. Accessibility is a property of states and interactions, not a property of a screenshot.

The Technical Requirements Businesses Should Prioritize

The full WCAG standard should guide an audit. The table below highlights criteria that frequently affect business websites and revenue-critical tasks. It is a triage map, not a substitute for testing all applicable Level A and AA criteria.

Accessibility is component behavior, not alt text alone

Alternative text receives disproportionate attention because scanners can find missing attributes. Yet many severe failures live in interaction logic: a menu that cannot be opened with a keyboard, an off-screen dialog that retains focus, a form error that is never announced, an unlabeled payment field inside an iframe, or an auto-advancing carousel that cannot be paused. Image alternatives matter. They are one part of a much larger system.

Audit the Customer Journey, Not Just the Page Inventory

An accessibility audit built only from a sitemap will miss the states where customers struggle. The audit scope should combine representative pages, shared components, business-critical processes, content types, responsive variants, and third-party services. W3C’s WCAG-EM methodology provides a useful structure for defining the scope, exploring the target, selecting a representative sample, auditing that sample, and reporting findings.

Start with the routes that create or protect revenue

• Find a product, service, location, provider, event, or piece of support information.
• Open and operate navigation, search, filtering, sorting, tabs, accordions, and carousels.
• Compare pricing, features, availability, specifications, plans, or eligibility.
• Complete lead, contact, quote, application, booking, registration, or account forms.
• Create an account, sign in, complete multifactor authentication, and reset a password.
• Add, configure, review, purchase, pay, and receive confirmation.
• Download, read, sign, or submit a PDF or other document.
• Use chat, maps, calendars, payment fields, video players, consent managers, and embedded third-party tools.
• Recognize, understand, and recover from validation, inventory, payment, or system errors.

For each route, test the default state and the states produced by interaction: expanded, collapsed, selected, checked, disabled, invalid, loading, empty, success, error, timeout, and return visit. Dynamic applications often fail after the first click, while static scans focus on the initial document.

Third-party code is still part of the customer experience

A business may not control the source code of a scheduler, payment gateway, embedded form, review widget, map, or chat tool, but the customer still experiences the barrier on the business’s website. Vendor ownership changes the remediation path, not the impact. Record vendor defects separately, escalate them contractually, provide an accessible alternative route when necessary, and avoid presenting “third party” as if it removes the obligation to help the user complete the task.

Accessible Implementation Patterns That Prevent Expensive Defects

The most reliable accessibility work begins with semantic HTML. The current ARIA in HTML specification emphasizes using native elements and attributes when they provide the required semantics and behavior. ARIA can communicate states and relationships, but it does not add keyboard behavior, focus management, validation logic, or visual design by itself.

Use a real button for an action

A generic element with a click handler is not automatically keyboard operable and does not automatically expose the button role. A native button includes expected semantics and keyboard behavior.

<!-- Fragile: no native role, focus, or keyboard behavior -->
<div class="menu-trigger" onclick="openMenu()">Menu</div>

<!-- Better: native semantics and an explicit state -->
<button type="button"
        class="menu-trigger"
        aria-expanded="false"
        aria-controls="primary-menu">
  Menu
</button>

JavaScript should update aria-expanded when the menu state changes. If the menu is a disclosure navigation, ordinary links and buttons are usually more resilient than implementing the full ARIA menu pattern, which carries desktop-application keyboard expectations.

Give every form field a durable label and usable error

Placeholder text disappears as the user types and often has insufficient contrast. It is not a durable replacement for a label. Error text should identify the problem, be associated with the field, and be announced when appropriate.

<label for="email">Work email</label>
<input id="email"
       name="email"
       type="email"
       autocomplete="email"
       aria-describedby="email-help email-error"
       aria-invalid="true" />
<p id="email-help">We will send the proposal to this address.</p>
<p id="email-error" role="alert">
  Enter an email address in the format name@example.com.
</p>

On submission, move focus to an error summary or the first invalid field according to the form design, preserve the user’s valid entries, and ensure the visual error is not conveyed by color alone. The W3C forms tutorial provides patterns for labels, grouping, instructions, validation, and notifications.

Design focus that remains visible and unobscured

:focus-visible {
  outline: 3px solid #0b63ce;
  outline-offset: 3px;
}

/* Prevent a sticky header from covering anchored or focused content. */
main :is(a, button, input, select, textarea, [tabindex]) {
  scroll-margin-top: 7rem;
}

Do not remove outlines unless a replacement is at least as usable. Test focus against every component background, not only white. Cookie banners, sticky headers, drawers, floating chat buttons, and mobile browser chrome can obscure the focused element even when the CSS outline itself is strong.

Announce dynamic results without stealing focus

<p id="cart-status" role="status" aria-atomic="true"></p>

<script>
  function announceCart(count) {
    document.querySelector('#cart-status').textContent =
      `${count} items in your cart.`;
  }
</script>

A polite status region can announce a cart update, filter result count, form success, or saved setting without moving the user’s focus. Reserve assertive announcements for truly urgent interruptions. Repeated or overly verbose live-region messages can become their own barrier.

Provide a skip link and meaningful page structure

<a class="skip-link" href="#main-content">Skip to main content</a>
<header>...</header>
<nav aria-label="Primary">...</nav>
<main id="main-content" tabindex="-1">...</main>

Use one descriptive page title, a logical heading hierarchy, landmarks that reflect the visible layout, unique link purposes in context, and a skip mechanism for repeated content. Do not add landmarks or ARIA labels merely to satisfy a tool. Too many redundant regions can make screen-reader navigation slower.

Complex components require an interaction contract

Before building a modal, combobox, tabs, carousel, date picker, tree, grid, or drag-and-drop interface, define its keyboard model, focus entry, focus movement, focus return, accessible name, role, states, instructions, announcements, and error behavior. Use the ARIA Authoring Practices Guide as implementation guidance, then test the result. Copying ARIA attributes without the full behavior is often worse than a simpler native control.

Why Automated Scans and Accessibility Overlays Are Not Enough

Automated tools are valuable. They can quickly find missing labels, some contrast failures, duplicate IDs, invalid ARIA, missing document language, empty links, and other machine-detectable patterns. They are especially useful in continuous integration because they catch regressions before deployment. But W3C’s guidance on selecting evaluation tools is explicit that tools cannot determine accessibility on their own and require knowledgeable human judgment.

A scanner generally cannot decide whether alternative text communicates the right meaning, whether heading structure matches the content, whether focus order is logical, whether instructions are understandable, whether a control works efficiently with a screen reader, or whether a disabled customer can complete the entire business process. It also may not reach authenticated, personalized, conditional, or post-error states.

A credible accessibility test stack

1. Automated rules. Run one or more reputable rule engines against templates, components, and rendered states. Use the output as leads, not a verdict.
2. Expert manual review. Evaluate applicable WCAG criteria that require interpretation, including semantics, meaning, sequence, instructions, consistency, and error handling.
3. Keyboard-only tasks. Complete the full journey with Tab, Shift+Tab, Enter, Space, arrow keys, Escape, and other documented controls. Verify visible focus and no traps.
4. Screen-reader testing. Use realistic browser and assistive-technology combinations such as NVDA with Firefox or Chrome, JAWS with Chrome, and VoiceOver with Safari, selected according to audience and risk.
5. Zoom, reflow, contrast, and motion. Test 200% and 400% zoom, 320 CSS-pixel reflow, text spacing, high-contrast or forced-colors behavior where relevant, reduced motion, orientation, and responsive states.
6. Disabled-user evaluation. Include people with relevant disabilities in usability research. W3C notes that involving users can reveal usability problems that conformance evaluation alone may not expose.
7. Regression evidence. Turn defects into component tests, acceptance criteria, and repeatable release checks so the same barrier does not return across templates.

What an accessibility audit should deliver

A useful audit is actionable by a product team. It should identify the evaluated scope, standard and conformance level, environment, browser and assistive-technology matrix, sampling method, limitations, steps to reproduce, expected behavior, actual behavior, affected users, screenshots or recordings, code context, responsible owner, severity, and retest status.

Be cautious with reports that contain hundreds of ungrouped URL-level findings. Ten pages generated from the same component do not necessarily represent ten root causes. Good reporting separates instances from defect classes. Fixing the shared navigation component once can resolve the barrier across the site and create a regression test that protects future pages.

What an overlay can and cannot do

An overlay or user-facing accessibility widget may change styles, expose controls, or attempt runtime repairs. It cannot reliably correct every semantic, interaction, content, document, mobile, third-party, or process-level barrier. It also cannot replace source-code remediation, organizational testing, or a responsive feedback process. DOJ’s web guidance warns that automated tools and overlays can be useful but that a clean report does not necessarily mean everything is accessible.

If a business uses an overlay, treat it as one tool in the stack. Do not let it block assistive technologies, alter expected keyboard behavior, create privacy concerns, or obscure the underlying defects. Test the site both with and without it. The long-term objective remains accessible source content and components.

Prioritize Accessibility Remediation by Human and Business Impact

Accessibility backlogs become ineffective when every violation receives the same severity. A missing alternative on a decorative image and an inaccessible payment button are both defects, but they do not create the same immediate harm. Prioritization should combine standards analysis with task impact.

Fix the system before chasing isolated pages

Start with shared shells and components: navigation, header, footer, cookie consent, search, forms, buttons, dialogs, cards, accordions, media players, and checkout. Then address critical templates and content. A component-level fix has a larger accessibility return and a lower regression risk than manually patching dozens of generated pages.

Each ticket should include an accessibility acceptance criterion and a test method. “Fix accessibility” is not actionable. “When the mobile menu opens, keyboard focus moves to the first control, remains within the open dialog, Escape closes it, focus returns to the trigger, the button exposes its expanded state, and background content is not operable” is testable.

A Practical 90-Day ADA Website Accessibility Roadmap

The timeline below assumes a typical marketing or ecommerce website. A large application, multisite portfolio, document library, or complex authentication system may require a longer program. Severe barriers should be fixed as soon as they are confirmed rather than waiting for a roadmap phase.

Days 0-15: Establish ownership and stop new regressions

• Name an executive sponsor and an operational accessibility owner.
• Inventory domains, subdomains, apps, documents, media, and third-party customer tools.
• Map critical customer journeys and high-volume templates.
• Document the required legal or contractual baseline and the internal technical target.
• Add accessible design and code checks to work already in progress.
• Create a public feedback route and an internal escalation process.
• Fix any confirmed keyboard traps, inaccessible forms, payment blockers, authentication failures, or missing critical captions immediately.

Days 16-35: Run the baseline evaluation

• Define a representative sample using pages, components, processes, technologies, and states.
• Run automated checks and expert manual WCAG review.
• Complete keyboard, screen-reader, zoom, reflow, contrast, motion, and responsive testing.
• Include disabled-user evaluation for the most important journeys where feasible.
• Group findings by root cause and affected component.
• Publish a baseline report with assumptions, limitations, severity, owners, and retest rules.

Days 36-65: Remediate the highest-impact systems

• Repair the global shell, design-system components, forms, navigation, dialogs, and critical third-party integrations.
• Correct templates before manually repairing repeated content instances.
• Remediate essential PDFs and create an accessible-document publishing standard.
• Add captions, transcripts, audio-description decisions, and media-player requirements to content operations.
• Retest each fix with the method that exposed the original defect.
• Track accepted exceptions with owner, rationale, alternative access, and expiration date.

Days 66-90: Institutionalize accessibility

• Add accessibility states and annotations to design review.
• Add linting, component tests, automated page checks, and manual release checks to development.
• Train content teams on headings, links, images, tables, documents, and media.
• Add accessibility requirements, evidence, defect response times, and exit rights to vendor procurement.
• Publish an accurate accessibility statement that reflects the current program.
• Set quarterly journey reviews and an annual independent assessment appropriate to risk.

Accessibility Governance: How to Keep the Website Accessible

W3C’s planning and managing guidance treats accessibility as an ongoing organizational activity. That is the correct model. The website will change, so the control system must detect and correct change.

Assign responsibility at each production stage

Build accessibility into the definition of done

A feature is not done merely because its visual design matches the mockup and its mouse interaction works. The definition of done should include semantic structure, accessible name and state, keyboard behavior, visible focus, responsive reflow, contrast, error handling, assistive-technology output, automated checks, and documentation for any exception. The exact list should be component-specific.

Track program health with measures that resist vanity reporting: percentage of critical journeys evaluated, critical defects open by age, median remediation time, regression rate, component coverage, vendor defects by owner, accessibility feedback response time, and percentage of releases that completed required manual checks. Avoid using one scanner score as the executive metric.

Ask vendors questions that expose real capability

• Which WCAG version and conformance level does the product claim, for which exact scope and release?
• Can the vendor provide a current Accessibility Conformance Report based on the VPAT format where appropriate?
• Which criteria are partially supported or not supported, and what customer journeys do those gaps affect?
• Which browsers, devices, keyboard interactions, and assistive technologies were tested?
• Were people with disabilities involved in evaluation?
• How are accessibility defects reported, prioritized, fixed, communicated, and retested?
• Will the contract include accessibility requirements, remediation timeframes, cooperation duties, and an exit path for unresolved barriers?

A polished VPAT is not proof that the implementation works in your environment. Test the actual embedded experience, including authentication, theming, validation, responsive behavior, and handoff between your site and the vendor.

Publish a useful accessibility statement

An accessibility statement should help a person get access, not merely protect the brand. Include the organization’s commitment, target standard, evaluated scope or known limitations, alternative methods for critical services, contact information, expected response process, and the date reviewed. W3C provides an accessibility statement resource and generator that can support this work.

The Business Value of Accessible Web Design

The ethical and legal reasons are sufficient, but accessibility also reflects good management. The CDC reports that more than one in four U.S. adults report a disability. Disability can be permanent, temporary, situational, visible, or non-visible. Customers may navigate without a mouse because of a motor disability, use captions in a noisy room, zoom content because of low vision, rely on clear instructions because of a cognitive disability, or use a screen reader because visual content is unavailable to them.

Accessible systems tend to make ordinary business mechanics more reliable:

• Semantic forms improve label clarity, validation, autofill, and error recovery.
• Keyboard-operable components are often easier to test and less dependent on fragile pointer behavior.
• Captions and transcripts make media usable in more environments and easier to reference.
• Clear headings, link purpose, and information hierarchy improve scanning and comprehension.
• Responsive reflow and target sizing support users on small screens, high zoom, and touch devices.
• Design-system remediation reduces repeated defects and maintenance cost.
• Accessible procurement reduces the chance that a critical vendor becomes an unfixable customer barrier.

Accessibility and SEO overlap, but do not confuse correlation with a ranking factor

Accessibility and search optimization share some healthy engineering practices: descriptive page titles, meaningful headings, crawlable text, semantic structure, useful link text, accurate image context, transcripts, mobile usability, and stable performance. These practices can help search engines understand content and help people use it. That does not justify claiming that WCAG conformance is a direct Google ranking factor or that adding alt text will automatically improve rankings.

The better strategic view is that both disciplines reward websites that communicate clearly and function reliably. Accessibility should be implemented because users need access. Any search benefit is secondary and should be measured honestly.

Accessibility protects conversion data quality

If a lead form cannot be completed by keyboard, analytics will record fewer conversions without explaining why. If a checkout error is not announced, the session may look like ordinary abandonment. If a consent tool traps focus, users may never reach the page. Accessibility defects are invisible failure modes in conversion reporting. Removing them does not guarantee a conversion lift, but it makes the funnel’s observed behavior more representative of customer intent.

W3C’s business case resources organize benefits across innovation, brand, market reach, and risk management. The strongest internal case connects accessibility to the organization’s actual services, customer mix, contracts, product quality, and operating costs rather than promising a universal return percentage.

Common ADA Website Compliance Mistakes

1. Treating a scan as a certification. Automated tools identify some detectable patterns. They do not prove complete functional accessibility.
2. Installing an overlay and closing the project. Runtime tools do not replace accessible source code, content, testing, or customer support.
3. Auditing only the home page. Critical failures often live in menus, filters, forms, authentication, checkout, documents, and third-party tools.
4. Fixing instances instead of components. Repeated page-level patches leave the underlying template or design-system defect intact.
5. Using ARIA before native HTML. ARIA can misrepresent a control and does not add behavior. Start with the native element.
6. Hiding behind third-party ownership. The customer still needs an accessible route through scheduling, payment, chat, maps, and other embedded services.
7. Removing content instead of making it accessible. Deleting useful PDFs, media, or features may deny the same service rather than provide equal access.
8. Claiming perfect compliance without a defined scope. Conformance claims require a version, level, scope, date, method, and evidence.
9. Ignoring disabled-user feedback. A fast, respectful response can restore access and reveal defects that formal testing missed.
10. Running a one-time remediation project with no release controls. Accessibility decays when content, code, and vendors keep changing without checks.

The Practical Recommendation for Businesses

Do not begin by shopping for a badge. Begin by identifying the services customers must be able to use. Set WCAG 2.2 AA as the modern engineering target unless counsel or contract requirements call for a different documented baseline. Evaluate representative pages and complete processes. Fix blockers and shared components first. Provide a feedback path and accessible alternatives while remediation is underway. Then build accessibility into the way the website is changed.

The quality of an accessibility program is visible in its evidence: a defined scope, tested journeys, reproducible defects, accountable owners, verified fixes, disabled-user input, vendor controls, honest public communication, and a declining regression rate. That is more valuable than a momentary score because it tells the business whether people can actually reach the outcome they came for.

Frequently Asked Questions

Sources, Methodology, and Editorial Standard

Last reviewed: July 22, 2026

This guide separates legal scope, technical standards, and practitioner recommendations. Federal statements and dates were checked against current Department of Justice ADA materials. Technical criteria and evaluation guidance were checked against current W3C specifications and Web Accessibility Initiative resources. Business prioritization, the 90-day roadmap, evidence model, and operating recommendations are Interactive Theory frameworks informed by two decades of digital strategy, analytics, UX, and web implementation work.

Editorial limitation: This article does not evaluate a specific organization’s legal exposure, claim that WCAG conformance guarantees ADA compliance, or provide legal advice. Accessibility conformance depends on a defined scope, technology, version, level, date, and evaluation method. Product behavior and legal requirements can change; verify current sources and consult qualified counsel for a specific matter.

• U.S. Department of Justice: ADA Title III
• U.S. Department of Justice: Guidance on Web Accessibility and the ADA
• U.S. Department of Justice: Title II Web and Mobile App Rule Fact Sheet
• U.S. Department of Justice: 2026 Interim Final Rule
• U.S. Department of Justice: Small Entity Compliance Guide
• W3C Recommendation: Web Content Accessibility Guidelines 2.2
• W3C WAI: What Is New in WCAG 2.2
• W3C WAI: WCAG-EM Conformance Evaluation Methodology
• W3C WAI: Selecting Web Accessibility Evaluation Tools
• W3C WAI: Involving Users in Web Accessibility
• W3C WAI: Forms Tutorial
• W3C WAI: Planning and Managing Web Accessibility
• W3C WAI: Developing Organizational Accessibility Policies
• W3C WAI: The Business Case for Digital Accessibility
• W3C Recommendation: ARIA in HTML
• W3C WAI: ARIA Authoring Practices Guide Introduction
• W3C WAI: Developing an Accessibility Statement
• CDC: Disability Impacts All of Us