Wikipedia for Everyone: Closing the Accessibility Gap
Roundtable — 60 minutes · Any experience level welcome
Accessibility is not a feature — it's a prerequisite for free knowledge. Yet across Wikipedia and its sister projects, thousands of interface elements and community-made templates silently fail users with visual impairments, color blindness, motor disabilities, and more. This roundtable brings together designers, developers, and gadget maintainers to map what's broken and agree on where to start.
Known issues — a quick tour
The session opens with a concise overview of the most common violations found in MediaWiki interfaces and community-created content.
- Color contrast failures — Many templates, banners, and gadgets use color combinations that fall below the WCAG 2.1 minimum ratios (4.5:1 for normal text, 3:1 for large text). Color-blind users are hit hardest where color is the only differentiator.
- Missing or meaningless alt text — Thousands of images across wikis lack alt text, or carry auto-generated filenames that convey nothing to screen reader users. Decorative images are rarely marked as such.
- Keyboard & focus accessibility — Interactive gadgets and custom UI components often lack visible focus indicators, logical tab order, or keyboard-only navigation paths — making them unusable without a mouse.
- Semantic markup & screen readers — Tables used for layout, missing heading hierarchy, absent ARIA roles, and unlabelled form fields make structured navigation impossible for assistive technologies.
- Responsive & zoom-based breakage — Many templates break or overflow when users zoom in (a common accessibility accommodation) or switch to high-contrast system themes. CSS is often written in fixed pixels, ignoring user preferences.
Session flow
1. Issue walkthrough (~10 min)
A rapid overview of known violations with live examples. Focus is primarily on color contrast and alt text, with a nod to the broader landscape above.
2. Technical discussion (~35 min)
Open roundtable on solutions: CSS custom properties for palette standardization, automated linting tools (axe, Lighthouse CI), per-wiki validation workflows, and what a realistic remediation path looks like in a community-driven codebase.
3. Towards a proposal (~15 min)
Gather community input to shape a Phabricator task. What should the guidelines cover? Who maintains them? How do we make them approachable for gadget authors with no formal a11y background?
Expected outcomes
- A shared map of the most critical contrast and accessibility violations in MediaWiki's default interface and community templates.
- Concrete technical recommendations — CSS variables, linting pipelines, or opt-in validator gadgets — that developers can act on immediately.
- Collected community feedback to draft an inclusive design guideline proposal and a follow-up Phabricator task.
Who should join
UI/UX designers, frontend developers, gadget and script maintainers — and anyone who has personally experienced barriers while using Wikipedia. No formal accessibility expertise needed: lived experience counts just as much as WCAG knowledge.
Skills preferred: Basic understanding of WCAG, CSS, or lived experience with accessibility challenges
Format: Roundtable
Duration: 60 minutes
Experience level: Any
Raw session notes
Unconference session: Wikipedia for Everyone: Closing the Accessibility Gap
Speakers: User:Daimona Eaytoy, User:Piergiovanna, User:valcio
Introduction from speakers. What is accessibility first? [Audio from text-to-speech tool about Wikipedia policy page, with a lot of HTML read out aloud] Visually impaired peole hear this everytime that they read Wikipedia, we need to change the way articles are written to allow them to be read a proper version of the articles.
For example, on a policy page regarding consensus, the text-to-speech tool didn't read a paramount image about what consensus is and how it is formed. Alternative text for the image is missing, and there is no explanation of what is its content.
Same goes with tables that get read aloud with their HTML. Plus in the example given, there are no real headers, and there is information about how big a Wikipedia is given by color, which a text-to-speech tool cannot read. Plus, the colors are not read by color-blind people.
How to fix all this? By adding alternative text to the image that actually explains the content of the image, and by fixing the table by adding proper headers, adding more color contrast, and adding the current status of the project, to reduce reliance on color only. This is not a complete list of problems that are present.
There is a proposal for a palette of colors that are good for accessibility, with proper tests for readability. https://it.wikipedia.org/wiki/Utente:Daimona_Eaytoy/Palette
Questions from audience:
- Derek T: Curious how these colors were chosen. Want to help with related efforts.
- TheDJ: You're not stopping people from making mistakes, and to make "wrong" decision. VisualEditor has already ways to do correct actions at scale for this, maybe a HTML structure can be done to scan for problems like inconsistent tables and reporting them as Lint problems
- these colors would be put in website CSS so we can force its adoption this way, the idea for making the palette is to never use hex code directly
- TheDJ: you're right, but it's gonna take a lot of time to get all wikis on board
- CristianCantoro: in the example we've seen, the text-to-speech reads aloud the structure of the table, but there are tools that "translate" stuff like math formulas into something that can be readable by t-t-s tools, do you know tools that can recognise skippable content?
- you can tell the tools to skip certain things, but for things like edit buttons it's a decision that needs to be made at software level
- Bartosz: The specific example you showed with the headings and edit-buttons being read imperfectly is a bug with the Mobile Web design and should be fixed soon. But they do need to be available.
- TheDJ: Screenreaders are very verbose
- Waldir: I've been doing personalisation on tools, one thing that would be helpful would be some guidance on how to find out the properties of what you see on screen, while using the debug URL parameter for example, to help people find the source of incompatibilities and how to fix them
- we'll allow you to paste any color hex and then tell you if they are compatible with the standards
- Supernabla: I found a tool that respects most of the things that are talked here, so I can share; there is also a problem with users don't caring much about these kind of problems, so we need more advocacy on the point
- Quiddity: Plug for https://www.mediawiki.org/wiki/Accessibility_and_usability_cleanup -- Please help everyone to clean/merge/update this mess.
- TheDJ: Alt-text: AI-recognition is something that already is taking some effect on this
- Iolanda: just want to mention that with European Directive for accessibility all websites are asked to have links to describe pages and ask for changes, maybe we can set up something like that on the Wikimedia projects (even if they are not in Europe)
- the problem is that we can apply to European websites, but it's not international
- plus it depends on the websites