维基百科:格式手冊/無障礙/2025

网站无障碍旨在让網頁更易於瀏覽、閱讀。這最初只是用于幫助身心障礙人士，但确实利于所有讀者。我們致力于遵循WCAG標準2.1，基于该标准，提出以下建議。遵守這些规范的条目方便所有人閱讀、編輯。

条目结构

条目结构规整能让读者对页面的内容铺排一目了然，因此有助达成无障碍。例如，某位失明读者在寻找消歧义链接时，如果没有在页顶找到这种链接，则能明白页面本来没有消歧义链接，因此无需阅读整页。

标准化是维基百科的一大习惯，因此只需遵循Wikipedia:格式手冊/版面佈局和Wikipedia:格式手冊/序言章節 § 應該有的東西。

章節標題

章节标题应该能简洁描述主题，且按照格式手册排列。

章节标题应该嵌套递进，由二级标题（==）开始，再到三级标题（===），如此类推（一级标题是页面标题）。不要为了凸显某些内容而故意用错或跳过章节标题层级，这样做有悖于它们的作用。

为求视障编辑者的便利，使用源代码编辑时可以在每个章节标题下面添加一个空行。如果添加多于一个空行，则会导致章节标题预览时在下面出现空行。在部分条目中，您也应留意小型屏幕如何显示章节标题下面的空行，因为许多编辑者都用移动设备进行编辑，如果章节标题下面有空行，则反而可能会削弱他们对条目的可读性。

嵌套章节标题的应用例和误用例

正确	随机/无规律	跳级
[条目序言] ==章节== [二级] ===子章节=== [三级] ==章节== [二级] ===子章节=== [三级] ====子章节的子章节==== [四级] ==章节== [二级]	[条目序言] ====章节?==== [四级] ===章节?=== [三级] ==章节?== [二级] ==章节?== [二级] ====章节?==== [四级] ===章节?=== [三级]	[条目序言] [缺失二级标题] ===章节?=== [三级] ==章节== [二级] [缺失三级标题] ====子章节?==== [四级] ==章节== [二级]

不要滥用半角分号制作伪标题（分号只可用于制作定义列表），亦避免使用粗体。屏幕阅读器和其他辅助工具只能依赖章节标题语法确定标题的排列。如欲缩小目录，则可以改用{{TOC limit}}。如果{{TOC limit}}因条目存在低层章节标题而无法使用，则五级标题可以改用粗体，这样就能减少对屏幕阅读器的干扰。伪标题只能在方法穷尽时使用，不应频繁出现。

伪标题和定义列表的应用例和误用例

可接受	错误
[条目序言] ==章节== [二级] ===子章节=== [三级] '''伪标题''' ==章节== [二级] ===子章节=== [三级] ====子章节的子章节==== [四级] ;术语 :一个定义或一个定义列表项 :列表中的其他项	[条目序言] ==章节== [二级] ===子章节=== [三级] ;伪标题 ==章节== [二级] ===子章节=== [三级] <small>==子章节的子章节==</small> [二级]

浮动元素

参见：Wikipedia:Manual of Style/Images § Location和Wikipedia:格式手冊/無障礙 § 图像

在维基代码中，浮动元素（包括图像）应该置于所述章节之内，而非前一章节的结尾。（在某些平台中，在一小段文本旁边“堆叠”几张图像会导致某些图像挤到下一章节，但这并非无障碍问题，因为屏幕阅读器必定会在每张图像代码所指定的位置阅读它们的alt=。）

屏幕分辨率

维基百科条目应该便利使用小型屏幕（比如移动设备）或低分辨率显示器的读者。在桌上显示器中，屏幕两侧有多张图像的条目可能会导致问题。虽然低分辨率显示器一般会垂直伸长段落，因而垂直移动图像，但您也需要避免在屏幕两侧同时添加图像或其他浮动元素。大型表格和图像也能产生问题：水平卷轴或不可避免，但您亦可考虑重新铺排大型表格，缩短水平篇幅。

文字

参见：Wikipedia:格式手冊/文字格式

大部分螢幕閱讀器默认不会标明视觉文字属性（粗体、斜体、下划线、等宽字体、删除线）乃至语义文字属性（着重、删除文字），所以它们会将刪除線文字视为普通文字朗读。如果您使用螢幕閱讀器且时常参与维基百科讨论，则建议开启文字属性的通知，因为维基百科讨论经常出现删除线文字。

因为螢幕閱讀器一般忽略删除线，所以如果它在条目中没有任何其他标示，则会引起无障碍问题或者混淆。这个问题适用于<s>、<del>元素（以及一般呈现为下划线的<ins>）和使用它们的模板。如果您认为内容不适当或错误，则不要使用删除线劃去它，而是用<!--和-->将其转为注释、删除内容，或挂上内文爭議模板，再于讨论页发起话题。

【中文的屏幕阅读器如何？

测试了一下我的设备Windows 11上的讲述人，没下载其它语音的时候遇到阿拉伯字母和希腊字母几乎完全跳过，因此我暂且这样改。】

有些螢幕閱讀器不支持常用汉字和拉丁字母以外的字符（？），因此您不能假定阅读器必然以某特定方式阅读这些字符。遇到不支持的字符时，屏幕阅读器和語音合成器可能会读作问号或完全省去它。

1. 在重要情况（如人名、地名、事物等）下，您需要为所有非拉丁、非汉字的文字（？）提供拉丁转写。您可以使用语言专用模板或{{Transliteration}}标注。这些模板在无障碍方面也有其他益处（参见“外语”一节）
2. 不要加入屏幕阅读器可能无法阅读的符号（比如心形符號♥），反而使用附带替代文字的图像。

您必须使用上下文清楚表达文字的语义特性（以及其他形态类似的内容）。不要依赖只能用CSS属性或Wikitext分辨的自定义“特殊符号”。

不要使用需要互动才能提供资料的技术，包括提示框和其他“悬浮”文字。缩写不受此限，所以您可以用{{abbr}}（<abbr>的包装模板）标示缩写（包括首字母縮略字）的全写。

不要在句中插入换行符，因为会对螢幕閱讀器造成干扰；但您可以在句末加入换行符，对某些编辑者有所帮助。（译注：如果指通过句末换行来产生空格的话，那中文不能有此体例。）？）

字体大小

主页面：Wikipedia:Manual of Style/Text formatting § Font size

大小字形一般由自动化页面元素（比如章节标题、表格标题和标准模板格式）负责实现，除此之外应避免使用。更改字体大小时，应当用原大小的百分比表示，而非以像素或点表示的绝对大小。如果使用相对大小，则视障用户仍能按情况调大浏览器的默认字体大小，但他们无法直接调整绝对大小。

避免在使用小字体的页面元素（比如信息框、导航模板和参考章节中的文字）内再使用小字体。换言之，您不应在这些元素中的纯文字使用<small>...</small>标签，以及诸如{{small}}和{{smalldiv}}的模板。所得文字的大小不得小于页面默认的85%，注意，HTML的<small>...</small>标签还具有“小字条款”（fine print）或“注疏”的语义含义，不可用于风格化。

分数

主页面：Wikipedia:Manual of Style/Dates and numbers § Fractions and ratios

不要使用Unicode已有的分数字符，如½（已弃用标记的有½和½），因为部分螢幕閱讀器无法解析一些分数字符，而且视障读者难以阅读。请改用{{frac}}，格式如3⁄4。（在科学和数学条目中，则用{{sfrac}}，格式如3/4。)

外文

标注外文

主页面：Template:Lang/doc § Rationale

参见：MOS:首句外语和Wikipedia:格式手册/标注外文

中文维基百科默认会向浏览器指明条目以中文（zh）书写。除在中文语境内常用的非中文（外文）词汇和字母词外，外文文字必须用{{lang}}（或其衍生模板）标明。这类模板使用IETF語言標籤包装文字，指定其语言和书写系统，例如：

• Assemblée nationale并未指出自己的语言（法语）。大多数屏幕阅读器处理时会读错。
• {{lang|fr|Assemblée nationale}}呈现为Assemblée nationale，屏幕阅读器处理时改用法语发音。
• {{lang-fr|Assemblée nationale}} → 法語：Assemblée nationale：同上。
• 上证A股、Facebook用户 → 上证A股、Facebook用户：由于“上证A股”和“Facebook”在中文语境内是常用词汇，无需专为其加上{{lang}}系列模板。

理由：如果使用{{lang}}指定文字的语言，则屏幕阅读器可以改用该语言的声音。

另外，在中文維基百科中，如果不将日語文本用模板包裹，日文漢字可能會被視作中文而錯誤簡繁轉換（韩文汉字、越南喃字等同理）。

关于使用{{lang}}系列模板的完整理由，见Template:Lang/doc#使用理由。

书写系统

IETF语言标签按照ISO 639标准指定文字的语言之余，还能标明文字的书写系统：

• {{lang|sr-Cyrl|Народна скупштина}} → Народна скупштина
• {{lang|sr-Latn|Narodna skupština}} → Narodna skupština ——塞尔维亚语一般用拉丁文字或西里尔文字书写。
• {{lang|ja|Kokumin gikai}} ——日语文字一般用汉字和假名书写。
• {{lang|ja-Latn|Kokumin gikai}}指明这段日语文字用拉丁文字书写（日语罗马字）。
• {{transliteration|ja|Kokumin gikai}}同上。

如果未指定书写系统，则IETF标签会默认使用该语言最常用的书写系统。鉴于此，处理字母转写时，您应该在语言代码加入-Latn，抑或使用相应的{{transliteration}}模板。维基百科的语言专用模板（比如{{lang-en}}和{{nihongo}}）能为编辑者提供各种功能，包括用一个模板展示几种转写。有些语言没有自己的专用模板，但这些模板防止编辑者频繁使用{{lang}}和{{transliteration}}，从而简化维基文本。 音标转写请用{{IPA}}或其他合适模板。原始印歐語请用{{PIE}}。

链接

1. 链接（尤其是外部链接）描述应该清楚易懂（不要使用“点击我！”“此链接”）。
2. 不要使用Unicode符号替换图标，反而应该使用附带替代文字的图标。例如，部分螢幕閱讀器无法将“→”等字符转为有用文字。
3. 为帮助视障读者找到目标页面的链接锚点，您可以利用{{Visible anchor}}标示锚点。

颜色

在红绿色盲读者的眼中，上截图的模板难以阅读（效果如下截图）

颜色最常出现于维基百科的模板和表格。

在条目和其他页面使用颜色时，您应时常留意无障碍，准则如下：

• 请确保颜色不是唯一传达重要资料的途径。特别而言，不要使用彩色文字或背景，除非其状态也以其他方式指明，比如图例上的无障碍符号或脚注标签。如不遵循这个准则，则失明用户或读者无法通过印本或非彩色装置获取资料。
• 读者必须能清楚明白哪些互动元素是链接。
• 部分读者有色盲、色弱或视觉障碍。请确保文字与背景的对比度最少能达到Web内容无障碍指南（WCAG）2.0的AA等级，且尽量达到AAA等级（参见WCAG“了解SC 1.4.3：对比度（最低限度）”）。如欲在白色背景下使用CSS颜色名称显示文字，请见Wikipedia:格式手冊/無障礙/CSS顏色與白色背景的對比度。此外，您也可以利用以下工具评估对比度：
  • 网络上有一些能检查对比度的工具，包括WebAIM网上对比度检查器、WhoCanUse网站和斯努克颜色对比度检查器。
    • 尽管如此，有些网上工具以WCAG 1.0的算法为根据，因此需要事先甄别。如果工具未指定自己采用WCAG 2.0，则您可以假设它已过时。
  • 维基媒体基金会设计团队提供一套达到AA等级的配色表。维基媒体产品（不论电脑端还是移动端）的所有用户界面元素都使用此配色，但链接文字除外。
  • Wikipedia:格式手冊/無障礙/顏色表就14种色相对黑字、白字、链接文字和访问链接文字展示达到AAA等级的最暗或最亮背景色。
  • Google Chrome有附带颜色挑选器的对比度检查器。
  • 您可以通过颜色对比度分析器选择页面上的颜色，然后详细评估它们的对比度，但只有“luminosity”（光度）算法是最新的，而“color brightness/difference”（颜色亮度/差）已过时。
• 以下工具能帮助您制作图表和地图配色。它们未必能准确评价颜色的对比度，但在特定情况下也值得使用。
  • 您可以在Paletton挑选图表配色。
  • Color Brewer 2.0可以提供地图配色和详解。
  • “明亮”定性数据配色方案是一套九种对色盲用户便利的颜色。
  • 网络上有一些模拟色盲的工具：Toptal ColorFilter（网页）和Coblis色盲模拟（本地文件）。浏览器也有一些扩展程序：NoCoffee（Firefox）
  • 您可以通过开源软件Color Oracle模拟色盲视觉和全色盲，从而选择更适当的对比色。
• 如果条目滥用颜色，但您无法改正问题，您可以挂上{{Overcolored}}，寻求编辑者协助。

网页安全颜色与黑字（上）和白字（下）的对比度。等高区域为3（红）、4.5（绿）和7（蓝）。

块元素

列表

参见：Help:列表、Wikipedia:列表和Wikipedia:列表格式指南

分隔列表项目时，不要在中间插入空行或制表符。这里的列表包括描述列表（由行首半角分号或冒号制成的列表，也是维基百科大多数讨论的格式）、有序列表和无序列表。列表的作用是组合同类元素，但MediaWiki会将空行解析为列表的结尾。此外，如果列表的双空行过多，则螢幕閱讀器会读出多个列表，因而误导或迷惑用户。此类不当格式也能大幅延长读完列表所需的时间。

同样，不要在同一列表内无规律使用项目符号标记（冒号、星号或井号）。回复留言时，您需要在原本留言的项目符号之上多加一个同类字符，才算适当缩进回复。您也可以“反缩进”，发起新的讨论（即是另一个HTML列表）。

例子：

Y这是适当做法：

* 支持。我喜欢这个想法。—User:Example 
** 疑问：你为什么喜欢？—User:Example2
*** 我觉得它符合维基百科的精神。—User:Example

Y 如果留言没有项目符号，则这也是适当的：

: 支持。我喜欢这个想法。—User:Example 
:: 疑问：你为什么喜欢？—User:Example2
::: 我觉得它符合维基百科的精神。—User:Example

Y 回复时，您也可以让项目符号保持在左边：

* 支持。我喜欢这个想法。—User:Example 
*: 疑问：你为什么喜欢？—User:Example2
*:: 我觉得它符合维基百科的精神。—User:Example

N 但是不要从无序列表转为描述列表：

* 支持。我喜欢这个想法。—User:Example 
:: 疑问：你为什么喜欢？—User:Example2

N 或者从无序列表转为混合列表：

* 支持。我喜欢这个想法。—User:Example 
:* 疑问：你为什么喜欢？—User:Example2

N 不应该在列表项目之间留空行：

* 支持。我喜欢这个想法。—User:Example

** 疑问：你为什么喜欢？—User:Example2

N 也不应该跳级：

* 支持。我喜欢这个想法。—User:Example
*** 疑问：你为什么喜欢？—User:Example2

N 不鼓励以下做法：

: 支持。我喜欢这个想法。—User:Example 
:* 疑问：你为什么喜欢？—User:Example2

这里的项目符号令列表更为复杂，让回复的用户更容易用错缩进层次。

在列表项目内分段

一般MediaWiki列表语法与一般MediaWiki段落语法不相容。

Y 如欲在列表项目内写下多个段落，您可以使用{{pb}}分段：

* 这是第一项。{{pb}}这是同一项内的另一段。
* 这是第二项。

Y 您也可以使用HTML的段落标签（留意结尾的</p>标签）：

* 这是第一项。<p>这是同一项内的另一段。</p>
* 这是第二项。

Y 在以上例子中，您必须在同一代码行中使用模板，但您也可以用HTML注释包围换行，防止换行显示的同时，让留言的分段更为清晰：

* 这是第一项。<!--
--><p>这是同一项内的另一段。</p>
* 这是第二项。

Y 这个技巧可以用来在列表项目内加入各种块元素（因为列表项目也是块元素，能包含其他块元素）：

* 这是第一项。<!--
--><p>这是同一项内的另一段，这里放引用：</p><!--
-->{{talk quote block|红烧肉好吃。|User:Example}}<!--
--><p>这是同一项内的结尾段。</p>
* 这是第二项。

请注意，这个方法不适用于部分装饰模板，比如一些装饰引用模板使用表格，但MediaWiki解析器无法处理列表项目中的表格语法。

N 不要用换行模拟分段，因为它们的语义不同：

* 这是第一项。<br />这还是同一段，只是之前有换行标签。
* 这是第二项。

换行标签之后的文字依然属于同一段，而且它的作用本来是给诗歌或代码块分行。参见<poem>和<syntaxhighlight>标签。

N 切勿用冒号与缩进层级对齐，因为它会产生三个列表：

* 这是第一个列表。
: 这是第二个列表。
* 这是第三个列表。

Y 除此之外，HTML列表模板是在列表内加入块元素（比如代码）的最好方法：

{{bulleted list
|1=这是第一项：
<pre>
这是代码。
</pre>
这还是同一项。
|2=这是第二项。
}}

但讨论页面不使用这个技巧。

缩进

您可以使用{{block indent}}（原理是CSS）缩进多行文字。单行文字的缩进模板有很多种，包括所有维基媒体网站通用的{{in5}}，用各种空格字符缩进文字。不要滥用<blockquote>...</blockquote>元素或使用它的模板（如{{blockquote}}）缩进文字：它们只可用来引用文字。{{block indent}}正是为这些引用以外的用途而制作的。

MediaWiki分析器将以半角冒号（:）开始的行标记为HTML描述列表（<dl>）的<dd>部分。大多数浏览器会缩进<dd>行，因此可用来标注回复。可是，这个语法缺乏描述列表中<dd>所依赖的<dt>（术语）。由网页对浏览器输送的代码可见，这样做会令HTML代码产生错误（不符合验证标准）。因此，屏幕阅读器等辅助技术会宣告描述列表不存在，让不熟悉维基百科的标记语言的访客费解。这个习惯对无障碍、HTML语义和维基百科的转载不利，但还是十分常用。

不要在以冒号缩进的文字之间插入空行，尤其在条目内。屏幕阅读器会将其解析为另一个列表的开端。

如果需要空行，则您可以采用以下任一方法，对屏幕阅读器产生不同效果：

第一个方法是插入一个空行，再用相等数量的冒号缩进。这个方式适用于两位编辑者在同一缩进层次中相继发言的情况，比如：

: 完全同意。—User:Example
:
: 我还不信，还有更好的来源吗？–User:Example2

屏幕阅读器会将其解析为两个列表项目（无视空行）。

如果您只需要一个留言（或其他列表项目），则可以采用第二个方法：在同一行中使用分段语法：

: 文字。{{pb}}更多文字。 —User:Example3

如欲分行展示数学方程式或表示式，则建议使用<math display="block">1 + 1 = 2</math>，不用:<math>1 + 1 = 2</math>。

垂直列表

带圆点垂直列表

带圆点垂直列表中，不要用空行分隔项目，而是要使用带圆点垂直列表模板或<p>标签。（列表开端前或结尾后的空行不会产生问题。）

在列表中间插入空行的坏处是，如果项目用多个换行符分隔，则那换行符会将列表“断裂”为两个。因此，螢幕閱讀器会将其解析为多个小列表，如：

* 白色玫瑰
* 黄色玫瑰

* 粉红色玫瑰

* 红色玫瑰

MediaWiki会隐藏部分换行符，所以会显示这个：

• 白色玫瑰
• 黄色玫瑰

• 粉红色玫瑰

• 红色玫瑰

但螢幕閱讀器会读出“2个项目的列表：白色玫瑰、黄色玫瑰，结束。1个项目的列表：粉红色玫瑰，结束。1个项目的列表，红色玫瑰，结束。”

不要用换行符（<br />）分离列表项目。如果您想保持垂直结构，则可以使用{{plainlist}}或{{unbulleted list}}；如果您觉得应当将列表改为水平形式，则可以改用{{flatlist}}或{{hlist}}。

无圆点垂直列表

制作无圆点垂直列表时，{{plainlist}}和{{unbulleted list}}可以标注哪些元素明显是列表，因此能提升无障碍和语义意义。它们的差别仅在于制作列表所用的标记语法。注意，由于它们是模板，每一项的文字的竖线（|）必须要替换成{{!}}，或使用<nowiki>...</nowiki>标签包围。同样，等号（=）也要替换成{{=}}或者用<nowiki>...</nowiki>包围，但您也可以通过命名参数（|1=、|2=等）解决问题。如果这些问题太麻烦，您也可以选用{{endplainlist}}。

plainlist用例

Wikitext	显示结果
{{plainlist | * 白色玫瑰 * 黄色玫瑰 * 粉红色玫瑰 * 红色玫瑰 }}	白色玫瑰 黄色玫瑰 粉红色玫瑰 红色玫瑰

无圆点列表用例

Wikitext	显示结果
{{unbulleted list | 白色玫瑰 | 黄色玫瑰 | 粉红色玫瑰 | 红色玫瑰 }}	白色玫瑰 黄色玫瑰 粉红色玫瑰 红色玫瑰

此外，在导航模板等模板或任何合适容器中，此类列表可以使用“plainlist”class，如下：

• | listclass = plainlist或
• | bodyclass = plainlist

信息框可以使用以下：

• | rowclass = plainlist或
• | bodyclass = plainlist

参见Wikipedia:格式手册/列表 § 无圆点的列表。

其他垂直列表

上述空行问题会让编号列表的编号从头开始计数。分项问题也适用于描述（定义、关联）列表，但以{{glossary}}系列模板制作的描述列表可以包含换行符。

水平列表

制作水平列表和信息框中的单行列表时，{{flatlist}}和{{hlist}}能对每个项目使用正确的HTML语法，因此防止辅助软件读出项目符号（比如“圆点，一，圆点，二，圆点，三……”），从而提升无障碍和语义意义。它们的差别仅在于制作列表所用的标记语法。注意，用这些模板制作列表时，竖线字符（|）必须替代成{{!}}转义。

flatlist用例

Wikitext	显示结果
{{flatlist | * 白色玫瑰 * 红色玫瑰 ** 粉红色玫瑰 * 黄色玫瑰 }}	白色玫瑰 红色玫瑰 粉红色玫瑰 黄色玫瑰

hlist用例

Wikitext	显示结果
{{hlist | 白色玫瑰 | 红色玫瑰 | 粉红色玫瑰 | 黄色玫瑰 }}	白色玫瑰 红色玫瑰 粉红色玫瑰 黄色玫瑰

此外，在导航模板等模板或任何合适容器中，此类列表可以使用“hlist”class，如下：

• | listclass = hlist或
• | bodyclass = hlist

信息框可以使用以下：

• | rowclass = hlist或
• | bodyclass = hlist

列表标题

参见：MOS:PSEUDOHEAD

在列表之前误用分号制作伪标题（例1）会产生列表间隔。分号一行是没有内容的描述列表，而之后的内容属于另一个列表。

正确的做法是使用章节标题语法（例2）。

N 例1：错误

; 四书
* 《论语》
* 《孟子》
* 《大学》
* 《中庸》

Y 例2：标题

== 四书 ==
* 《论语》
* 《孟子》
* 《大学》
* 《中庸》

表格

屏幕阅读器和其他浏览工具利用特定表格标签帮助用户明白表格内容。

唯有妥当使用表格的竖线语法，才能充分利用当中功能。表格的特殊语法请见mw:Help:Tables。不要只用格式（不论CSS还是表格代码内，比如改变背景颜色）建立语义意义。

许多导航模板和信息框都是用表格制成的。避免在相邻单元格中使用<br />或<hr />模拟行。屏幕阅读器会按照HTML表格的顺序逐行阅读单元格。

数据表格

Wikitext：

{| class="wikitable"
|+ 标题
|-
! scope="col" | -{zh-hant:行;zh-hans:列;}-标题1
! scope="col" | -{zh-hant:行;zh-hans:列;}-标题2
! scope="col" | -{zh-hant:行;zh-hans:列;}-标题3
|-
! scope="row" | -{zh-hant:列;zh-hans:行;}-标题1
| 数据1 || 数据2
|-
! scope="row" | -{zh-hant:列;zh-hans:行;}-标题2
| 数据3 || 数据4
|}

效果：

标题

列标题1	列标题2	列标题3
行标题1	数据1	数据2
行标题2	数据3	数据4

标题（|+）

表格标题的作用是描述其性质。数据表格应包含标题。

行列标题（ ! ）

和标题一样，这些标题有助有逻辑地铺排信息。屏幕阅读器可以凭借标题了解有关数据单元格的信息，比如在数据单元格之前读出标题信息，或者应要求提供标题信息。因为平面阅读器可能会先读出行标题和列标题，所以您必须确保这些标题标识在自身行/列中是唯一的。

标题范围（! scope="col" |和! scope="row" |）()

标题范围能清楚指明单元格是列标题或行标题。如果列标题占据一组列，则请改用! scope="colgroup" colspan="2" |；如果行标题占据一组行，则请改用! scope="rowgroup" rowspan="2" |（数字视需要改变）。这个做法可以联系标题和对应的单元格。

Wikipedia:格式手冊/無障礙/數據表格教程就以下方面提供详细要求：

1. 适当表格标题
2. 规整标题结构
3. 复杂表格
4. 图像和颜色
5. 避免嵌套表格

格式表格

避免使用表格对齐非表格内容。数据表格在内容之外还提供额外信息和导航方式，如果用于排列没有行列逻辑关系的内容，则可能令人困惑。正确做法是使用语义合适的元素或<div>以及style属性。

如果您需要用表格对齐非表格内容，则必须让屏幕阅读器将其解析为格式表格。您应该设置role="presentation"属性，不应设置summary属性。不要在表格和嵌套表格内使用<caption>和<th>元素。就Wiki表格标记语言而言，不要使用|+和!前缀。请确保内容的阅读顺序正确。置中和粗体等视觉效果可以用样式表或语义元素实现。例如：

{| role="presentation"
|-
| colspan="2" style="text-align: center; background-color: #ccf;" | <strong>重要文字</strong>
|-
| 三个字 || 这是五个字
|-
| 又是五个字 || 再四个字
|}

重要文字 三个字 这是五个字 又是五个字 再四个字

图像

在移动端中，图像有时候会互相重叠

除特殊情况外，您应该使用Wikitext语法为图像加上题注。题注应间接描述图像的意义和所传达的重要信息。

如果详细描述不适合置于条目内，您可以将其置于描述页，并指明点击图像链接可以查看详细描述。

• 不要使用图像取代表格和图表。图表和示意图应尽量包括文字版本或详细描述，方便无法查看图像的用户明白所表达的意思。
• 除非必需，则不要在两张图像之间夹杂文字或指定图像绝对大小。
• 不要不经筛选地堆积图像，因为在特定的屏幕大小和浏览器格式下，图像会互相重叠，从而影响无障碍。条目图像过多会延长加载时间，所以一页不应包含超过100张图像（不论大小）。
• 不要在文字中用左边或右边指代图像。图像排列在移动端可能有所变化，而且这种指称在辅助技术中毫无价值。请使用题注辨识图像。

图像位置

参见：§ 章节标题和MOS:ACCESS § FLOAT

图像应该置于有关章节之内（标题和頂註之后），而非在标题中或前一节的结尾。这样能确保屏幕阅读器会在正确位置阅读图像（及其替代文字），而图像在移动端中会在适当位置出现。

此指引亦包括以<math>标签显示的LaTeX方程式的替代文字。

不要在标题中插入图像，包括旗帜图标 和<math>标签，否则会使章节链接失效，并产生其他问题。

图标

更多信息：Wikipedia:格式手册/旗帜 § 让视觉缺陷人士可辨识

非装饰性图像和图标应包含Alt屬性，方便屏幕阅读器、網路爬蟲和其他辅助技术解析。替代文字应言简意赅，或参照题注或附近文字。

动画、视频和音频

更多信息：Help:媒體幫助和Help:媒体文件的创建和使用

动画

动画（GIF）应满足以下任一条件才能达到无障碍要求：

• 时长不超过五秒（因而成为装饰性元素）
• 具备控制功能（停止、暂停、播放）

因此，时长超过五秒的GIF应转换为视频（将GIF动画转换为Theora OGG文件的教程）。

此外，动画不得在任何一秒时段内闪烁超过三次。闪烁频率超越此限的动画可能会引致癫痫发作。

视频

主条目：c:Commons:Timed Text

参见：mw:Extension:TimedMediaHandler和Commons:Video § Subtitles and closed captioning

隱藏式字幕（CC）和字幕是在视听文件显示文字的常见方法，在维基百科中用定時文本实现。它们一般都会（逐字或经过修改）转写文件的音频，有时亦包含非言语音频的描述。字幕可以帮助听障用户和非母语说话者理解多媒体文件的内容。

隱藏式字幕是视频中所有重要音频信息的文字撰写，可以包括对话、声音（自然或人为）、背景、人事物的动作和表情、文字和图像。网络上有许多编写隱藏式字幕的教程。

音频

音频文件可以添加言语、歌词、对话等的字幕，方法与视频的类似：:commons:Commons:Video/zh § 字幕。

样式和标记语言选项

最佳做法：Wiki标记语言和CSS样式表

表格和其他块级元素的样式应该使用CSS样式表（而非内文样式属性）设置。全站通用的MediaWiki:Common.css经测试，对大部分主流浏览器皆无障碍（如颜色对比度足够）且兼容。此外，用户有特定需要时可利用自己的样式表（Special:MyPage/skin.css或浏览器的样式表）调整配色方案。例如，Wikipedia:视障用户样式表为导航模板提供对比度更高的背景配色。然而，如果全站样式表被覆盖，则用户很难自选合适的主题。

全站样式表也能维持条目外观一致，从而提升专业性。

您可以使用样式表以外的配色方案，唯需符合无障碍条件即可。如果某模板或其他元素的配色方案与标准不同，作者应确保它能满足无障碍要求，比如颜色对比度够高。例如，某体育队的信息框和导航模板为了配合队伍的代表颜色，可以采用红黄配色方案。在此，深红色链接与浅黄色背景的对比度足够，但白字与黄色背景或黑字与红色背景的对比度太低。

条目一般只能用可允许HTML元素所限的Wiki标记语言标签。特别的是，如果需要装饰性的斜体和粗体，不要使用HTML样式元素<i>和<b>，反而应使用Wiki内置的''和'''；如果在此之外还需要语义意义，则请使用语义标记语言。

在条目中凸显语义差别时，不要使用<font>，反而应使用{{em}}、{{code}}等{{var}}。改变字体大小需要用{{subst:resize}}、{{subst:small}}和{{subst:Large}}实现，不要使用font-size、<big />等HTML标签。当然，这个准则也有例外，比如您可以使用<u>...</u>元素表示某个示例链接不可点击，但条目内文一般不出现下划线。

CSS或JavaScript支持有限的用户

参见：Wikipedia:格式手册 § 滚动列表与折叠元素和mw:No-JavaScript notes

条目内文不应使用自动折叠（预先折叠）元素隐藏内容。

维基百科条目应兼顾浏览器或装置缺少JavaScript或CSS支持的读者，在网页设计中称为“渐进增强”。谨记维基百科内容可以自由转载，当然也不乏浏览器陈旧的用户，但亦请明白，我们必须牺牲功能齐全的浏览器才能支持的元素，才能为这些用户提供品质相等的体验。因此，你不应该使用依赖CSS或JavaScript显示内容的元素。然而，您一般只需考虑缺乏CSS或JavaScript的用户是否可以阅读页面，因为他们的阅读体验必然不如他人。

出于以上因素，您可以关闭JavaScript和CSS，查出任何重大变化。Firefox或Chrome的用户可以通过Web Developer扩充程序实现，而使用其他浏览器的编辑者可以通过“选项”屏幕关闭JavaScript。很多浏览器、媒体和XHTML版本不支持内文CSS特效，所以处理时要特别小心。

参见

• 行话解释
• Wikipedia:行動存取
• WikiProject:可用性

延伸阅读

• Clark, Joe. Building Accessible Websites. New Riders Press. 2003 [1 January 2011]. ISBN 0-7357-1150-X. 
• Pilgrim, Mark. Dive into Accessibility: 30 Days to a More Accessible Web Site. 2002. （原始内容存档于5 October 2017）. 
• Lynch, Patrick J.; Horton, Sarah. Web Style Guide. Yale University Press. 2016. ISBN 978-0-300-21165-8. OCLC 1004033147 –通过Google Books. 

外部链接

• The Wikimedia Design Style Guide
• Recommendations for mobile friendly articles on Wikimedia wikis
• 10 Quick Tips to Make Accessible Web Sites, from WAI
• Colorblind web page filter
• Legibility, from Web Style Guide, 3rd Edition
• Essential Components of Web Accessibility, from WAI
• Introduction to Web Accessibility, from WAI
• Known and tracked MediaWiki accessibility issues

{{Wikipedia policies and guidelines}} [[Category:Wikipedia Manual of Style (accessibility)| ]] [[Category:Wikipedia accessibility| ]]