Accessible grantmaking: What WCAG 2.2 means in practice

Accessibility compliance can feel like a technical minefield, especially if you are a grant manager who’s focused on running great programs, not reading web standards documentation. Yet the question of whether your grant program is accessible to everyone who needs it is one worth taking seriously.

Grantmaking is about creating opportunity. If the application process itself presents barriers to people with disabilities, that mission is compromised before it even begins.

“Accessibility is universal design: when we design for people with disabilities, we’re also creating better experiences for everyone,” said Rachel Martin, the Good Grants Product Manager and our de facto accessibility champion.

“Think of how captions are helpful if you’re in a noisy environment or good colour contrast when you’re out and about on a sunny day and trying to read a message on your phone. Even dropped kerbs and ramps, designed for people with disabilities, are useful for anyone with wheels, be it a pram, bike or scooter. Universal design makes things better for everyone.”

Good Grants is fully compliant with WCAG 2.2, the current global benchmark for web accessibility. This article explains what that standard actually means, why it matters for your program and what you can do in practice as a grant manager.

What is WCAG 2.2?

WCAG (Web Content Accessibility Guidelines) is the international standard for making digital content accessible to people with disabilities. It is published and maintained by the W3C (World Wide Web Consortium), the body responsible for setting global web standards.

The standard covers everything a user might encounter on a web page or application:

• Content such as text, images and audio
• The underlying code that controls structure and presentation

Its scope extends beyond websites to mobile apps, software, documents and AI-driven interfaces — anywhere people interact with digital content

Is WCAG 2.2 a legal requirement?

WCAG itself is not legislation, but it is the standard that most accessibility laws reference. In the UK, the Public Sector Bodies Accessibility Regulations and the Equality Act 2010 both point to it. In the US, it underpins obligations under the Americans with Disabilities Act. In the EU, the European Accessibility Act does the same.

For grantmakers, this is especially relevant. Many grant programs are publicly funded, administered on behalf of government bodies, or run by charities with broad inclusion obligations.

In those contexts, WCAG 2.2 AA compliance is good practice, and in many cases a formal requirement.

The standard is built around four principles, known as POUR:

• Perceivable: Information must be presented in ways users can detect, regardless of disability
• Operable: The interface must work for people who cannot use a mouse, touchscreen or other standard input device
• Understandable: Both content and navigation must be clear and predictable
• Robust: Content must remain accessible as assistive technologies and browsers evolve

Failing on any one of these means some users will be unable to engage with your program at all.

What’s new in WCAG 2.2, and what does it mean in practice?

Version 2.2 brought the total number of success criteria to 87, adding 9 new requirements and retiring one from version 2.1 that modern browsers had made obsolete.

Here are five criteria that have changed, and why they matter for grant programs:

Clearer keyboard navigation

The new Focus Not Obscured and Focus Appearance criteria require that the currently active element is always visible when a user navigates by keyboard. Previously, overlapping page elements such as sticky headers or notification banners could cover it without any warning.

Grant application forms and review interfaces involve a lot of sequential navigation — moving through fields, sections and documents. For users who rely on keyboard navigation due to motor impairments, this change meaningfully improves the experience.

Accessible login

Accessible Authentication prohibits sites from making a cognitive puzzle — such as identifying distorted text or solving a visual CAPTCHA — the sole method of logging in. An alternative must always exist.

The criterion also requires that users be able to paste into password and authentication fields. This is important for applicants with cognitive disabilities who use password managers, and for anyone returning to a multi-stage application across multiple sessions.

Less repetitive data entry

Under the Redundant Entry criterion, any information a user has already submitted within a session must be either pre-populated or selectable rather than requiring manual re-entry.

Grant applications frequently span multiple stages and forms. Asking applicants to re-enter their organisation name, contact details or eligibility information they have already provided adds friction and creates a barrier for users with cognitive or motor disabilities.

Better touch and pointer usability

Two new criteria improve usability on touchscreens and for users who rely on pointing devices:

• Dragging Movements: any drag-based interaction must have a single-tap or click equivalent
• Target Size Minimum: buttons, links and other interactive elements must be at least 24×24 CSS pixels to reduce accidental taps on smaller screens

As grant applicants and reviewers increasingly work on mobile devices, these changes have practical significance for how programs are designed and tested.

Consistent help

Where a help mechanism, whether a chat widget, a help link or contact information, appears on multiple pages, it must occupy the same position throughout. People who rely on those features should not need to search for them each time.

Grant managers who embed help content or contact details in their program pages have direct control over this. Consistent placement is a simple change with a meaningful impact.

How to meet WCAG 2.2 as a grant manager

Responsibility for accessibility is shared between your platform and you. The platform handles the technical foundation; you shape the content that sits within it.

What to ask your platform provider

Ask for an accessibility statement or a Voluntary Product Accessibility Template (VPAT) — a standardised document detailing which WCAG criteria the platform meets and any known gaps. A provider that cannot supply one warrants scrutiny, particularly if your program has public sector or government connections.

Good Grants meets WCAG 2.2 AA standards, Revised Section 508 standards and EN 301 549 requirements. A VPAT is available to download, and the platform is subject to regular accessibility audits as the standard evolves.

What you can control as a grant manager

The content you configure is your domain. Here are some items you can focus on to improve accessibility for your grantmaking:

• Images: Write meaningful alt text for images you add to your program. Good Grants handles alt text for its own platform images, but any content you upload is your responsibility.
• Links: Make link text descriptive. “Download the application guide” tells a screen reader user far more than “click here”.
• Documents: PDFs and attachments should be properly tagged for screen readers. Free tools such as Adobe Acrobat’s accessibility checker can help identify issues.
• Video: Add captions or provide a written transcript for any video content you include. Good Grants supports caption files on uploaded video media.
• Help content: Position any help links or contact details consistently across your program pages.
• Colour and branding: If you customise your program’s appearance, verify that text contrast meets WCAG minimums.

Good Grants’ default theme meets these standards, and colour customisation options are available without compromising compliance.

Practical next steps

• Run a free automated check on your program’s public-facing pages using a tool such as WAVE
• Work through the content checklist above for any program currently live or in preparation
• Include accessibility requirements in any future platform evaluation or renewal process

Accessibility benefits everyone

Meeting WCAG 2.2 means avoiding legal risks, but it also means reaching more people, reducing application drop-off and signalling to your community that your organisation means what it says about inclusion.

The practical benefits extend well beyond users with disabilities. Clear navigation, readable contrast, consistent layouts and straightforward language improve the experience for everyone.

Accessible grantmaking goes beyond compliance to provide a positive user experience for all your program participants.