把網站當作商業系統來營運。

網站無障礙

按角色建立網站無障礙測試計劃:由改動風險到發布證據

以一張可重用的測試責任矩陣,把自動檢查、人工判斷、輔助科技測試及殘疾人士評估分配到設計、內容、開發、品質保證與發布角色;再按改動風險調整深度、保存可追溯證據、設定阻擋與重測責任,讓團隊毋須等到發布前才找專家補救,也不把一次掃描誤當成符合標準的證明,並由獲授權負責人作出清晰發布決定。

五名同事圍在木桌旁,一名站立的男子把空白卡放進牆上方格,桌面放有鍵盤、耳機及無障礙輔助設備。

要把無障礙測試變成日常交付能力,團隊需要在動工前界定改動範圍及所需證據,再為每種檢查寫明觸發條件、最早可做的階段、執行者、接受結果的人、阻擋規則和重測責任。這樣,發布審查收到的便不是一份孤立掃描報告,而是一條由設計、內容、開發、品質保證、專家評估到發布決定均可追溯的證據鏈;建立工作的人仍須為其決定負責,無障礙主管則集中管理政策、方法、培訓和疑難判斷。

可直接採用的原則

  • 無障礙測試應成為分布於交付流程的證據,而不是發布前才加入的專家審核。
  • 每種測試都要有觸發條件、最早階段、執行者、接受者、所需環境、證據、阻擋規則及重測負責人。
  • 自動偵測、人工符合程度檢查、輔助科技兼容測試及殘疾人士評估回答不同問題,不能互相取代。
  • 改動風險越高,測試深度應越大;風險較低並不代表可忽略已知障礙或未測路徑。
  • 發布例外只記錄獲授權的風險決定,不會令不合格結果變成符合標準。

甚麼令無障礙測試成為計劃,而不只是最後審核?

四名同事在木桌旁把深藍色及琥珀色空白卡分類放入淺托盤,前方放有鍵盤、耳機和文件夾。

一套真正的測試計劃,會在設計、內容製作、開發、品質保證及發布準備各階段產生不同而互補的證據。自動檢查找出可程式化偵測的情況;人工符合程度檢查判斷行為及語意;輔助科技測試驗證代表性任務在指定環境的兼容性;殘疾人士評估則探索實際可用性及尚未滿足的需要。四者目的不同,不能因其中一項結果理想便取消其餘適用檢查。

評估應在開發或重新設計初期開始,並在改動仍容易調整時持續進行。沒有任何單一工具可以判定網站是否符合無障礙標準,具備相關知識的人員仍須審視語意、互動及使用情境。實務上,設計師、作者和開發者負責自己建立的工作;品質保證人員提供獨立執行;無障礙主管制定政策、教授方法並處理複雜或具爭議的發現,而不是成為所有檢查的唯一樽頸。

測試深度應如何隨發布內容改變?

兩名成人扶着四疊逐漸增高的空白卡,桌上亦放有鍵盤、耳機、放大鏡及可更新點字顯示器。

測試深度應隨互動程度、重用範圍、新穎性、旅程重要性及潛在使用者影響增加,但任何級別都要保留適用證據。先盤點受影響的旅程、元件、範本、內容類型、文件、媒體、控制項及支援技術,再選方法;不要只按工單名稱判斷風險。以下四級是可調整的編輯模型,不是官方風險標準、固定評分或聲稱未測路徑符合標準的依據。

  • 純內容改動:人工內容審查加適用自動檢查;結構、媒體、文件、控制項或任務意義有變時再加相關人工測試。
  • 視覺或布局改動:加入設計審查、縮放及重排;若影響互動,亦要檢查鍵盤焦點。
  • 元件或互動改動:開發前訂驗收條件,開發者作本地檢查,品質保證人員獨立測試各狀態及代表性任務。
  • 新範本、關鍵旅程或重大發布:採用所有適用層次、受訓輔助科技測試、代表性覆蓋、抽樣符合程度評估及適時的殘疾人士評估。

可重用元件一旦出錯,影響可能擴散至多個頁面,因此應加入迴歸覆蓋;關鍵旅程則要涵蓋開始、輸入、驗證、錯誤復原、確認及返回等狀態。若進行較廣泛的符合程度評估,應先界定範圍與目標,探索主要頁面和功能,在無法全量評估時選取具代表性的樣本,然後評估並報告結果。抽樣只代表已界定的覆蓋,不能把未測部分悄悄納入結論。

測試責任矩陣要寫甚麼,交接由誰負責?

三名同事把深藍色卡放入五欄牆面矩陣,前方長桌放滿透明證據套、手提電腦、平板電腦及手機。

責任矩陣最少要為每個測試層次列明改動觸發條件與範圍、最早執行階段、實際執行者、對結果問責的接受者、所需技能與環境、保存證據、發布阻擋規則,以及修正和重測負責人。把這些欄位放進需求、工作票或測試計劃,團隊便可在動工前知道「要證明甚麼」,發布負責人亦可在最後看到由誰完成、在哪個環境完成及仍有甚麼未決事項。

角色界線要保持清楚:設計師負責無障礙設計決定,作者或編輯負責內容意義,開發者負責實作及本地檢查,品質保證人員負責測試計劃和獨立執行,使用者研究員負責合乎倫理的殘疾人士研究,獲授權產品或發布負責人作接受決定。小型團隊可由一人兼任多個角色,但記錄要注明當時戴着哪一頂「帽」,較高風險工作仍應保留受訓或獨立覆核。

當每項改動都有具名證據、清楚責任和重測路徑,無障礙便不再是別人在最後一刻才做的檢查。

七個核心測試層次的責任矩陣示例
測試層次、觸發條件及範圍最早階段、執行者、技能及環境接受者及保存證據發布影響及重測者
自動檢查:每次相關程式碼、範本或內容改動;記錄掃描範圍。開發及整合階段;開發者或內容團隊在受支援流程執行。品質保證接受;保存版本、範圍、規則及結果。命中既定阻擋規則便暫停;修正者重跑,品質保證確認。
內容審查:標題、標籤、連結、指示、錯誤、替代文字、字幕或謄本有變。撰寫及設計階段;作者或編輯以真實頁面語境判斷。內容負責人接受;保存審閱項目、決定及修訂。意思不清或關鍵指示缺失時阻擋;作者修正並重審。
鍵盤審查:新增或改動控制項、元件、焦點次序及完整任務。原型及開發階段;開發者先測,品質保證獨立執行。品質保證接受;保存任務、狀態、焦點及結果。任務不能完成、焦點受困或不可見時阻擋;開發者修正。
縮放與重排:文字、布局、導覽、覆蓋層或固定元件有變。設計及品質保證階段;以適用視窗、縮放及內容狀態測試。設計或品質保證接受;保存條件、畫面及功能結果。資訊或功能遺失、受阻或出現不容許捲動時阻擋並重測。
螢幕閱讀器或指定輔助科技:高風險互動、重要狀態或關鍵任務有變。可操作原型及開發階段;受訓測試員使用已選定技術組合。無障礙主管或品質保證接受;保存任務、版本、輸出及影響。關鍵任務或狀態不可理解或操作時阻擋;開發者修正後原測試員重測。
殘疾人士評估:原型、關鍵旅程、重大改動或未明使用需要。決定尚可改變時;有經驗研究員策劃,殘疾參與者完成任務。產品負責人接受研究結果;保存方法、同意安排、觀察及決定。發現進入風險及修正流程;研究員或指定測試員驗證後續改動。
抽樣符合程度評估:新範本、重大發布或需要較廣泛保證。發布準備前;受訓或獨立評估員界定範圍及代表樣本。獲授權負責人接受;保存範圍、方法、樣本、結果及限制。既定阻擋發現須修正及重測;評估員確認受影響樣本。

每項核心無障礙檢查實際要看甚麼?

兩名同事坐在測試桌前,男子操作螢幕背向鏡頭的鍵盤,女子則調校桌面視像放大器並拿着彩色卡。

核心檢查應圍繞使用者能否理解及完成代表性任務,而不是逐頁機械剔格。自動檢查宜放入本地工作流程及適用整合管道,並記錄實際掃描範圍;乾淨結果不是符合程度決定。內容審查則由人判斷頁面標題、各級標題、標籤、連結、指示、錯誤訊息、字幕、謄本及文字替代是否在當下語境傳達有用意思,因為欄位存在不等於內容有效。

  • 以鍵盤完成整個代表性任務,而非只按一次Tab鍵。
  • 確認每個相關控制項可操作,焦點次序合理、可見且不被完全遮蔽。
  • 測試能否進入及離開元件,並觀察展開、選取、載入及錯誤狀態。
  • 輸入不完整或錯誤資料,確認使用者可理解問題並復原。
  • 檢查意外焦點跳動、畫面外變化及操作後未獲宣告的狀態。
  • 保存重現步驟、預期行為、實際結果、影響、修正者及重測結果。

縮放與重排要分開記錄適用條件。WCAG 2.2要求文字在所列例外以外可放大至200%,而不損失內容或功能;重排準則則要求內容在相當於320 CSS像素闊度時避免水平捲動,在相當於256 CSS像素高度時避免垂直捲動,但為意義或使用而必須採用二維布局的內容除外。審查重點是資訊或功能有否遺失、遮擋、焦點隱藏或移出可視範圍,而不是畫面能否保持像素完全相同。

何時要加入輔助科技、殘疾人士及符合程度評估?

一名戴深色眼鏡和耳機的失明男子使用點字顯示器及小型鍵盤,女研究員在旁觀察並拿着空白工作卡。

當改動涉及高風險互動、重要狀態、重用元件、關鍵旅程或重大發布,便應加入受訓的螢幕閱讀器或其他相關輔助科技測試。測試員要完成代表性任務,檢查閱讀次序、名稱與角色、指示、狀態變化、錯誤復原及操作結果。瀏覽器與輔助科技組合應按受眾證據、產品技術、支援承諾及已知風險選定;一次結果只反映該任務與環境,不能代表所有失明人士或證明整體符合標準。

殘疾人士評估應安排在研究結果仍可改變原型或關鍵旅程的階段,並在研究前處理已知而明顯的重大障礙,避免整節只重複團隊本可先發現的問題。研究可以由針對原型的非正式意見發展至正式任務評估,但不應把一名參與者的經驗推論至整個群體。這類研究可發現標準評估未必揭示的可用性問題,卻不能取代符合程度評估;即使達到WCAG最高級別,也不保證滿足每一名使用者的需要。

證據應如何控制發布,並持續改善計劃?

三名同事在發布審查桌旁核對證據套及狀態卡,其中一人把一張琥珀色卡移到鍵盤與耳機旁準備重新測試。

發布決定應按該改動級別要求的證據作出,而不是依賴一個全站分數:所有適用檢查已完成,阻擋發布的發現已修正及重測,記錄亦清楚列出範圍、方法、環境、結果、負責人、處置及重測狀態。品質保證和無障礙專家提供獨立證據,建立工作的人負責修正,最後由獲授權的產品或發布負責人接受或拒絕風險,避免由測試員同時充當唯一裁決者。

  1. 先選一條關鍵旅程作試點,把所需證據及交接做完整。
  2. 培訓矩陣列明的角色負責人,並提供一致測試方法。
  3. 建立發現、證據、修正及重測範本,再加入適用自動化。
  4. 以真實個案校準阻擋規則及發布接受權限。
  5. 定期檢視重複缺陷,把所學更新至元件、範本、培訓及迴歸測試。
  6. 證據鏈穩定後才擴展至更多旅程、內容類型及改動級別。

若機構政策容許例外,記錄須保留獲授權負責人、理由、受影響使用者、緩解措施、到期日及跟進安排;例外只記錄風險決定,不會改變測試結果或建立符合標準的聲稱。發布後收到的障礙報告及重複缺陷,應回饋至責任矩陣、迴歸檢查和培訓。複雜互動、輔助科技行為、代表性抽樣或爭議發現可交由受訓評估員處理;殘疾人士研究宜由有經驗研究員主持,而個別司法管轄區的合規解釋應尋求合資格法律意見。

常見問題

如何建立網站無障礙測試計劃?

先界定旅程、元件、內容及改動級別,再區分自動、人工、輔助科技及殘疾人士評估四類證據。為每項方法指定觸發條件、階段、執行者、接受者、證據、阻擋及重測責任,然後以一條關鍵旅程試行。按重複發現更新培訓、範本及覆蓋範圍。

網站無障礙測試由誰負責?

責任由設計、內容、開發、品質保證、研究、無障礙專家及獲授權發布負責人共同承擔。建立工作的人仍要為其決定及修正負責,品質保證和專家提供獨立證據。小型團隊可一人兼任多個角色,但要記錄所代表的角色及接受權限。

自動無障礙測試可以證明符合WCAG嗎?

不可以。自動工具適合重複偵測可程式化判斷的情況,但沒有任何單一工具能判定網站是否符合無障礙標準。語意、互動、任務完成及使用者經驗仍需要具備相關知識的人員和其他適用方法評估。

甚麼時候要用螢幕閱讀器及邀請殘疾人士測試?

高風險互動、重要狀態、關鍵旅程及重大改動,應加入受訓而以任務為本的輔助科技兼容測試。殘疾人士評估則應在結果仍可影響設計時進行,用來探索可用性及未滿足需要。兩者回答不同問題,也不能取代標準符合程度評估。

哪些無障礙問題應阻擋網站發布?

機構須由獲授權負責人預先界定阻擋規則,並連結至改動級別及使用者影響。發布證據至少要顯示適用檢查已完成、阻擋發現已修正及重測。若政策容許例外,仍須具名、具理由、有限期及有跟進安排,而且不能當成符合標準。

WebChorus logo

WebChorus 編輯團隊

我們報道網站上線後仍持續左右其成敗的決策。文章以具名資料來源為起點,清楚區分查證所得與編輯觀點,並依據有文件記錄的編採準則,運用 AI 協助研究及草擬。凡有商業關係,我們一律披露。