HTML5/introduction

介绍

背景

此章节非正式版本

繁：全球資訊網（Web）的標記語言一直是 HTML。HTML 當初主要是被當作是一個記載科學文件的語言來設計，然而 HTML 的設計的一般性與多年來的修改也讓它具有記載其他種類文件的能力。

HTML 規範尚未觸及的領域，廣泛稱作為 Web 應用程式。這份規範是正視這個領域，並以以解決過去幾年來 HTML 的問題為目標更新規範。

對象

此章节非正式版本

這份規範的對象有三：文件或腳本作者（使用定義於此規範的機能）、工具（運作在定義於此規範的文件上）的實作者、希望驗證文件或實作是否符合這份規範要求的人員。

這份文件大概不適合沒對 Web 技術至少有一個概括性了解的讀者—— 在某些地方，這份規範以精確取代明確，以完整性取代簡潔性。其他教程或是創作指引可能是比較親切的入門指引。

其中， DOM Core 與 Dom Events 基礎的掌握對這份規範的一些技術部份是不可或缺的。理解 Web IDL、HTTP、XML、Unicode、字符編碼、JavaScript、CSS 對閱讀這份文件有種種的幫助，雖然它們不是必需的。

範圍

此章节非正式版本

這份規範僅提供了一個標記語言與對應的腳本 API 的語意上的定義，使得網頁作者可以提供從靜態文件到動態應用程序的無障礙頁面。

本規範的內容不包括特定媒介的表現機制（但是在本規範的後面有瀏覽器的預設宣染規則，與作為 HTML 語言的一部份的幾個 CSS 套入機制）

這份規範的內容不包括整個作業系統。硬體調整軟體、影像處理工具、使用者需要用到高端工作站來做日常工作的應用程式不在範圍內。以應用程式來說，本規範的目標是使用者有時候會用到的應用程式，或是時時在用卻是在不同地方，需求 CPU 資源不高的應用程式。比如說，線上購買系統、搜尋系統、遊戲（特別是多人遊戲）、公用電話簿或地址簿、溝通軟體（e-mail 客戶端、即時通訊軟體、討論軟體）、文件編輯軟體等等。

沿革

此章节非正式版本

HTML 在最早的五年（1900-1995）更新並擴展了數次，主辦單位先是 CERN，然後是 IETF。

自從 W3C 的創立開始，HTML 的開發又換了一個場所。HTML 第一次失敗的擴展是 1995 年的 HTML 3.0，務實的 HTML 3.2 取而代之並於 1997 年完成。之後是於 1998 年完成的 HTML4。

在這個時候，W3C 會員決定停止發展 HTML 並啟動了 XML 版等同語言的開發，稱之為 XHTML，從將 HTML4 用 XML 改寫開始，也就是所謂的 XHTML 1.0。不具有除了新的序列化方法外的任何新功能的 XHTML 1.0 於 2000 年完成。XHTML 1.0 之後，W3C 將重點放在讓其他工作組能更輕易的擴充 XHTML，稱之為「XHTML 模組化」。於此同時，W3C 也進行了一個發展一個新語言的工作，稱之為 XHTML2，是個與之前 HTML、XHTML 都不兼容的語言。

當 HTML 的演進在 1998 年停止的那段時間，瀏覽器商開發的 HTML API 部份被制定、發佈為 DOM Level 1（於1998）、DOM Level 2 Core、DOM Level 2 HTML（起始於 2000 年並於 2003 年完成）。DOM Level 3 的一些規範於 2004 年發佈，但是工作組卻在所有 Level 3 草案完成前關閉了，這份努力漸漸消逝。

2003 年，隨著一項定位在下一世代的 Web 表單的科技—— XForms 的發佈，發展 HTML 而不是尋求一個替代物的想法複燃。XML 作為一個 Web 技術的成功僅限於全新的技術（如 RSS 或者事後來的 Atom）而不是已廣泛使用的技術（如 HTML）的這種領悟造就了這個想法。

一個作為概念驗證的草案是這個複燃想法的第一個結果，它證明擴展 HTML4，而不要求瀏覽器實作與既存 HTML 網頁不兼容的宣染引擎， 是可以達到 XForms 1.0 的新功能的。在這個開始階段，雖然草案是公開的並且向所有可以的地方徵求回饋，Opera 軟體公司有規範的版權。

應該重新啟動 HTML 的演進的這個想法在一個 2004 年的 W3C 工作仿經歷考驗，Mozilla 與 Opera 共同將 HTML5 的原則（描述於下面）與這份含有表單相關功能的初始向 W3C 發表。這份提案被以「與之前決定的 Web 演進方向有衝突」的理由拒之門外—— W3C 工作人員與會員投票決定繼續進行 XML 版取代物的發展。

不久之後，Apple、Mozilla、Opera 共同宣佈在一個稱作 WHATWG 的場所繼續這項工作。之後有了一個公開的郵件群，草案也被移至 WHATWG 的網站。接者版權被修正為三家廠商擁有，並允許規範的再利用。

WHATWG 基於幾個核心原則工作，特別是：1. 技術必須向後兼容 2. 規範與實作必須相符，就算需要更改規範而不是實作 3. 規範必須要夠詳盡，使得實作可以在不需要互相做逆向工程的情形下達到完整的互操作性。

最後一個原則使得 HTML5 必須包含之前在分開的文件—— HTML4、XHTML1、DOM2 HTML 裡制定的內容。也代表 HTML5 必須比先前視為基準的內容詳細很多。

2006 年，W3C 終究對參與 HTML5 的發展有了興趣，並於 2007 年成立了一個工作組與 WHATWG 合作進行 HTML5 規範的開發。Apple、Mozilla、Opera 允許 W3C 將規範以 W3C 的版權發佈，並保有了一個授權拘束比較少的版本在 WHATWG 的網站。

從此，兩個團體一起進行這份工作。

WHATWG 出版的 HTML 規範並不完全與本規範相同。在這個時間點，主要的差異是 WHATWG 版本有 W3C 版本沒有的功能——有些功能被略去了，雖然可能變成 HTML 在 HTML5 以後的未來版本的一部份；其他功能在 W3C 被放在不同的規範出版。

W3C HTML 工作組發佈了另一份記載此規範與 HTML4 規範差異的文件。[HTMLDIFF]

設計備註

此章节非正式版本

我們必須承認，HTML 的很多方面在第一眼看起來是沒道理且不一致的。

HTML、與它相輔相成的 DOM API 及其他伴隨的技術，由很多有不同目標的人們，經歷了很長了一段時間的開發。在很多情況下，這些人並不知道其他人的存在。

也因此有了從不同地方來的各式各樣的功能，也不總是有一致的設計。更甚者，由於線上內容總是在來得及修好實作錯誤前無意間的使用這些錯誤，造就了萬維網獨特的性質，而實作錯誤也往往成為實務上的標準，現在更是規範上的標準。

儘管如此，我們還是努力不偏離某些設計目標。下面幾的子節我們談談這些。

腳本執行的可序列性

此章節不具有規範性

為了避免 Web 作者誤觸多執行緒的複雜性，HTML 與 DOM API 被設計成永遠不能偵測到其他腳本的同步執行，連 workers 也不例外。其目的在於使得實作的行為可以被想成是一步一步執行在所有瀏覽上下文的所有腳本。

遵守其他規範

此章节非正式版本

本規範建立在很多其他種類的規範，並與這些規範作用。很不幸的，在某些狀況下，不同的需求使得本規範並須違反其他規範的要求。當這種情形發生時，這些違例被標注為「肆意違抗」，並備註違抗的理由。

HTML vs XHTML

此章节非正式版本

本規範定義了一個描述文件、應用程式的抽象語言，並定義了一些作用在使用此語言的資源內部結構的 API。

這個內部結構就是所謂的「DOM HTML」，或簡稱為「DOM」。本規範定義 DOM HTML 的五號版本，也就是所謂的「DOM5 HTML」。

有數個能夠傳輸使用這個抽象語言的資源的具體語法存在，本規範定義了其中的兩個。

這一個具體語法是 HTML 語法。這是建議給大部分作者的格式，它與大部分的老舊瀏覽器兼容。如果一份文件以像是 text/html 的 HTML MIME 類型傳輸，則瀏覽器會把其當作是 HTML 文件處理。本規範定義 HTML 語法的五號版本，也就是所謂的「HTML5」。

第二個具體語法是 XHTML 語法，是一個 XML 的應用。當一份文件以像是 application/xhtml+xml 的 XML MIME 類型傳輸的時候，瀏覽器會把其當作是 XML 文件，用 XML 處理器解析。作者需要注意 XML 與 HTML 的處理不同，特別是細小的語法錯誤會讓標為 XML 的文件無法完整宣染，然而在 HTML 語法下細小的錯誤會被忽略。本規範定義 XHTML 語法的五號版本，也就是所謂的「XHTML5」。

DOM、HTML 語法、XML 並不是皆能表示一樣的內容。舉例來說，用 HTML 語法表示名稱空間是做不到的，但是在 DOM 跟 XML 下是沒有問題。用 HTML 語法表示 noscript 功能是可以的，但是無法用 DOM 或 XML 表示。含有 "-->" 字串的註解可以用 DOM 表示，但是 HTML 與 XML 不行。

這份規範的結構

此章节非正式版本

本規範分為以下的主要章節：

通用基礎架構

符合類、演算法、定義與規範其他部份的共通基礎。

語意、結構與 HTML 文件的 API

文件由元素構成。這些文素用 DOM 形成了一棵樹。此章節定義這個 DOM 的功能，並介紹所有元素共通的功能與定義元素使用的概念。

HTML 的元素

這章節解釋每個元素預定義的語意，並解釋作者使用各元素的規則與用戶代理處理各元素的要求。

網頁加載過程

HTML 文件並不在真空存在——此章節定義影響處理多個頁面環境的功能。

Web 應用程式 API

此章節介紹 HTML 應用程式腳本的基本功能。

用戶交互

HTML 文件可以提供數個讓使用者交互、更改內容的機制，描述於這個章節。

HTML 語法

XHTML 語法

若文件無法被序列化並在人們之間傳遞，這些功能便是虛無。這兩個章節定義 HTML 的語法與用這個些法解析內容的規則。

也有些附錄章節定義瀏覽器的宣染規則，列出作廢的功能與 IANA 對價。

如何閱讀本規範

本規範的閱讀方式與其他規範差不多。首先，從頭到尾多次閱讀。然後，從後面 向前讀至少一次。然後從目錄取隨機章節來讀，並遵循所有交差引用閱讀。

排版慣例

這是一個定義、要求或解釋。

interface Example {
  // 這是一個 IDL 定義
};

/* 這是一個 CSS  片段 */

一個專有名詞的定義位置的標記就像這樣。使用這個專有名詞的標記就像這樣或「這樣」

一個元素、屬性或 API 的定義位置的標記就像這樣。參照該元素、屬性或 API 的標記就像這樣。

其他源碼片段的標記就像這樣。

變數的標記就像這樣。

這是一個實作要求。

HTML 的簡短介紹

此章節不具有規範性

一個基本的 HTML 文件長得像這樣：

<!DOCTYPE html>
<html>
 <head>
  <title>頁面樣本</title>
 </head>
 <body>
  <h1>頁面樣本</h1>
  <p>這是一個<a href="demo.html">簡單</a>的樣本。</p>
  <!-- 這是一個註解 -->
 </body>
</html>

HTML 文件由一個元素的樹與文字組成。每一個元素在原始碼中表示為像是「<body>」的開始標籤與像是「</body>」的結束標衝。（某些開始標籤與結束標籤，因為其他標籤的存在，在某些情形可以忽略）。

標籤的出現必須是巢狀，也就是元素是一個在一個裡面而沒有重疊：

<p>這真是<em><strong>錯</em>得離譜！</strong></p>

<p>這<em>是<strong>正確</strong>的。</em></p>

本規範定義了可以在 HTML 裡使用的元素集合，並定義了哪些元素可以在哪些元素裡的規則。

元素可以有控制元素行為的屬性。在下面這個例子裡，a 元素與它的 href 屬性形成了一個超連結：

<a href="demo.html">簡單</a>

屬性位於開始標籤裡面，由被 "=" 字符分開的一個名稱與一個取值構成。如果屬性值不含有 " ' ` = < > 其中任一，它可以不被誇起來。否則，必須用單引號或雙引號將屬性值誇起來。如果取值是空白字串，可以直接同時省略取值與 "=" 字符。

<!-- 空白屬性 -->
<input name=address disabled>
<input name=address disabled="">

<!-- 有值屬性 -->
<input name=address maxlength=200>
<input name=address maxlength='200'>
<input name=address maxlength="200">

然後 HTML 使用代理（例如瀏覽器）會「解析」這些標籤，將標籤轉化成一個 DOM（文件物件模型）樹。一個 DOM 樹是一個文件的內部結構。

DOM 樹裡面會有幾種不同種類的節點，特別是 DOCTYPE 節點、元素、文字節點與註解節點。

本小節一開始的標籤範例會轉化成下面這個 DOM 樹。

├ DOCTYPE: html
└ html
  ├ head
  │ ├ #text: ⏎␣␣
  │ ├ title
  │ │ └ #text: 頁面樣本
  │ └ #text: ⏎␣
  ├ #text: ⏎␣
  └ body
     ├ #text: ⏎␣␣
     ├ h1
     │ └ #text: 頁面樣本
     ├ #text: ⏎␣␣
     ├ p
     │ ├ #text: 這是一個
     │ ├ a href="demo.html"
     │ │ └ #text: 簡單
     │ └ #text: 的樣本。
     ├ #text: ⏎␣␣
     ├ #comment:  這是一個註解
     └ #text: ⏎␣⏎

html 元素是這棵樹的根元素，也總是任何一個 HTML 文件的根元素。這個 html 元素含有兩個元素，head 與 body 跟兩個節點之間的一個文字節點。

由於原始碼含有很多會成為 DOM 裡文字節點的空格（用 "␣"）與換行字符（"⏎"），DOM 裡面有比一般人預期更多的文字節點。然而，由於歷史因素，並非所有在原始碼的空格跟換行字符都進入了 DOM。所有在 head 的開始標籤之前的空白會被偷偷地丟掉，所有 body 的結束標籤後面的空白會跑到 body 的最後面。

這個 head 元素含有一個 title 元素，title 元素本身含有內容是 "頁面樣本" 的文字節點。這個 body 元素含有一個 h1 元素、一個 p 元素跟註解。

這個 DOM 樹可以用頁面裡的腳本操作。腳本（通常是 JavaScript）是可以用 script 元素或是事件處起器內容元素嵌入的小程式。這裡有一個用腳本讓表單的 output 元素說「歡迎，世界！」的例子：

<form name="main">
 結果：<output name="result"></output>
 <script>
  document.forms.main.elements.result.value = 'Hello, World！';
 </script>
</form>

DOM 樹裡面的每一個元素都有一個對應的物件，而這些物件有可以操作它們的 API。舉例來說，有很多不同方式可以更改一個連結（例如上面的樹的 a 元素）的 "href" 屬性：

var a = document.links[0]; // 得到文件裡的第一個連結
a.href = 'sample.html'; // 變更連結的目的地 URL
a.protocol = 'https'; // 只變更 URL 的 scheme 部份 
a.setAttribute('href', 'http://example.com/'); // 直接更改內容屬性

由於 DOM 樹是實作（特別是瀏覽器之類的互動實作）對 HTML 文件處理並呈現的結構，本規範大部分以 DOM 樹而不是標記語言作為書寫基準。

HTML 文件是一種動態內容的不分媒介的描述。HTML 元素可在屏幕、語音合成器或是點字顯示器宣染。作者可以用 CSS 之類的樣式語言影響宣染的過程。

在下面的例子裡，頁面呈現為藍底黃字。

<!DOCTYPE html>
<html>
 <head>
  <title>具有樣式的頁面樣本</title>
  <style>
   body { background: navy; color: yellow; }
  </style>
 </head>
 <body>
  <h1>具有樣式的頁面樣本</h1>
  <p>本頁面只是個演示。</p>
 </body>
</html>

若想仔細的學如何使用 HTML，我們鼓勵作者參考其他教程與指引。本規範裡面的一些例子可能有用，但是初學者要注意本規範作為定義語言的文件，其詳細的程度可能造成一開始的理解困難。

對於作者的符合要求

此章節不具有規範性

與先前的 HTML 規範版本不同，本規範同時定義了處理合法與不合法文件的處理細節。

然而，儘管在大多數的情況下處理不合法內容的方法是有明確定義的，文件的符合要求仍然很重要——實際來說，互操作性（所有實作皆以可靠又雷同或是相同的方式處理特定內容）不是文件符合要求的唯一目標。本規範仍區別符合規範的文件與有錯誤的文件，此小節描述一些這樣做的理由與細節。

表象標記

此章节非正式版本

本規範不再與許大部分先前 HTML 版本有的表象功能。表象標記有很多問題：

表象標記的使用造成糟糕的無障礙環境

儘管使用表象標記並給予輔助科技（AT）使用者可接受的體驗（例如使用 ARIA）是可能的，這樣做卻比使用適合的語意標籤困難很多。另外，用這些技巧不會讓文字瀏覽器之類非 AT 非圖像界面的使用者具有無障礙的體驗。

另一方面，使用不分媒介的標記是使更多使用者（例如文字瀏覽器使用者）能閱覽文件的簡單方法。

更高的維護成本

維護一個用不分樣式的標記寫出來的網站簡單很多。舉例來說，對於一個全程使用 <font color=""> 的網站，改變顏色會更動整個網站，對於一個使用 CSS 的網站做類似的更改只需要改一個檔案。

文件尺寸較大

一般來說，表象標記比較冗長，因而導致文件尺寸較大的現象。

由於這些理由，這個版本裡已沒有表象標記。這並不讓人意外——HTML4 已在多年前廢棄了表象標籤並提供作者一個從表象標記離開的模式（HTML4 Transitional）。之後，XHTML 1.1 更是完全廢除了這些功能。

在 HTML 裡剩下的表象標籤功能只有 style 屬性與 style 元素。雖然 style 屬性在原型製作上很快且很有用（之後可以 將規則直接移至另外的樣式表），也可以在使用另外的樣式表不方便的時候指定樣式，但是我們不鼓勵在生產環境裡使用。同樣的，style 元素在發佈消息來源 或是要指定某頁面的特定樣式的時候很有用，但是一般來說當樣式用於多個頁面的時候，額外的樣式表可能比較方便。

值得一提的是，一些過去的表象元素被本規範定義為不分媒介的元素：b、i、hr、s、small 與 u。

語法錯誤

此章节非正式版本

HTML 語法的限制在於避免很多不同的問題。

不直觀的錯誤處理行為

解析某些不合法的語法構造會產生非常不直觀的 DOM 樹。

<table><hr>...

造成選擇性錯誤處理的錯誤

為了讓使用者代理在受控制的環境運行而不必要實作更多奇怪、費解的錯誤處理規則，本規範允許使用者代理在遇到解析錯誤的時候停止解析。

造成錯誤處理行為與串流使用者代理不兼容的錯誤

前面提到的例子 <table><hr>... 之類的錯誤處理行為與串流使用者代理（直接處理 HTML 檔案而沒有儲存狀態的用戶代理）不兼容。為了避免與該類的用戶代理發生的互操作性問題，任何造成這種行為的語法被視為是不合法的。

造成信息集間接轉換的錯誤

當一個建構於 XML 之上的用戶代理與一個 HTML 解析器相連的時候，HTML 檔可能違反 XML 要求的某些不變式，像是註解不能以含有連續兩個連字符號。若要處理這種狀況，勢必要要求解析器做 HTML DOM 到與 XML 兼容信息集的間接轉換。大部分會要求解析器做這種處理的語法構造被視為是不合法的。

造成不成比例的性能不良的錯誤

某些語法構造會導致不成比例的性能不良。為避免這類構造的使用，將這類構造定義為非標準。

<p><i>他睡著了。
<p><i>他夢到他在吃早餐。
<p><i>然後是午餐。
<p><i>最後是晚餐。

├ p 
│ └ i
│    └ #text: 他睡著了。
├ p
│ └ i
│    └ i
│       └ #text: 他夢到他在吃早餐。
├ p
│ └ i
│    └ i
│       └ i
│          └ #text: 然後是午餐。
└ p
    └ i
       └ i
          └ i
             └ i

具有脆弱的語法構造的錯誤

由於歷史因素，有些語法構造相對脆弱。為了減少不小心碰觸這個問題的使用者，將這類構造定義為非標準。

<a href="?bill&ted">比爾和泰德</a>

<a href="?art&copy">藝術與拷貝</a>

<a href="?bill&ted">比爾和泰德</a> <!-- &ted 因為不是命名字符引用，沒問題 -->

<a href="?art&copy">藝術與拷貝</a> <!-- 由於 &copy 是一個命名字符引用，必須要轉義 -->

與老舊使用者代理有已知互操作性問題的錯誤

某些語法構造有已知在老舊使用者代理上嚴重或難以察覺的問題。為了幫助作者避開這種問題，將這類構造標為非標準。

會導致作者遭受安全攻擊的錯誤

某些限制僅為了避免安全問題。

作者的目的不明確的情形

本規範將作者目的非常不明確的標記定義為非標準。修復這些錯誤可以簡化維護的過程。

<h1>詳細連絡方式</h2>

可能是錯字的情形

當使用者寫錯字，為了減少作者除錯時間，最好能越早發現越好。因此，本規範大致將不符合定易於本規範的元素名、屬姓名等等視為錯誤。

可能與未來新語法造成衝突的錯誤

為了讓語法在未來得以延伸，不允許使用某些無害的功能。

有些作者喜歡將每個屬性誇起來、不省略所有選擇性的標籤，喜歡這種風格的一致性勝過於使用 HTML 語法伸展性帶來的簡潔。為了幫助這種作者，標準符合驗證器可以提供強迫使用這種慣例的運行模式。

內容模型與屬性值的限制

此章节非正式版本

除了語言的語法之外，本規範在使用元素、屬性上也做了限制。這些限制也有類似的理由：

內容具有不三不四語意的錯誤

為了避免使用者亂用有既定意義的元素，內容模型限制了哪些元素可以在哪些元素的規則，避免不三不四的使用方式。

表示語意有衝突的錯誤

<hr role="cell">

<input type=radio role=progressbar>

預設樣式可能會造成混亂的情形

某些元素有預設的樣式或行為，而某些組合會造成混亂。而這些組合也有沒有這種問題 的替代方案存在，所以不允許這些造成混亂的組合。

可能的規範誤解

有時候不允許某種功能是因為這個機能可能造成作者的困擾。

為了簡化語言造成的錯誤

某些符合錯誤的存在是為了簡化作者需要學習的語言

與解析器特異之處相關的錯誤

某些元素的解析方式有古怪之處（通常由於歷史因素），而為了避免作者誤觸這些問題，在這些元素內容模型上加上限制。

<p>歡迎。<form><label>姓名：</label> <input></form>

<p>歡迎。</p><form><label>姓名：</label> <input></form>

會導致有問題的腳本難以偵錯

有些錯誤是為了避免難以偵錯的腳本問題。

浪費創作時間

本規範不允許一些曾浪費很多創作時間的構造，鼓勵作者避免使用這些構造可以讓作者在未來省下很多時間。

與移植至 XHTML 或從 XTHML 移植過來相關的錯誤

有些作者喜歡寫可以同時被解讀為 XML 與 HTML 並得到類似結果的檔案。由於無數的微妙複雜性（特別是與腳本執行、樣式套用或任何的自動序列化），本規範一般來說不鼓勵這種做法，但是本規範具有一些為了減少這種複雜性而有的限制。這讓作者以這種檔案當作 HTML 與 XHTML 之間移植的過渡格式。

保留作為未來擴展

與為了保持未來新語法的擴充對於語法做的限制相同，為了未來 HTML 字彙的延伸，做了對於元素的內容模型與屬性值的一些限制。

其他規範的錯誤使用

某些限制為其他規範給予的限制。

建議閱讀

此章节非正式版本

本規範的讀者可能會對以下的文件有興趣：

全球資訊網的字符模型 1.0：基礎 [CHARMOD]

全球資訊網建構在由《Unicode 標準》與《ISO/IEC 10646》共同定義的通用字符集上。這份架構規範是一份給規範作者、軟體開發者與內容開發者的共通參考資料，內容是全球資訊網上的互操作文字處理，主題包括術語「字符」、「編碼」與「字串」的使用，一個參考用的處理模型，字符編碼的選擇與識別，字符轉義與字串索引。

Unicode 安全考量 [UTR36]

因為 Unicode 有那麼多的字符並涵蓋了世界上不同的書寫系統，不正確的使用 Unicode 可能導致程式、系統遭受安全攻擊。由於越來越多產品經歷了國際化，這也特別重要。這份文件有程式員、系統分析師、標準開發者與使用者應該注意的安全考量，也為了減低問題的風險提供建議。

Web 內容親和力指引（WCAG）2.0 [WCAG]

《Web 內容親和力指引（WCAG）2.0》涵蓋了讓 Web 內容更具有親和力的廣泛建議。遵照這些指引即可製出讓廣泛的傷殘人士親易使用的內容，對象包括盲人與低視力族群、聾啞人士、學習障礙人士、認知缺陷人士、行動障礙人士、語言障礙人士、光敏患者等等。遵照這個指引也使得 Web 內容對於一般使用者更為可用。

創作工具親和力指引（ATAG）2.0 [ATAG]

這份規範提供了設計讓傷殘人士親易使用 Web 創作工具的指引。符合這些指引的創作工具提供傷殘人士親和力高的使用者界面，支持、促進所有作者產出具有親和力的 Web 內容，因而促進網頁親和力。

使用者代理親和力指引（UAAG）2.0 [UAAG]

這份文件提供使用者代理的在 Web 親和力方面的設計指引，以減低傷殘人士擷取 Web 內容受到的障礙。使用者代理包含瀏覽器或是其他讀取、宣染 Web 內容的軟體。符合這些指引的使用者代理透過使用者界面與其他內部設施（包含與其他科技，特別是輔助科技，溝通的能力）促進網頁親和力。符合規範的使用者代理對所有人更方便使用，不僅是傷殘人士。

多語言標記：與 HTML 兼容的 XHTML 文件 [POLYGLOT]

使用多語言標記的文件是一串當作 HTML 跟 XML 解析後會得等同文件樹（除了根元素的 xmlns 屬性以外）的位元組串流。符合一連串明確限制的多語言標記，根據 HTML5 規範當作 HTML 或是 XHTML 處理會得到兼容的結果。多語言標記使用一個特定的 DOCTYPE、命名空間宣告、元素與屬性名的特定寫法——一般是小寫不過有時候要大小兼用。多語言標記在某些屬性值使用小寫。另外也有對於空元素、命名字符引用、腳本與樣式使用的限制。

從 HTML 到平台親和力 API 實作指南 [HPAAIG]

這是份描寫 HTML 元素與屬性至數個平台的親和力 API 角色、狀態與屬性對應的文檔草案，提供了從 HTML 元素取得親和名與描述的建議，並提供了具有親和力的功能實作的範例。