可及性 (A11y) 實務：表單與圖片的改善技巧

提供對應的文字標籤:每個表單輸入欄位都應有明確的文字標籤 (<label>)。標籤讓視覺使用者一眼明瞭欄位用途,同時透過程式關聯(使用 <label for> 屬性對應 <input id>)使螢幕閱讀器能讀出標籤內容。例如,對於電子郵件輸入欄位,可以這樣建立標籤:

當使用者聚焦此欄位時,輔助技術將會讀出「電子郵件:」以提供欄位意義。請避免僅以視覺排版將文字放在欄位旁而不使用<label>,因為那無法讓非視覺使用者感知兩者的關聯。

切勿以 Placeholder 取代標籤:Placeholder(佔位提示文字)經常被誤用為欄位標籤,但這並不是好做法。首先,placeholder 在使用者輸入內容後會消失,可能導致使用者遺忘欄位原本的用途;其次,許多螢幕閱讀器並不會在聚焦時自動讀出 placeholder(或只當作輔助說明而非名稱)。正如 HTML 規範所述:"placeholder 屬性不應被用來替代 <label>"。因此,應確保永遠都有視覺可見或隱藏但可被無障礙技術讀出的標籤。若因版面限制確實無法顯示標籤,可考慮使用隱形文字(例如以 CSS 將標籤藏起但保留屏幕閱讀器可讀取),或用 ARIA 提供可及性名稱,例如 aria-label 或 aria-labelledby:

上例中,雖然輸入框沒有顯示實際的文字標籤,但 aria-label 提供了可被輔助技術朗讀的名稱「站內搜尋欄位」,確保無障礙使用者了解此欄位的用途。總而言之,最佳做法仍是提供對應的 <label>,ARIA 屬性應作為輔助方案而非替代。

提供欄位說明與提示:若欄位需要特定格式或有額外說明(例如密碼規則、地址格式),應將這些提示資訊與欄位相關聯,而不是僅僅放在欄位附近的純文字註解。您可以在標籤中直接包含簡要說明,或使用 aria-describedby 將欄位與說明文字連結。例如:

透過 aria-describedby="phoneTip",當螢幕閱讀器聚焦輸入框時,會先讀出標籤「手機號碼:」,接著讀出提示內容「請輸入 10 碼行動電話號碼。」。如此一來,用戶不用四處搜尋說明文字即可明瞭格式要求。此外,這段提示文字在視覺上緊鄰欄位,對於一般使用者也同樣友善。

群組相關欄位:當多個選項屬於同一組別(例如性別選擇的兩個 radio 按鈕,或地址的多個欄位),別忘了使用 <fieldset> 與 <legend> 將它們包裹起來。<legend> 會作為該群組的描述,例如:

螢幕閱讀器在進入這個欄位群組時,會先朗讀 <legend>(例如「聯絡方式偏好」),讓使用者知道接下來的選項都屬於同一類別。這對視障用戶尤為重要,因為純粹透過縮排或版面佈局來表現群組,在他們的體驗中是不存在的。

小技巧總結:

• 每個輸入欄位都務必有對應的可及性名稱——首選可見的 <label> 連結,其次可用 ARIA 標示補充。
• 別用 placeholder 取代真正的標籤。Placeholder 可作為範例或輔助說明,但不能作唯一識別。
• 必要時使用 aria-describedby 將輔助文字(格式說明、範例等)與欄位關聯,確保提示會被讀出。
• 利用 <fieldset>/<legend> 群組相關欄位,為輔助技術提供脈絡說明。

標示必填欄位:在表單中明確標出哪些欄位是必填,對所有用戶都是基本的禮貌與指南。對於視覺使用者,常見做法是在標籤旁加上紅色星號或文字說明「(必填)」。但光靠顏色或符號不足以傳達給螢幕閱讀器用戶。建議直接在標籤文字中標示必填,例如:

如上例,螢幕閱讀器會讀出「姓名 必填」,確保用戶瞭解這是必填欄位。另外我們也加上 required 屬性,讓瀏覽器本身(及部分輔助技術)得知此欄位不可留空。required 屬性會使得某些瀏覽器在未填時自動顯示錯誤提示,但 仍建議 開發者自行實作更完整的驗證回饋(稍後詳述)。如果出於設計原因不方便在標籤寫上「必填」,至少應以 ARIA 標註,例如加入 aria-required="true",以程式方式標記欄位為必填。不過請注意,aria-required 並不會自動讓瀏覽器驗證,它僅提供給輔助技術識別用途。

格式要求:若欄位有特定格式(例如日期格式 YYYY-MM-DD、電話需要 10 碼等),要提早讓使用者知道。可以在標籤或描述文字中說明格式要求,如上一小節的範例所示。另一種方式是善用 HTML5 輸入類型和屬性,例如使用 <input type="email">、<input type="number"> 或 pattern 正則表達式等,瀏覽器會在提交前自動檢查基本格式並提示錯誤。但切記不要完全依賴 HTML5 驗證,因為瀏覽器行為不統一,而且無法取代自訂的易用性考量。例如,如果電話欄位有固定格式需求,開發者可以選擇在後端/前端程式自動去除空白或調整格式,減輕使用者的負擔。總之,讓規則透明且前置:在用戶輸入前就給出清晰指引,而非等提交後才報錯,這對無障礙與整體體驗都至關重要。

小技巧總結:

• 在標籤或輔助文字中直接標示「必填」或必要格式,千萬別只用顏色或星號暗示。
• 使用 required 或 aria-required="true" 明確定義必填欄位,確保輔助技術會通知使用者。
• 善用適當的 <input type>(例如 Email、URL、Number)和內建屬性來提升可及性與使用便利,但仍應提供清楚的人性化說明。
• 提前告知格式限制,將潛在錯誤扼殺在搖籃中,這對所有使用者都是最友善的作法。

即使有完善的指引,用戶仍可能在提交表單時遺漏欄位或輸入無效資訊。因此,良好的錯誤處理機制必不可少。可及性的重點在於:錯誤發生時,我們要清楚地通知使用者哪裡需要修正,以及如何修正,同時確保這些訊息對於視障或行動不便者也是明確可達的。

即時與提交後驗證:表單驗證可分為即時(使用者輸入時或離開欄位時檢查)和提交後(整體表單送出時檢查)兩種。無論哪種,都應遵循以下原則:

• 明確提示:錯誤訊息要具體說明問題,例如「請輸入有效的電子郵件地址」,而不是含糊的「格式錯誤」。理想上還應告訴使用者如何更正(例如「電子郵件地址需包含 '@' 符號」)。
• 視覺呈現:將錯誤訊息以明顯的樣式(如紅色文字)顯示在相關欄位附近,或者彙總顯示在表單頂部。同時以圖示或樣式標記出錯的欄位,例如讓欄位邊框變紅色,增強視覺辨識度。
• 無障礙呈現:對於螢幕閱讀器,用戶提交後若有多個錯誤,可在頁面頂部提供一則總括的錯誤通知並將焦點移至該處,讓他們立即知道表單未成功提交。此外,每個錯誤訊息應與對應的欄位程式關聯,這點相當重要。

將錯誤訊息關聯至欄位:可透過兩種方式實現:一是直接將錯誤文字包含在標籤或<fieldset>的 <legend> 中(對於一些簡單情況);二是使用 aria-describedby 或 aria-errormessage。aria-describedby 可以將欄位和錯誤訊息元素連結起來,使螢幕閱讀器在聚焦該欄位時一併讀出錯誤。aria-errormessage 則是專門用於錯誤描述的屬性,它的值指向提供錯誤訊息的元素id,但只有在該欄位標記為無效時(例如設置 aria-invalid="true")才會被讀取。以下是一個使用 aria-describedby 的範例:

在上述程式碼中,我們採取了多項措施來確保錯誤易於被察覺和理解:

• 當電子郵件欄位未通過驗證時,在 <input> 上加上了 aria-invalid="true",螢幕閱讀器將會提示該欄位「無效,需要關注」。
• aria-describedby="err-email" 使得螢幕閱讀器讀出欄位時會附帶參考 id="err-email" 的<span>內容。因此使用者一聚焦在欄位上,就能聽到「請輸入有效的電子郵件位址」這條錯誤描述。
• 錯誤訊息的 <span> 使用了 role="alert"。這會將其宣告為即時的「警示」區域,只要它出現在頁面上(例如透過JS動態插入或顯示),螢幕閱讀器便會立即朗讀其中內容,無需使用者特別聚焦。換言之,一旦使用者觸發驗證、錯誤訊息出現,即便他們還停留在輸入框,螢幕閱讀器也會自動打斷當前流程,播報「請輸入有效的電子郵件位址」這段文字,確保錯誤不會被錯過。
• 我們也以紅色字體顯示錯誤(可透過CSS設定 .error-msg 的樣式),並在欄位上加上 aria-invalid 後配合CSS讓該欄位邊框變色,以視覺提示錯誤位置。

當表單有多個錯誤時,建議同時提供整體與逐項的反饋:例如在表單頂部集中顯示「請更正以下錯誤:電子郵件無效、密碼未填寫。」,並列出每項錯誤(可搭配超連結讓使用者點擊後跳到對應欄位)。顯示後立即將鍵盤焦點設到這個錯誤總覽區塊,使螢幕閱讀器用戶第一時間聽到總體訊息。然後使用者可以逐一修正,每個欄位旁都有內聯錯誤提示做支援。這種「上有總覽、下有細節」的方式兼具了可見性與便利性:視覺使用者可以快速掃描錯誤列表並點擊跳轉,非視覺使用者則能透過焦點移動順序先聽到總覽,再進一步逐欄位確認錯誤。

小技巧總結:

• 錯誤訊息要具體明瞭,語氣友善但直截了當,清楚指出問題和解決方式。
• 無障礙角度,確保每則錯誤訊息都程序性地關聯到對應欄位(例如用aria-describedby),並將出錯欄位標記為無效(aria-invalid="true")供螢幕閱讀器提示。
• 使用 ARIA live 區域(role="alert" 或 aria-live)讓動態出現的錯誤訊息即時被讀出。避免只有視覺上的提示而輔助技術無法即刻感知。
• 提供快速導覽所有錯誤的方式。提交後若有多處錯誤,可將焦點導向頁面頂部的錯誤概覽,列出問題摘要並支援一鍵定位各欄位,提升可修正性。
• 切忌使用者提交表單遇到錯誤時什麼反饋都沒有就把畫面重置或停留原地——對於看不見螢幕變化的用戶,那等同於陷入無聲的失敗境地。

無障礙的表單設計還需考量鍵盤操作等多方面細節:

• 鍵盤導覽順序:確保表單的欄位排列順序和來源碼順序一致,以符合使用 Tab 鍵逐項瀏覽的預期。不要用複雜的版面讓瀏覽順序混亂,也盡量不要使用 tabindex 改變順序(除非必要),以免使用者在鍵盤導航時感到跳躍突兀。
• 避免鍵盤陷阱:表單中的互動元件(例如下拉選單、自訂的小工具)應能以鍵盤操作完全使用。如果使用了 JavaScript 控制元素狀態,務必提供對應的鍵盤事件監聽(如 Enter 或空白鍵觸發按鈕點擊、方向鍵操作選單等),並測試確保使用 Tab 可以進出該元件而不被困住。一個實用建議是:嘗試不碰滑鼠只用鍵盤完整操作一次表單,看看是否流暢。
• 自訂元件的語意:若您創建了自訂的表單控制項(例如自行設計開關Toggle或星等評分等),請使用ARIA為它們補上適當的語意和屬性。例如,一個自製的切換開關,應該有 role="switch" 並隨狀態更新 aria-checked="true/false",如此螢幕閱讀器才能將其當作可切換元件來宣告。又或者,如果您設計一個客製下拉選單,點擊後展開的選項列表應該有 role="listbox",其項目有 role="option" 且可被鍵盤上下鍵導航等。這些進階技巧雖超出本文範疇,但核心在於:自訂互動元件務必給予適當的無障礙標記,不要讓輔助技術只看到一堆沒有語意的 <div>。
• 提供明確的焦點指示:當使用者以鍵盤操作表單時,確保聚焦所在的位置清晰可見。瀏覽器預設會以虛線或螢光框表示焦點,但有些開發者可能會將它移除以求美觀。千萬不要隱藏焦點指示,或至少自行以CSS設計一個等價的樣式(例如明顯的底線或陰影)來告知使用者哪個欄位正在輸入。
• 避免僅用動態變化傳遞訊息:表單有些互動可能透過即時動態變化(AJAX 更新某區塊內容、即時計算結果等)來提示使用者。記得為這些區域加上 ARIA live 属性,例如 aria-live="polite" 讓螢幕閱讀器得知該區塊內容變了,進而朗讀新的內容。否則使用者在視覺上看到了變化,但視障者可能毫無察覺。

總而言之,在表單可及性上所花的每分努力,都在讓更多人享受到產品的便利。當所有使用者——無論能力高低、使用裝置不同——都能順利地填寫您的表單時,這份體驗的良善將自然地反映在產品口碑中。

每張圖片都應有替代文字:HTML 提供了 alt 屬性讓您為 <img> 圖像定義替代文字(Alternative Text)。所有圖像都必須設置 alt 屬性,即便只是留空(alt="")。沒有 alt 的圖片,對螢幕閱讀器而言是一片沉默,有時它們可能會讀出難以理解的檔案名稱來代替。因此,永遠不要省略 alt,應視情況提供適當內容或空值。

根據情境撰寫替代文字:替代文字應該傳達圖像的內容或功能,而非機械地描述圖像外觀。撰寫時可以自問:「這張圖對使用者來說代表什麼資訊?如果看不到它,我需要以文字知道什麼?」例如:

• 圖片是裝飾用途(不帶資訊):alt 應該是空字串(""),因為我們不需要任何冗餘說明,詳細原因在下節討論。
• 圖片呈現了內容資訊:alt 應扼要描述重點。假設有一張照片顯示一位科學家在實驗室進行 COVID-19 疫苗研發,那麼合適的 alt 可能是「科學家在實驗室研發疫苗」。
• 圖片傳達功能或意圖:如果圖片包含文字(如促銷海報)或明確意義,則 alt 應包含那些文字或意義。例如,一張活動宣傳海報,上面寫有「OpenA11y 年會,2025/12/3」,則可以:

如此一來,看不到圖的人也能得知海報的關鍵資訊。

圖片是連結或按鈕:如果圖像本身可點擊且沒有其他文字說明(例如一個只有圖示的「搜尋」按鈕),那麼 alt 應說明其功能,例如 alt="搜尋"。這樣當螢幕閱讀器聚焦該按鈕時,會讀出「搜尋,按鈕」,而不是默默無聲或讀出難解的檔名。

撰寫優良 alt 的原則:

• 等價:替代文字應完整傳達圖像的等價資訊或功能。如果圖像中有重要的文字訊息,務必包含在 alt 中;如果圖像是一個操作按鈕,alt 要說明按下會做什麼。
• 簡潔:能用幾個字說明就不要整句,一般而言一兩個詞到最多一兩句已足夠。冗長的 alt 可能使閱讀變得緩慢繁瑣。但也要避免過度簡略以致失去意義。尋找精準的表達:足夠完整又不囉嗦。
• 避免冗餘:不要在 alt 中重複周圍文本已經提供的資訊。如果圖像的內容在正文中已有說明,alt 可以適當簡化。例如正文寫著「愛因斯坦站在黑板前微笑」且旁邊有張愛因斯坦的照片,那 alt 可以只是「愛因斯坦」,無需重述微笑等細節,因為文字已經說明了。
• 避免描述「這是一張圖片」:別寫「圖片:XX」或「圖像:XX」,因為螢幕閱讀器會自己標示這是圖像,不需要你在 alt 再講一次。直接敘述內容即可。例如,把 alt="圖示:放大鏡" 改為 alt="搜尋"(若此圖示用作搜尋功能)。當然,如果圖像類型本身是重點(攝影照片、手繪插圖等)且對語意有幫助,才在 alt 提及。
• 情境決定 alt:值得再次強調,替代文字沒有萬用公式,它取決於圖像所處的情境和用途。同一張圖用在不同地方,alt 可能截然不同——這也是為何我們強調由內容作者來提供替代文字,而非依賴機器自動判斷。

因此請根據圖像的目的來編寫替代文字,而非僅僅描述圖像表面。

所謂裝飾性(裝飾性)圖像,指的是對內容資訊沒有實質貢獻的圖片。例如版面上的分隔線、純美術裝飾的花邊、或與鄰近文本描述完全重複的圖像等。如果拿掉這些圖,並不影響使用者對內容的理解。對於這類圖像,我們的策略是讓輔助技術忽略它們,以避免干擾。

使用空的 alt 屬性:最簡單的做法,就是在 <img> 上寫 alt=""。空的 alt(也稱「null 替代文字」)會讓螢幕閱讀器直接跳過該圖片,不會發出任何聲音。這能防止朗讀一些無意義的內容(例如「邊框圖像」)干擾使用者注意力。請注意:一定要寫出 alt="",而不是省略整個 alt 屬性!如果缺少 alt,有些螢幕閱讀器可能會讀出圖片檔名當替代—想像聽到「圖像, DECOR123.webp」的困惑場景。所以,對於裝飾圖請明確地將 alt 設為空字串。例子:

以上表示這個 border.webp 只是裝飾用途,輔助技術可放心忽略它。

ARIA 隱藏或 role=presentation:除了 alt="" 之外,也可以採用 WAI-ARIA 屬性:給裝飾性元素加上 aria-hidden="true",或對 <img> 用 role="presentation"。兩者作用類似,都是將元素從無障礙樹中移除。比如:

role="presentation" 會告訴輔助技術此圖像只是呈現用途,不需朗讀;aria-hidden="true" 則直接將包含該屬性的節點隱藏。但需注意:role="presentation" 對某些舊型態技術的支援度不如 alt="" 來得廣。一般而言,對於 <img> 標籤,寫 alt="" 已足夠且是最佳實踐;aria-hidden 則常用於非 <img> 的元素(例如用 CSS 或字型圖示呈現的裝飾圖案)。

盡量使用 CSS 背景圖作為裝飾:如果一張圖完全是為了版面美觀考量,優先考慮不要以 <img> 嵌入,而改用 CSS background-image 來呈現。CSS 背景圖不在文件結構中,本身對螢幕閱讀器是不可見的,自然達到裝飾隱藏的效果(當然也代表它不能攜帶有意義的替代文字)。例如,大面積的情境圖片或花紋可以用背景圖,然後在 HTML 中不額外插入<img>。這樣做有個額外好處:如果使用者開啟「高對比模式」或自訂樣式,這些純裝飾的背景圖可能被抑制掉,以提高內容對比度,反而讓重點內容更突出。

小技巧總結:

• 無資訊傳遞作用的圖像,一律 alt="",避免不必要的朗讀干擾。
• 千萬別省略 alt 屬性,空的才是忽略,沒有的話反而可能亂播檔名。
• 可用 ARIA 作額外保險:在裝飾元素上加 aria-hidden="true" 或對 <img> 設 role="presentation",讓輔助技術完全無視它們。
• 善用 CSS 背景圖實現裝飾效果,將純裝飾與內容結構解耦。但切記背景圖不可用於傳遞重要資訊,否則就是無障礙大忌。

在多數情況下,善用 alt 已能覆蓋圖像無障礙的大部分需求。但在某些特殊情境下,ARIA 屬性和適當的 role 能進一步幫助我們處理圖像的可及性:

1. 非 <img> 元素的圖像語意:有時開發者會使用非 <img> 方式來呈現圖片,例如用 CSS 背景、Canvas 繪製、Icon Font 字型圖示、或 inline SVG 等。這些元素本身沒有預設的無障礙語意,我們需要手動加上。ARIA 提供了 role="img" 來標示一個元素應被視為圖像。例如,如果有一個區塊用了 CSS 背景圖來顯示橫幅:

這段程式將 <div class="hero-banner"> 暗示為一張圖,螢幕閱讀器遇到它時會將其當作圖像處理,並朗讀我們以 aria-label 提供的描述。這種技巧在無法使用 <img> 的情況下非常實用,例如設計需求需要把圖當背景又要為其提供可存取的名稱。注意:當背景圖包含重要資訊時才這麼做。如果背景只是裝飾,應該用前述方式隱藏而不是設定 role。

2. 圖像的附加說明:有些圖像可能需要較長的文字說明(例如資訊圖表、統計圖等)。在確保主要資訊透過 alt 傳達外,您還可以使用 ARIA 技巧提供額外的細節。如果說明文字在頁面其他地方,可以用 aria-describedby 將圖像和說明段落連結,使用者在圖像上按下快捷鍵查詢更多資訊時,可跳轉到該段描述。或者將長說明文字放在頁面別處,提供一個「詳見圖表說明」的連結。另一種方法是 HTML5 <figure> 元素搭配 <figcaption>:把圖像和說明文字包在 <figure> 中,螢幕閱讀器會在朗讀圖像後宣告 figcaption 內容,這對需要額外背景的圖像很有用。

3. inline SVG 的可及性:SVG 圖像如果通過 <img src="file.svg" alt="..."> 引用,那直接用 alt 即可。但若 SVG 直接寫在 HTML 中(inline SVG),需要特別處理。最佳實踐是:在 <svg> 標籤上加 role="img",並透過 aria-label 或 <title> 提供圖像說明。例如:

這樣可確保螢幕閱讀器將整個 SVG 視作一個圖像,直接讀出「紅色的心形圖示」,而不會逐步念出每個路徑或群組節點(那些對使用者毫無意義)。同時,如果這個 SVG 只是裝飾用途,那就應該加上 aria-hidden="true" 而不要給描述,或採用 CSS 背景的方式。

4. 圖示字型 (Icon Fonts) 的處理:許多網站使用 icon font(圖示字體)或自行繪製的符號來呈現小圖標。例如,用 <i class="icon-star"></i> 顯示一個星星符號。如果這個圖示純粹裝飾或重複旁邊文字的意思(如旁邊有「收藏」二字),我們應該隱藏它以避免朗讀兩次同樣的概念。方法是為圖示元素加上 aria-hidden="true",讓輔助技術跳過它。反之,如果這個圖示是唯一的按鈕內容,那就需要給它一個可及名稱,比如:

上例中,星形圖示本身隱藏起來,改由父按鈕提供 aria-label 來傳達功能。如此一來,視覺上使用者看到星星符號,輔助技術用戶則聽到「收藏,按鈕」。總之,圖示字型的要點是:有對應文字時隱藏,無文字時提供名稱。

5. 避免圖像的誤用:在可及性設計中,也要盡量避免一些反模式。例如切忌用圖像來呈現大量文字內容(所謂「文字圖片」);這不但對 SEO 不利,對無障礙更是傷害,因為您得將整段文字都寫進 alt 裡,使用者還不能方便地選取其中文字。若一定要展示文字圖片(例如品牌Logo或簽名字樣),alt 必須涵蓋相同的文字資訊。再例如,別用一個空鏈結只為插入圖片後再用 JS 綁定功能——如果要當按鈕,就直接用 <button> 或明確的 <a> 文字鏈結包圖,並確保有替代文字。遵循語意正確的 HTML,大多數情況下即可自帶可及性優勢。

小技巧總結:

• 使用非 <img> 呈現重要圖像時,記得透過 role="img" 和 aria-label 提供替代資訊。但此技術應謹慎使用於必要情況,不要氾濫添加無謂的 role。
• 圖像若需要較長解說,可考慮 aria-describedby 連結至詳細說明段落,或利用 <figure><figcaption> 結構在視覺與無障礙上同步呈現詳細資訊。
• Inline SVG 務必在 <svg> 上標註角色及替代文字,以避免輔助技術讀出雜亂的節點資訊。
• 圖示字體或裝飾性符號:若旁有文字則將其隱藏(aria-hidden="true"),若無文字則由父元素(如按鈕)提供無障礙名稱。
• 盡量使用語意正確的元素:適當使用 <img>、<button>、<svg> 等,以減少額外ARIA的負擔——能不用 ARIA 就不用,以免徒增複雜度和潛在錯誤。ARIA 的座右銘是:「Don't use ARIA when you don't need to」。