MOS:ACCESS

網頁親和力致力於使網頁更易瀏覽與閱讀。雖然這主要旨在幫助身心障礙者，但亦能可以幫助所有讀者。我們旨在遵循 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 字元依然非常難以閱讀。

1. 在名稱、地點、事物等原文相當重要的地方，如果原文使用的既非漢字也不是拉丁書寫系統文字，則請始終給出轉寫，即羅馬化。此功能在表示非羅馬字語言的模板中可用，也可以在諸如 {{transl}}} 等模板中找到；這些模板還具有可存取性等其它優點（請參閱下文的「外語」章節）。
2. 請勿使用♥（心形符號）等無法發音的符號；請以注有替代文字（`|alt=`）的圖像（如）代之。
3. 對於在螢幕閱讀器上產生問題的符號，可能已經有了生成圖像和替代文字的模板。比如 {{†}}。（有關更多資訊，請參見 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}}` 可以使語音合成器以正確的語言發音。在中文維基百科中，對於日語如不使用模板，則日本漢字可能會被視作中文錯誤簡繁轉換。其它見 Template:Lang/doc# 使用理由的完整理由。

1. 建立好的連結描述，外部連結尤甚。（避免「點此！」「見此處」）
2. 不要用 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:Manual of Style/Accessibility/Colors 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 表）。

例如，在論壇，請遵循以下最佳做法：

或用無圓點的縮進：

在回覆中隱藏圓點，也可以接受：

但 N 請勿將表格類型由點列表變成定義列表：

也 N 請勿用以下方法（同樣將表格類型由點列表變成定義列表）：

亦 N 請勿在列表項之間隔空行：

以及 N 請勿越級：

以下做法 N 不鼓勵：

因為加入的圓點，令列表變得更複雜，且令讀屏器較難跟上討論，因為可能將多出的圓點視為全新巢狀列表的開始。

#### 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}}`:

Do not N use line breaks to simulate paragraphs, because they have different semantics:

Definitely do not N 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>`). 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). 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 – see WP:Manual of Style/Glossaries/DD bug test cases.

#### 垂直列表

##### 無序垂直列表

對於無序垂直列表，請不要在專案之間用空行隔行。如果列表項之間有超過一次換行，HTML 列表將會在換行後結束，並在下一項的換行之前開啟一個新 HTML 列表。這種有效換行在螢幕閱讀器中會被視為幾個小列表。比如代碼：

```
* 白玫瑰
* 黄玫瑰

* 粉红玫瑰

* 红玫瑰
```

因為軟體抑制了行距，所以看起來如：

* 白玫瑰
* 黃玫瑰
* 粉紅玫瑰
* 紅玫瑰

但是螢幕閱讀器讀者看起來是：「2 個專案的列表：（圓點）白玫瑰，（圓點）黃玫瑰，列表結束。單專案列表：（圓點）粉紅玫瑰，列表結束。單專案列表：（圓點）紅玫瑰，列表結束。」

請不要以換行符分隔列表專案。請用以下方法代之。

##### 無專案符號垂直列表

對於頁面中縱向列出的無專案符號列表，可使用模板 {{plainlist}} 和 {{unbulleted list}} 來提高親和性語意意義，表明這是一個清晰的列表，而非通過不應使用的 `<br />` 換行。

代之在導航框一類別模板或合適的容器中，可以使用類「S`plainlist`」，也就是：

　
: `| listclass = plainlist` 或

　
: `| bodyclass = plainlist`

在資訊框中則可以使用：

　
: `| rowclass = plainlist` or

　
: `| bodyclass = plainlist`

。另見 Wikipedia: 格式手冊 / 列表 #無專案符號列表。見 WP:NAV 獲得更多關於導航模板的細節。

#### 水平列表

對於頁面中橫向列出的，以及資訊框等表格中在一行內列出的列表，請使用 {{flatlist}} 和 {{hlist}} 模板提升親和力和與語意意義。該特性對各列表項使用了正確的 HTML 標記，而不包含盲人用輔助軟體會讀出的專案符號字元（比如「點－貓－點－狗－點－馬－點……」）。

代之在導航框等模板或相似的容器中，列表可以使用 CSS 類「`hlist`」格式，也就是：

　
: `| listclass = hlist` 或

　
: `| bodyclass = hlist`

資訊框中可使用：

　
: `| rowclass = hlist` 或

　
: `| bodyclass = hlist`

見 WP:NAV 獲得更多關於導航模板的細節。

#### List headings

Improper use of a semicolon to bold a "fake heading" before a list (figure 1) creates a list gap, and worse. The semicolon line is a one-item description list, with no description content, followed by a second list.
Instead, use heading markup (figure 2).

### 表格

螢幕閱讀器和其它網頁瀏覽器工具通過特定表格標籤幫助使用者導航其中記錄的資料。

使用正確的維基表格管道語法利於所有可用特性。見 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]
...
|}
```

**標題文字（`|+`）**
: 標題文字是表格的題頭，描述其性質。

**行、列標題（`!` ）**
: 如同標題文字，它們使資訊以更為邏輯的結構展現給讀者。行列標題有助於螢幕閱讀器顯示資料儲存格的標題資訊。比如，標題資訊會在儲存格資料之前念出，或標題資訊根據要求提供。

**標題的範圍（`! scope="col" | and ! scope="row" |` ）**
: 這清晰的定義了行標題或列標題，指明了標題和其他儲存格的對應關係。

Wikipedia: 格式手冊 / 親和力 / 資料表格指南列出了這些詳細要求：

1. 正確的表格標題
2. 正確的標題結構
3. 圖像和顏色
4. 避免巢狀表格

#### 排版表格

請避免使用表格做純排版用途。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.
|}
```

1. 所有非裝飾的圖像都要有替代文字。替代文字是給盲人讀者、搜尋蜘蛛和其他非視覺使用者的代替品。加入的替代文字應該簡潔，或者應該提到圖像題注或相鄰文字：見 WP:ALT 取得更多資訊。
2. 在多數情況下，無論是使用內建的圖像語法，還是一行附屬文字，圖像都應該帶有題注。題注應該簡潔描述圖像意義，即其試圖傳達的必要資訊。
3. 避免用圖片替代資料圖表。若可能，任何圖表都應該有替代文字或充分描述，使無法檢視圖像的使用者可以明白一些內容。
4. Avoid sandwiching text between two images or, unless absolutely necessary, using fixed image sizes.
5. Avoid indiscriminate gallery sections because screen size and browser formatting may affect accessibility for some readers due to fragmented image display.
6. 不要使用左圖或右圖的描述。對於維基百科行動版而言，圖像的排列是不同的，而這對於使用輔助軟體的讀者也沒有意義。相反，請使用題注來指明圖像。
7. 如有不適合條目的詳細圖像說明，則應將其置於圖像描述頁，並留下文字註明，點開圖像連結可以獲得更詳細描述。
8. 圖像應置於其所屬章節內（在章節標題和引導至其他條目的連結之後），不應放在標題裡面或上一章節末尾，否則螢幕閱讀器會在其它章節顯示圖像（和替代文字）；行動版站點也同樣如此顯示。見 Wikipedia: 圖像指南獲得更多資訊。
9. 該指引包括 <math> 模式下 LaTeX 格式公式的替代文字。
10. Do not put images in headings; this includes icons and `<math>` markup. Doing so can break links to sections and cause other problems.

### 動畫

出於親和力考慮，動畫（GIF–圖形交換格式）應該滿足以下兩者之一：

* 持續時間不超過 5 秒（否則會變成純裝飾元素），或者
* 有控制模組（停止、暫停、播放）。

總而言之，大多數動畫 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.

### 影片

影片可以加入計時文字格式的字幕。commons:Commons:Video#Subtitles and closed captioning 有相應的幫助頁面。字幕為語音的轉錄。

對於聽力障礙者可以加入隱藏字幕。在 2012 年 11 月之前這很難做到，但通過 bugzilla:41694 的請求，現在可以簡單的加入此特性。隱藏字幕以文字形式提供了關於聲音的全部重要資訊。其可以包含在對話、聲音（自然或人聲）、環境與背景、人與動物的動作表情，以及文字或圖形。關於如何建立隱藏字幕，請參閱：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.

### 聲音

可以很方便的為演講、歌詞和對話等加入字幕。方法和影片相似：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.

* usability:Accessibility Initiative

* 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)