What happened since GAAD 2024 and what’s ahead
Every year, Global Accessibility Awareness Day (GAAD) calls us to reflect – not just on progress made, but on the path forward toward a more inclusive digital world. At the Wikimedia Foundation, this day is a milestone, but also a reminder of our vision to serve everyone. Over the past twelve months, our Product & Technology teams have deepened their longstanding commitment to accessible products in alignment with the wider Wikimedia movement – improving the usability of Wikimedia platforms for millions worldwide.
For GAAD 2025 we would like to look back together and highlight recent improvements in Wikimedia Foundation’s work over the last 12 months and provide some outlook.

A change about wiki headings, under the visible hood
For more than 17 years, MediaWiki and with it Wikipedia have featured an unconventional heading markup.
In MediaWiki 1.43, the HTML structure of headings has been updated. Previously, section edit links and other interface elements were nested directly within heading tags (e.g., <h2>), which caused screen readers to read out both the heading text and the associated interface elements together. The new structure separates the heading text from interface elements like edit links. This change ensures that screen readers announce only the heading, providing a clearer and more navigable experience for users. In an outstanding effort over many months spanning two MediaWiki releases, dozens of patches in dozens of skins and extensions the change was successfully implemented by Bartosz Dziewoński and C. Scott Ananian with help of many more.
Why It Matters
For users of screen readers, headings serve as vital navigation landmarks. By isolating heading content from interactive elements, the updated markup prevents confusion and enhances the usability of pages. This aligns with broader web accessibility standards, ensuring that MediaWiki-powered sites are following familiar patterns and removing burdens of access.
Fine-tuned Codex components
As mentioned in our Codex year in review article, American Foundation for the Blind (AFB) has helped to answer specific questions we had around very advanced accessibility best practices and compliance with WCAG 2 Level AA. Improvements were achieved throughout the Vue 3 and CSS-only components of the library for Wikimedia’s design system.
Why it matters
As described by the AFB, our design system’s approach has already followed advanced accessible patterns. Speaking to our own vision, we want to ensure an excellent experience – independent of your physical abilities.
Mobile Apps
Accessibility is built into our mobile apps feature development process, and continuously improving our processes and checks for accessibility is a orchestrated team effort.
Motivating Alt Text Contributions
The iOS App ran an experiment that prompted users to add alt text for an image related to what they were editing, and provided a guided task to help them write it. About 18% of users who saw the prompt went on to publish alt text. Of those entries, 55% were rated as effective – showing us that the prompt helped, but there’s room to improve in future versions.
Why it matters
Images help bring Wikipedia articles to life, but many need descriptive alt text to be truly accessible. While both apps support adding alt text when images are uploaded, only about 16% of image recommendation edits currently include it. Allowing contributors to easily add useful alternative text could help ensure full access to the context and information from article images.
Optimizing our navigation
The iOS App recently completed major enhancements to our navigation to align more closely with native iOS patterns. These changes will help actions like searching and filtering on the iOS app feel more natural to users. We’re also working to add a major navigational change: tabbed browsing. As we build tabbed browsing, we’ve adapted our layouts to accommodate larger text on iPhone in portrait mode: what is typically a two-column tab layout switches to a one-column layout when larger fonts are enabled.
Why it matters
Switching to system elements instead of custom elements improves the user experience for VoiceOver users, and ensures long-term platform support as Apple continues to add accessibility features. Accommodating larger type sizes, both within the article and for our app’s interface ensures that basic navigation, and new features remain legible and user-friendly to users who use larger type sizes.
Building a More Inclusive Future
As we mark Global Accessibility Awareness Day 2025, these advancements serve both as milestones of progress and as foundations for building a more accessible Wikimedia experience for everyone.
Can you help us translate this article?
In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?
Start translation