维基百科:格式手册/无障碍
 |
 | 此条目可参照英语维基百科相应条目来扩充。 |
| 格式手册 |
|---|
| 灰字链接非正式指引，仅供参考 |
Web无障碍致力使网页更易浏览与阅读。虽然这主要旨在帮助身心障碍者，但亦能可以帮助所有读者。我们旨在遵循WCAG标准2.0（即ISO/IEC 40500:2012），并以此提出以下建议。遵守这些内容会使条目更易阅读与编辑。
2006年1月14日，维基媒体基金会理事会提议了以下反歧视政策：“维基媒体基金会禁止基于种族、肤色、性别、宗教、民族血统、年龄、残疾、性取向或任何其他受法律保护的特征而歧视现有或未来的用户和雇员。维基媒体基金会承诺遵守机会平等的原则，特别是在雇员关系的所有方面，包括就业、工资管理、雇员发展、晋升和调动”
，并断称，“维基媒体基金会的官员或工作人员或任何维基媒体项目的地方政策不得规避、侵蚀或忽视”
此政策。
条目结构
[编辑]条目结构规整能让读者对页面的内容铺排一目了然，因此有助达成无障碍。例如，某位失明读者在寻找消歧义链接时，如果没有在页顶找到这种链接，则能明白页面本来没有消歧义链接，因此无需阅读整页。
标准化是维基百科的一大习惯，因此只需遵循Wikipedia:格式手册/版面布局和Wikipedia:格式手册/序言章节 § 应该有的东西。
章节标题
[编辑]章节标题应该能简洁描述主题，且按照Wikipedia:版面指南排列。
章节标题应该巢状递进，由二级标题（==）开始，再到三级标题（===），如此类推（一级标题是页面标题）。不要为了凸显某些内容而故意用错或跳过章节标题层级，这样做有悖于它们的作用。
请不要使用加粗或分号语法的伪章节标题。屏幕阅读器等机器只能使用正确格式的章节标题。
| 正确 | 随机/乱序 | 跳级 | 伪章节标题 |
|---|---|---|---|
|
[这是条目序言] |
[这是条目序言] |
[这是条目序言] |
[这是条目序言] |
请勿滥用行首半角分号和粗体来“伪装”标题，行首半角分号是定义列表专用。读屏器和其他辅助工具仅能使用有章节标记（半角等号）的标题来导航定位。如欲缩小目录，请用{{TOC limit}}。在{{TOC limit}}因为条目其他地方有低层级标题而无用的情况，才可妥协用粗体，但要先将子子子标题用粗体取代，因为这对读屏器用户构成的滋扰最少。必先穷尽其他解决方案，才可以使用伪标题。此为罕见情况。
| 可接受 | 错误 |
|---|---|
[条目首段] |
[条目首段] |
浮动元素
[编辑]在维基代码中，浮动元素应置于所属章节之内。比如，虽然维基语法中图像置于页面顶部，但可能被其它浮动元素推到目录下方显示。图像也应插入其所属的章节之内。（视乎所用平台，若将多张图片“堆栈”在很少文字的旁边，则可能会使某图片被推挤到后面的章节。然而，此并非亲和力问题，因为读屏器总会在图片原始码的位置，将其alt=读出。）
分辨率
[编辑]维基百科条目应便于使用小屏幕装置，或低分辨率显示器的读者访问。我们将1024×768视作对其他用户无可能不利影响的最低分辨率；条目在该分辨率下应无不必要的水平滚动栏。这个问题有时会在屏幕两边同时出现多张图像时出现；将图像移至一侧，即使这样垂直滚动栏会加长——注意不要同时在屏幕两侧加入图像等浮动元素。大表格和图像也会产生问题；有时无法避免水平滚动栏的出现，但可设法调整表格，让它朝垂直而非水平方向发展。
文字
[编辑]删除线
[编辑]请勿在条目页面及导航模板中用删除线划去任何文字。如有需要，请用“<!--”和“-->”注释处理，或直接移除。大多数屏幕阅读器默认不呈现文本属性（粗体、斜体、下划线）乃至语义文本属性（强调、重要、文字删除），带删除线的文字和正常文字阅读效果相同。然而，带删除线的文字在维基百科内部讨论中非常常见，建议在参与维基百科的方针和存废讨论时，编辑激活显示文本属性。
如果条目有显然错误的内容，应该用注释处理，或者直接移除，不要使用删除线；也可用行内清理模板标记，并在讨论页提出意见。
符号
[编辑] | 此章节需要编修，以确保本地化（字符集、音译要求）使用恰当。 |
不支持Unicode的屏幕阅读器会将非Latin-1和Windows-1252的字符显示问号，即使对于最普及的屏幕阅读器JAWS中，Unicode字符依然非常难以阅读。
- 在名称、地点、事物等原文相当重要的地方，如果原文使用的既非汉字也不是拉丁书写系统文字，则请始终给出转写，即罗马化。此功能在表示非罗马字语言的模板中可用，也可以在诸如{{transl}}}等模板中找到；这些模板还具有可访问性等其它优点（请参阅下文的“外语”章节）。
- 请勿使用♥（心形符号）等无法发音的符号；请以注有替代文本（
|alt=）的图像（如
）代之[1]。 - 对于在屏幕阅读器上产生问题的符号，可能已经有了生成图像和替代文字的模板。比如{{†}}。（有关更多资讯，请参见Category:图像插入模板）
字符序列必须足以传达文本的语义方面（最好是其他类似形式的内容）； 不可使用只能使用CSS属性或Wiki标记语言区分的自定义“特殊符号”。
请勿使用需要交互来提供资讯的技术，比如工具提示（tooltip）或其他“悬停”文字。缩写属于例外，因此可以使用{{abbr}}模板来缩写很长的术语。
不要在句中插入换行符（<br>），会让屏幕阅读器难以编辑。句子后面允许插入单独的换行符，可能对某些编者有帮助。
字体大小
[编辑]谨慎使用缩小和放大字体。字号通常是由页面元素自动决定，如标题、列表标题、标准模板。改变字号时，应当用原字体的百分比大小（相对大小）描述，而不用像素或点数描述绝对大小，以便利默认使用较大字体的用户。
避免在资讯框、导航模板和参考章节等已经为小字体元素的地方再次使用缩小字体。所以，<small>...</small>标签，及{{small}}、{{smaller}}等模板，不应用于该些页面元素的纯文字。无论何时都不应该使用比85%（或11像素）还小的字体。注意HTML的<small>...</small>标签还有小字条款的含义，不用作字体风格变化。
关于为二名法的命名者使用小字，请见“Wikipedia:Manual of Style/Text formatting § Scientific names”。外语
[编辑]非中文单词或短语应以使用ISO 639语言代码的{{lang}}包围，比如：{{lang|fr|Assemblée nationale}}，会显示为：
Assemblée nationale
或{{lang-fr|Assemblée nationale}}，会显示为：
法语：Assemblée nationale
使用理由：{{lang}}可以使语音合成器以正确的语言发音[2]。在中文维基百科中，对于日语如不使用模板，则日本汉字可能会被视作中文错误简繁转换。其它见Template:Lang/doc#使用理由的完整理由。
链接
[编辑]- 建立好的链接描述，外部链接尤甚。（避免“点此！”“见此处”）[3][4]
- 不要用Unicode字符当图符；以使用替代文字描述的图符文件代之。比如“→”等字符可能无法在屏幕阅读器上重现为有效文字，读者看到的可能是问号。
颜色
[编辑]
颜色最常见于维基百科条目的模板和表格。欲查看可用的颜色，请见颜色列表，关于如何使用颜色的技术帮助，请见Help:使用颜色。
条目中的颜色应用须牢记亲和力，如下：
- 确保颜色并非唯一传达重要资讯的方式。特别的，请不要使用上色文字或背景，除非其状态还用指示另一事物，比如亲和性符号对应图例，或脚注标签。另外失明用户或读者通过打印物或非彩色装置或获得维基百科时，将无法获得此类资讯。
- 对于我们的读者，链接应该如链接一样清晰可识别。
- 维基百科有读者为部分或全色盲。确保文字和背景的对比达到WCAG 2.0的AA等级，如可能则达到AAA等级。可以选择这些工具检查对比度是否正确：
- 色彩对比分析器使您能够挑选在页面上的颜色，并充分检查其对比度。但请务必只使用最新的“亮度”算法，而非过时的“色彩亮度/差”。
- 你还可以选择完全更新的斯努克的色彩对比工具。
- The Wikimedia Foundation Design team has provided a color palette with colors being marked towards level AA conformance. It is used for all user-interface elements across products and in the main Wikimedia themes, desktop and mobile. However, it does not consider linked text.
- The table at Wikipedia:格式手册/无障碍/色彩表 shows the results for 14 hues of finding the darkest or lightest backgrounds that are AAA-compliant against black text, white text, linked text and visited linked text.
- Google's Chrome Canary has a color contrast debugger with visual guide and color-picker.
- 网上还有其它工具，但请在使用前检查它们是否更新。一些工具以WCAG 1.0算法为基础，而我们应该参考现今的WCAG 2.0算法。如果工具没有提到其基于WCAG 2.0，则假设它过时。
- {{Color contrast ratio}}
- 此外还有工具可以协助制作图形图表，或是地图等的配色方案。这些工具对于对比度亲和力检查并不严格，但其可以在特定任务上有帮助作用。
- 配色方案生成器（Paletton）可以协助在图表中选择好的颜色搭配。
- 色彩酿造师2.0提供了地图的安全配色方案和详细讲解。
- Light qualitative colour scheme provides a set of 9 colours that work for color blind users and with black text labels (among other palettes).
- There are some tools for simulating color-blind vision: toptal (webpage analysis) and coblis (local file analysis). There are also browser extensions for webpage analysis: Colorblinding (Chrome) NoCoffee (Chrome) NoCoffee (Firefox)
- A very simple open-source tool that can be helpful for choosing contrasting colours is Color Oracle, a "free color blindness simulator for Windows, Mac and Linux". It lets you view whatever is on your screen as it would be seen by someone with one of three types of colourblindness or in greyscale.
- 如果条目过度使用颜色，但你不知道如何亲自修复，则可请其他编辑协助。请将{{Overcolored}}放置于条目顶部。
块元素
[编辑]列表
[编辑]不要在列表项间用空行或表格列分断，即使是定义列表（以分号和冒号打头形成的列表）和无序列表。列表是用来把项目组合起来的，但分断会让MediaWiki理解为结束再新起列表。拆散分组会让屏幕阅读器读者误解与困惑，因为阅读器也会跟着播报多个列表。不当的格式还会让阅读列表消耗三倍以上的时间。
同样，请勿列表之中，切换行首符号（分号、星号、井号）。回复时，若对方行首混合用分号与星号（甚至井号），则需要先复制该串符号，后另加一个符号，以正确缩进。开新话题，则取消缩进即可（等同开一个新的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:Example2
亦请勿在列表项之间隔空行：
* 支持。我喜歡此想法。—User:Example
** 疑問：你為何喜歡？—User:Example2
以及请勿越级：
* 支持。我喜歡此想法。—User:Example
*** 疑問：你為何喜歡？—User:Example2
以下做法
不鼓励：
: 支持。我喜歡此想法。—User:Example
:* 疑問：你為何喜歡？—User:Example2
因为加入的圆点，令列表变得更复杂，且令读屏器较难跟上讨论，因为可能将多出的圆点视为全新嵌套列表的开始。
Multiple paragraphs within list items
[编辑]
Normal MediaWiki list markup is unfortunately incompatible with normal MediaWiki paragraph markup. To put multiple paragraphs in a list item, separate them with {{pb}}:
* This is one item.{{pb}}This is another paragraph within this item.
* This is another item.
Do not use line breaks to simulate paragraphs, because they have different semantics:
* This is one item.<br>This is the same paragraph, with a line break before it.
* This is another item.
Definitely do not attempt to use a colon to match the indentation level, since (as mentioned above) it produces three separate lists:
* This is one item. : This is an entirely separate list. * This is a third list.
Alternatively, you can use one of the HTML list templates to guarantee grouping. This is most useful for including block elements, such as formatted code, in lists:
{{bulleted list |1=This is one item: <pre> This is some code. </pre> This is still the same item. |2=This is a second item. }}
缩进
[编辑]An accessible approach to indentation is the template {{block indent}} for multi-line content; it uses CSS to indent the material. For single lines, a variety of templates exist, including {{in5}} (a universal template, with the same name on all Wikimedia sites); these indent with various whitespace characters. Do not abuse the <blockquote>...</blockquote> element or templates that use it (such as {{Quote}}) for visual indentation; they are only for directly quoted material.
以英文冒号起头的行会缩进。比如这种用法会在讨论页的往来讨论中表示回复。该缩进用了HTML的定义列表。这在可亲和性和语义学都并不理想，但目前却广泛应用。缩进行之间不应插入空行，因为这表示列表的结束并开启新列表。如果确实需要空行，请插入一个以同样数量冒号起头的额外行。
A colon (:) at the start of a line marks that line in the MediaWiki parser as the <dd>...</dd> part of an HTML description list (<dl>...</dl>).[a] The visual effect in most Web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on talk pages. However, this markup alone is missing the required <dt> (term) element of a description list, to which the <dd> (description/definition) pertains. As can be seen by inspecting the code sent to the browser, this results in broken HTML (i.e. it fails validation[5]). The result is that assistive technology, such as screen readers, will announce a description list that does not exist, which is confusing for any visitor unused to Wikipedia's broken markup. This is not ideal for accessibility, semantics, or reuse, but is currently commonly used, despite the problems it causes for users of screen readers.
Blank lines must not be placed between colon-indented lines of text – especially in article content. This is interpreted by the software as marking the end of a list and the start of a new one. If a blank line is needed, place the same number of colons on it as those preceding the text below the blank line, for instance:
: Text here. : : More text.
Another solution is new-paragraph markup, but it must be in one unbroken line in the wiki code:
- Text here.<p>More text.</p>
For more information on the weaknesses of colon-based description list markup – even for actual description lists – .
垂直列表
[编辑]无序垂直列表
[编辑]对于无序垂直列表，请不要在项目之间用空行隔行。如果列表项之间有超过一次换行，HTML列表将会在换行后结束，并在下一项的换行之前开启新HTML列表。这种有效换行在屏幕阅读器中会视为几张小列表，比如代码：
* 白玫瑰 * 黄玫瑰 * 粉红玫瑰 * 红玫瑰
因为软件抑制了行距，所以看起来如：
- 白玫瑰
- 黄玫瑰
- 粉红玫瑰
- 红玫瑰
但是屏幕阅读器读者看起来是：“2个项目的列表：（圆点）白玫瑰，（圆点）黄玫瑰，列表结束。单项目列表：（圆点）粉红玫瑰，列表结束。单项目列表：（圆点）红玫瑰，列表结束。”
请不要以换行符分隔列表项目。请用以下方法代之。
无项目符号垂直列表
[编辑]对于页面中纵向列出的无项目符号列表，可使用模板{{plainlist}}和{{unbulleted list}}来提高亲和性语义意义，表明这是清晰的列表，而非通过不应使用的<br />换行。
代之在导航框一类模板或合适的容器中，可以使用类“Splainlist”，也就是：
| listclass = plainlist或| bodyclass = plainlist
在资讯框中则可以使用：
| rowclass = plainlistor| bodyclass = plainlist
。另见Wikipedia:格式手册/列表#无项目符号列表。见WP:NAV获得更多关于导航模板的细节。
水平列表
[编辑]对于页面中横向列出的，以及资讯框等表格中在一行内列出的列表，请使用{{flatlist}}和{{hlist}}模板提升亲和力和与语义意义。该特性对各列表项使用了正确的HTML标记，而不包含盲人用辅助软件会读出的项目符号字符（比如“点－猫－点－狗－点－马－点……”）。
代之在导航框等模板或相似的容器中，列表可以使用CSS类“hlist”格式，也就是：
| listclass = hlist或| bodyclass = hlist
资讯框中可使用：
| classn = hlist（在单独的某一行中使用）| bodyclass = hlist（在整个资讯框中使用）
水平列表默认使用间隔号（·）作为定界符，如需使用其他定界符，可以使用以下CSS类：
hlist hlist-pipe（使用管道符号作为定界符）hlist hlist-hyphen（使用连字号作为定界符）hlist hlist-comma（使用顿号作为定界符）
在导航框中使用非间隔号作为定界符时，请使用|listclass=参数而非|bodyclass=参数，否则将影响标题栏左侧的导航按钮。
见WP:NAV获得更多关于导航模板的细节。
List headings
[编辑]请勿滥用行首半角分号和粗体来“伪装”标题，行首半角分号是定义列表专用。读屏器和其他辅助工具仅能使用有章节标记（半角等号）的标题来导航定位。
Instead, use heading markup (figure 2).
1. Incorrect; Noble gases
* Helium
* Neon
* Argon
* Krypton
* Xenon
* Radon
2. Heading== Noble gases == * Helium * Neon * Argon * Krypton * Xenon * Radon
表格
[编辑]屏幕阅读器和其它网页浏览器工具通过特定表格标签帮助用户导航其中记录的数据。
使用正确的维基表格管道语法利于所有可用特性。见Help:表格获得更多关于表格特定语法的资讯。请不要单独使用格式——从CSS或硬编码风格——创建语义意义。（如改变背景颜色）。
通过在相邻单元格中嵌入成组的HTML<br />、<hr>标签，可以在视觉上创建多行资讯框，不过该技术并不适合HTML表格结构。屏幕阅读器用户是以单元格和HTML行为单位阅读，而非以视觉上的行阅读，因此这对它们会产生问题。英文维基的资讯框亲和度项目（WikiProject Accessibility/Infobox accessibility）就是为此而生。
数据表格
[编辑]{|
|+ [标题文字]
|-
! scope="col" | [列标题1]
! scope="col" | [列标题2]
! scope="col" | [列标题3]
|-
! scope="row" | [列标题1]
| [常规单元格1,2] || [常规单元格1,3]
|-
! scope="row" | [列标题2]
| [常规单元格2,2] || [常规单元格2,3]
...
|}
- 标题文字（
|+） - 标题文字是表格的题头，描述其性质[6]。
- 行、列标题（
!） - 如同标题文字，它们使资讯以更为逻辑的结构展现给读者[7]。行列标题有助于屏幕阅读器显示数据单元格的标题资讯。比如，标题资讯会在单元格数据之前念出，或标题资讯根据要求提供[8]。
- 标题的范围（
! scope="col" | and ! scope="row" |） - 这清晰的定义了行标题或列标题，指明了标题和其他单元格的对应关系。[9]
Wikipedia:格式手册/亲和力/数据表格指南列出了这些详细要求：
- 正确的表格标题
- 正确的标题结构
- 图像和颜色
- 避免嵌套表格
排版表格
[编辑]请避免使用表格做纯排版用途。Data tables provide extra information and navigation methods that can be confusing when the content lacks logical row and column relationships. 最佳的选择是使用更有适应性的HTML的<div>块和样式（style）属性。
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" class="toccolors" style="width:94%"
| colspan="2" style="text-align: center; background-color: #ccf;" | <strong>Important text</strong>
|-
| The quick || brown fox
|-
| jumps over || the lazy dog.
|}
图像
[编辑]- 所有非装饰的图像都要有替代文字。替代文字是给盲人读者、搜索蜘蛛和其他非视觉用户的代替品。加入的替代文字应该简洁，或者应该提到图像题注或相邻文字：见WP:ALT获取更多资讯。
- 在多数情况下，无论是使用内建的图像语法，还是一行附属文字，图像都应该带有题注。题注应该简洁描述图像意义，即其试图传达的必要资讯。
- 避免用图片替代数据图表。若可能，任何图表都应该有替代文字或充分描述，使无法查看图像的用户可以明白一些内容。
- Avoid sandwiching text between two images or, unless absolutely necessary, using fixed image sizes.
- Avoid indiscriminate gallery sections because screen size and browser formatting may affect accessibility for some readers due to fragmented image display.
- 不要使用左图或右图的描述。对于维基百科移动版而言，图像的排列是不同的，而这对于使用辅助软件的读者也没有意义。相反，请使用题注来指明图像。
- 如有不适合条目的详细图像说明，则应将其置于图像描述页，并留下文字注明，点开图像链接可以获得更详细描述。
- 图像应置于其所属章节内（在章节标题和引导至其他条目的链接之后），不应放在标题里面或上一章节末尾，否则屏幕阅读器会在其它章节显示图像（和替代文字）；移动版站点也同样如此显示。见Wikipedia:图像指南获得更多资讯。
- 该指引包括<math>模式下LaTeX格式公式的替代文字。
- Do not put images in headings; this includes icons and
<math>markup. Doing so can break links to sections and cause other problems.
动画、视频与音频
[编辑]动画
[编辑]出于亲和力考虑，动画（GIF–图形交换格式）应该满足以下两者之一：
总而言之，大多数动画GIF应当能转换为视频。（转换方法可见指南将动画GIF转换为Theora OGG）
In addition, animations Template:Strong-em produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.[12]
视频
[编辑]视频可以加入计时文本格式的字幕。commons:Commons:Video#Subtitles and closed captioning有相应的帮助页面。字幕为语音的转录。
对于听力障碍者可以加入隐藏字幕。在2012年11月之前这很难做到，但通过bugzilla:41694的请求，现在可以简单的加入此特性。隐藏字幕以文字形式提供了关于声音的全部重要资讯。其可以包含在对话、声音（自然或人声）、环境与背景、人与动物的动作表情，以及文本或图形[13]。关于如何创建隐藏字幕，请参阅：A quick and basic reference for closed captions、a detailed reference (PDF)和a list of best practices for closed captions。
A text version of the video would also be needed for the blind, but as of November 2012 there is no convenient way to provide alt text for videos.
声音
[编辑]可以很方便的为演讲、歌词和对话等加入字幕[14]。方法和视频相似：commons:Commons:Video#Subtitles and closed captioning。
样式及标记选项
[编辑]最佳惯例：使用维基标记和CSS语法
[编辑]一般来说，表格与其他区块元素的格式应该采用CSS类别，而不是内嵌式属性。全站层级CSS的MediaWiki:Common.css经过最谨慎测试以增进对大多数浏览器的亲和力（比如充足的颜色对比）和兼容性。此外，透过个人样式表（Special:MyPage/skin.css，或浏览器设置）用户可以自定义配色方案以满足特定需求。举例来说，en: Wikipedia:Style sheets for visually impaired users 提供了视障用户适用的高背景色对比导航模板。不过这会盖过既定的全站CSS，使得个人选择自己的主题会变得比较困难。
它还确保了文章之间的一致性且遵守格式指南，从而提高了专业度。
考量到无障碍访问，只要可以达到目标，与标准不同是可以被容许的。亲和度专题的成员应该确保默认样式是可以无障碍访问的。如果某些范本或特定的颜色方案偏离标准，其作者应确保它满足可访问性要求，如提供足够的颜色对比。例如：与辛普森家庭有关的导航模板和消息框会使用黄色以配合此系列的主色。在这种情况下，蓝色链接提供了充足的对比度，因此它是可访问的。
一般来讲，文章应优先于使用Wiki标记来替代HTML元素。尤其是，不要使用物理HTML标签<i>...</i>和<b>...</b>来单纯格式粗体、斜体文字，请使用Wiki标记'''、''，或是语义HTML（Semantic HTML）。<font>标签也应该要尽量避免在文章中使用；使用逻辑模板（例如{{em}}、{{strong}}或{{code}}）来强调与其它文字的不同之处。使用及{{small}}及{{big}}模板来改变文字大小，而非以font-size=方式或是已过时的<small>来设置样式。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.
CSS与JavaScript支持不足的读者
[编辑]Auto-collapsed (pre-collapsed) elements should not be used to hide content in the article's main body, though elements such as tables can be made collapsible at the reader's option.
维基百科条目应该让使用不完全支持JavaScript与CSS浏览器的读者也能够容易阅览。想同时避开不必要的功能又提供相同的外观质感给不同浏览器的用户是不可能的，因此不应该使用在CSS或JavaScript无法使用时会直接隐藏或是走样的功能。这包含了像是以结构隐藏方法来折叠表格内容（但没有CSS时会以不可折叠的样式显示）或是某些折叠码（可能会使没有JavaScript的用户无法阅读内容）。请考虑到那些无法使用CSS或JavaScript的用户，确保他们可以阅读；效果变差是意料之中。
为了因应这些考量，测试任何潜在的破坏性修改都在关闭JavaScript或CSS的情况下进行。在Firefox或Chrome，这可以很容易地透过网页开发扩展完成；IE浏览器可以在“选项”画面禁用JavaScript。要特别小心：内嵌式CSS效果在某些浏览器、媒体、以及XHTML版本并不支持。
In 2016 around 7% of visitors to Wikipedia did not request JavaScript resources.[15]
参见
[编辑]注释
[编辑]- ^ HTML description lists were formerly called definition lists and association lists. The
<dl><dt>...</dt><dd>...</dd></dl>structure is the same; only the terminology has changed between HTML specification versions.
参考资料
[编辑]- ^ F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ H58: Using language attributes to identify changes in the human language, Techniques for WCAG 2.0, W3C, accessibility level: AA.
- ^ G91: Providing link text that describes the purpose of a link. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ F84: Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click here" or "more" without a mechanism to change the link text to specific text. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ Markup Validation Service: Check the markup (HTML, XHTML, …) of Web documents. validator.w3.org. v1.3+hg. World Wide Web Consortium. 2017 [December 13, 2017]. The validator failure reported is "Error: Element
dlis missing a required child element." - ^ H39: Using caption elements to associate data table captions with data tables, A accessibility level.
- ^ H51: Using table markup to present tabular information. W3C. [2011-01-01].
- ^ Table cells: The TH and TD elements. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ H63: Using the scope attribute to associate header cells and data cells in data tables. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ Setting animated gif images to stop blinking after n cycles (within 5 seconds). Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ Allowing the content to be paused and restarted from where it was paused. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.. Web Content Accessibility Guidelines (WCAG) 2.0. World Wide Web Consortium. 11 December 2008 [28 May 2015].
- ^ Providing an alternative for time based media. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ Providing an alternative for time-based media for audio-only content. Techniques for WCAG 2.0. W3C. [2011-01-01].
- ^ File:Browsers, Geography, and JavaScript Support on Wikipedia Portal.pdf and File:Analysis of Wikipedia Portal Traffic and JavaScript Support.pdf.
- Clark, Joe. Building Accessible Websites. New Riders Press. 2003 [2011-01-01]. ISBN 0-7357-1150-X.
- Pilgrim, Mark. Dive Into Accessibility: 30 days to a more accessible web site. 2002 [2013-12-26].
外部链接
[编辑]- 10 Quick Tips to Make Accessible Web Sites, from WAI
- Colorblind web page filter
- Essential Components of Web Accessibility, from WAI
- Introduction to Web Accessibility, from WAI
- MediaWiki bug 367: Markup accessibility issues (tracking)
| 内容 | |
|---|---|
| 格式 | |
| 图片 | |
| 排版 | |
| 列表 | |
| 法律 | |
| 创作 | |
| 音乐 | |
| 地区 | |
| 科学 | |
| 交通 | |
| 相关方针指引 | |
| 检索 | |
