求闻百科:无障碍访问

求闻百科致力于让网页更易浏览与阅读，即无障碍。无障碍的范围比较广，不仅指能够向色盲用户、残障人士等特殊群体提供辅助功能，还包括了对常见情况下的一些基本的需求。

我们希望求闻百科的所有页面均能遵循Web内容无障碍指南（WCAG）2.1版，以让条目更易于所有人阅读与编辑。

基本原则

根据WCAG 2.1，无障碍共包含四大原则：可感知、可操作、可理解和稳健。

可感知

可感知（英语：perceivable）是指网页的内容能够以用户可感知的方式呈现。它包含以下指南：

替代文本

非文本内容内容应该有替代文本，从而让不能阅读非文本内容的用户也能够知道其内容。例如，盲人可以通过屏幕阅读器或者盲文来知晓图片或者视频中是什么内容。装饰性的内容不要求可感知。

基于时间的媒体

媒体应该要提供替代文本以呈现相同的信息。音频内容应当有字幕或者描述。（字幕功能也可以通过系统的辅助功能中的实时字幕实现。）

适应性

内容应该要可以以不同的方式呈现，而不应该丢失其信息或结构。一个信息，无论是用于理解还是指示的，不能仅通过形状、大小、位置、方向等感官特性呈现。内容的信息和关系应该要正确指定（参见#条目结构和#块元素）。

可辨别

颜色不能用途传达信息的唯一手段，对比度应该要符合要求（参见#颜色）。此外，大多内容应该可以在不同时滚动两个方向的滚动条的情况下完整呈现，除非无法实现（如图表、地图等）。

可操作

可操作（英语：operable）是指网页内容组件和导航必须是可操作的。

键盘可访问

网页内容（尤其是对于小工具）必须可以在仅使用键盘的情况下就完成大部分的操作，且不能有键盘陷阱。

充足的时间

除非必要，网页的功能应该要给用户充足的时间以使用其功能，对于有时间限制自动操作的内容，除非必要，应该要允许用户取消此时间限制。

癫痫和身体反应

禁止设计会导致癫痫发作或身体反应的内容，如闪光超过每秒3次的内容，或低于一般闪光和红色闪光阈值的闪光。

可导航

要求网页中重复出现的内容块可以跳过，此外还有一些其他的要求，这些主要都是通过皮肤界面实现的，与条目内容的关联性不大。

输入模式

用户能够通过键盘以外的各种输入更轻松地操作功能。 这些主要都是通过皮肤界面实现的，与条目内容的关联性不大。

可理解

可理解（英语：understandable）是指不同类型的用户都可以理解其内容。

可读

指定内容语言。每个页面都自动指定的语言，一般不需要用户去操作，但是部分内容可能需要用户手动去指定，参见#外语。

可预测

这个是主要对于网页界面尤其是小工具的。组件接收焦点不能够有上下文变化。

输入辅助

任何需要用户输入的地方，都应该提供标签或说明。

稳健

稳健（英语：robust，也称“健壮”）是指内容能够被各种各样的用户代理（包括辅助技术）解释。稳健性主要体现在以下方面：

兼容

遵循HTML规范，元素应当有完整的开始和结束标签，并根据其规范行嵌套，不得包含重复的属性，且任何ID都是唯一的，除非规范允许这些特性。

章节标题

章节标题的内容应该要概括这一章节的主要内容。

章节标题应该以二级（==）开始，接下来是三级（===）等，禁止使用一级标题。禁止随意使用章节标题层级，或者任何形式的“跳级”。

请避免使用加粗或“分号语法”生成伪章节标题，除非这些内容即使没有被视为标题也不影响阅读（通常是内容较少的情况）。屏幕阅读器等辅助功能在对标题进行导航时，只能使用正确格式的章节标题。如果你想缩减目录长度，请使用模板链接：{{TOC limit}}。

正确标题示例：

这是条目序言
== 二级标题 ==
=== 三级标题 ===
== 二级标题 ==
=== 三级标题 ===
==== 四级标题 ====
== 二级标题 ==

随意使用层级的错误标题示例：

这是条目序言
==== 四级标题 ====
=== 三级标题 ===
== 二级标题 ==
== 二级标题 ==
==== 四级标题 ====
=== 三级标题 ===

跳级标题的错误示例：

这是条目序言

此处缺失二级标题
=== 三级标题 ===
== 二级标题 ==
此处缺失三级标题
==== 四级标题 ====
== 二级标题 ==

伪章节标题示例：

这是条目序言
== 二级标题 ==
=== 三级标题 ===
'''伪章节标题'''
== 二级标题 ==
=== 三级标题 ===
; 伪章节标题
== 二级标题 ==
== <small>伪三级标题</small> ==

请勿滥用加粗或“分号语法”来生成“伪章节标题”，“分号语法”（行首半角分号）专用于定义列表，而屏幕阅读器和其他辅助工具仅能使用被系统认为是的标题来导航定位。但是，如果其标题层级对内容不重要，例如内容较少，使用标题反而会比较冗余，这种情况下也可以使用伪标题。

可接受的例子：

条目首段
== 二级标题 ==
=== 三级标题 ===
'''伪标题'''
== 二级标题 ==
=== 三级标题 ====
; 术语
: 定义
; 术语
: 定义

不可接受的例子：

条目首段
== 二级标题 ==
=== 三级标题 ===
; 伪标题
== 二级标题 ==
=== 三级标题 ===
== <small>伪三级标题</small> ==

浮动元素

在源代码中，浮动元素（包括浮动的图像）应置于所属的章节之内。虽然源代码语法中图像置于页面顶部，但可能被其它浮动元素推到目录下方显示。

无法正常屏幕阅读的内容

阅读求闻百科的读者不一定是通过观察屏幕来阅读其内容的，一些读者存在视力残疾，需要通过屏幕阅读器（又称“讲述人”（英语：narrator）或“复述功能”）来了解内容，并进行操作。因此，需要确保这些内容（除了仅用途装饰的之外）也能够正常被屏幕阅读。

特殊符号

一些符号可能无法正常地被屏幕阅读器阅读，这种情况下，可以尝试使用加有替代文本的图像。例如，符号“♥”（心形符号）可能无法被阅读，可以使用“”等图像取代，屏幕阅读器在阅读时，将会读出“心形”这个词。

如果上述内容仅用于装饰（参见#装饰），则无需遵守上述规则。

非文本形式的可交互组件或表意内容

在一些页面上（特别是在一些小工具中），会有一些没有使用文本而仅使用图标的可交互组件，这在求闻百科的网站皮肤上也很常见。例如，用一个铃铛的图标表示“通知”按钮，用一个放大镜的图标表示“搜索”按钮。对于这类可交互组件，务必做到以下几点：

• 提供相应的title或name属性（或其他有关的HTML语义）来表明其目的，使得用户在把鼠标悬停在该可交互组件上或将焦点聚集在该可交互组件时，能够看到其文本描述，这样就不会导致看到没有文字的可交互组件后产生困惑。
  • 对于有可见的文本描述的可交互组件，也建议如此，但这不一定是必需的。
• 提供相应的可屏幕阅读的内容，这样屏幕阅读器在阅读此可交互组件时，能够直接将其内容读出来。如果相应内容不是由<button>或类似标签组成的，提供可屏幕阅读的内容的方法请见下文。

此外，还有一些内容，需要表达相应的意思，但是它并没有相应的文本。例如，在某网站上，需要用颜色来表示各个功能的支持情况，于是用以下的方式来表示各个颜色与支持情况的对应关系：

• 
  = 支持
• 
  = 不支持
• 
  = 部分支持

有完整视觉和色觉的人可以知道，上面这个内容表达的意思是，绿色表示支持，红色表示不支持，棕黄色表示的是部分支持。等号前的色块表示了这一个颜色。色盲用户无法识别颜色，但仍可通过其颜色中的条纹，看出无条纹的表示支持，斜条纹的表示不支持，纵向条纹的表示部分支持。但如果是使用屏幕阅读器的用户，就会感到困惑：屏幕阅读器说，“等于支持，等于不支持，等于部分支持”，这是啥意思？实际上，在上面这个例子中，我们使用了空白的<span>...</span>来表述颜色，但它没有内容，屏幕阅读器不知道怎么读。

因此，为了照顾屏幕阅读器，我们需要在里面加入不会渲染在屏幕但是会被屏幕阅读器阅读出来的内容，例如：

• 绿色 = 支持
• 红色 = 不支持
• 棕黄色 = 部分支持

从表面上看，这个例子和前面的那个例子没有区别。但是如果启用屏幕阅读器，就会发现，屏幕阅读器读的是“绿色等于支持，红色等于不支持，棕黄色等于部分支持”。这样，使用屏幕阅读器的盲人也能够知道这些内容所表达的意思。

使元素可被屏幕阅读器阅读但不渲染在屏幕上的方法

在前面提到的这个例子中，我们给元素添加了文本，并使得这些文本不渲染在屏幕上，但能够被屏幕阅读器阅读。display: none和visibility: hidden会使得内容隐藏后也不会被屏幕阅读器阅读，因此不符合其要求。以下几种方法可以使内容不会渲染在屏幕上但仍能被屏幕阅读器阅读：

• 使用text-indent: -99999px，这是最简单粗暴的方法，但是非常有效。例如：这个内容不会显示但是会被读出来。
• 使用clip-path: inset(50%)。这也会使得元素不显示，但是不影响屏幕阅读器。例如：
  这个内容不会显示但是会被读出来。

需要注意，以下几种方式不建议：

• 使用position: absolute; opacity: 0：这样的内容在不显示的同时，仍然会被鼠标像在选择文本一样选中，影响对其他普通内容的选择，还可能导致困惑。
• 将元素移动到非常远的位置，例如position: absolute; left: 99999px或position: fixed; left: 200%：这会使得元素的边界无法正常显示。屏幕阅读器在阅读内容时，会突出显示正在阅读的内容的边框，而在阅读此内容时，边框消失了，或者屏幕滚动到了异常的位置，因此这种方式也会产生困惑。

仅装饰的内容

仅装饰的内容不需要被屏幕阅读器阅读，或者以其他形式被辅助技术识别，否则，反而可能会产生困惑。对于这类内容，如果其有文本，可以给相应的元素添加aria-hidden="true"以从辅助功能树中隐藏。

文字格式

删除线

在条目页面中，请勿使用删除线划去任何文字。如有需要，请使用“<!--”和“-->”注释处理，或直接移除。

请避免在导航框或者类似的列表、表格中，使用仅删除线来表示某项目已失效。可以直接通过括注文本的形式来表明，也可以两者都有。例如（在导航框中）：

• 错误：张江有轨电车
• 正确：张江有轨电车（已停运）
• 正确：张江有轨电车（已停运）

屏幕阅读器通常不支持呈现文本属性（粗体、斜体、下划线）乃至语义文本属性（强调、重要、文字删除），因此带删除线的文字和正常文字阅读效果相同。此外，在上述使用删除线的情形中，请使用<del>...</del>，不得使用<s>...</s>。

如果条目内有错误的内容，不要使用删除线。这些内容应该使用注释处理，或者直接移除；你也可以用某个行内清理模板进行标记，并在讨论页上提出意见。

字体大小

主页面：QW:TEXT § 字号

谨慎使用缩小和放大字体。字号通常是由页面元素自动决定，如标题、列表标题、标准模板。改变字号时，应当用原字体的百分比大小（相对大小）描述，而不用像素或点数描述绝对大小，以便利默认使用较大字体的用户。

避免在信息框、导航模板和参考章节等已经为小字体元素的地方再次使用缩小字体。所以，<small>...</small>标签，及{{small}}、{{smaller}}等模板，不应用于该些页面元素的纯文字。无论何时都不应该使用比85%（或11像素）还小的字体。注意HTML的<small>...</small>标签还有“小字条款”的含义，不用作字体风格变化。

语言元数据

主页面：Template:Lang/doc § 使用理由

非中文单词或短语应以使用ISO 639语言代码的模板链接：{{lang}}包围，这样可以有助于屏幕阅读器阅读，同时提高内容的稳健性，因为搜索引擎和人工智能可能需要识别内容的语言以正好地理解内容，此外系统还可以根据这个来选择合适的字体。例如：

• 正确的例子：国民议会，法语称为{{lang|fr|Assemblée nationale}}，是法国的机构，与参议院一起组成第五共和国议会。
• 错误的例子：国民议会，法语称为Assemblée nationale，

或者，您也可以使用{{lang-fr|Assemblée nationale}}，例如：

• 正确的例子：国民议会（{{lang-fr|Assemblée nationale}}）是法国的机构，与参议院一起组成第五共和国议会。
• 显示效果：国民议会（法语：Assemblée nationale）是法国的机构，与参议院一起组成第五共和国议会。

模板链接：{{lang}}或者以“lang-”开头的一系列模板均可以使语音合成器以正确的语言发音。

此外，在求闻百科中，对于日语如不使用模板，则日本汉字可能会被视作中文错误简繁转换。

链接

链接（包括内部链接和外部链接）的显示文本应该能够描述链接的目的，而不是“点此”“此处”“查看更多”这样的文本。链接是可交互元素，如果使用屏幕阅读器的用户使用Tab键在链接之间进行导航，听到的却是“链接：点此”“链接：点击此处”，就会感到困惑。因此，链接的显示文本应该能够表现出链接的主要内容。链接的目的应该要能够仅从链接的显示文本中就推断出来。

例如：

• 错误：点击此处以了解如何使用表格。（仅从“此处”二字无法推断出链接的目的。）
• 正确：请参考Help:表格以了解如果使用表格。（从显示文本中可以推断出，链接的目的是一个叫做“Help:表格”的页面。）
• 正确：点击此处以了解如何使用表格。（链接文本是整个句子，能够表现出链接的目的。）

颜色

颜色最常用于表现某个内容的状态，吸引读者的注意，或者颜色是与条目的内容相关的。此外，一些内容的颜色可能会起到装饰性作用。但是，使用颜色时，需注意无法看到有关颜色的读者，以及确保能够看到有关颜色的读者能够清楚地将其辨别出来。

颜色不是传达信息的唯一方式

任何内容都不能够仅通过颜色的方式来表达。这是因为，不是所有的读者都能够准确地看到内容的颜色。一些人可能会需要通过屏幕阅读器或者盲文来阅读其内容，或者其显示介质本身就是没有彩色的，或者读者无法观察到颜色。因此，在使用颜色的同时，务必使用非颜色的方式来相等地表达其内容。

例如：

某活动成员列表

名字		年龄	籍贯	居住地
	甲	15	苏州	嘉兴
	乙	16	南京	滁州
	丙	15	上饶	上饶
	丁	18	乌鲁木齐	上海
	戊	17	台北	郴州
	己	14	台州	温州
说明：红队、绿队、蓝队

上面这个表格列举了某活动内各个成员的基本信息，以及其分组情况，不同的分组是通过颜色来展示的。名字前面的单元格的颜色表示了该成员所属的队伍。但是，其队伍的信息只有拥有正常的视觉与色觉在彩色显示器上阅读时，才能够理解，对于色盲或者使用屏幕阅读器或盲文的用户而言难以理解，且如果不理解其颜色，表格底部的：“说明：红队、绿队、蓝队”更是令人费解。因此，我们可以对上述表格进行如下的修改：

某活动成员列表（修改后）

名字		队伍	年龄	籍贯	居住地
	甲	红队	15	苏州	嘉兴
	乙	蓝队	16	南京	滁州
	丙	红队	15	上饶	上饶
	丁	绿队	18	乌鲁木齐	上海
	戊	蓝队	17	台北	郴州
	己	绿队	14	台州	温州

这个，即使是色盲用户或者使用屏幕阅读器或盲文的盲人，也能够知道每个成员是属于哪个队伍的。同样，以文本形式将其内容表达出来，也有助于搜索引擎和人工智能工具的理解和优化。

对比度

任何文本或者其他形式内容的前景色和背景色都应该有足够的对比度。例如，不要在浅色的背景上使用浅色的文字，或者在深色的背景上使用深色的文字，否则这些内容看不清，或者即使你能看清楚，但是部分存在视力障碍的人无法看清楚。例如：

说明	效果	对比度
白色背景黄色文字	白色背景黄色文字	1.0738392309266
白色背景灰色文字	白色背景灰色文字	3.9494396480491
红色背景绿色文字	红色背景绿色文字	1.2848399716615
青色背景黑色文字	青色背景黑色文字	16.748

对于拥有视力的读者，观察上面这个表格，可以发现：第一行的白色和黄色非常接近，因此在白色背景上的黄色文字非常不明显，基本难以看清。第二行大多数读者可以看清，但是如果读者有视力问题，可能仍会遇到一些困难，需要将内容放大才能够看清楚里面的内容。第三行或许也能够看清，但如果读者因色盲或者色弱而难以区分红色和绿色，则在阅读时可能存在一定的困难。而第四行，青色是比较浅的颜色，与黑色形成了一定的对比度，因此是能够看清楚的。

根据Web内容无障碍指南2.1的标准，文本的前景色与背景色应达到如下标准（有两种标准）：

• 最小标准（AA级）：文本的对比度不小于4.5，其中大文本的对比度不小于3。
• 增强标准（AAA级）：文本的对比度不小于7，其中大文本的对比度不小于4.5。

根据上述标准，在上面的例子中，只有“青色背景黑色文字”是符合标准的，且符合了AAA级标准。

对比度的计算方式

根据Web内容无障碍指南2.1，文本的对比度（英语：contrast ratio）的计算方式如下：

对比度 = $\dfrac{L1 + 0.05}{L2 + 0.05}$，其中$L1$和$L2$表示两个颜色的相对亮度。

对于sRGB颜色空间，颜色的相对亮度（英语：relative luminance）的计算公式为:

$L = 0.2126 * R + 0.7152 * G + 0.0722 * B$

其中，R、G、B的定义如下：

• 如果$RsRGB \le 0.04045$，那么$R = \frac{RsRGB}{12.92}$，否则$R = \left(\frac{RsRGB+0.055}{1.055}\right) ^ {2.4}$
• 如果$GsRGB \le 0.04045$，那么$G = \frac{GsRGB}{12.92}$，否则$G = \left(\frac{GsRGB+0.055}{1.055}\right) ^ {2.4}$
• 如果$BsRGB \le 0.04045$，那么$B = \frac{BsRGB}{12.92}$，否则$B = \left(\frac{BsRGB+0.055}{1.055}\right) ^ {2.4}$

其中，RsRGB、GsRGB、BsRGB的定义如下：

• $RsRGB = R8bit \div 255$
• $GsRGB = G8bit \div 255$
• $BsRGB = B8bit \div 255$

对比度检查工具

可以选择这些工具检查对比度是否正确：

• 色彩对比分析器使您能够挑选在页面上的颜色，并充分检查其对比度。但请务必只使用最新的“亮度”算法，而非过时的“色彩亮度/差”。
• 你还可以选择完全更新的斯努克的色彩对比工具。
• Google Chrome Canary有一个带有视觉指南和颜色选择器的颜色对比度调试器。
• 网上还有其它工具，但请在使用前检查它们是否更新。一些工具以WCAG 1.0算法为基础，而我们应该参考现今的WCAG 2.0算法。如果工具没有提到其基于WCAG 2.0，则假设它过时。
• 您可以将两种颜色输入模板链接：{{Color contrast ratio}}模板，以计算其对比度；一般推荐小字与背景颜色的对比度在4.5以上，大字与背景颜色的对比度在7以上。

此外还有工具可以协助制作图形图表，或是地图等的配色方案。这些工具对于对比度亲和力检查并不严格，但其可以在特定任务上有帮助作用。

• 配色方案生成器（Paletton）可以协助在图表中选择好的颜色搭配。
• 色彩酿造师2.0（Color Brewer 2.0）提供了地图的安全配色方案和详细讲解。
• 浅色定性配色方案（Light qualitative colour scheme）提供了一组9种颜色，适用于色盲用户，并带有黑色文本标签（以及其他调色板）。
• 有一些工具可以模拟色盲视觉：toptal（网页分析）和coblis（本地文件分析）；还有用于网页分析的浏览器扩展：Colorblinding（Chrome）、NoCoffee（Chrome）、NoCoffee（FireFox）
• Color Oracle是非常简单的开源工具，可以帮助选择对比色，其自称为“适用于Windows、Mac和Linux的免费色盲模拟器”。它可以让你看到屏幕上的任何东西，就像患有三种色盲之一或灰度的人看到的一样。

如果条目过度使用颜色，但你不知道如何亲自修复，则可请其他编辑协助。请将模板链接：{{Overcolored}}放置于条目顶部。

需要准确表达的颜色

有些情况下，一些条目需要将一些颜色进行描述，使用了这个颜色，例如，下面这个例子直接给文本上了颜色：

武汉轨道交通2号线的标志色为梅花红。

这种做法有几个缺点：

• 梅花红色是比较淡的颜色，在浅色的背景上显示得不是很清楚。
• 在深色模式下，受到其机制的影响，梅花红会被扭曲成深红色，导致与实际情况不符。
• 如果颜色正好接近红色、蓝色或者紫色，则容易被误以为是链接。

一种可行的方案，是使用模板链接：{{color box}}或模板链接：{{color block}}模板，例如：

武汉轨道交通2号线的标志色为 梅花红 。

武汉轨道交通2号线的标志色为
梅花红。

根据此模板的运作机制，模板链接：{{color box}}模板会自动选择一个对比度高的颜色用于文本的显示。同时，由于使用了mw-no-invert类，在深色模式下，颜色会被纠正为原来的颜色。其中，第二种写法是更好的，因为它可以确保文本的部分与背景保持应有的对比度。

除此之外，还有很多用于装饰的场合也会使用需要准确表达的颜色。例如，在与轨道交通线路有关的模板中，通常会以装饰为目的而使用线路标志色，这些颜色也应该通过增加mw-no-invert类的方式，避免其在深色模式下被转换。

列表

参见：Help:列表

在页面中往往会出现各种形式的列表，用于列举一系列的内容。列表不仅提供了一个外观，在代码层面，不同列表的使用还代表了一定的语义。因此，使用列表时，应当遵循相应的规范。

不要拆散列表

不要在列表项间用空行或表格切断。如果使用空格或者其他内容将列表切断，那么将会变成多个列表，也就是说一个列表结束后开户了新的列表。例如：

您所输入的

* 白玫瑰
* 黄玫瑰

* 粉红玫瑰

* 红玫瑰

您所看到的

• 白玫瑰
• 黄玫瑰

• 粉红玫瑰

• 红玫瑰

可能你已经看出来了，这个列表的的各项之间的显示间距有问题。实际上这个列表是多个列表组成的。如果使用屏幕阅读器（以Windows系统的讲述人为例），那么屏幕阅读器会这么读：

输入列表，2的1，项目符号，白玫瑰，2的2，项目符号，黄玫瑰，退出列表。

输入列表，1的1，项目符号，粉红玫瑰，退出列表。

输入列表，1的1，项目符号，红玫瑰，退出列表。

正确的做法应该是将一个列表连贯到底，例如：

您所输入的

* 白玫瑰
* 黄玫瑰
* 粉红玫瑰
* 红玫瑰

您所看到的

• 白玫瑰
• 黄玫瑰
• 粉红玫瑰
• 红玫瑰

在讨论页中，也是遵循相同的规则，不要在讨论串中切断列表，下面这个例子就是错误的：

您所输入的

* 支持，我喜欢此想法。——User:Example 

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

您所看到的

• 支持，我喜欢此想法。——User:Example

• • 疑问：你为何喜欢？——User:Example2

不要中途改换列表形式

请勿在同一个、同一层级的列表中，混用不用种类的列表，即在源代码中，中途更换行首的符号（分号、星号、井号）。在讨论页，如果您是在源代码模式下回复他人的留言，若对方行首混合用符号，则需要先复制该串符号，后另加一个符号，以正确缩进。开新话题，则取消缩进即可（等同开一个新的HTML表）。

例如，以下做法都是可以接受的：

您所输入的

仅使用星号（无序列表）的例子：

* 支持，我喜欢此想法。——User:Example 
** 疑问：你为何喜欢？——User:Example2
*** 这似乎合乎求闻百科的宗旨和基本原则。——User:Example

您所看到的

仅使用星号（无序列表）的例子：

• 支持，我喜欢此想法。——User:Example
  • 疑问：你为何喜欢？——User:Example2
    • 这似乎合乎求闻百科的宗旨和基本原则。——User:Example

您所输入的

仅使用冒号（定义列表）的例子：

: 支持，我喜欢此想法。——User:Example 
:: 疑问：你为何喜欢？——User:Example2
::: 这似乎合乎求闻百科的宗旨和基本原则。——User:Example

您所看到的

仅使用冒号（定义列表）的例子：

支持，我喜欢此想法。——User:Example

疑问：你为何喜欢？——User:Example2

这似乎合乎求闻百科的宗旨和基本原则。——User:Example

您所输入的

一级列表为无序列表、二级列表为定义列表的例子：

* 支持，我喜欢此想法。——User:Example 
*: 疑问：你为何喜欢？——User:Example2
*:: 这似乎合乎求闻百科的宗旨和基本原则。——User:Example

您所看到的

一级列表为无序列表、二级列表为定义列表的例子：

• 支持，我喜欢此想法。——User:Example

  疑问：你为何喜欢？——User:Example2

  这似乎合乎求闻百科的宗旨和基本原则。——User:Example

请勿在中途改换为不同的列表格式

您所输入的

无序列表改换为定义列表的错误例子1：

* 支持，我喜欢此想法。—User:Example 
:: 疑问：你为何喜欢？—User:Example2

您所看到的

无序列表改换为定义列表的错误例子1：

• 支持，我喜欢此想法。—User:Example

疑问：你为何喜欢？—User:Example2

您所输入的

无序列表改换为定义列表的错误例子2：

* 支持，我喜欢此想法。—User:Example 
:* 疑问：你为何喜欢？—User:Example2

您所看到的

无序列表改换为定义列表的错误例子2：

• 支持，我喜欢此想法。—User:Example

• 疑问：你为何喜欢？—User:Example2

不要越级

一级列表的下一级是二级列表，然后是三级，不要从一级列表跳到三级列表。例如，下面这个做法就是错误的：

您所输入的

* 兰花
* 玫瑰
*** 白玫瑰
*** 黄玫瑰
*** 粉红玫瑰
*** 红玫瑰
* 牡丹
* 杜鹃

您所看到的

• 兰花
• 玫瑰
  • • 白玫瑰
    • 黄玫瑰
    • 粉红玫瑰
    • 红玫瑰
• 牡丹
• 杜鹃

您所输入的

* 支持，我喜欢此想法。—User:Example 
*** 疑问：你为何喜欢？—User:Example2

您所看到的

• 支持，我喜欢此想法。—User:Example
  • • 疑问：你为何喜欢？—User:Example2

列表项中的多个段落

MediaWiki的列表标记与普通的MediaWiki段落标记不兼容。若要在列表项中放置多个段落，请使用模板链接：{{pb}}模板将其分开。

您所输入的

* 这是列表中的第一项的第一行。{{pb}}这是列表第一项中的第二行。
* 这是列表中的第二项。

您所看到的

• 这是列表中的第一项的第一行。
  这是列表第一项中的第二行。
• 这是列表中的第二项。

换行符（<br />）是在段落内折行，而不是开启新的段落，因此不能用来形成新段落。

您所输入的

* 这是列表中的第一项。<br>这是列表第一项中的第二行，但行前有一个换行符。
* 这是列表中的第二项。

您所看到的

• 这是列表中的第一项。
  这是列表第一项中的第二行，但行前有一个换行符。
• 这是列表中的第二项。

不要混用列表符号和半角冒号做缩进排版，因为这会导致一个列表被分裂为三个。从外观上看，似乎是开启了新的段落，而且对齐的，但是这在语义上是不正确的，且容易产生困惑。

您所输入的

* 这是第一个列表中的第一项。
: 这是另一个定义列表。
* 这是第三个列表中的第一项。

您所看到的

• 这是第一个列表中的第一项。

这是另一个定义列表。

• 这是第三个列表中的第一项。

可以使用HTML列表模板之一，以确保列表不会意外分开。若列表中包括块元素（如<pre>...</pre>），则这一技巧非常有用。

{{bulleted list
|1=这是列表中的第一项：
<pre>
<?php

print('Hello world!');
</pre>
这仍在第一项范畴内。
|2=这是列表中的第二项。
}}

您所输入的

{{ordered list
|1=这是列表的第一项的第一段。

这是列表的第二项的第二段。
|2=这是列表的第二项，然后有一个表格：

<table class="wikitable"><tr><td>这是一个表格。</td></tr></table>
|3=这是列表的第三项，然后有一段代码：
<syntaxhighlight lang="java">
public class ExampleClass implements ModInitializer {
  @Override
  public void onInitialize() {
    System.out.println("Hello world!");
  }
}
</syntaxhighlight>
|4=这是列表的第四项。
}}

您所看到的

1. 这是列表的第一项的第一段。 这是列表的第二项的第二段。
2. 这是列表的第二项，然后有一个表格：

   这是一个表格。

3. 这是列表的第三项，然后有一段代码：

   public class ExampleClass implements ModInitializer {
     @Override
     public void onInitialize() {
       System.out.println("Hello world!");
     }
   }
   

4. 这是列表的第四项。

缩进

多行内容的缩进方法是模板模板链接：{{block indent}}，使用CSS实现缩进。对于单行内容，可以使用多种模板实现缩进，包括但不限于模板链接：{{in5}}等，这些模板使用各种空白字符缩进。不要滥用<blockquote>...</blockquote>元素或使用它的模板（如模板链接：{{Quote}}）进行视觉缩进，这些标记、模板只用于条目中的直接引语。

以英文冒号起头的行会缩进。比如这种用法会在讨论页的往来讨论中表示回复。该缩进是使用了HTML的定义列表。这在可亲和性和语义学上都并不理想，但目前却广泛应用。缩进行之间不应插入空行，因为这表示列表的结束并开启新列表。如果确实需要空行，请插入一个以同样数量冒号起头的额外行。

MediaWiki解析器将带有行首冒号（:）的所在行标记为HTML描述列表（<dl>...</dl>）的一部分（<dd>...</dd>）。在大多数网络浏览器中，其视觉效果是缩进行。例如，这用于表示讨论页中讨论串中的回复。然而，仅包含此标记就缺少描述列表中所需的<dt>元素（语义为“术语”），而<dd>元素（语义为“描述”“定义”）与该元素相关。通过检查发送到浏览器的代码可以看出，这会导致HTML损坏（即验证失败）。结果是，屏幕阅读器等辅助技术会报出一个实际上不存在的描述列表，这让任何不习惯MediaWiki所输出非标准HTML的访问者感到困惑。这并不利于无障碍访问，不符合HTML语义原则，也不利于其他用户对内容加以利用。尽管它会给屏幕阅读器的用户带来问题，但在MediaWiki中很常用。

空行不能放在冒号缩进的文本行之间，尤其是在文章内容中。这被软件解释为标记列表的结束和新列表的开始。如果需要空行，请在其上放置与空行下方文本前相同数量的冒号，例如：

: 此处有文字。
:
: 更多文字。

另一个解决方案是新的段落标记（<p>...</p>），但它必须在源代码中的同一行中：

: 文字。<p>新段落文字。</p>

垂直列表

无序垂直列表

对于无序垂直列表，请不要在项目之间用空行隔行。如果列表项之间有超过一次换行，HTML列表将会在换行后结束，并在下一项的换行之前开启一个新HTML列表。这种有效换行在屏幕阅读器中会被视为几个小列表。比如N代码：

* 白玫瑰
* 黄玫瑰

* 粉红玫瑰

* 红玫瑰

因为软件抑制了行距，所以看起来如：

• 白玫瑰
• 黄玫瑰

• 粉红玫瑰

• 红玫瑰

但是屏幕阅读器读者看起来是：“输入列表，2的1，项目符号，白玫瑰，2的2，项目符号，黄玫瑰，退出列表。输入列表，1的1，项目符号，粉红玫瑰，退出列表。输入列表，1的1，项目符号，红玫瑰，退出列表。”

请不要以换行符分隔列表项目。请用以下方法代之。

无项目符号垂直列表

对于页面中纵向列出的无项目符号列表，可使用模板模板链接：{{plainlist}}和模板链接：{{unbulleted list}}来提高亲和性语义意义，表明这是一个清晰的列表，而非通过不应使用的<br />换行。

代之在导航框一类模板或合适的容器中，可以使用CSS类“plainlist”，也就是：

| listclass = plainlist或

| bodyclass = plainlist

在信息框中则可以使用：

| rowclass = plainlist

或者

| bodyclass = plainlist

另见Qiuwen:格式手册/列表#无项目符号列表。

水平列表

对于页面中横向列出的，以及信息框等表格中在一行内列出的列表，请使用模板链接：{{flatlist}}和模板链接：{{hlist}}模板提升亲和力和与语义意义。该特性对各列表项使用了正确的HTML标记，而不包含视障人士用辅助软件会读出的项目符号符号（比如“点－猫－点－狗－点－马－点……”）。

代之在导航框等模板或相似的容器中，列表可以使用CSS类“hlist”格式，也就是：

| listclass = hlist或

| bodyclass = hlist

信息框中可使用：

| rowclass = hlist或

| bodyclass = hlist

列表标题

参见： § PSEUDOHEAD

不应使用半角分号在列表前生成 "假标题"（图1）；语义上，分号开头的列表应接续一组以半角冒号开头的列表，以表示术语表的标题及其条目（图2）。若要表示一组无序列表，应使用章节标记（图3）。

N 图1 不正确

; 稀有气体
* 氦（He）
* 氖（Ne）
* 氩（Ar）
* 氪（Kr）
* 氙（Xe）
* 氡（Rn；放射性）
* 鿫（Og；人工合成，存疑）

图2 定义列表（正确）

; 稀有气体
: 氦（He）
: 氖（Ne）
: 氩（Ar）
: 氪（Kr）
: 氙（Xe）
: 氡（Rn；放射性）
: 鿫（Og；人工合成，存疑）

图3 章节标题及无序列表（正确）

=== 稀有气体 ===
* 氦（He）
* 氖（Ne）
* 氩（Ar）
* 氪（Kr）
* 氙（Xe）
* 氡（Rn；放射性）
* 鿫（Og；人工合成，存疑）

表格

屏幕阅读器和其它网页浏览器工具通过特定表格标签帮助用户导航其中记录的数据。

使用正确的维基表格管道语法利于所有可用特性。见Help:表格获得更多关于表格特定语法的信息。请不要单独使用格式——从CSS或硬编码风格——创建语义意义（如改变背景颜色）。

“系列模板”及信息框由表格制成。

通过在相邻单元格中嵌入成组的HTML<br>、<hr>标签，可以在视觉上创建多行信息框，不过该技术并不适合HTML表格结构。屏幕阅读器用户是以单元格和HTML行为单位阅读，而非以视觉上的行阅读，因此这对它们会产生问题。

数据表格

以下给出了数据表格的示例：

{|
|+ [标题文字]
|-
! scope="col" | [列标题1]
! scope="col" | [列标题2]
! scope="col" | [列标题3]
|-
! scope="row" | [列标题1]
| [常规单元格1,2] || [常规单元格1,3]
|-
! scope="row" | [列标题2]
| [常规单元格2,2] || [常规单元格2,3]
...
|}

标题文字（|+）

标题文字是表格的题头，描述其性质。

行、列标题（ ! ）

如同标题文字，它们使信息以更为逻辑的结构展现给读者。行列标题有助于屏幕阅读器显示数据单元格的标题信息。例如：标题信息会在单元格数据之前念出，或标题信息根据要求提供。

标题的范围（ ! scope="col" | and ! scope="row" | ）

这清晰的定义了行标题或列标题，指明了标题和其他单元格的对应关系。

简而言之，数据表格应满足下列要求：

1. 正确的表格标题
2. 正确的标题结构
3. 图像和颜色
4. 避免嵌套表格

排版表格

请避免使用表格做纯排版用途。数据表提供了额外的信息和导航方法，当内容缺乏逻辑行和列关系时，这些信息和导航方式可能会令人困惑。

最佳的选择是使用更有适应性的HTML的<div>块和样式（style）属性。

使用表格定位非表格内容时，帮助屏幕阅读器将其识别为布局表格，而不是数据表格。在表上设置role="presentation"属性，并且不设置任何summary属性。不要在表内或任何嵌套表内使用任何<caption>或<th>元素。在wiki表标记中，这意味着不要使用|+或!前缀。确保内容的阅读顺序正确。视觉效果（如居中或粗体）可以通过样式表或语义元素来实现。例如：

{| role="presentation" class="toccolors"
| colspan="2" style="text-align: center; background-color: #ccf;" | <strong>重要文本</strong>
|-
| 一去二三里 || 烟村四五家
|-
| 亭台六七座 || 八九十支花
|}

图像

更多信息：Qiuwen:格式手册 § 图像和Qiuwen:文件使用守则 § 大小

1. 所有非装饰的图像都要有替代文字。替代文字是给视障人士读者、搜索蜘蛛和其他非视觉用户的代替品。加入的替代文字应该简洁，或者应该提到图像题注或相邻文字。
2. 在多数情况下，无论是使用内置的图像语法，还是一行附属文字，图像都应该带有题注。题注应该简洁描述图像意义，即其试图传达的必要信息。
3. 避免用图片替代数据图表。若可能，任何图表都应该有替代文字或充分描述，使无法查看图像的用户可以明白一些内容。
4. 除非绝对必要，否则避免将文本夹在两个图像之间，或者使用固定的图像大小。
5. 避免不分青红皂白向页面中加入图库（<gallery>），因为用户的屏幕大小和浏览器有所差异，可能会因图像显示碎片而影响某些读者的访问。
6. 不要使用左图或右图的描述。对于求闻百科移动版而言，图像的排列是不同的，而这对于使用辅助软件的读者也没有意义。相反，请使用题注来指明图像。
7. 如有不适合条目的详细图像说明，则应将其置于图像描述页，并留下文字注明，点开图像链接可以获得更详细描述。
8. 图像应置于其所属章节内（在章节标题和引导至其他条目的链接之后），不应放在标题里面或上一章节末尾，否则屏幕阅读器会在其它章节显示图像（和替代文字。
9. 该指引包括<math>标签内LaTeX格式公式的替代文字。
10. 不要将图片放在标题中；这包括图标和<math>标记；这样做可能会导致章节链接受损，并导致其他问题。

动画、视频与音频

更多信息：Qiuwen:媒体帮助

动画

出于亲和力考虑，动画（GIF：图形交换格式）应该满足以下两者之一：

• 持续时间不超过5秒（否则会变成纯装饰元素），或者
• 有控制模块（停止、暂停、播放）。

总而言之，大多数动画GIF应当能转换为视频。

此外，动画在任何一秒钟内产生的闪光严禁超过三次。闪光次数超过这个限度的内容会导致光敏癫痫发作。

视听内容

视听内容可以加入计时文本格式的字幕。对于视频内容，为便于听力障碍者使用，可以加入隐藏字幕。隐藏字幕以文字形式提供了关于声音的全部重要信息。其可以包含在对话、声音（自然或人声）、环境与背景、人与动物的动作表情，以及文本或图形。

关于如何为视频创建隐藏字幕，请参阅：

• A quick and basic reference for closed captions
• a detailed reference (PDF)
• a list of best practices for closed captions。

对于声音内容而言，可以很方便的为演讲、歌词和对话等加入字幕。

样式及标记选项

最佳实践

表格与其他区块元素的格式，应尽量采用CSS类（CSS class）调用样式表中已定义的样式，而不是撰写行间CSS代码（inline CSS）。全站CSS样式表（MediaWiki:Common.css）已经过测试，在大多数浏览器条件下可以确保兼容性，满足大部分用户的需求。此外，注册用户可以通过自定义样式表（Special:MyPage/skin.css；或浏览器设置）以修改配色方案，以满足自身的特定需求。

为了在实现无障碍访问的同时确保页面的美观，页面可以在一定程度上允许页面与公认的互联网标准存在差异。若页面的某些配色方案偏离公认标准，其作者应确保其满足无障碍访问要求（例如：颜色应满足对比度要求、添加相应辅助属性标签等）。

页面应优先使用wiki标记；wiki标记无法满足要求或不能使用wiki标记的情况下，才可以使用HTML元素。您应避免使用HTML标签<i>...</i>、<b>...</b>来表示斜体、粗体文字，而应使用wiki标记''、'''；在不能使用wiki标记的情况下，请使用具有语义的HTML标签，诸如<em>...</em>和<strong>...</strong>。HTML的font-size属性也应尽量避免使用（禁止使用<font>），建议使用模板链接：{{em}}、模板链接：{{strong}}、模板链接：{{code}}、模板链接：{{small}}及模板链接：{{big}}等模板替代，这些模板包含具有语义的wiki标记或HTML标签，并使用行间CSS代码添加样式，可以强调与其它文字的不同之处。

折叠内容

参见：Qiuwen:格式手册 § 滚动列表及折叠内容和mw:No-JavaScript notes

自动折叠的元素（或设为“预先折叠”的元素）不应用于隐藏文章主体中的内容。

对于使用较少支持JavaScript、CSS新特性的较旧浏览器的读者，求闻百科的界面应该维持基本的可读性。请编者考虑到那些浏览器不支持相应JavaScript、CSS特性的用户，确保他们至少可以阅读。

若您需要模拟较旧浏览器，可以尝试在浏览器中关闭JavaScript、CSS。

参考资料

• Web Content Accessibility Guidelines (WCAG) 2.1 [网页内容无障碍指南（WCAG）2.1]. W3C. 2018 （英语）. 
  • 另请参见根据勘误表进行勘误的中文版本（非官方，仅供参考）。
• Web信息无障碍通用设计规范介绍介绍. 互联网应用适老化及无障碍标准体系. 2021 （简体中文（中国大陆））. 
• 网站设计无障碍技术要求介绍. 互联网应用适老化及无障碍标准体系. 2012 （简体中文（中国大陆））. 
• HTML 4.01 Specification. W3C. 1999.