Metopedia accessibility standards

This page sets accessibility standards for Metopedia content. It applies to article structure, headings, images, tables, links, captions, media, code blocks, color use, and mobile readability. File-specific rules appear in Metopedia:File and media standards.

Metopedia accessibility standards
Type	Editorial and technical standard
Applies to	Articles, policy pages, help pages, templates, tables, images, uploaded media, captions, and source records
Baseline reference	WCAG 2.2 principles: perceivable, operable, understandable, robust
Core rule	Content must remain understandable to readers using screen readers, keyboards, magnification, mobile devices, low-bandwidth connections, or assistive technology.
Related pages	Metopedia:Style guide, Metopedia:File and media standards, Metopedia:Article standards, Help:Contributor help

Metopedia accessibility standards require contributors to write and format pages so that content remains readable, navigable, and understandable for users with different devices, abilities, browsers, and assistive technologies.

Accessibility is not an optional visual improvement. It is part of source integrity. If a page cannot be read, navigated, or understood by a portion of users, its evidence is not fully inspectable.

Baseline principles

Metopedia follows the practical structure of the Web Content Accessibility Guidelines. WCAG 2.2 is organized around four principles: content must be perceivable, operable, understandable, and robust. WCAG 2.2 became a W3C Recommendation on October 5, 2023 and added success criteria beyond WCAG 2.1.

Metopedia uses these principles as editorial guidance. This page does not certify formal legal compliance. It sets the practical content rules contributors must follow.

Principle	Meaning for Metopedia
Perceivable	Readers must be able to perceive text, images, tables, captions, and page structure through ordinary browsers or assistive technology.
Operable	Readers must be able to navigate links, sections, tables, media, and page controls without mouse-only assumptions.
Understandable	Pages must use clear headings, direct language, defined terms, and predictable structure.
Robust	Pages must use stable wiki markup and semantic structure that works across devices, skins, screen readers, and future rendering changes.

Headings

Headings must describe the topic or purpose of a section. WCAG guidance for headings and labels emphasizes that descriptive headings help users orient themselves, especially users with cognitive or visual disabilities.

Rules:

• use headings in logical order;
• do not skip from level 2 to level 5 for visual effect;
• do not use headings as jokes or slogans;
• avoid vague headings such as “More,” “Important,” or “Miscellaneous”;
• keep headings short but specific;
• do not create empty sections.

Good:

= Evidence record =
== Source preservation ==
== Search method ==
== Limitations ==

Weak:

= Stuff =
==== Weird things ====
= Read this =

Link text

Link text must identify the destination or purpose. Do not use repeated “click here” links.

Good:

See [[Metopedia:Source standards]] for citation requirements.

Weak:

For citation requirements, click [[Metopedia:Source standards|here]].

When linking to files, identify the type and purpose:

See the [[:File:Figshare-removal-notice-2026-04-21.png|Figshare removal notice screenshot]].

Alt text and image descriptions

Images that communicate information require text alternatives. W3C guidance states that images must have text alternatives describing the information or function they represent.

Metopedia treats image descriptions as evidence access. If an image contains source material, a chart, a screenshot, a diagram, or a comparison, readers who cannot see it still need access to its meaning.

Image type	Required description
Decorative image	Empty or minimal description; avoid decorative images in evidence pages.
Informative image	Concise description of the information shown.
Screenshot	What page/app/document is shown, date if relevant, and the visible evidence.
Chart	Title, axes, units, trend, and conclusion the chart supports.
Complex diagram	Caption plus nearby explanation or a longer description.
Image of text	Use real text instead of image text when possible; otherwise transcribe essential text.

W3C guidance also recommends using real text styled with CSS rather than images of text when possible because real text can be resized and adjusted more reliably.

Captions

Captions must explain the image’s relevance. A caption is not the same as alt text. Captions are visible to all readers; alt text or text alternatives are for readers who need a nonvisual description.

Good caption:

Screenshot of the Figshare account-disabled notice received on April 21, 2026. The notice cites broad Terms and Conditions categories but does not identify an itemized violation.

Weak caption:

Screenshot.

Tables

Tables must be used for structured comparison, not layout decoration.

Accessible table rules:

• use header cells with ! for column and row headings;
• keep headings short;
• avoid empty cells when possible;
• avoid tables wider than the page body;
• do not use color alone to mark meaning;
• explain the table before or after it;
• avoid long paragraphs inside cells;
• use lists when a table creates mobile overflow without adding structure.

Good table:

{| class="wikitable"
|-
! Claim
! Evidence status
! Notes
|-
| The record was removed.
| Supported
| DOI landing page showed a removal notice.
|}

Color and visual emphasis

Color must not be the only way meaning is conveyed. If a table uses color to distinguish status, include text labels as well.

Use:

• “Supported,” “Unverified,” “Contradicted,” or “Open” as text labels;
• icons only when the label remains readable without the icon;
• high contrast for text and backgrounds;
• dark-mode-safe colors when CSS variables are available.

Avoid:

• red/green-only meaning;
• pale gray text for body content;
• background colors that obscure links;
• image-only labels.

Mobile readability

Pages must remain usable on narrow screens. Many readers will view Metopedia from phones.

Mobile rules:

• avoid unnecessarily wide tables;
• keep infoboxes concise;
• use short headings;
• avoid excessive inline styling;
• do not force fixed pixel widths unless needed for images or technical display;
• use percentages or responsive classes where possible;
• break long source lists into sections.

Code and preformatted text

Code blocks, logs, and command examples must be readable and copyable.

Use <pre> blocks for commands, logs, and literal markup. Explain what the code does before or after the block. Do not use screenshots of commands when real text is available.

Good:

php /var/www/metopedia/maintenance/run.php importDump import.xml

Weak:

• an image showing the command with no transcription;
• a command without explanation;
• a log snippet with private tokens or passwords visible.

Math and technical notation

Mathematical and technical pages must define variables, units, inputs, and outputs. A formula image is not enough; provide the formula in text or math markup where possible.

When using tables for mathematical examples, include labels and units. When using diagrams, explain them in nearby text.

Audio and video

Audio and video require supporting text when the media carries meaning.

Requirements:

• title or description;
• source and license;
• transcript for spoken content when practical;
• captions or summary for video where practical;
• note of edits, cuts, overlays, or transformations;
• warning for flashing content, loud audio, or disturbing material.

PDF and document uploads

PDFs must not be the only place where critical page content exists. Important claims from PDFs must be summarized or transcribed into the wiki page with citation.

For uploaded PDFs, include:

• source;
• author;
• date;
• license or permission status;
• file description;
• whether OCR text is available;
• accessibility limits if the file is scanned or image-only.

Plain language

Metopedia can cover technical subjects, but technical complexity is not an excuse for avoidable obscurity.

Use:

• direct verbs;
• defined terms;
• short paragraphs;
• examples;
• tables for comparison;
• scope notes;
• “inference” labels when needed.

Avoid:

• unnecessary jargon;
• undefined acronyms;
• long chains of subordinate clauses;
• unexplained technical leaps;
• rhetorical density that prevents inspection.

Cognitive accessibility

Readers must be able to track the page’s reasoning. This matters especially for investigations, disputed claims, and long evidence records.

Use:

• summary boxes;
• scope statements;
• section overviews;
• evidence tables;
• clear verdict tables in fact checks;
• “what this establishes / what this does not establish” sections;
• limitations sections.

Accessibility review checklist

Before publishing a page, check that:

• headings are descriptive and ordered;
• images have captions and text alternatives when meaningful;
• links identify their destination;
• tables use header cells and remain readable;
• color is not the only source of meaning;
• important text is not trapped inside images;
• code and logs are real text where possible;
• videos or audio have summaries or transcripts when relevant;
• long pages have navigation and section structure;
• pages are readable on mobile;
• private information is not exposed in screenshots.

See also

• Metopedia:Style guide
• Metopedia:File and media standards
• Metopedia:Article standards
• Metopedia:Source standards
• Help:Contributor help