維基百科:格式手冊/無障礙
格式手冊 |
---|
灰字連結非正式指引,僅供參考 |
此條目可參照英語維基百科相應條目來擴充。 |
Web無障礙致力使網頁更易瀏覽與閱讀。雖然這主要旨在幫助身心障礙者,但亦能可以幫助所有讀者。我們旨在遵循WCAG標準2.0(即ISO/IEC 40500:2012),並以此提出以下建議。遵守這些內容會使條目更易閱讀與編輯。
2006年1月14日,維基媒體基金會理事會提議了以下反歧視政策:「維基媒體基金會禁止基於種族、膚色、性別、宗教、民族血統、年齡、殘疾、性取向或任何其他受法律保護的特徵而歧視現有或未來的用戶和僱員。維基媒體基金會承諾遵守機會平等的原則,特別是在僱員關係的所有方面,包括就業、工資管理、僱員發展、晉升和調動」
,並斷稱,「維基媒體基金會的官員或工作人員或任何維基媒體專案的地方政策不得規避、侵蝕或忽視」
此政策。
條目結構
[編輯]規範條目結構可讓用戶從頁面特定部分獲得期望內容,增加親和力;如果有盲人在搜尋消歧義連結,沒有從頁面頂部搜尋到任何內容,就可知道此處什麼也沒有,不必費時繼續閱讀下去。 期望內容是在頁面的特定部分。
規範是維基百科已形成的習慣,只需簡單遵循指引Wikipedia:版面指南和Wikipedia:格式手冊/序言章節#導言文字。
章節標題
[編輯]章節標題應該是具體描述,且順序一致(參見—參考文獻—擴展閱讀—外部連結)。
章節標題應該巢狀遞進,以二級(==
)起頭,接下來是三級(===
)等(不應該用自動生成的一級標題),請勿隨機使用章節標題層級(比如選擇加重,這不是標題的目的),也不要跳級。
請不要使用加粗或分號語法的偽章節標題。螢幕閱讀器等機器只能使用正確格式的章節標題。如欲縮減目錄長度,請使用{{TOC limit}}。
正確 | 隨機/亂序 | 跳級 | 偽章節標題 |
---|---|---|---|
[這是條目序言] |
[這是條目序言] |
[這是條目序言] |
[這是條目序言] |
請勿濫用行首半形分號和粗體來「偽裝」標題,行首半形分號是定義列表專用。讀屏器和其他輔助工具僅能使用有章節標記(半形等號)的標題來導航定位。如欲縮小目錄,請用{{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>
標籤還有小字條款的含義,不用作字體風格變化。
外語
[編輯]非中文單詞或短語應以使用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 = plainlist
or| 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).
; Noble gases
* Helium
* Neon
* Argon
* Krypton
* Xenon
* Radon
== 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
dl
is 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].