Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Drupal core has strong accessibility foundations; failures usually come from what you add.
- Automated tools find only a portion of real barriers.
- Keyboard-only and screen-reader testing are not optional.
- Configure the editor so the accessible path is the easy one.
What core gives you
Drupal has taken accessibility seriously for a long time. Core markup, form handling, the administration interface and the default themes are built with it in mind, and the project has accessibility gates on core changes.
That is a strong starting point and it is not a compliance guarantee, because the parts most likely to fail are the parts you add.
Where failures come from
- Custom themes — heading order, focus states, contrast on secondary text, and interactive elements built from divs.
- Contributed modules — sliders, accordions and modals with no keyboard support.
- Content — missing alt text, link text that says “click here”, tables used for layout, and PDFs that are images of text.
The third category is ongoing rather than one-off, which is why editorial guidance matters as much as the build.
Make it a build gate
Run automated checks in the pipeline — axe-core catches a meaningful share of issues cheaply. Then do the part automation cannot: keyboard-only navigation of every key journey, and testing with a screen reader.
Automated tooling typically identifies only a portion of real barriers. Treating a clean automated report as compliance is the most common mistake in this area.
Help the editors
Configure the editor to make the accessible path the easy one: require alt text on images, restrict the heading levels available in the body field so structure cannot be broken, and provide guidance text where a decision is needed.
Then train the people who publish. Accessibility is maintained through content decisions long after the build is finished.
Documents, media and the long tail
Website accessibility work tends to stop at the HTML, and a large share of the real barriers on organisational sites are in the files attached to it. A scanned PDF is an image of text: unreadable to a screen reader, unsearchable, and often the only version of an important document.
Set a policy that primary information is published as web pages, with documents as a supplementary format rather than the only one. Where PDFs are genuinely required, they need proper tagging, reading order and alternative text in the same way a web page does.
Video and audio carry a similar obligation. Captions serve far more people than those who are deaf, including anyone watching without sound, and transcripts make the content searchable. Budget for these at the point the media is commissioned rather than treating them as a later remediation.
Frequently asked questions
It is a set of testable success criteria covering perceivability, operability, understandability and robustness things like sufficient contrast, keyboard operability, meaningful link text, correct heading structure and clearly labelled forms. AA is the level most commonly referenced in procurement and legislation.
No. Overlay tools that claim to fix accessibility automatically are widely criticised by disabled users and do not address underlying markup problems. Accessibility comes from the templates, the content and the components.
A full audit at launch and after any significant redesign, with automated checks running continuously in the pipeline. Because content is added constantly, editorial guidance and training matter more than periodic audits for keeping a site compliant.
