Django and WCAG

The Django project committed to WCAG 2.2 at AA level as their target standard . That's the same level most legal requirements reference. AA means you've covered the major barriers: color contrast, keyboard navigation, consistent identification, and error identification.

Thibaud Colas and the Django accessibility team announced this formally in May 2025, timing it for Global Accessibility Awareness Day . The announcement included a statistic worth remembering: according to the WebAIM Million survey, 94.6 percent of sites have detectable accessibility issues . That number is from 2025. It hasn't improved much in years.

The Django team publishes an accessibility statement so you can factor it into procurement and legal compliance. If you're bidding on government contracts or European projects covered by the European Accessibility Act (which took effect June 2025), that statement matters .

Where Django's built-in components help

The admin interface is the most visible part of Django that users interact with directly. The accessibility team tests it against keyboard-only navigation, screen readers, and zoom up to 400 percent .

Form rendering is another area. Django's default form HTML includes labels, error lists, and field identification. Those are the building blocks of accessible forms. But the framework doesn't automatically give you accessible error announcements or proper ARIA attributes. That's still on you.

The documentation now includes specific testing guidelines for contributors. If you're submitting changes to Django itself, you need to test with:

• Keyboard-only navigation
• Accessibility Insights or Axe automated checks
• Touch-only navigation where relevant
• 400 percent browser zoom
• Forced-colors mode

Thibaud Colas, who leads much of this work, also published a detailed VPAT for Wagtail 7.0, which runs on Django . VPAT stands for Voluntary Product Accessibility Template. It's the format the U.S. government requires for software procurement. The Wagtail report shows what a serious accessibility audit looks like for a Django-based CMS.

Testing tools Django recommends

The Django documentation lists specific assistive technologies they test with .

For Windows:

• NVDA with Firefox ESR
• Narrator with Microsoft Edge
• Windows Magnifier
• Windows Speech Recognition

For macOS:

• VoiceOver with Safari
• macOS Zoom
• macOS Voice Control

For Linux:

• Orca with Firefox ESR

For mobile:

• VoiceOver on iOS
• TalkBack on Android

They also recommend licensed tools like JAWS and Dragon NaturallySpeaking if you have access to them .

This list is useful because it tells you what the Django team actually uses. It's not theoretical. These are the combinations they test before releasing new versions.

The Wagtail example: what real conformance looks like

Wagtail is a Django-based CMS. In May 2025, they published a conformance report for version 7.0 . The report is worth reading because it shows what "Supports," "Partially Supports," and "Does Not Support" actually mean in practice.

For WCAG 2.2 Level A criteria, Wagtail supports 24 criteria, partially supports 2, and doesn't support zero . The two partial support items are worth noting.

First, 1.1.1 Non-text Content. Wagtail provides alt text options for all images by default. But in the authoring tool itself, there are scenarios where alt text exists but isn't programmatically associated with the image . That's a subtle but real gap.

Second, 2.2.1 Timing Adjustable. Animated images displayed within the CMS can't be paused . That's a Level A failure if you're strict about it.

These aren't huge problems. But they're real. The Wagtail team documents them publicly with links to specific GitHub issues. That's the level of transparency you should expect from any serious accessibility effort.

How third-party Django packages handle WCAG

There are Django packages that try to bolt on accessibility. The django-all-in-one-accessibility package, for example, installs a widget that lets users adjust contrast, font size, and other display settings .

The package claims to improve ADA compliance and reduce lawsuit risk. It references WCAG 2.1, ATAG 2.0, Section 508, and various international standards.

But there's a trade-off with these overlays. Accessibility specialists often criticize them because they don't fix underlying code problems. They add a layer on top. If your site has missing alt text or improper heading structure, the widget doesn't fix that. It just gives users tools to work around it.

The package requires adding a script tag to your base template, running migrate, and adding a context processor . It works. But it's not a substitute for building accessible templates from the start.

The django-contact-us package had a 1.1.0 release that included "some WCAG accessibility changes" . The 0.4.4 release fixed a label "for" attribute issue. These are small fixes, but they show that package maintainers are starting to think about accessibility.

What Django doesn't do for you

Here's the honest part. Django gives you a solid foundation, but it doesn't make your site accessible.

Your templates are your responsibility. Django's template language doesn't enforce alt text on images. It doesn't check that you're using semantic HTML. It won't stop you from building a completely inaccessible interface.

The admin is accessible, but most users never see the admin. They see the front-end you build.

Dynamic content is another area where Django stops helping. If you're building single-page app behavior with JavaScript, accessibility is entirely on you. Django serves the initial HTML, but once the page loads, you're in JavaScript territory.

The accessibility team acknowledges there are known issues in Django itself. They maintain a project board and encourage contributors to pick up accessibility tickets . Rahmat Akintola announced in August 2025 that the contributing guide is now live, specifically to help new contributors work on accessibility .

Testing requirements for Django contributors

If you want to contribute accessibility fixes to Django, the documentation tells you exactly what to test .

Always test:

• Keyboard-only navigation
• Accessibility Insights or Axe automated checks

Where relevant, also test:

• Touch-only navigation
• 400 percent browser zoom
• Forced-colors mode

This testing baseline applies to any change that affects the admin interface or rendered HTML output .

The documentation also includes specific advice about forced-colors mode. You can test this using the "high_contrast" mode in Django's screenshot tests . Common issues include relying on color alone for meaning and using !important or inline styles that break forced-colors mode.

The numbers problem

Meagen Voss, Wagtail Community Manager at Torchbox, led a tutorial at DjangoCon US 2024 titled "How To Build More Accessible Websites with Wagtail" . The tutorial description includes that WebAIM statistic again: 96.3 percent of websites have accessibility issues.

Voss's workshop covered WCAG basics, choosing which version to follow, and using Wagtail's built-in accessibility checker . The workshop was hands-on. Participants built a blog and learned how to test continuously.

The fact that DjangoCon had a dedicated accessibility tutorial suggests the community is taking this seriously. But it also suggests that most developers don't already know how to do it.

Practical steps for Django developers

If you're building a Django site today and you need WCAG compliance, here's what the documentation suggests.

First, design with accessibility in mind. The Django team says "design the UI with accessibility in mind, and the testing will only be needed as a final check" . That's aspirational, but it's also true. Retrofitting accessibility is harder than building it in.

Second, test with real assistive technology. Automated tools catch maybe 30 percent of issues. The Django documentation lists specific screen readers to test with . Use them.

Third, if you're building a CMS-driven site, consider Wagtail. Their VPAT shows they've done the work. You still have to build accessible templates, but the admin interface won't be a barrier.

Fourth, be honest about what Django doesn't do. The framework team is transparent about known issues . Your project should be transparent too. If there are gaps, document them. That's what the Wagtail VPAT does. It lists specific GitHub issues for each partial support item.

Fifth, if you're using third-party packages, check whether they've done any accessibility work. The django-contact-us changelog shows they fixed a label attribute issue . That's the kind of detail that matters. If a package hasn't fixed basic form labeling, it's probably not accessible.

The European Accessibility Act complication

The Django accessibility statement mentions the European Accessibility Act specifically . Starting June 2025, accessibility is a legal requirement for large parts of the private sector in the EU.

If you're building sites for European clients, you need to know what this means. The Act references EN 301 549, which is essentially WCAG 2.1 AA with some additional requirements. Django's commitment to WCAG 2.2 AA covers that, but again, only for the framework itself. Your code is your responsibility.

The statement also mentions ATAG, the Authoring Tool Accessibility Guidelines . This matters if you're building tools that let users create content. The Django admin is an authoring tool. So is Wagtail. ATAG compliance means the tools themselves are accessible and they encourage accessible content creation.

Where Django is headed

The August 2025 announcement about the accessibility contributing guide shows the team's direction . They want more contributors working on accessibility. They've created a forum topic, a Discord channel, and a project board.

The known issues list is public . You can see exactly what needs fixing. If you're a developer looking for open source work, these are good tickets to pick up.

The documentation now includes specific references to accessibility in the committing code guidelines. If a change affects the admin or rendered HTML, contributors must do accessibility testing . That's new. It means accessibility is now part of the review process, not an afterthought.

The trade-offs

Here's the thing about Django and accessibility that nobody says directly. Django is a framework, not a solution. It gives you tools, but it doesn't build your site for you.

The admin is accessible. That's good. But most users never see the admin. They see the front-end you build. If you build it badly, Django won't save you.

The documentation tells you how to test, but testing takes time. Real screen reader testing takes hours, not minutes. Automated testing misses most issues. Doing accessibility properly means slowing down.

The European Accessibility Act creates legal risk, but the standards are still fuzzy. WCAG 2.2 AA is the target, but enforcement is inconsistent. Some clients will demand VPATs. Others won't ask.

Django's accessibility team is small. Thibaud Colas, Rahmat Akintola, and a few others are doing most of the work. They welcome contributions, but the core team isn't large enough to audit every pull request.

What to actually do

If you're building a Django site today, start with the templates. Use semantic HTML. Label your forms properly. Add alt text to images. Test keyboard navigation. Run Axe. Those basics cover most issues.

If you need WCAG AA conformance, read the Django testing guidelines. Use the assistive technology they recommend. Test at 400 percent zoom. Check forced-colors mode.

If you're bidding on contracts that require accessibility, read the Wagtail VPAT. It shows what a real audit looks like. You might need to produce something similar for your own site.

If you find bugs in Django's accessibility, report them. The team wants to know. There's a ticket tracker keyword for accessibility issues .

And if someone asks whether Django is accessible, the answer is: the framework itself is getting there. The admin works with screen readers. The forms render semantic HTML. But your site is your responsibility. Django gives you a foundation. You build the rest.