维基百科:格式手册/无障碍/2025

网站无障碍旨在让网页更易于浏览、阅读。这最初只是用于帮助身心障碍人士，但确实利于所有读者。我们致力于遵循WCAG标准2.1，基于是提出以下建议。遵守这些规范的条目方便所有人阅读、编辑。

条目结构

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

标准化是维基百科的一大习惯，因此只需遵循Wikipedia:格式手册/版面布局和Wikipedia:格式手册/序言章节 § 应该有的东西。

章节标题

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

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

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

巢状章节标题的应用例和误用例

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

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

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

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

浮动元素

参见：Wikipedia:Manual of Style/Images § Location和Wikipedia:Manual of Style/Accessibility § Images

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

参见：Wikipedia:格式手册/标注外文

中文维基百科默认会向浏览器指明条目以中文（zh）书写。非中文（外文）文字必须用{{lang}}（或其派生模板）标明。这类模板使用IETF语言标签包装文字，指定其语言和书写系统，例如：

• Assemblée nationale并未指出自己的语言（法语）。大多数屏幕阅读器处理时会读错。
• {{lang|fr|Assemblée nationale}}呈现为Assemblée nationale，屏幕阅读器处理时改用法语发音。
• {{lang-fr|Assemblée nationale}} → 法语：Assemblée nationale：同上。

理由：如果使用{{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>这是同一项内的另一段。
* 这是第二项。

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：标题

== 贵气体 ==
* 氦
* 氖
* 氩
* 氪
* 氙
* 氡

表格

Screen readers and other web browsing tools make use of specific table tags to help users navigate the data contained within them.

Use the correct wikitable pipe syntax to take advantage of all the features available. See mw:Help:Tables for more information on the special syntax used for tables. Do not solely use formatting, either from CSS or hard-coded styles, to create semantic meaning (e.g., changing background color).

Many navboxes, series templates, and infoboxes are made using tables.

Avoid using <br /> or <hr /> tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row.

数据表格

主页面：Wikipedia:Manual of Style/Accessibility/Data tables tutorial

Wikitext:

{| class="wikitable"
|+ caption text
|-
! scope="col" | column header 1
! scope="col" | column header 2
! scope="col" | column header 3
|-
! scope="row" | row header 1
| data 1 || data 2
|-
! scope="row" | row header 2
| data 3 || data 4
|}

Produces:

caption text

column header 1	column header 2	column header 3
row header 1	data 1	data 2
row header 2	data 3	data 4

Caption ( |+ )

A caption is a table's title, describing its nature. Data tables should always include a caption.

Row and column headers ( ! )

Like the caption, these help present the information in a logical structure to visitors. The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request. Because the row header and column header may be spoken before the data in each cell when navigating in table mode, it is necessary for the column headers and row headers to uniquely identify the column and row respectively.

Scope of headers (! scope="col" | and ! scope="row" |)

This clearly identifies a cell as a header for a column or row. Use ! scope="colgroup" colspan="2" | if a column header spans a group of columns and ! scope="rowgroup" rowspan="2" | if a row header spans a group of rows, adjusting the span count as needed. Headers can now be associated to corresponding cells.

Wikipedia:Manual of Style/Accessibility/Data tables tutorial provides detailed requirements about:

1. Correct table captions
2. Correct headers structure
3. Complex tables
4. Images and color
5. Avoiding nested tables

格式表格

Avoid using tables for visual positioning of non-tabular content. Data tables provide extra information and navigation methods that can be confusing when the content lacks logical row and column relationships. Instead, use semantically appropriate elements or <div>s, and style attributes.

When using a table to position non-tabular content, help screen readers identify it as a layout table, not a data table. Set a role="presentation" attribute on the table, and do not set any summary attribute. Do not use any <caption> or <th> elements inside the table, or inside any nested tables. In wiki table markup, this means do not use the |+ or ! prefixes. Make sure the content's reading order is correct. Visual effects, such as centering or bold typeface, can be achieved with style sheets or semantic elements. For example:

{| role="presentation"
|-
| colspan="2" style="text-align: center; background-color: #ccf;" | <strong>Important text</strong>
|-
| The quick || brown fox
|-
| jumps over || the lazy dog.
|}

Important text The quick brown fox jumps over the lazy dog.

Images

更多信息：Wikipedia:Alternative text for images、Wikipedia:Manual of Style § Images、Wikipedia:Image use policy § Displayed image size和Wikipedia:Image dos and don'ts

Display of a fragmented image gallery on mobile

In most cases, images should include a caption using the built-in image syntax. The caption should concisely describe the meaning of the image and the essential information it is trying to convey.

Detailed image descriptions, where not appropriate for an article, should be placed on the image's description page, with a note saying that activating the image link will lead to a more detailed description.

• Avoid using images in place of tables or charts. Where possible, any charts or diagrams should have a text equivalent or should be well-described so that users who are unable to see the image can gain some understanding of the concept.
• Avoid sandwiching text between two images or, unless absolutely necessary, using fixed image sizes.
• Avoid indiscriminate galleries because screen size and browser formatting may affect accessibility for some readers due to fragmented image display. Articles with many images may time out on mobile versions of Wikipedia. Ideally, a page should have no more than 100 images (regardless of how small). See MediaWiki:Limit number of images in a page
• Avoid referring in text to images as being on the left or right. Image placement may be different for viewers of the mobile site, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify images. (See Wikipedia:Manual of Style/Images § References from article text.)

Image placement

参见：§ Section headings、Wikipedia:Manual of Style/Images § Section和MOS:ACCESS § FLOAT

Images should be inside the section to which they are related (after the heading and any hatnotes), and not in the heading itself nor at the end of the previous section. This ensures that screen readers will read, and the mobile site will display, the image (and its textual alternative) in the correct section.

This guideline includes alt text for LaTeX-formatted equations in <math> mode. See Wikipedia:Manual of Style/Mathematics § Alt text

Do not insert images in headings; this includes icons and <math> markup. Doing so can break links to sections and cause other problems.

Icons

更多信息：Wikipedia:Manual of Style/Icons § Remember accessibility for people with visual impairment和Wikipedia:Manual of Style/Accessibility/Alternative text for images § Links and attribution

Images and icons that are not purely decorative should include an alt attribute that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users. If additional alt text is added, it should be succinct or refer the reader to the caption or adjacent text.

Animations, video, and audio content

更多信息：Help:Media和Help:Creation and usage of media files

Animations

To be accessible, an animation (GIF – Graphics Interchange Format) should either:

• Not exceed a duration of five seconds (which results in making it a purely decorative element) or
• Be equipped with control functions (stop, pause, play)

This requires that GIFs with animations longer than five seconds be converted to video (to learn how, see the tutorial converting animated GIFs to Theora OGG).

In addition, animations must not produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.

Video

主条目：c:Commons:Timed Text

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

Closed captioning (CC) and subtitling are both processes of displaying text on audio and visual files on Wikipedia through c:Commons:Timed Text. Both are typically used as a transcription of the audio portion of a program as it occurs (either verbatim or in edited form), sometimes including descriptions of non-speech elements. This aids hearing-impaired and deaf people and provides a way for non-native language speakers to understand the content in a multimedia file.

Closed captions provide a text version of all important information provided through the sound. It can include dialogue, sounds (natural and artificial), the setting and background, the actions and expressions of people and animals, text or graphics. Off-Wikipedia guides should be consulted for how to create closed captions.

Audio

Subtitles for speech, lyrics, dialogue, etc. can easily be added to audio files. The method is similar to that of the video: :commons:Commons:Video § Subtitles and closed captioning.

Styles and markup options

Best practice: wiki markup and CSS classes

In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. The site-wide CSS in MediaWiki:Common.css is more carefully tested to ensure accessibility (e.g. sufficient color contrast) and compatibility with a wide range of browsers. Moreover, it allows users with very specific needs to change the color schemes in their own style sheet (Special:MyPage/skin.css, or their browser's style sheet). For example, a style sheet at Wikipedia:Style sheets for visually impaired users provides higher contrast backgrounds for navboxes. The problem is that when the default site-wide classes are overridden, it makes it far more difficult for an individual to choose their own theme.

It also creates a greater degree of professionalism by ensuring a consistent appearance between articles and conformance to a style guide.

Regarding accessibility, deviations from standard conventions may be tolerated so long as they are accessible. Members of the accessibility project have ensured that the default style is accessible. If some template or specific color scheme deviates from the standard, its authors should make sure that it meets accessibility requirements such as providing enough color contrast. For instance, the infobox and navbox relating to a sport team might use a yellow and red color scheme, to tie in with the colors of the team livery. In this case, dark red links on light yellow provide enough color contrast, and thus would be accessible, while white on yellow or black on red would not.

In general, articles should use wiki markup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style elements <i> and <b> to format text; it is preferable to use Wiki-markup '' or ''' for purely typographic italicization and boldfacing, respectively, and use semantic markup templates or elements for more meaningful differences. The <font> element should also be avoided in article text; use {{em}}, {{code}}, {{var}}, and our other semantic markup templates as needed, to emphasize logical differences not just visual ones. Use the {{subst:resize}}, {{subst:small}}, and {{subst:Large}} templates to change font size, rather than setting it explicitly with CSS style attributes like font-size or deprecated style elements like <big />. Of course there are natural exceptions; e.g., it may be beneficial to use the <u>...</u> element to indicate something like an example link that isn't really clickable, but underlining is otherwise generally not used in article text.

Users with limited CSS or JavaScript support

参见：Wikipedia:Manual of Style § Scrolling lists and collapsible content和mw:No-JavaScript notes

Auto-collapsed (pre-collapsed) elements should not be used to hide content in the article's main body.

Wikipedia articles should be accessible to readers using browsers and devices that have limited or no support for JavaScript or Cascading Style Sheets, which is referred to as "progressive enhancement" in web development. Remember that Wikipedia content can be reused freely in ways we cannot predict as well as accessed directly via older browsers. At the same time, it is recognized that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognized that it will inevitably be inferior.

To accommodate these considerations, test any potentially disruptive changes with JavaScript or CSS disabled. In Firefox or Chrome, this can be done easily with the Web Developer extension; JavaScript can be disabled in other browsers in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.

In 2016, around 7% of visitors to Wikipedia did not request JavaScript resources.

See also

• List of style guides
• Usability:Accessibility Initiative (located at Wikimedia)
• Web Accessibility Initiative (WAI)
• Wikipedia:Accessibility dos and don'ts (key points of this guideline)
• Wikipedia:Dyslexic readers
• Wikipedia:Make technical articles understandable
• Wikipedia:Verifiability § Accessibility
• Wikipedia:Using JAWS
• Help:Mobile access
• Wikipedia:Accessibility advocates
• Wikipedia:WikiProject Accessibility
• Wikipedia:WikiProject Usability

延伸阅读

• 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| ]]