Website Accessibility for RDOs: A Practical Guide for Your Team

Your website connects people to regional plans, public meetings, funding opportunities, transportation information, and community services. Accessibility helps ensure people with disabilities can use those resources—not simply open the homepage.

For regional development organizations, the work extends beyond web development. Staff create documents, communications teams publish updates, procurement teams select platforms, and leadership assigns resources. An effective accessibility effort brings those responsibilities together.

This guide gives your team a practical starting point: what to review, which tools can help, what to ask vendors, and how to organize corrections. Share it with your leadership, content authors, program staff, and web team.

The goal is access: people should be able to find information, understand it, and complete important tasks.

Last updated: October 18, 2026. This guide is a planning resource, not legal advice or a determination that a particular organization complies with the ADA. Confirm current requirements and deadlines with the Department of Justice and your legal counsel.

Quick jump menu

• 1. Standards and deadlines
• 2. Ownership and inventory
• 3. Automated and manual testing
• 4. Four common areas to review
• 5. PDFs and other documents
• 6. VPATs, ACRs, and vendor questions
• 7. Prioritizing corrections
• 8. A request to send your web team
• 9. Ongoing accessibility practices
• 10. Your first team meeting checklist
• Tools and resources

1. Know the standard—and confirm your deadline

The U.S. Department of Justice’s ADA Title II web accessibility rule establishes WCAG 2.1 Level AA as the technical standard for covered state and local government websites and mobile applications. WCAG stands for Web Content Accessibility Guidelines. Level AA includes the applicable Level A and Level AA requirements.

As of October 2026, DOJ lists these compliance dates:

Public entity classification	Compliance date
State or local governments with populations of 50,000 or more, other than special district governments	April 26, 2027
State or local governments with populations below 50,000	April 26, 2028
Special district governments	April 26, 2028

Do not assume your RDO’s classification or deadline based on its name, employee count, or the number of people it serves. Confirm the applicable classification and population calculation with your ADA coordinator or legal counsel.

Existing ADA obligations—including effective communication and equal opportunity to access public services—apply before these technical-standard deadlines.

Start with the official guidance

• DOJ: First Steps Toward Complying with the Web Accessibility Rule | New Window
• DOJ: Small Entity Compliance Guide | New Window

2. Assign an owner and inventory what you provide

Before buying software or requesting a quote, identify who will coordinate the effort. That person does not need to make every correction. Their job is to keep the inventory, responsibilities, vendor communications, and remediation plan moving.

Recommended responsibilities

• Leadership: assign an accountable owner, resources, and deadlines.
• ADA coordinator or legal counsel: confirm obligations, classification, exceptions, and response procedures.
• Communications and content authors: maintain accessible pages, images, documents, and media.
• Web team or agency: correct templates, navigation, forms, and underlying code.
• Procurement: request accessibility evidence and address requirements in purchasing.
• Program staff: identify essential tasks and help test whether their services work.

Build a shared inventory

Include more than the main website:

• Program websites, microsites, and subdomains.
• PDFs, Word documents, spreadsheets, and presentations.
• Forms, applications, registration systems, and payment tools.
• Calendars, maps, embedded widgets, and portals.
• Videos and audio recordings.
• Mobile applications and vendor-provided services.
• Content your organization posts on social platforms.

For each item, record its owner, purpose, location, vendor, current use, and whether it supports an essential public task.

Suggested inventory columns:

• Resource name or URL.
• Purpose and essential task.
• Internal owner and vendor.
• Evaluation status.
• Next action and target date.

3. Use automated tools—but do not stop there

Automated testing can identify useful findings, including some missing text alternatives, contrast problems, and code-related issues. It cannot evaluate every aspect of accessibility. A clean automated report is not proof that a website meets WCAG.

Start with WAVE

WAVE Web Accessibility Evaluation Tools | New Window can evaluate a public page and display findings in context. Browser extensions are also available for testing directly in Chrome, Firefox, and Edge, including password-protected or dynamic pages.

Use the findings to start a conversation with your web team—not to generate a single “compliant or noncompliant” verdict.

Request a scoped manual evaluation

Ask the evaluator to include representative templates, shared components, essential workflows, and relevant interactive states.

For an RDO, suggested tasks might include:

• Find the next public meeting and its materials.
• Read a regional plan.
• Submit a public comment.
• Complete a program application.
• Register for a workshop.
• Locate contact information and request assistance.

Ask for findings that explain the barrier, affected users, relevant requirement, and expected correction.

4. Review four common areas

These categories provide a starting point. They are not a complete WCAG checklist.

Keyboard navigation

Can someone operate the website without a mouse?

Ask your web team to verify:

• Links, menus, buttons, and forms can be reached and operated.
• Keyboard focus is visible.
• Focus moves in a meaningful order.
• Dialogs and menus can be operated and exited.
• Users can bypass repeated content.

For a preliminary check, use Tab and Shift + Tab to move between controls. Operate them using the appropriate keys; different controls may require Enter, Space, arrow keys, or Escape.

Record what happened rather than assuming every unexpected interaction is a verified failure.

Visuals and color contrast

Check whether text and important interface elements remain distinguishable from their backgrounds.

Common Level AA contrast thresholds include:

• Normal text: at least 4.5:1.
• Qualifying large text: at least 3:1.
• Required visual information in interface components and graphics: generally at least 3:1, subject to the applicable exceptions.

Large text generally means at least 18 points, or 14 points bold. A heading does not qualify simply because it is a heading.

Use the WebAIM Contrast Checker | New Window to compare foreground and background colors. It reports results for normal text, large text, and graphical objects or interface components.

Ask your web team to check more than the default appearance: hover states, keyboard focus, error messages, and text over images may require separate attention.

Code structure, labels, and image alternatives

A page’s visual appearance does not reveal everything assistive technology needs.

Ask your team to review:

• Meaningful heading structure.
• Appropriate labels for form controls.
• Accessible names for icon-only buttons.
• Text alternatives for informative images.
• Appropriate handling of decorative images.
• Structured tables with correctly identified headers.

For image alternatives, describe the relevant purpose—not every visible detail. If accurate and useful in context, an alternative might read:

Participants reviewing a regional transit map.

Avoid guessing people’s identities, occupations, or activities. Decorative images generally need an empty alternative rather than a description that adds unnecessary noise.

Use the W3C accessibility tutorials | New Window for implementation guidance on images, forms, tables, and page structure.

Media, motion, and user control

Include video and audio in the evaluation scope. Ask about:

• Captions for relevant video audio.
• Alternatives for audio-only content.
• Audio description where required for important visual information.
• Controls for applicable moving or auto-updating content.
• Time limits and flashing content.

A caption file is not automatically an accurate caption file. Include a human review of names, terminology, timing, and meaningful sounds in your publishing workflow.

5. Treat documents as part of the website

An accessible webpage can still lead to an inaccessible application, plan, or meeting packet.

Start by identifying documents people currently need to access programs, understand services, or participate in public activities. Evaluate those documents rather than assuming that opening successfully in a PDF reader means they are accessible.

Recommended document workflow

1. Create accessible source documents using meaningful headings, lists, tables, and image alternatives.
2. Run the authoring tool’s accessibility checks.
3. Export using accessibility-preserving settings.
4. Review the exported file’s structure and reading order.
5. Test important content with appropriate assistive technology.
6. Correct the source so future versions do not repeat the same problems.

Do not assume old PDFs are exempt

The rule has separate exceptions for archived web content and preexisting conventional electronic documents. Each has conditions.

For example, the preexisting-document exception does not cover documents currently used to apply for, access, or participate in a public entity’s services, programs, or activities. Moving content into a folder called “Archive” does not automatically qualify it for the archived-content exception.

Have the appropriate staff review and document exception decisions. Even when an exception applies, other ADA obligations remain. Review the DOJ guidance on the rule and its exceptions | New Window before excluding documents from your plan.

6. Ask vendors for evidence: VPATs and ACRs

If your organization uses a registration platform, CMS, application portal, or other vendor technology, ask for its current Accessibility Conformance Report.VPAT: Voluntary Product Accessibility TemplateThe blank reporting template.ACR: Accessibility Conformance ReportThe completed report for a specific product or service.

Download the templates and instructions from ITI’s official VPAT page | New Window. Select the edition appropriate to the standards and procurement requirements involved.

What to check in an ACR

• The product and version evaluated.
• Report and evaluation dates.
• Standards and conformance levels addressed.
• Evaluation methods.
• Explanations supporting each rating.
• Known limitations.
• A contact for questions.

Ratings can include “Supports,” “Partially Supports,” “Does Not Support,” and “Not Applicable.” Having an ACR does not mean the product meets every requirement. ITI does not approve reports or provide VPAT certification.

Questions to send your vendor

Please provide your current ACR for the product and version we use.

• Does it address WCAG 2.1 Level AA?
• Which configurations, workflows, integrations, or features were evaluated?
• What manual testing was performed?
• Which known limitations could affect our public-facing services?
• What remediation commitments and target dates can you provide?
• How will you notify us of accessibility changes?

Do not assume a platform’s report covers your organization’s content, customizations, or integrations.

For a custom website, an actionable evaluation report may be more immediately useful than an ACR alone. Ask for the deliverables you need to identify, correct, and verify barriers.

Outsourcing does not transfer away a public entity’s accessibility responsibilities. Vendor-provided services supplied on its behalf can still fall within the rule.

7. Prioritize corrections by impact

Limited resources make sequencing important. They do not make unaddressed covered content exempt.

A practical sequence is:

1. Address reported barriers and blocked essential services.
2. Prevent new barriers in current publishing and development.
3. Fix shared components such as navigation, forms, and templates.
4. Correct high-impact pages and current service documents.
5. Continue through the remaining covered content.
6. Verify corrections and maintain the result.

Do not rely on traffic alone. A low-traffic application can still be essential to the person who needs it.

Track work in one place

Use a shared issue log with these fields:

• Location: URL, document, component, or workflow.
• Barrier: what prevents or complicates access.
• Impact: who is affected and which task is affected.
• Requirement: relevant criterion, when verified.
• Owner: person or vendor responsible.
• Correction: expected change.
• Deadline: target completion date.
• Verification: retest result, date, and reviewer.

Close issues after verification—not merely after someone reports that a change was made.

8. Give your web team a clear request

Copy and adapt this project brief:

We are organizing an accessibility evaluation and remediation effort for our website and related public-facing services.

Please propose a scope addressing WCAG 2.1 Level AA, including representative templates, shared components, essential workflows, and relevant interactive states.

Include automated and qualified manual evaluation. Identify which documents, media, vendor tools, and configurations are included or excluded.

Provide actionable findings, remediation responsibilities, estimated costs, a schedule, and a verification process.

Please separate evaluation, report preparation, remediation, document work, vendor coordination, and retesting in your proposal.

Identify any ACR deliverable separately and explain what it will cover.

Include recommendations for staff training and ongoing publishing checks.

9. Make accessibility part of routine work

A one-time evaluation cannot prevent tomorrow’s inaccessible upload or software change.

Recommended ongoing practices:

• Train staff according to their roles.
• Check new pages and documents before publication.
• Include accessibility in procurement and vendor review.
• Evaluate meaningful website changes.
• Combine automated monitoring with periodic manual review.
• Provide an accessible way to report barriers or request assistance.
• Assign responsibility for responding and verifying resolutions.

For content authors, designers, developers, and project managers, the W3C accessibility tutorials | New Window offer practical training organized around common web tasks.

10. Your first team meeting: a working checklist

Use this agenda to turn the guide into an action plan:

• Name the person coordinating the effort.
• Confirm the organization’s applicable requirements and deadline.
• Start the website, document, and vendor inventory.
• Identify essential public tasks.
• Select initial pages and workflows for evaluation.
• Request relevant vendor ACRs.
• Assign owners for content, code, documents, and procurement.
• Obtain a scoped evaluation and remediation proposal.
• Establish an issue log and retesting process.
• Make it easy for the public to report barriers.

The first meeting does not need to solve every problem. It should produce an owner, a defined scope, and scheduled next actions.

Tools and resources

DOJ: First Steps Toward Complying | New WindowA practical starting point for organizing a public entity’s accessibility work.DOJ: Small Entity Compliance Guide | New WindowGuidance on the technical standard, deadlines, exceptions, and related responsibilities.WAVE Web Accessibility Evaluation Tools | New WindowPage-level evaluation and browser extensions to help identify potential accessibility issues.WebAIM Contrast Checker | New WindowCompare foreground and background colors against WCAG contrast thresholds.ITI: VPAT Templates and Instructions | New WindowOfficial templates and guidance for preparing Accessibility Conformance Reports.W3C Web Accessibility Tutorials | New WindowPractical guidance on images, forms, tables, page structure, and other common development tasks.

Back to the top of this guide