為什麼台灣的數位親和力之路至少耗時兩百年（下）

內容目錄

• 能力歧視主義（健全主義）（上篇）
  • 優生保健法（上篇）
  • 微歧視的型態（上篇）
  • 合法歧視（上篇）
• 誰是身心障礙者（上篇）
  • 身心障礙者人口統計（上篇）
  • 身心障礙分類系統（上篇）
  • 反向健全主義（上篇）
  • 網頁導盲磚（上篇）
  • 各方山頭（上篇）
• 公務體系及主管機關（中篇）
• PDIS 與數位韌性（中篇）
  • 設計制度（中篇）
  • 參與 W3C（中篇）
• 元件庫
• 業務委外
  • 標案需求規格
  • 薛丁格的政府網站
• 數位文件
• 無障礙標章及親和力宣告
• 政治的現實

元件庫

這套新的設計制度遇到的第一個挑戰，卻是來自數發部。數發部內高階文官誤以為「設計制度就是元件庫」，從一開始就忽略設計制度本體，以「每個月交付兩個元件」做為專案管理的關鍵績效指標。

正式的設計制度底下，元件庫收納整理的每個元件會以「成熟度」來管理其生命週期。新提案的元件從概念實證成熟度開始，數位服務的開發團隊在這個階段可以理解元件想要解決的設計挑戰，確認這個元件是否有存在的必要性、是否值得投入資源持續開發。隨著元件逐漸開發，確認元件符合設計制度的各項規範，與其他既有元件具備設計上的一致性，就會達到封閉測試成熟度，表示數位服務的開發團隊可以開始把這個元件用於嘗試性的程式碼分支，確認這個元件的行為、表現、設計、相容性、可靠性是否符合實際可能發生的情境。元件經過完整詳細的親和力測試、安全性測試、弱點掃描、壓力測試並完成相關的測試報告後，即達到公開測試成熟度，表示數位服務的開發團隊可以開始把這個元件用於開發中的程式碼分支，確認這個元件是否能夠符合完整數位服務的需求。隨著使用元件的數位服務正式推到正式上線分支，通過完整的整體性稽核檢測，並經過充分使用者測試的改善調整，即表示這個元件達到穩定成熟度，接下來主要會在設計制度調整（例如變更網頁技術基準、對應法規修訂等情況）才需要修訂；或者若設計制度指定以浮動式的技術基準（例如 W3C WebDX 社群小組維護的 Baseline），則需要排入定期檢討審閱。

數發部高階文官認為依照公務體系的需求，「交付的元件一定要已經成熟穩定」才能驗收，這就跟上述的成熟度管理機制產生衝突。

第一個衝突是文官對元件開發生命週期的欠缺理解。元件的提案、試行、測試、正式上線等程序都要花費一定的時間，具體時間長短又跟數位服務開發團隊的敏捷程度、實際開發的專案數量及規模等有關。即使是最簡易單純的元件，在最敏捷完整的數位服務團隊中，大概也需要半年才能從概念實證發展到穩定的成熟度。然而數發部高階文官在規劃管理專案時卻要求從第二個月起，每個月要交付兩個穩定成熟的元件。

第二個衝突是台灣絕大多數政府機關內部根本沒有數位服務開發團隊，元件光是要從概念實證推進到封閉測試都很有困難。台灣絕大多數公務資訊單位都在做業務委外標案而不是資訊開發，這跟英國 GDS 編制兩萬八千多位設計師及工程師在各級政府機關實際開發的形態全然不同。註：英國 GDS 成立於 2011 年，到 2013 年全體編制約 200 人，到 2015 年成長到約 500 人，後來經過幾次整併，到 2025 年成長到上述專業人數。

業務委外

台灣政府幾乎沒有數位服務開發團隊的原因，可以追溯回研考會在 1998 年制定實施的行政院所屬各機關資訊業務整體委外作業實施辦法，以及在 2002 年接續的行政院所屬各機關資訊業務委外服務作業參考；在這些行政命令的作用下，除了更高位階法律明確規定，或少數例外情況之外，政府機關有義務不編制數位服務開發團隊。

這個政策實施將近三十年來，對政府數位服務的開發方式產生巨大影響。姑且不論智慧財產權爭議、廠商套牢 (vendor lock-in) 頻繁發生，更重要的是政府機關大幅受到採購驗收的法規約束，只能以短期且膚淺的「成果」進行驗收，對「手段」難以干涉，也逐漸喪失對科技的熟悉及敏感。

「文官找『配合廠商』協助草擬需求規格 (Request For Proposal, RFP)」屢見不鮮，因為許多文官對於技術缺乏掌握，無法辨別哪些事情可行、哪些不行，而且文官考績又會受到辦理委外案「是否能夠順利驗收結案」的「執行績效」影響，與其自己寫出一些（可能有意願來投標的）廠商缺乏能力執行的規格，不如先找（一定會來投標的）廠商寫出有能力執行的規格。

2022 年在一場與金融監督管理委員會（以下簡稱金管會）、國內各銀行業者數位服務開發工程部門的座談會議上，我提到Android 及 iOS 在作業系統層級都有輔助使用相關的設置選項，例如文字尺寸、明暗配色、動態（動畫）效果開關等，銀行服務的行動應用程式應該遵循這些作業系統的應用程式介面 (API) 來尊重個別使用者的需求。金管會文官在會議中直接詢問銀行業者是否可行，銀行業者直接回答「這沒辦法」，於是當時金管會文官堅持「另外做一套模式」的隔離策略。「利用作業系統提供的 API 來設計及開發應用程式」是基礎中的基礎，也是資訊軟體領域幾十年來的教科書等級標準做法，很遺憾當時的金管會文官缺少能「正確判斷銀行業者的資訊技術能力其實水準低落」的能力。

因為有這段歷史，去年我才會據理回應金管會的指引草案，令人感到欣慰的是這次金管會終於願意採納相關意見，即使這只是一份非強制性的指引文件。

標案需求規格

在資訊業務委外服務案當中，政府機關無法在 RFP 等標案文件裡指定要用哪種程式語言或網頁框架進行開發，也無法指定使用特定元件庫；對於這些業務委外服務案的得標廠商來說，用自己行之有年的（無論是否老舊過時）技術也能順利履約結案的話，何必投入資源冒險嘗試自己不熟悉的元件庫或技術？換句話說，數發部文官想像中的「建置一套元件庫，各級政府機關的資訊系統就能直接套用」的未來根本不會發生。

無論是想悄然勸誘得標廠商採用不同技術，或者引導得標廠商自己改善現有技術，都得在標案文件裡「寫出關鍵的規格」，這個規格需要有某種依據，因為文官可能得向（同樣不怎麼熟悉相關技術的）長官講出一番道理，解釋「為什麼過去沒這項，這次要加這項」，這個規格要是投標廠商有能力做到的，而且這個規格還要是不具特定背景的人也能檢核驗收的。

上述這些規格條件可能令人感到不可思議，到底要怎麼寫出符合所有條件的規格？秘訣講破就是用抄的。行政院公共工程委員會（以下簡稱工程會）是政府採購法的主管機關，也制定公告多種指引及範本文件，例如 2023 年公告更新的資訊服務採購作業指引，其附件常用資訊服務等級協議 (SLA) 之參考項目往往就是機關承辦人員會納入（抄進）標案文件的項目。這一版列出的 SLA 有個問題：關於「使用者體驗」的常用服務水準項目都不怎麼恰當；然而這並非工程會的疏失，因為這些內容其實是由數發部提供。我在數發部內順藤摸瓜，找到原因是有一份政府網站服務管理規範內容過於陳舊所致。

政府網站服務管理規範係整併取代 2005 年政府網站版型與內容管理規範、2010 年政府網站建置及營運作業參考指引、2011 年政府網站 Web 2.0 營運作業參考指引（社會網絡篇）等三份規範指引，再依 2019 年政府數位服務指引修正，算是數發部主管規範中最具設計制度性質的文件。然而，當時其內容已經落後國際現實大約 20 年。

我跟幾位 PDIS_HEX 總顧問開始緊鑼密鼓地協助數發部檢討修訂政府網站服務管理規範，這項任務於隔年三月中完成（數位政府字第 1134000368 號函），在各方尚能接受執行的前提下，我們估計大約能追趕 10 年進度，包括服務管理原則納入聯合國二〇〇六年身心障礙者權利公約，修訂服務易用性原則的解釋及參考指南，修訂網頁標準的定義及鼓勵使用漸進式增強技術，強調採用第三方套件、開發框架及函式庫時應擔負其親和力、隱私性、安全性等相關義務，強調運用社群平台提供的無障礙功能，大幅修訂附錄二政府機關網站親和性設計原則及相關指標、附錄六網頁設計參考內容等。

到了六月下旬，工程會函告（工程企字第 1130007244 號）修正政府資訊服務採購作業指引之「使用者體驗」常用 SLA 參考項目，明確指出係參考新版政府網站服務管理規範，說明爾後機關辦理資訊服務採購倘涉及網站設計及使用者體驗者，亦請參考旨揭修正後 SLA 參考項目。

由於這些規範、指引都不是強制性的文件，各級政府機關有得抄也不見得會去抄；我甚至還會看到要求採用（已經廢止的）政府網站版型與內容管理規範的標案規格需求，我猜想是辦理資訊業務委外服務案的人還在抄「先前的標案文件」，沒掌握到工程會告示的最新範本。

另一方面，許多政府機關其實對於設計制度抱著排斥立場，原因在於經費預算。認真遵循設計制度，照理說可以讓整個資訊系統（無論是不是網站）維持一致的形象、觀感、邏輯、品質，能夠有效建立民眾的信任，降低民眾使用的心力負擔；但是這麼一來，「改版前後」很一致，也就容易「看不出有改版」，依照政府資訊服務採購經費估算編列手冊可能被主計、審計等人員視為「應用軟體或系統維運服務」的採購樣態，只能編列維運成本費用。

換句話說，政府機關若用心採納實作設計制度就會受到可動用經費的「處罰」，這就成為排斥設計制度的重要理由。除此之外，數位親和力相當仰賴持續使用者測試等研究方法，以及敏銳地分析使用者回饋，不斷以短週期循環調整設計及實作技術，但這麼一來會跟公務體系認知的現行採購樣態很不一樣：

政府機關資訊業務委外服務案的現行邏輯是每個階段之間壁壘分明，一旦做出規格規劃，那個規劃就是執行後一定要達成的驗收項目，即使後來才發現規劃跟使用情境不符，原則上也要先依規劃內容來竣工驗收（當然也有變更契約的手段，但程序上的代價並不小，更無法每個星期都在變更契約），要到整個案件結案後才會另外編列「委託研究案」來研究「現行設計有哪些痛點、有什麼改善建議」，用以擬定下一期委外案的規劃。

在台灣目前營運的資訊系統當中，如果說政府機關的資訊單位是（委外服務案的）買辦，對於資訊單位而言，業務單位就是實際的「客戶」，資訊系統的規劃是按照「客戶提出的需求」⸺也就是業務單位提出的要求來進行，往往不考慮實際的系統使用者；實際使用者遇到困難或挑戰，或遇到設計不良導致的親和力瑕疵，經常被導向整個機關共用的客服窗口（另一個委外服務案）處理，這些客服窗口所受的訓練及態度多半是抱持著「使用者不懂、不會，所以我們來消化」的預設態度，缺乏對系統瑕疵進行鑒別分類 (triage) 的能力及權限。業務、資訊、客服三個單位「各司其職」，結果業務單位無法發現業務邏輯中的障礙，資訊單位無法發現系統的親和力瑕疵，客服單位不斷重複回答原本可以不存在的問題。

親和友善的設計模式在於隨時能夠敏銳察覺到使用情境萌生的需求與困擾，調整資訊系統的行為樣貌，甚至要調整業務邏輯，資訊系統以「受到引導的有機成長」型態發展，雖然是朝向早已確認的大方向前進，但許多具體的細節很可能超出原本的預期及想像；政府機關文官很容易誤以為這種設計模式是「先射箭再畫靶」，這種認知落差來自於對於「靶」的理解根本不在相同層次上。

「以使用者的回饋來決定產品的最終樣態」並不是毫無限制地、奔放不羈地隨意做出什麼都可以驗收，相反地，這種有機模式非常考驗對於嚴謹方法論的規劃及實踐，需要事先制定「如何監控一套自我監控機制的機制」，對於最終的產品樣態要有足夠強度的論述來支持闡明其有效性；專案管理上的各階段也不再以斷點區分，像是平行又互連且不斷循環的縝密結構，在各階段需要參與的團隊成員角色將更為多元。資訊業務不能再像製造業思維那樣以「接單—依規格生產」來理解，要改為「探索問題—定義問題—解決問題—驗證解決方案—回顧問題及解決方案」的服務設計思維。

舉例來說，以現行的資訊業務委外服務案模式，網站要等到「完成上線」之後，才會申請接受無障礙檢測；通過檢測之後，除非遇到「抽測未通過」，幾乎沒有人會去注意有沒有哪裡發生障礙。強調數位親和力的設計模式則會在各個階段實施測試，並隨著測試結果動態調整專案階段；例如完成實作線上申辦的系統流程後，先找約五位身心功能各異的使用者進行測試，結果其中一位相當吃力地完成，另一位最終仍無法完成整個流程，測試團隊對這兩個不成功的情況深入分析研究，發現主要的困難在於要填寫的資料很多，雖然網站已經在使用者進入流程前事先說明提示時間限制，也提供可以每次延長五分鐘時限的功能 (SC 2.2.1)，但對其中一位使用者仍然造成肢體動作上的顯著負擔，而另一位使用者遇到的困難則是無法背誦許多自己的個人資料，因而最終無法填完所有必填欄位；前端開發團隊的成員一邊探索是否可以運用網頁標準技術，在不構成資安風險的前提下，讓使用者可以把曾經輸入過的資訊自動帶入對應欄位 (SC 3.3.7)，業務團隊另一邊也重新檢視這些資料欄位是否真的有必要性⸺這些欄位是否真的跟申辦的事項有關？是否無法從其他途徑介接取得相關資料？修改業務流程是否涉及其他法規限制？調整後的版本需要輸入的欄位變少了，而且也能支援瀏覽器的常用資料填入功能，測試團隊又找了五位使用者再次測試，這次每位使用者都能順利完成整個流程，整體耗時縮短，其中一位使用者發現先前資料內容有誤也能輕易修正，要儲存到系統資料庫（因而需要保護）的資料減少，業務單位需要人工處理的資料項目也精簡許多，證實改變業務流程及程式行為的有效性。接著前端開發團隊繼續投入下一組系統功能……

這種改變對於業務委外服務案來說，意味著計畫成本組成、人力資源需求等都跟以往大為不同，多次實施使用者測試也需要更多經費（包括實施使用者測試所需的空間場地及設備成本）；然而有一次我跟某位文官討論起這種模式，文官的想法卻是「既然這些事情本來就該做，就沒有增加預算的道理，得標廠商本來就應該在框定的經費內完成。」我認為過去幾十年的經費規劃設想得不夠詳盡完善，若不重新檢討而直接轉嫁到廠商，只會逼迫廠商發展出看起來符合標案需求、實際上卻沒有效果的方式來應付，對於各方都只有弊而沒有利。

薛丁格的政府網站

另一個相當令人玩味的現象，是很多政府機關偏好建置「不是政府網站的政府網站」。這類網站雖然實際由政府機關出資、委託建置或營運，但網域名稱不是 .gov.tw 或 .gov.taipei 結尾（教育性質的 .edu.tw、法人性質的 .org.tw 等除外，按下不表）；最常見的例子是各種「活動網站」，例如「2025 花蓮購物節」網站的網域名稱是 hlgo.tw、「2025 與神同行遊雲林滿額 500 抽豪禮」網站的網域名稱是 yunlinluckydraw.net，有些「政務網站」居然也如此，例如「內政部警政署 165 打詐儀表板」網站的網域名稱是 165dashboard.tw、「台北通」網站的網域名稱是 id.taipei、「台北服務通」網站的網域名稱是 service.taipei。

少了 gov 次級域名，任何人都可以註冊相似的網域名稱來混淆大眾。有心人可以註冊如 hualiengo.tw、yunlinluckdraw.net、165dashboards.tw、passid.taipei、services.taipei 等網域名稱，架設詐騙網站，輕易誘騙民眾。

有些「網域名稱不像是政府網站」的網域名稱，至少可以利用 WHOIS 查詢確認是否由政府機關部門註冊，但例如「內政部警政署 165 打詐儀表板」由私人企業註冊網域名稱（坤侑科技股份有限公司，Registrant: KunYou Technology Co., Ltd. gordonUNDERLINEhsu@kunyoutech.com.tw），很難說是政府網站。這類網站的存在及營運，不斷教育訓練民眾輕易地把不像是政府網站的網站，當成政府網站來信任，甚至交出個人的身分、戶籍、金融消費等資訊，儼然是助長詐騙的幫凶。

為什麼政府機關要冒這麼大的風險？曾有位文官半開玩笑地向我解釋：「多半是為了不列管。」

正式的政府網站受到許多法規規範，例如應完成資通系統防護需求分級、保護使用者個人資訊及隱私、通過無障礙檢測等；「不列管」暗指免除上述這些法定義務，萬一發生民眾權益受損或更嚴重的災害等情況，政府機關都可以輕鬆切割，宣稱民間企業擅自更改網域名稱伺服器設定而導向假冒網站，或稱這是民間企業單方面的過失，順便主張政府機關自己也是受害者，還能夠反過來向民間企業求償或裁罰。

從行政的角度來看，列管資訊系統的法規規範都有其用意跟目的；以「打詐儀表板」為例，打詐網站充滿親和力障礙，身心障礙者無法使用，傳達的訊息就變成「把詐騙集中到身心障礙者那邊」，反倒比不打詐還糟糕。

對於擺明要閃避法規規範的資訊系統，怎麼可能有辦法要求採用任何設計制度？如果政府機關可以公然鑽漏洞，整個社會居然也覺得理所當然、欣然接受，怎麼可能理解反歧視的平等概念？

我在台灣與美國的網頁親和力法規簡略比較文中提到：美國不是採用「政府網站應無障礙」這種說法，而是採「政府機關執行的業務，以及獲得政府經費（無論佔所有費用比例多寡）而辦理的業務，包括因業務提供的電磁通訊及資訊科技，如網站、網頁內容、網頁應用程式、網頁文件、數位文件檔案、應用程式軟體、電子郵件等，都不能因身心障礙而有所歧視」；未接受政府費用的民間公共及商務網站或資訊科技等，在美國也不得因身心障礙而有所歧視。台灣身權法的寫法則執著在政府〔……〕所建置之網站，差異相當之大。

台灣和美國法規的差異並非單純在於「如何界定政府網站」，更在於整體的思考模式不同；台灣的關鍵詞強調「建置網站」、「通過檢測」，美國的關鍵詞強調「業務」、「不歧視」、「有效溝通」、「融合」、「機會均等」、「輔助協助或服務」。不只美國，歐盟國家也是如此，歐洲親和力法案 (European Accessibility Act, EAA) 涵蓋各種資訊產品及服務，EN 301 549 歐盟國際標準納入雙向語音溝通資訊科技、影音資通科技、硬體產品、網頁、非網頁式文件、軟體、文件及支援服務、介接及緊急服務等。「網站」對歐美國家只是執行業務、提供服務的一種手段，不是「為了建置網站而建置網站」。

行政院去年底提出的身心障礙者權益保障法部分條文修正草案稍微擴大適用範圍，調整為各級政府與其附屬機關（構）、學校、公營事業與政府捐助之財團法人所建置之網站及行動化應用軟體，以及一定規模以上之醫院、金融機構之網站，思維脈絡仍未成長。從主管身權法的衛福部到數發部，乃至於許多身心障礙者團體，都只注意到身權法第五十二條第一項第三款公共資訊無障礙，錯誤地望文生義認為所有跟資訊通訊科技有關的親和力法源都在這一項，前述在第五十二之二條應通過無障礙檢測的規範，就是在這個架構底下所制定，因此無法跳脫窠臼。

以實際的社會參與需求來舉例，每次舉辦選舉投票時，選舉委員會依法都要編製公報，對於所有民眾認識候選人學、經歷及政見，或公民投票主文理由，以及投票相關規定與資訊等至關重要，如果身心障礙者無法透過選舉公報獲得充分資訊，會導致選舉結果偏向忽略身心障礙者權益的政治方向，而加重社會整體對身心障礙者的歧視。相對於前述身權法第五十二條第一項第三款公共資訊無障礙，選舉／投票公報更應依第四款公平之政治參與辦理；我在六年前撰文探討選舉／投票公報的親和力議題，發現選舉／投票公報充滿障礙，至今仍然沒什麼改善，例如去年辦理的「全國性公民投票案第 21 案」，其投票公報短短兩頁即有幾千處障礙。

數位文件

選舉委員會的選舉／投票公報不是特例，台灣各級政府機關最常提供民眾下載使用的數位文件盡是：有障礙的 PDF、有障礙的 DOCX、有障礙的 ODT 等檔案。從行政院公報，到衛福部便民服務提供的表單下載，到社家署的出版品及研究報告、年報、施政方針及施政報告、內部控制聲明書、預算書、決算書等，清一色有障礙的 PDF 檔案。

幾年前我曾經去審查社家署委託辦理的中央層級輔具資源整合推廣中心，我在審查中指出該中心依合約編製的數位出版品 PDF 有障礙，而且中心主任及所有人員都對於 PDF 檔案格式有哪些國際或國家親和力標準渾然不知；然而，因為社家署合約中對數位出版品的親和力沒有任何要求，審查結果仍然順利通過驗收。

數發部自成立以來，對各級政府機關提供數位文件下載格式的行政指導以採用 HTML 檔案以及 TXT 檔案為主，這是很不適切的建議，除了因為這兩種檔案格式都不適合封裝／打包內容媒體（例如字型、圖片、影音等），純文字 (TXT) 格式連內容的結構化資訊（標題、段落、強調內容等）都無法提供。實際上，數發部自己都沒有這麼做⸺數發部網站上無論施政計畫、業務報告、公務出國報告、預算書、決算書，乃至於各項主管文件如公部門人工智慧應用參考手冊（草案）、政府數位服務指引、各機關資通訊應用管理要點等，都是以有障礙的 PDF 檔案為主，少部分為有障礙的 ODT 檔案。

PDF、ODT、DOCX 等檔案格式都不必然造成障礙，W3C 發布 Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) 清楚說明 WCAG 2.*／ISO/IEC 40500 國際標準如何適用於數位文件。實際上，這些檔案格式也都有相對應的專屬親和力標準或指引可以依循。

PDF 檔案格式有三個專屬國際標準跟親和力相關：ISO 14289-1 (PDF/UA-1)、ISO 14289-2 (PDF/UA-2)、ISO/TS 32005，產業界也有一套專門用於檢測 PDF 親和力的 Matterhorn Protocol 1.1 標準程序，以及一套 Well-Tagged PDF (WTPDF) 最佳實踐指引。歐美國家政府機關發布的任何 PDF 文件，依法應符合上述這些國際標準及業界指引，台灣則全然沒有相關規範；儘管經濟部標準檢驗局早已根據 ISO 14289-1:2014 國際標準制定 CNS 16179:2022 國家標準，現實是還沒有任何政府機關採用。

ODT、ODS、ODP、ODG 等檔案格式在定義格式本身的 ISO/IEC 26300-1 國際標準的附錄 D Accessibility Gudielines，提供這些檔案格式的親和力指引。雖然這份指引屬於國際標準中「非強制性」的部份，但數發部開發提供給公務機關（以及民眾）使用的 ODF 文件應用工具裡，的的確確已經內建「無障礙檢查」功能，然而就連數發部製作提供的 ODT 檔案也沒有利用這項功能，文件檔案充滿障礙。

DOCX、XLSX、PPTX、VSDX 等檔案格式在定義格式本身的 ISO/IEC 29500-1 國際標準的附錄 J Accessibility Best Practices，提供這些檔案格式的最佳親和力實作方式，不過也同樣是屬於國際標準中「非強制性」的部份。微軟在 Office 應用程式裡，均提供「檢查協助工具」多項功能，協助文件編撰者改善數位文件親和力；但同樣遺憾地，台灣從未有任何法規對此做出要求或規範，目前為止所有政府機關提供的這類文件格式檔案都有障礙。

我在 2023 年曾協助數發部及資安院研究多達 33 種數位圖書／文件格式，分析各自的特性、優勢、劣勢、相關標準規格規範等，再依政策上的技術需求（檔案格式要直接具備親和力或運用輔助科技後可具備親和力、採用技術開放格式）、內容形式需求（要可包含文字、聲音、圖像、影像等內容型態）進行過濾，以及參酌馬拉喀什公約 (Marrakesh Treaty to Facilitate Access to Published Works for Persons who are Blind, Visually Impaired or Otherwise Print Disabled) 國際條約和著作權法、圖書館法、身心障礙者數位化圖書資源利用辦法、特殊讀者使用圖書資訊特殊版本徵集轉製提供及技術規範辦法等國內法規描述的使用情境需求（翻譯、點字、錄音、數位轉換、口述影像、附加手語）篩選，最符合的數位圖書／文件格式是 EPUB。

EPUB 是受到國際數位出版聯盟及 DAISY 聯盟支持並參與發展的 W3C 網頁標準，有對應的 ISO/IEC 23736 國際標準，也是國際數位出版界的主流數位圖書／文件格式，在各種作業系統平台上都有可以製作、轉換、處理、閱讀、利用 EPUB 檔案格式的開放源碼應用程式，數發部提供的 ODF 文件應用工具也具備匯出成 EPUB 格式的功能。W3C 有 EPUB Accessibility 和 EPUB Fixed Layout Accessibility 兩份 EPUB 親和力標準，能夠符合各式各樣的圖書文件樣態需求，且有開放源碼的檢測工具能用來協助確認 EPUB 檔案是否符合親和力品質基準；另外還有一份 EPUB Reading Systems 標準，定義 EPUB 數位圖書／文件閱讀軟體應如何支援各項親和力功能。從製作、處理、轉換、利用，到品質檢測，整個生命週期都有成熟的規格及工具，EPUB 是目前最理想的數位圖書／文件格式。

經過上述研究分析，當年數發部部長在內部會議裁示要發展 EPUB 格式為政策方向。

那為什麼現在政府機關網站上，還是滿坑滿谷的 PDF 檔案，仍然看不到 EPUB 檔案？數發部文官對網頁科技的熟悉程度可能是一個因素，有些文官抱持著「EPUB 格式是文化部主管的，不是數發部的業務」的想法（註：文化部這幾年補助台灣數位出版聯盟參與 W3C 的 EPUB 相關工作小組）也會影響積極度，最主要的原因大概還是因為⸺部長換人了。

數發部從 2024 年下半年之後，許多政策方向大幅改變。前一年重啟 PDIS 提出的「數位韌性」概念調整成偏重海纜、低軌衛星等的「硬體設備設施韌性」，不再把聯合國通用數位公共基礎建設安全框架放在心上，數位政府司掌理事項刪除政府數位服務法規，多元創新司改名資料創新司、掌理事項刪除數位共融，民主網絡司改名數位國際司、掌理事項刪除公民科技倫理與自律規範，政府網站設計原則（設計制度）停止發展及推動、其元件庫不再依據相同原則進行後續維護，數位圖書／文件親和力的政策發展陷入沉寂，然後，無障礙標章又來了。

無障礙標章及親和力宣告

無障礙標章是上世紀 90 年代到本世紀 00 年代盛行的一種網頁親和力政策工具，概念是以某一組檢測程序及規則對網站或網頁進行測試，如果通過所有測試項目，就在網頁上標示一張特定的圖片標章，讓任何使用者可以輕易判斷這個網站或網頁已經通過某些測試，並暗示由「發放、管理標章的機關單位」擔保。

研考會在 2002 年委外辦理「無障礙網頁開發標準暨標章核發作業」，是台灣運用這種標章工具的起點；到了 2011 年，〔……〕應通過第一優先等級以上之無障礙檢測，並取得認證標章等文字正式寫入身權法。比利時、葡萄牙、法國、德國、尼德蘭、義大利等國也曾經或仍然使用這種標章機制。

不過，大約從 2010 年起，這類標章機制在歐美各國逐漸式微，主因是網頁科技的開發典範轉移，功能及內容都變動得更頻繁，使用者代理改版週期也大幅縮短，「通過檢測」的實質代表性弱化。此外也應注意，W3C 雖然也提供標章，但不做任何監管或擔保，完全是網站或網頁作者單方面的宣稱性質。

因應網頁科技的典範轉移，先進國家目前的主流模式不再使用靜態斷代的標章，改以親和力宣告的方式，強調與使用者之間維繫的良性溝通互動，2016 年的歐盟網頁親和力指令 (EU Web Accessibility Directive) 即要求各國公部門網站及行動應用程式均應提供親和力宣告，已不採用標章機制。W3C 在網站上提供如何開發親和力宣告的完整說明，以及開放源碼的親和力聲明產生器；簡單來說，親和力聲明應包含的基本內容如下：

• 承諾為了身心障礙者而致力於親和力
• 適用的親和力標準
• 使用者遭遇親和力障礙時的專屬聯絡窗口

另外還建議在親和力聲明裡描述以下事項：

• 已知的系統限制（還沒有完全排除的障礙）
• 整個機關對於促進親和力所採取的措施
• 相關的技術基準，例如可支援哪些網頁標準的瀏覽器版本
• 內容在哪些環境中通過測試，例如特定瀏覽器與特定輔助科技的組合
• 相關的法律規範

我在協助數發部更新政府網站服務管理規範時，建議過納入親和力宣告，但是數發部文官認為在實務上有很大的困難而否決：「機關承辦怎麼可能自己做出承諾？聯絡窗口不就是 1999 或首長信箱嗎？機關怎麼可能自己說還有未排除的障礙？機關促進親和力的措施有沒有可以抄的範本？符合標準就不應該有技術基準吧？通過測試就是取得標章啊？」即使經過解釋，文官仍然無法接受數位親和力是整個機關要一起努力的事（在一般的政府機關組織架構中，表示至少要從秘書處室施力），而非資訊部門用標案就可以「解決」的事；尼德蘭政府在 2020 年有一份 Web accessibility in your organisation: roles and responsibilities ⸺ Web accessibility in the public sector，詳述政府機關裡，各級政務官及事務官對於數位親和力的角色及責任；我指導資安院夥伴將這份文件翻譯後提供給數發部文官參考，獲得的回應是「無法理解」，由此也能發現台灣公務體系跟歐盟國家的天壤之別。

台灣政府文官對網頁科技的技術基準了解不足，對於提出規格需求及驗收都會造成困難；最重要的是，文官反映出台灣公務體系無法誠實的困境⸺公務體系不能犯錯，所以公務體系不可能承認犯錯；公務體系認為任何時候的作為都是正確的，只能講「持續精進」而不能指認不足。這也是台灣公務體系很難實踐 ISO 30071-1 國際標準的原因，無法對自己誠實就無法成長。

相對之下，「標章」正合台灣公務體系的口味。「標章」容易計算量化績效，方便用來推諉搪塞「已經盡到法定義務，一切合法合規」，符合健全主義「我們身心健全者已經對你們身心障礙者夠好了」的慈善模式；已經受到健全主義馴化的身心障礙者也鼓吹標章機制，「有標章至少有點保障」，無論那個保障多麼虛無飄渺。

平心而論，標章機制真的有機會帶來實質保障，前提是相關的配套都做對、做好。W3C 有一套嚴謹、完整的 W3C Accessibility Guidelines Evaluation Methodology (WCAG-EM) 親和力指引評估方法學，對於檢測評估的步驟、範圍界定、取樣方式、取樣數量等均明確定義，有搭配這套評估方法學的評估報告產生器及報告模版；W3C 還有一個由全世界各個從事網頁親和力評估的機構、團體、顧問公司所共同組成的 ACT-R 社群小組，以 W3C Accessibility Conformance Testing (ACT) Rules Format 網頁標準格式記錄及交流檢測規則（包括純人工檢測、純自動檢測、半自動檢測），編寫測試案例確認個別實作的檢測規則具備一致結果，減少偽陽性（誤判為不符合）及偽陰性（誤判為符合）。

台灣的現況是：「無障礙標章」的檢測範圍經常未涵蓋完整使用歷程，檢測取樣的類型及數量明顯不足而不夠具代表性，檢測方法只以「機器檢測碼」及「（人工）稽核評量碼」為主，未確實依「成功準則」實施評估，檢測規則與 ACT-R 國際社群小組不一致，機器檢測及人工稽核評量都有部分的實際判定基準與文件上記載的規則不同，檢測結果存在高偽陽性及高偽陰性，檢測報告過於粗糙簡略。換而言之，在親和力評估檢測的每一個面向都有待加強。

然而最大的問題，在於歷年來許多政府機關在資訊業務委外服務案中，把「取得無障礙標章」列為承商工作項目。網頁親和力跟業務邏輯、業務內容息息相關，委外服務案承商不可能凌駕於政府機關業務部門之上；障礙也可能起因於比委外服務案更高層級的機關架構位置，例如我多年前曾向社家署文官說明（當時）「影片內容都放在 YouTube 平台會有很多限制，包括很容易洩漏民眾隱私給私人企業，也有很多親和力障礙難以克服，建議改放在機關自己的伺服器上，能夠使用的設計手段及親和力技術較完整」，但是文官表示「不可能，因為本部資訊處說頻寬有限，禁止把影片內容放在部自己的伺服器」；在這個情況中，委外服務案承商又怎麼可能去左右整個部的資訊管理政策？

把「取得無障礙標章」列為承商工作項目，言下之意就是政府機關不負擔相關責任，只負責向承商究責，然而造成障礙的根源在機關內部（敵人就在本能寺！），承商只剩一條活路：詐。多年來，許多「專門承接政府標案」的資訊服務廠商已經練就一套應付驗收的武功招式，無論是矇騙台灣政府專用的檢測軟體，讓視覺功能障礙檢測人員無法察覺有問題的功能或內容，或者把真正的功能及內容留待「取得標章」後再上線，總之能先依期程結案才重要，承商開心，政府機關承辦人員也開心；反正在這種政府機關—承商的交相賊之間，只有民眾的權益受到犧牲。

我此前協助修訂政府網站服務管理規範及政府資訊服務採購作業指引，實際上就是要弱化這種公務體系的不良慣性。眼看終於趕在「改朝換代」之際往理想的方向推進，想不到幾個月後，數發部提出普及與深化政府網站與行動化應用軟體無障礙設計行動方案經行政院核定，排定研議修訂政府資訊服務採購契約範本，納入機關官方網站、對外服務網站及行動化應用軟體應取得無障礙認證標章工作項目，又把這項劣習加強到行政院推行的政策方向。

政治的現實

「進步」是全部的人一起往前移動一點點，然後每天不斷往前，日積月累之後才發現大家已經站在不同的地方、看到不同的世界；只靠一、兩個人，或者一支團隊，眼界、技術再超前也沒有意義，轉瞬之間灰飛湮滅。

邁向數位親和力的道路上，台灣社會整體要擺脫能力歧視主義（健全主義）的枷鎖，每個社會成員要真心理解並接受人人在人生歷程的某些階段都是身心障礙者，投入親和力能夠把餅做大而不是爭奪資源，而公務體系要理解自身並非超然於台灣社會的天龍人，「公務體系」跟「民間」要有更健康的關係……這一切需要幾個世代的成長，沒辦法透過任何法規、指引或制度，一夕之間改變。