Government accessibility, standards and Ruby

Understand government accessibility requirements, choose practical design systems and Rails libraries, and retain evidence from automated and manual testing.

A public service works when people can complete its tasks: understand a notice, apply for assistance, correct an answer and receive a decision. Accessibility belongs in that workflow from the first design. A component library helps, but the team remains responsible for the assembled service.

Published and research checked 16 October 2026. Technical and regulatory overview; not an individual legal-compliance determination.

Start with jurisdiction, scope and version

Write down the public entity, product, applicable jurisdiction, contract and assessment boundary. Then identify the exact technical standard and version. A WCAG assessment, a procurement report and a conclusion about legal compliance answer different questions. This guide covers major US federal and state/local requirements, with limited UK and EU context; it does not survey every state law, national implementation or contract.

US federal agencies: Section 508

Section 508 applies to information and communication technology that federal agencies develop, procure, maintain or use. Suppliers should read the acquisition’s actual requirements; Section 508 is not a universal rule for every private website.

The Revised 508 Standards incorporate WCAG 2.0 Level A and AA for covered content and software. Public-facing electronic content and specified official internal communications are included. There are also requirements for areas such as hardware, interoperability, authoring tools and support. Assess scoping and exceptions explicitly: a passing website scan does not address this entire standard.

US state and local government: ADA Title II

The DOJ web and mobile rule specifies WCAG 2.1 Level AA for covered state and local government services, including services supplied through contractual or licensing arrangements. Public schools, courts and public universities are examples of covered settings.

The deadlines changed in 2026. The interim final rule effective 20 April 2026 extended them:

• Public entities with populations of 50,000 or more, except special district governments: 26 April 2027.
• Entities below 50,000 and special district governments: 26 April 2028.

Use the rule’s population calculation, not a count of staff or website visitors. Limited exceptions cover specified archived material, preexisting documents, independent third-party posts, individualized secured documents and older social-media posts. Old application forms still used to obtain services are not automatically exempt. Nor is a contractor’s application exempt simply because another company supplies it. Consult the current regulation before applying an exception. Broader duties such as effective communication remain. This Title II timetable is not a statement about private businesses under Title III.

UK and EU: distinguish publication from legal reference

UK public-sector guidance directs covered organisations to WCAG 2.2 AA and an accessibility statement. Applicable exemptions and disproportionate-burden assessments need care; Equality Act duties, or Northern Ireland’s Disability Discrimination Act duties, also matter.

For EU public-sector websites and apps, the Web Accessibility Directive operates through national implementation and harmonised standards. EN 301 549 includes requirements beyond WCAG. A version must be formally referenced in the EU Official Journal to become harmonised for this purpose; a new publication alone does not change that reference. See the Commission’s explanation.

AccessibleEU reports that EN 301 549 v4.1.1 was published in September 2026 and adopts WCAG 2.2, while v3.2.1 remains the referenced WAD version pending formal citation. The Commission overview reviewed here still lists v3.2.1 and predates that publication. Recheck Official Journal citations for a procurement decision; do not label the older version the newest published edition.

Choose an engineering target without rewriting the law

For new web work, our recommendation is WCAG 2.2 AA, with a separate mapping to the version named in the contract or law. Its additions address needs including visible focus when content overlaps, alternatives to dragging, target size, repeated data entry and accessible authentication. The obsolete Parsing criterion was removed. Keep versioned checklists instead of silently replacing a 2.0 or 2.1 assessment with a 2.2 score.

Translate criteria into tasks. Can a keyboard user finish the application? Can someone enlarge text and still read the decision? Does a failed upload explain how to recover? Can a person use a password manager and paste a verification code? Include notices, downloads, emails and support channels in the service inventory, even when different requirements apply to different formats.

Choose a design system and keep its behavior

USWDS for US government services

The U.S. Web Design System provides HTML patterns, CSS/Sass and JavaScript through @uswds/uswds and compiled assets. Rails, Sinatra and Rack can render its markup without a special backend adapter. Follow the component’s structure and initialization instructions as well as its visual styling. USWDS accessibility guidance calls for testing the implementation.

Our Rails recommendation is a small set of ERB partials or ViewComponents: page shell, text field, radio group, error summary and confirmation. Keep the rendered markup easy to compare with upstream examples. Pin dependencies, review release notes and retest local wrappers when updating. This is an architectural recommendation, not a claim that an official USWDS Rails gem certifies the result.

USWDS is predominantly public-domain/CC0 work, with separately licensed assets. Read its license and asset notices for the files you distribute; do not assume every bundled font has the same terms.

GOV.UK patterns and Ruby libraries

GOV.UK Frontend implements the GOV.UK Design System. Independent projects should follow its unbranded implementation guidance rather than implying official government identity.

• govuk_design_system_formbuilder generates Rails form markup, connects hints and errors to fields and handles validation messages. It still needs GOV.UK Frontend assets.
• govuk-components uses ViewComponent for non-form interface elements and complements the form builder.

These two Ruby packages use MIT licenses. Check the selected release’s Ruby, Rails, ViewComponent and frontend compatibility before installation. Test their rendered output in your application; package choice does not settle wording, focus behavior or task usability.

Make the failed submission a complete screen

Give fields persistent labels and groups a fieldset and legend. Associate help and errors programmatically. Keep the person’s answers after validation fails. Placeholder text should not carry essential instructions. Prefer a short question with a clear reason for collecting sensitive information.

The GOV.UK error-summary pattern calls for a summary even for one error, focus on that summary, links to affected answers, consistent summary and inline wording, and an “Error:” prefix in the document title. Follow initialization instructions so the focus behavior runs. An error color alone communicates too little.

For a Ruby service, begin with server-rendered HTML and ordinary form submission, then add enhancements. When using Turbo, test validation responses, frame replacements, back navigation and component reinitialization. Check the document title, focus destination and announcement after every meaningful update. An asynchronous status message should explain what changed without repeatedly interrupting the person. Use conventional navigation where it provides the more dependable interaction.

Focus and announcement are different interactions

The GOV.UK error summary above receives focus after failed submission. A standalone dynamic APG alert announces feedback without moving focus. Follow the chosen component as a whole; this distinction is not a reason to remove GOV.UK's documented nested alert markup.

If adopting ARIA19, create the empty announcement container before inserting errors and test repeated invalid submissions. Its example uses aria-atomic="true". Our Rails/Turbo integration recommendation is to retain that container across the relevant partial update, or verify the replacement strategy with supported assistive technologies. A newly populated alert is not proof that speech occurred.

For an in-place save or result count, ARIA22 uses a pre-existing role="status" container with polite semantics. Include meaningful context such as “3 matching applications”; explicit aria-atomic="true" helps where the whole message matters. Avoid competing announcements for the same event. These are informative techniques, not the only conforming implementations.

Application checks—proposed, not run: test first and repeated invalid submissions, partial correction, full navigation, Turbo updates and Back/Forward restoration. Assert summary-link targets, intended focus, stable containers, and removal of stale or duplicate errors. Separately record actual screen-reader speech and focus on supported browser/OS/AT combinations, including iOS VoiceOver where supported. DOM assertions and an automated scan cannot establish what was spoken.

Combine automated checks with manual assessment

Keep the project’s existing test framework. For a Rails team using Minitest, retain system tests for complete journeys; there is no need to adopt RSpec merely to add an accessibility scanner. A browser scan can run alongside those tests and preserve its results as a separate check.

• @axe-core/playwright integrates axe checks with Playwright. Scan meaningful states after opening a menu, revealing a conditional question and submitting invalid data. Automated checks cannot establish complete conformance.
• For an existing RSpec/Capybara project, Deque’s axe-core-rspec and Ruby browser integrations provide a compatible route. Choose the integration matching the actual browser driver.
• Accessibility Insights for Web combines automated checks with guided keyboard and manual assessment. Its overview describes WCAG 2.1 AA coverage; account separately for additional 2.2 criteria.

These are tool options, not a stack to install in full. Record the scanner version, rules selected, browser and tested states. Review findings rather than weakening rules to get a green build. Keep exceptions specific, owned and time-limited.

Manual release checks should include keyboard-only completion, visible focus, zoom and reflow, meaningful reading order and screen-reader use. A practical starting matrix is NVDA with a supported Windows browser and VoiceOver with Safari on Apple devices; expand it for actual users. Include disabled participants in service research. The GOV.UK assistive-technology testing guide offers a fuller approach. Store reproduction steps and actual outcomes, including failures, so another tester can repeat them.

Procure and release with evidence

A VPAT is a template. An Accessibility Conformance Report, often produced from that template, records the assessment of a particular product. Inspect the version, scope, criteria, methods and explanations. A report about a library is not a report about the service built with it. GSA’s ACR/VPAT guidance explains the distinction.

For a concrete release, retain the following evidence:

1. The applicable standards and versions, covered journeys and document inventory.
2. The component and dependency versions, plus the local changes made to their behavior.
3. Automated results and manual findings with operating system, browser and assistive-technology versions.
4. Open defects, user impact, remediation owners and retest results.
5. An accurate accessibility statement and a usable way to report problems or request assistance.

Review this record after changes to forms, navigation, authentication, document generation or third-party services. Treat a procurement report as dated evidence and keep checking the configured service. No score, library or disclaimer guarantees compliance.

Continue with durable web standards, the browser-first series and our testing guidance. This article recommends a process; it does not claim that a government application or a full accessibility audit was implemented here.