维基百科:格式手冊/親和力

维基百科,自由的百科全书
跳转至: 导航搜索

網頁親和力致力於使網頁更易瀏覽與閱讀。雖然這主要旨在幫助身心障礙者,但亦能可以幫助所有讀者。我們旨在遵循WCAG標準2.0(即ISO/IEC 40500:2012),並以此提出以下建議。遵守這些內容會使條目更易於大家閱讀與編輯。

條目結構[编辑]

條目結構規範化能增加親和力,因為它使用戶能夠從頁面特定部分獲得期望內容。例如一個盲人正在搜索消歧義連結。如果他沒有從頁面頂部搜索到任何內容,他就能知道此處什麼也沒有,並不必繼續閱讀整個頁面查找內容。 期望內容是在頁面的特定部分。

規範是維基百科已經形成的習慣,因而只需簡單的遵循指引Wikipedia:版面指南Wikipedia:格式手冊/序言章節#導言文字

章節標題[编辑]

章節標題應該是描述性的,且順序一致(參見—參考文獻—擴展閱讀—外部連結)。

章節標題應該嵌套遞進,以二級(==)起頭,接下來是三級(===)等等(不應當使用一級,它已經由頁面標題自動生成),請勿隨機使用章節標題層級(比如選擇加重,這不是標題的目的),也不要跳級。

請不要使用加粗或分號語法的偽章節標題。螢幕閱讀器等機器只能使用正確格式的章節標題。如果你想縮減目錄長度,請使用{{TOC limit}}。

章節標題使用(與誤用)示例
正確 隨機/亂序 跳級 偽章節標題

[這是條目序言]
==章節== [二級標題]
===子章節=== [三級]
==章節== [二級]
===子章節=== [三級]
====子章節的子章節==== [四級]
==章節== [二級]

[這是條目序言]
====章節?==== [四級]
===章節?=== [三級]
==章節?== [二級]
==章節?== [二級]
====章節?==== [四級]
===章節?=== [二級]

[這是條目序言]
[此處缺失二級標題]
===章節?=== [三級]
==章節== [二級]
[此處缺失三級標題]
====子章节?==== [四級]
==章節== [二級]

[這是條目序言]
==章節== [level 二級]
===子章節=== [三級]
'''子章節''' [偽章節標題]
==章節== [2]
===子章節=== [3]
;子子章節 [偽章節標題]
==章節== [二級]
<small>==子章節==</small> [偽三級標題]

浮動元素[编辑]

在維基代碼中,浮動元素應置於所屬的章節之內。比如,雖然維基語法中圖像置於頁面頂部,但可能被其它浮動元素推到目錄下方顯示。圖像也應插入其所屬的章節之內

解析度[编辑]

維基百科條目應便於使用小螢幕設備,或低解析度顯示器的讀者訪問。我們將1024×768視作對其他使用者無可能不利影響的最低解析度;條目在該解析度下應無不必要的水平捲軸。這個問題有時會在螢幕兩邊同時出現多張圖像時出現;將圖像移至一側,即使這樣垂直捲軸會加長——注意不要同時在屏幕兩側加入圖像等浮動元素。大表格和圖像也會產生問題;有時無法避免水平捲軸的出現,但可設法調整表格,讓它朝垂直而非水平方向發展。

文字[编辑]

快捷方式
WP:NOSTRIKE
WP:NOSYMBOLS

在條目頁面中,請勿使用刪除線劃去有異議的文字。要麼用「<!--」和「-->」注釋掉,要麼直接移除。默認情況下,大多數螢幕閱讀器不支援呈現文本屬性(粗體、斜體、下劃線)乃至語義文本屬性(強調、重要、文字刪除),因此帶刪除線的文字和正常文字顯示效果相同。(而在參與維基百科方針和刪除討論時,我們建議編輯啟用顯示文字格式,而刪除線文字在維基百科內部討論中非常常見。)

不支援Unicode的螢幕閱讀器會將非Latin-1字元顯示為問號,即使對於最普及螢幕閱讀器JAWS的最新版本,Unicode字元依然非常難以閱讀。

  1. 在名稱、地點、事物等原文相當重要的地方,如果使用的是拉丁書寫系統文字,則請始終給出音譯
  2. 請勿使用♥(心形符號)等無法發音的符號;請以注有替代文本的圖像代之[1]
  3. 對於在螢幕閱讀器上產生問題的符號,可能已經有了生成圖像和替代文字的模板。比如{{}}。

請勿使用需要交互來提供資訊的技術,比如工具提示(tooltip)或其他「懸停」文字。縮寫屬於例外,因此可以使用{{abbr}}模板來縮寫很長的術語。

不要在句子中插入換行符,這會讓螢幕閱讀器難以編輯。A single line break may follow a sentence, which may help some editors.

謹慎使用縮小字體。避免在資訊框、導航模板和參考章節等已經為小字體元素的地方再次使用小字體。無論何時都不應該使用比85%(或11像素)還小的字體。

外語[编辑]

快捷方式
WP:ATLANG

非中文單詞或短語應以使用ISO 639語言代碼的{{lang}}包圍,比如:{{lang|ja|Assemblée nationale}}

使用理由{{lang}}可以使語音合成器以正確的語言發音[2]。在中文維基百科中,對於日語如不使用模板,則日本漢字可能會被視作中文錯誤簡繁轉換。其它見Template:Lang/doc#使用理由的完整理由。

連結[编辑]

  1. 建立好的連結描述,外部連結尤甚。(避免「點此!」「見此處」)[3][4]
  2. 不要用Unicode字元當圖符;以使用替代文字描述的圖符檔案代之。比如「→」等字元可能無法在螢幕閱讀器上重現為有效文字,讀者看到的可能是問號。

顏色[编辑]

快捷方式
WP:COLOR
WP:COLOUR
WP:CONTRAST
两个文本用户界面的同高度截图。上方的使用了红色、绿色和蓝色;下方的则使用了对红色和绿色几乎相同的颜色,借个红色文字几乎淹没在绿色的背景中。
一对截图显示红/绿色盲对易读性的影响

颜色最常见于维基百科条目的模板表格。欲查看可用的颜色,请见颜色列表,关于如何使用颜色的技术帮助,请见Help:使用颜色

条目中的颜色应用须牢记亲和力,如下:

  • 确保颜色并非唯一传达重要信息的方式。特别的,请不要使用上色文字或背景,除非其状态还用指示另一事物,比如亲和性符号对应图例,或脚注标签。另外失明用户或读者通过打印物或非彩色装置或获得维基百科时,将无法获得此类信息。
  • 对于我们的读者,链接应该如链接一样清晰可识别。
  • 维基百科的一些读者为部分或全色盲。确保文字和背景的对比达到WCAG 2.0的AA等级,如可能则达到AAA等级。可以选择这些工具检查对比度是否正确:
    • 色彩对比分析器使您能够挑选在页面上的颜色,并充分检查其对比度。但请务必只使用最新的“亮度”算法,而非过时的“色彩亮度/差”。
    • 你还可以选择完全更新的斯努克的色彩对比工具
    • 网上还有其它工具,但请在使用前检查它们是否更新。一些工具以WCAG 1.0算法为基础,而我们应该参考现今的WCAG 2.0算法。如果工具没有提到其基于WCAG 2.0,则假设它过时。
  • 此外还有工具可以协助制作图形图表,或是地图等的配色方案。这些工具对于对比度亲和力检查并不严格,但其可以在特定任务上有帮助作用。
  • 如果条目过度使用颜色,但你不知道如何亲自修复,则可请其他编辑协助。请将{{Overcolored}}放置于条目顶部。

块元素[编辑]

列表[编辑]

快捷方式
WP:LISTGAP
WP:LISTGAPS

不要在列表项间用空行或表格列分断,即使是定义列表(以分号和冒号打头形成的列表)和無序列表,这会让MediaWiki理解为结束再新起列表。这会让屏幕阅读器显示为多个列表,虽然编辑意在只做一个列表。列表是合为一体的一组元素,拆散分组会让屏幕阅读器读者误解与困惑。不当的格式还会让阅读列表消耗三倍以上的时间。

缩进[编辑]

快捷方式
WP:INDENTGAP
WP:INDENTGAPS

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

垂直列表[编辑]

无序垂直列表[编辑]

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

* 白玫瑰
* 黄玫瑰

* 粉红玫瑰

* 红玫瑰

因为软件抑制了行距,所以看起来如:

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

但是屏幕阅读器读者看起来是:“2个项目的列表:(圆点)白玫瑰,(圆点)黄玫瑰,列表结束。单项目列表:(圆点)粉红玫瑰,列表结束。单项目列表:(圆点)红玫瑰,列表结束。”

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

无项目符号垂直列表[编辑]
快捷方式
WP:PLIST
WP:VLIST

对于页面中纵向列出的无项目符号列表,可使用模板{{plainlist}}和{{unbulleted list}}来提高亲和性语义意义,表明这是一个清晰的列表,而非通过不应使用的<br />换行。代之在导航框一类模板或合适的容器中,可以使用类“plainlist”,也就是:

| listclass = plainlist
| bodyclass = plainlist

在信息框中则可以使用:

| rowclass = plainlist or
| bodyclass = plainlist

。另见Wikipedia:格式手册/列表#无项目符号列表。见WP:NAV获得更多关于导航模板的细节。

水平列表[编辑]

快捷方式
WP:HLIST

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

包含项目符号字元,比如读出盲人使用的堵住软件

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

| listclass = hlist
| bodyclass = hlist

信息框中可使用:

| rowclass = hlist
| bodyclass = hlist

WP:NAV获得更多关于导航模板的细节。

表格[编辑]

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

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

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

数据表格[编辑]

快捷方式
WP:DTAB
{|
|+ [标题文字]
|-
! scope="col" | [列标题1]
! scope="col" | [列标题2]
! scope="col" | [列标题3]
|-
! scope="row" | [列标题1]
| [常规单元格1,2] || [常规单元格1,3]
|-
! scope="row" | [列标题2]
| [常规单元格2,2] || [常规单元格2,3]
...
|}
标题文字(|+) 
标题文字是表格的题头,描述其性质[5]
行、列标题( ! ) 
如同标题文字,它们使信息以更为逻辑的结构展现给读者[6]。行列标题有助于屏幕阅读器显示数据单元格的标题信息。比如,标题信息会在单元格数据之前念出,或标题信息根据要求提供[7]
标题的范围( ! scope="col" | and ! scope="row" | ) 
这清晰的定义了行标题或列标题。标题单元格现在可以合并[8]

Wikipedia:格式手册/亲和力/数据表格指南列出了这些详细要求:

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

排版表格[编辑]

快捷方式
WP:LTAB

部分导航框系列模板,以及信息框由表格制成。

请不要使用表格做纯排版用途。最佳的选择是使用更有适应性的HTML<div>块和样式属性。比如请见{{Navbox}}

可以选择一些简单的排版表格。特别是用align="right"等表格仅为获得浮动效果之时,这会在一些完全不支持CSS的浏览器上良好运行。这实际上是一个<div>加CSS的繁琐近似,而非被称为(嵌套)“表格布局”的设计之最。

然而为避免亲和性障碍,当表格用于布局时,请勿使用任何表格、行或列标题,也不要使用summary属性。这些结构表格元素仅应在数据表格中使用。请勿将结构元素用于效果呈现,而是使用结构表。对于维基表格标记,这表示这种下方情形不要使用“!”(相当于XHTML中的 <th>):

{| class="toccolours" style="width:94%"
| style="text-align: center; background-color: #ccf;" | '''标题'''
|-
| [常规单元格] || [常规单元格]
|-
| [常规单元格] || [常规单元格]
|}

示例请见{{Navbox}}

图像[编辑]

  1. 即使是空白的图像,也应该带有替换文字,替换文字是给盲人读者、搜索蜘蛛和其他非视觉用户的代替品。加入的替代文字应该简洁,或者应该提到图像题注或相邻文字:见WP:ALT获取更多信息。
  2. 多数情况下,无论是使用内置的图像语法,还是一行附属文字,图像都应该带有题注。题注应该简洁描述图像意义,即其试图传达的必要信息。
  3. 若可能,任何图表或图表都应该有替代文字或充分描述,使无法查看图像的用户可以明白一些内容。
  4. 如有不适合条目的详细图像说明,则应将其置于图像描述页,并留下文字注明,点开图像链接可以获得更详细描述。
  5. 图像应置于其所属章节内(在章节标题和引导至其他条目的链接之后),不应放在标题里面或上一章节末尾,否则屏幕阅读器会在其它章节显示图像(和替换文字);移动版站点也同样如此显示。见Wikipedia:图像指南获得更多信息。
  6. 不要使用左图或右图的描述。对于维基百科移动版而言,图像的排列是不同的,而这对于使用辅助软件的读者也没有意义。相反,使用题注来指明图像。
  7. 该指引包括<math>模式下LaTeX格式公式的替代文字。

动画、视频与音频[编辑]

动画[编辑]

出于亲和力考虑,动画(GIF–图形交换格式)应该满足以下两者之一:

  • 持续时间不超过5秒(否则会变成纯装饰元素)[9],或者
  • 有控制模块(停止、暂停、播放)[10]

总而言之,大多数动画GIF应当能转换为视频。(转换方法可见指南将动画GIF转换为Theora OGG

视频[编辑]

视频可以加入计时文本格式的字幕。commons:Commons:Video#Subtitles and closed captioning有相应的帮助页面。字幕为语音的转录。

对于听力障碍者可以加入隱藏字幕。在2012年11月之前这很难做到,但通过bugzilla:41694的请求,现在可以简单的加入此特性。隱藏字幕以文字形式提供了关于声音的全部重要信息。其可以包含在对话、声音(自然或人声)、环境与背景、人与动物的动作表情,以及文本或图形[11]。关于如何创建隱藏字幕,请参阅:A quick and basic reference for closed captionsa detailed reference (PDF)a list of best practices for closed captions

声音[编辑]

可以很方便的为演讲、歌词和对话等加入字幕[12]。方法和视频相似:commons:Commons:Video#Subtitles and closed captioning

Styles and markup options[编辑]

快捷方式
WP:Deviations

Best practice: Use Wikimarkup and CSS classes in preference to alternatives[编辑]

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 for 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 his/her 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 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 infoboxes and navigational templates relating to The Simpsons use a yellow colour-scheme, to tie in with the dominant colour in the series. In this case, blue links on yellow provides enough color contrast, thus it is accessible.

In general, articles should use wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style tags <i> and <b> to format text; it is preferable to use Wiki markup '' or ''', or logical style tags. Of course there are natural exceptions: it may be beneficial to use <u></u> tags to indicate something like an example of an unclickable link. The <font> tag should also be avoided in article text; use logical style tags like <em>, <code>, or <strong> to emphasise semantic differences. Use <small> and <big> semantic tags to change font size, rather than setting it explicitly with the font-size= style attribute.

Users with limited CSS/JavaScript support [编辑]

Wikipedia articles should be accessible to readers using browsers and devices which have limited or no support for JavaScript or Cascading Style Sheets. At the same time, it is recognised 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 which would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. This includes techniques such as the hiddenStructure method for hiding table content—which produces incomprehensible output without CSS—and some implementations of the NavFrame collapsing code—which can make content inaccessible without JavaScript support. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised 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 IE in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.

参见[编辑]

参考资料[编辑]

  1. ^ F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information. Techniques for WCAG 2.0. W3C. [1 January 2011]. 
  2. ^ H58: Using language attributes to identify changes in the human language, Techniques for WCAG 2.0, W3C, accessibility level: AA.
  3. ^ G91: Providing link text that describes the purpose of a link. Techniques for WCAG 2.0. W3C. [1 January 2011]. 
  4. ^ 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. [1 January 2011]. 
  5. ^ H39: Using caption elements to associate data table captions with data tables, A accessibility level.
  6. ^ H51: Using table markup to present tabular information. W3C. [1 January 2011]. 
  7. ^ Table cells: The TH and TD elements. Techniques for WCAG 2.0. W3C. [1 January 2011]. 
  8. ^ H63: Using the scope attribute to associate header cells and data cells in data tables. Techniques for WCAG 2.0. W3C. [1 January 2011]. 
  9. ^ Setting animated gif images to stop blinking after n cycles (within 5 seconds). Techniques for WCAG 2.0. W3C. [1 January 2011]. 
  10. ^ Allowing the content to be paused and restarted from where it was paused. Techniques for WCAG 2.0. W3C. [1 January 2011]. 
  11. ^ Providing an alternative for time based media. Techniques for WCAG 2.0. W3C. [1 January 2011]. 
  12. ^ Providing an alternative for time-based media for audio-only content. Techniques for WCAG 2.0. W3C. [1 January 2011]. 

外部链接[编辑]