<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
  xmlns:admin="http://webns.net/mvcb/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule">

  <channel>
    <title>Jedi&apos;s BLOG</title>
    <link>https://jedi.org/blog/</link>
    <description>Context makes sense</description>
    <dc:language>zh-tw</dc:language>
    <dc:creator>jedilin@gmail.com</dc:creator>
    <dc:date>2026-03-01T15:27:21+08:00</dc:date>
        <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
    
    <admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=2.661" />
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>

        <item>
      <title>助聽器相容性不再評級</title>
      <link>https://jedi.org/blog/archives/006463.html</link>
      <description>
        <![CDATA[<p>很久以前介紹過 <a href="https://jedi.org/blog/archives/006259.html" title="查詢手機的助聽器相容性評級 (HAC Rating) | Jedi's BLOG">助聽器相容性評級 (<span lang="en">HAC Rating</span>)</a>，不過我最近查詢資料時（後知後覺地）注意到有些較新的手機只有標示「符合」，沒有細分評級。</p>

<p>查詢後發現是因為先前版本的 <a href="https://xplorestaging.ieee.org/document/6046067" title="C63.19-2011 - American National Standard Methods of Measurement of Compatibility between Wireless Communications Devices and Hearing Aids - Redline | IEEE Standard | IEEE Xplore" lang="en">ANSI C63.19-2011</a> 標準才有「評級」，較新版本的 <a href="https://ieeexplore.ieee.org/document/8906258" title="C63.19-2019 - American National Standard Methods of Measurement of Compatibility between Wireless Communications Devices and Hearing Aids | IEEE Standard | IEEE Xplore" lang="en">ANSI C63.19-2019</a> 標準只有「符合」或「未符合」的結果。</p>

<p>根據 Google <a href="https://support.google.com/pixelphone/answer/9393002?hl=zh-Hant" title="Pixel 手機的助聽器相容性 - Pixel 手機說明"><cite>Pixel 手機的助聽器相容性</cite></a>以及 Apple <a href="https://support.apple.com/zh-tw/106349" title="關於 iPhone 的助聽器相容性（HAC）要求 - Apple 支援 (台灣)"><cite>關於 iPhone 的助聽器相容性 (HAC) 要求</cite></a>等資訊來看，大約是從<time datetime="2024"> 2024 年</time>起的產品（例如 Pixel 8a、iPhone 16）已改採用 ANSI C63.19-2019 標準；又查了一下，確認是依<u>美國</u> <abbr title="Federal Communications Commission">FCC</abbr> 發布的 <a href="https://www.fcc.gov/document/order-extending-transition-period-hac-technical-standard" title="Order Extending Transition Period for HAC Technical Standard | Federal Communications Commission">DA-23-327 行政命令</a>，所以從<time datetime="2023-12-05"> 2023 年 12 月 5 日</time>之後都要採用新的標準。</p>

<p>新的 ANSI C63.19-2019 標準雖然新增了關於音量調節的規範（注意：有些手機可能會依 <a href="https://www.fcc.gov/document/wtb-grants-limited-waiver-hac-volume-control-rules" title="WTB Grants Limited Waiver of HAC Volume Control Rules | Federal Communications Commission">DA-23-914</a> 主張部分豁免），但似乎就很難用來確認<a href="https://jedi.org/blog/archives/006320.html#inductive" title="電感耦合 | 聽損者職務再設計策略：佩戴助聽器接聽電話 | Jedi's BLOG">電感耦合</a>能不能有更佳的聆聽效果；這大概也反映出這個時代的主流助聽器產品已經轉移到其他無線配接技術，例如 <a href="https://support.apple.com/zh-tw/108780" title="使用 Made for iPhone 助聽裝置 - Apple 支援 (台灣)"><abbr title="Made For iPhone" lang="en">MFi</abbr></a>、<a href="https://jedi.org/blog/archives/006279.html" title="助聽器、人工電子耳、智慧型手機：MFi 與 ASHA | Jedi's BLOG"><abbr title="Audio Streaming for Hearing Aids" lang="en">ASHA</abbr></a>、<a href="https://www.bluetooth.com/specifications/specs/hearing-access-profile-1-0/" title="Hearing Access Profile | Bluetooth® Technology Website"><abbr title="Hearing Access Profile" lang="en">HAP</abbr></a> 等。</p>

<p>註：<u>台灣</u>至今為止仍然沒有任何法規規範電話設備應與助聽器相容。</p>]]>
        
      </description>
      <guid isPermaLink="false">6463@https://jedi.org/blog/</guid>
      <dc:subject>occupation</dc:subject>
      <dc:date>2026-03-01T15:27:21+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>世代交替</title>
      <link>https://jedi.org/blog/archives/006462.html</link>
      <description>
        <![CDATA[<p>前幾篇提到<cite>報導者</cite>採訪，報導末尾講到<a href="https://jedi.org/blog/archives/006458.html" title="為什麼台灣的數位親和力之路至少耗時兩百年（上） | Jedi's BLOG">至少耗時兩百年</a>後，記者提出一個很實際的問題：「這兩百年內，我們什麼也不做嗎？」</p>]]>
        <![CDATA[<p>我的回答因為主題跟篇幅的關係，沒有放到報導內。我的想法是，這兩百年的關鍵是要把對於親和力的追求融入到文化底蘊，在歷程上需要完成多次世代交替。歷史帶給人類的教訓是：人類幾乎無法從歷史中學到教訓。講述上個世紀各種慘痛的人權發展經驗，現在二、三十歲以下的人很難真正體會，我認為這是目前數位親和力發展的瓶頸，有太多歷史情感的包袱集結到來自<u>歐</u><u>美</u>的親和力實務，我們不可能只把這些集結累積的形式拿過來，而忽略過去幾百年的脈絡，偏偏這些抽象的感受正在快速消逝；如果堅持著「用別人的經驗來指導我們的發展方向」，阻力越來越大，方向只會偏掉歪掉。</p>

<p>親和力是關於人權、關於日常生活的實踐，需要跟普遍人口的生活經驗密切結合。（相對）年輕世代需要能夠用自身的生活經驗，去理解跟論述數位親和力，這是（相對）年長世代無法強迫或代勞的任務。實際上我也看到一些年輕設計師正在用自己的步調跟方法，正視數位親和力，探尋不同產業中可行的發展策略；儘管我不總是同意這些路，或已預見種種挑戰，重點是讓這些事情成為新世代的具體切身體驗。</p>

<p>也許有些我這個世代所堅持的<a href="https://jedi.org/blog/archives/006461.html" title="核心價值與選擇 | Jedi's BLOG">價值</a>已經跟下一個世代的生活脈絡無法契合，我無法跳脫我自己的視角而無法看清，這是任何人自身的極限。年輕世代在摸索跟累積經驗、建立價值的過程中，最不需要的就是「別的世代動不動就來指指點點」這種父權說教。所以我說，我自己在做的事情是記錄跟揭露我經歷過的歷史跟知識，攤開這些故事，然後閉嘴，不要擋路、不要侷限世代發展的可能性。</p>

<p>有些人可能覺得文化的累積是持續的加法，我持不同想法；我認為是在持續失去許多東西的情況下，有一些東西能夠留下來，然後轉變成不同的樣子，變多，又失去，再留下一些東西……那些能夠持續留下的，就是文化的累積。</p>

<p>這種世代交替，就是這兩百年的功課。</p>]]>
      </description>
      <guid isPermaLink="false">6462@https://jedi.org/blog/</guid>
      <dc:subject>kitchen</dc:subject>
      <dc:date>2026-02-26T11:45:53+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>核心價值與選擇</title>
      <link>https://jedi.org/blog/archives/006461.html</link>
      <description>
        <![CDATA[<p>不論對於人還是對於企業、組織，真正的「核心價值」都不是公關文宣稿上那段冠冕堂皇的話語；<dfn>核心價值</dfn>體現在於利益發生衝突之際，實際做出的選擇。</p>

<p>先前<cite>報導者</cite>記者來採訪我（<cite><a href="https://jedi.org/blog/archives/006458.html" title="為什麼台灣的數位親和力之路至少耗時兩百年（上） | Jedi's BLOG">為什麼台灣的數位親和力之路至少耗時兩百年</a></cite>提到的那件）時，提到撰寫這系列報導的契機是<time datetime="202508">去年 8 月</time> LINE 宣布預計停止提供（相對障礙比較少一點的）網頁版用戶端，引起國內視覺功能障礙者一陣恐慌；記者採訪的第一個問題是問我怎麼看這個事件、問我是否覺得 LINE 應該多投入在親和力領域。</p>]]>
        <![CDATA[<p>我說，<u>台灣</u>人是全世界少數特別偏好使用 LINE 的族群，而且<u>台灣</u>人從一開始就不是因為 LINE 在安全性、效能（系統資源耗用）、親和力（無障礙）做得多好而選擇 LINE，僅僅是「我認識的人用 LINE，所以我用 LINE」這種原因，即使遭遇上述這些利益衝突，還是做出這個選擇；在這個自由競爭的市場，明明存在更安全、更多功能、更有效率、更省資源、更具親和力、也有其他人使用的即時通訊系統，現狀就是絕大多數的<u>台灣</u>人也不會棄用 LINE 而轉移到其他即時通訊系統。這一點在<u>台灣</u>多數的身心障礙者群體，包括視覺功能障礙者群體，也沒有不同。</p>

<p>我認為（這個世代的）<u>台灣</u>人已經在選擇中體現出核心價值，並未包含親和力（大概也不包含安全性或效能），無論大家各自如何宣稱。那麼，在商言商，做為私人企業的 LINE，有什麼理由要把資源挹注到不會構成產品選擇的面向？</p>

<p>我自己不使用 LINE（我全家人都不使用 LINE），因為 LINE 的產品跟我堅持的核心價值不符，儘管我有朋友就在 LINE 公司內任職。多年來，如果有人對我提出「加一下 LINE」，我會請對方使用其他的通訊服務或系統；如果我想使用的產品或服務需要透過 LINE 才能提供，我會直接改找其他廠商。我並不是因為 LINE 是 LINE 而抵制 LINE，而是我認為要以實際的選擇來讓 LINE 公司理解到我堅持的核心價值的商業價值。</p>

<p>所以我對這個事件的看法是：使用者已經用行動表明自己接受且不會放棄有障礙的服務，我這個局外人也沒有什麼說話表態的立場了。</p>]]>
      </description>
      <guid isPermaLink="false">6461@https://jedi.org/blog/</guid>
      <dc:subject>kitchen</dc:subject>
      <dc:date>2026-02-21T16:06:58+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>為什麼台灣的數位親和力之路至少耗時兩百年（下）</title>
      <link>https://jedi.org/blog/archives/006460.html</link>
      <description>
        <![CDATA[<p>前情提要：本文<a href="https://jedi.org/blog/archives/006459.html" title="為什麼台灣的數位親和力之路至少耗時兩百年（中） | Jedi's BLOG">中篇</a>談到我們在 <abbr title="行政院公共數位創新空間">PDIS</abbr> 的努力，接下來要說明這些努力如今還剩下什麼、前方有什麼挑戰正等著<u>台灣</u>的公務體系。</p>]]>
        <![CDATA[<h2>內容目錄</h2>
<ul>
  <li><a href="https://jedi.org/blog/archives/006458.html#ableism_h">能力歧視主義（健全主義）</a>（上篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006458.html#eugenics_law_h">優生保健法</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#discrimination_type_h">微歧視的型態</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#legally_discrimination_h">合法歧視</a>（上篇）</li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006458.html#person_with_disabilities_h">誰是身心障礙者</a>（上篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006458.html#population_h">身心障礙者人口統計</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#classification_h">身心障礙分類系統</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#reverse_ableism_h">反向健全主義</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#:::_h">網頁導盲磚</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#territories_h">各方山頭</a>（上篇）</li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006459.html#government_h">公務體系及主管機關</a>（中篇）</li>
  <li><a href="https://jedi.org/blog/archives/006459.html#pdis_h">PDIS 與數位韌性</a>（中篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006459.html#design_systems_h">設計制度</a>（中篇）</li>
    <li><a href="https://jedi.org/blog/archives/006459.html#w3c_h">參與 W3C</a>（中篇）</li>
  </ul></li>
  <li><a href="#component_libraries_h">元件庫</a></li>
  <li><a href="#outsourcing_h">業務委外</a><ul>
    <li><a href="#rfp_h">標案需求規格</a></li>
    <li><a href="#gov_website_h">薛丁格的政府網站</a></li>
  </ul></li>
  <li><a href="#digital_documents_h">數位文件</a></li>
  <li><a href="#badge_statement_h">無障礙標章及親和力宣告</a></li>
  <li><a href="#reality_h">政治的現實</a></li>
  <li>後記<ul>
    <li>其一：<a href="https://jedi.org/blog/archives/006461.html" title="核心價值與選擇 | Jedi's BLOG">核心價值與選擇</a></li>
    <li>其二：<a href="https://jedi.org/blog/archives/006462.html" title="世代交替 | Jedi's BLOG">世代交替</a></li>
  </ul></li>
</ul>

<h2>元件庫</h2>

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

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

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

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

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

<h2>業務委外</h2>

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

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

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

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

<p>因為有這段歷史，<time datetime="2025">去年</time>我才會<a href="https://jedi.org/blog/archives/006452.html" title="回應金管會「數位金融服務包容性指引（草案）」意見 | Jedi's BLOG">據理回應金管會的指引草案</a>，令人感到欣慰的是這次<abbr title="金融監督管理委員會">金管會</abbr>終於願意採納相關意見，即使這只是一份非強制性的指引文件。</p>

<h3>標案需求規格</h3>

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

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

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

<p><cite>政府網站服務管理規範</cite>係整併取代<time datetime="2005"> 2005 年</time><cite>政府網站版型與內容管理規範</cite>、<time datetime="2010">2010 年</time><cite>政府網站建置及營運作業參考指引</cite>、<time datetime="2011">2011 年</time><cite>政府網站 Web 2.0 營運作業參考指引（社會網絡篇）</cite>等三份規範指引，再依<time datetime="2019"> 2019 年</time><cite>政府數位服務指引</cite>修正，算是<abbr title="數位發展部">數發部</abbr>主管規範中最具<a href="https://jedi.org/blog/archives/006459.html#designsystems">設計制度</a>性質的文件。然而，當時其內容已經落後國際現實大約 20 年。</p>

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

<p>到了<time datetime="2024-06-21">六月下旬</time>，<abbr title="行政院公共工程委員會">工程會</abbr><a href="https://gov.tw/NWC" title="行政院公共工程委員會工程企字第 1130007244 號函 | 政府電子採購網">函告</a>（<cite>工程企字第 1130007244 號</cite>）修正<cite>政府資訊服務採購作業指引</cite>之「使用者體驗」常用 <abbr title="資訊服務等級協議">SLA</abbr> 參考項目，明確指出係參考新版<cite>政府網站服務管理規範</cite>，說明<q>爾後機關辦理資訊服務採購倘涉及網站設計及使用者體驗者，亦請參考旨揭修正後 <abbr title="資訊服務等級協議">SLA</abbr> 參考項目</q>。</p>

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

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

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

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

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

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

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

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

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

<u>台灣</u>的主計、審計都是獨立於各政府機關既有編制的獨立體制（所謂「一條鞭」），這種結構設計旨在防弊，但對於數位親和力的發展相當不利；我曾向<abbr title="數位發展部">數發部</abbr>高階文官說明解釋 <a href="https://jedi.org/blog/archives/006352.html" title="ISO 30071-1 數位親和力成熟度計分卡 | Jedi's BLOG"><cite>ISO 30071-1</cite> 國際標準</a>及 <a href="https://jedi.org/blog/archives/006377.html" title="W3C 親和力成熟度模型 | Jedi's BLOG"><cite>W3C 親和力成熟度模型</cite></a>，兩者皆強調「採購」及「人員」對機關團體發展數位親和力的重要性，是不是應該直接跟主計、審計交流討論可能的採購政策，找出既能符合防弊目標又能兼顧當代設計模式典範的型態？結果文官驚恐地連忙表示「千萬不要！沒問之前還可以偷偷做，問了之後一定不能做！」從這個反應也能看出，「籌獲親和力」(<span lang="en">accessible procurement</span>) 對於<u>台灣</u>還是相當大的挑戰，拖累<u>台灣</u>公務體系的親和力成熟度發展。

<h3>薛丁格的政府網站</h3>

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

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

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

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

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

<p>從行政的角度來看，列管資訊系統的法規規範都有其用意跟目的；以「打詐儀表板」為例，打詐網站充滿親和力障礙，身心障礙者無法使用，傳達的訊息就變成「把詐騙集中到身心障礙者那邊」，<a href="https://jedi.org/blog/archives/006333.html" title="與其「完全不提供內容」，是否「提供有障礙的內容」比較好？ | Jedi's BLOG">反倒比不打詐還糟糕</a>。</p>

<p>對於擺明要閃避法規規範的資訊系統，怎麼可能有辦法要求採用任何<a href="https://jedi.org/blog/archives/006459.html#designsystems">設計制度</a>？如果政府機關可以公然鑽漏洞，整個社會居然也覺得理所當然、欣然接受，怎麼可能理解反歧視的平等概念？</p>

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

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

<p>行政院<time datetime="2025-12-18">去年底</time>提出的<cite>身心障礙者權益保障法部分條文修正草案</cite>稍微擴大適用範圍，調整為<q>各級政府與其附屬機關（構）、學校、公營事業與政府捐助之財團法人所建置之網站及行動化應用軟體</q>，以及<q>一定規模以上之醫院、金融機構之網站</q>，思維脈絡仍未成長。從主管<cite><abbr title="身心障礙者權益保障法">身權法</abbr></cite>的<abbr title="衛生福利部">衛福部</abbr>到<abbr title="數位發展部">數發部</abbr>，乃至於許多身心障礙者團體，都只注意到<abbr title="身心障礙者權益保障法">身權法</abbr><a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=D0050046&amp;flno=52" title="身心障礙者權益保障法 &#167;52 | 全國法規資料庫">第五十二條</a>第一項第三款<q>公共資訊無障礙</q>，錯誤地望文生義認為所有跟資訊通訊科技有關的親和力法源都在這一項，前述在<a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=D0050046&amp;flno=52-2" title="身心障礙者權益保障法 &#167;52-2 | 全國法規資料庫">第五十二之二條</a><q>應通過無障礙檢測</q>的規範，就是在這個架構底下所制定，因此無法跳脫窠臼。</p>

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

<h2>數位文件</h2>

<p>選舉委員會的選舉／投票公報不是特例，<u>台灣</u>各級政府機關最常提供民眾下載使用的數位文件盡是：<em>有障礙</em>的 <abbr title="Portable Document Format">PDF</abbr>、<em>有障礙</em>的 <abbr title="Microsoft Office Open XML WordprocessiongML">DOCX</abbr>、<em>有障礙</em>的 <abbr title="OpenDocument Text">ODT</abbr> 等檔案。從行政院公報，到<abbr title="衛生福利部">衛福部</abbr>便民服務提供的表單下載，到<abbr title="衛生福利部社會及家庭署">社家署</abbr>的出版品及研究報告、年報、施政方針及施政報告、內部控制聲明書、預算書、決算書等，清一色<em>有障礙</em>的 <abbr title="Portable Document Format">PDF</abbr> 檔案。</p>

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

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

<p><abbr title="Portable Document Format">PDF</abbr>、<abbr title="OpenDocument Text">ODT</abbr>、<abbr title="Microsoft Office Open XML WordprocessiongML">DOCX</abbr> 等檔案格式都不必然造成障礙，<abbr title="全球資訊網協會">W3C</abbr> 發布 <cite lang="en">Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)</cite> 清楚說明 <cite lang="en"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.*</cite>／<cite lang="en">ISO/IEC 40500</cite> 國際標準如何適用於數位文件。實際上，這些檔案格式也都有相對應的專屬親和力標準或指引可以依循。</p>

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

<p><abbr title="OpenDocument Text">ODT</abbr>、<abbr title="OpenDocument Spreadsheet">ODS</abbr>、<abbr title="OpenDocument Presentation">ODP</abbr>、<abbr title="OpenDocument Graphics">ODG</abbr> 等檔案格式在定義格式本身的 <cite>ISO/IEC 26300-1</cite> 國際標準的附錄 D <cite lang="en">Accessibility Gudielines</cite>，提供這些檔案格式的親和力指引。雖然這份指引屬於國際標準中「非強制性」的部份，但<abbr title="數位發展部">數發部</abbr>開發提供給公務機關（以及民眾）使用的 <a href="https://moda.gov.tw/digital-affairs/digital-service/app-services/248" title="ODF 文件應用工具 | 政府共通應用服務 - 數位政府 - 核心業務 | moda — 數位發展部 Ministry of Digital Affairs">ODF 文件應用工具</a>裡，的的確確已經內建「無障礙檢查」功能，然而就連<abbr title="數位發展部">數發部</abbr>製作提供的 <abbr title="OpenDocument Text">ODT</abbr> 檔案也沒有利用這項功能，文件檔案充滿障礙。<br />
<img alt="MODA ODF Application Tools Writer 開啟「資安風險及防護機制評估檢視表.odt」檔案，在「無障礙檢查」面板中列出一連串的錯誤及警告" src="https://jedi.org/blog/archives/moda_odt_inaccessible_sample.png" width="1122" height="659"></img></p>

<p><abbr title="Microsoft Office Open XML WordprocessiongML">DOCX</abbr>、<abbr title="Microsoft Office Open XML SpreadsheetML">XLSX</abbr>、<abbr title="Microsoft Office Open XML PresentationML">PPTX</abbr>、<abbr title="Microsoft Office Open XML DrawingML">VSDX</abbr> 等檔案格式在定義格式本身的 <cite>ISO/IEC 29500-1</cite> 國際標準的附錄 J <cite lang="en">Accessibility Best Practices</cite>，提供這些檔案格式的最佳親和力實作方式，不過也同樣是屬於國際標準中「非強制性」的部份。微軟在 Office 應用程式裡，均提供「檢查協助工具」多項功能，協助文件編撰者改善數位文件親和力；但同樣遺憾地，<u>台灣</u>從未有任何法規對此做出要求或規範，目前為止所有政府機關提供的這類文件格式檔案都有障礙。<br />
<img alt="微軟 Word 應用程式在「校閱」功能區的「檢查協助工具」按鈕展開五項功能，分別是檢查協助工具、替代文字、功能窗格、焦點、選項：協助工具" src="https://jedi.org/blog/archives/ms_word_a11y_checker_screenshot.png" width="779" height="472"></img></p>

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

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

<p>經過上述研究分析，<time datetime="2023">當年</time><abbr title="數位發展部">數發部</abbr>部長在內部會議裁示要發展 EPUB 格式為政策方向。</p>

<p>那為什麼現在政府機關網站上，還是滿坑滿谷的 <abbr title="Portable Document Format">PDF</abbr> 檔案，仍然看不到 EPUB 檔案？<abbr title="數位發展部">數發部</abbr>文官對網頁科技的熟悉程度可能是一個因素，有些文官抱持著「EPUB 格式是文化部主管的，不是<abbr title="數位發展部">數發部</abbr>的業務」的想法（註：文化部這幾年補助<a href="http://www.dpublishing.org.tw" title="台灣數位出版聯盟 Taiwan Digital Publishing Forum TDPF">台灣數位出版聯盟</a>參與 <abbr title="全球資訊網協會">W3C</abbr> 的 EPUB 相關工作小組）也會影響積極度，最主要的原因大概還是因為&#x2E3A;部長換人了。</p>

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

<h2>無障礙標章及親和力宣告</h2>

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

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

<p>不過，大約從<time datetime="2010"> 2010 年</time>起，這類標章機制在<u>歐</u><u>美</u>各國逐漸式微，主因是網頁科技的開發典範轉移，功能及內容都變動得更頻繁，<a href="https://www.w3.org/TR/web-user-agents/" title="Web User Agents | W3C Group Draft Note">使用者代理</a>改版週期也大幅縮短，「通過檢測」的實質代表性弱化。此外也應注意，<abbr title="全球資訊網協會">W3C</abbr> 雖然也<a href="https://www.w3.org/WAI/standards-guidelines/wcag/conformance-logos/" title="Adding WCAG Conformance Logos | Web Accessibility Initiative (WAI) | W3C">提供標章</a>，但不做任何監管或擔保，完全是網站或網頁作者單方面的宣稱性質。</p>

<p>因應網頁科技的典範轉移，先進國家目前的主流模式不再使用靜態斷代的標章，改以<em>親和力宣告</em>的方式，強調與使用者之間維繫的良性溝通互動，<time datetime="2016">2016 年</time>的<u>歐盟</u>網頁親和力指令 (<cite lang="en">EU Web Accessibility Directive</cite>) 即要求各國公部門網站及行動應用程式均應提供親和力宣告，已不採用標章機制。<abbr title="全球資訊網協會">W3C</abbr> 在網站上提供<a href="https://www.w3.org/WAI/planning/statements/" title="Developing an Accessibility Statement | Web Accessibility Initiative (WAI) | W3C">如何開發親和力宣告</a>的完整說明，以及開放源碼的<a href="https://www.w3.org/WAI/planning/statements/generator/" title="Generate an Accessibility Statement | Web Accessibility Initiative (WAI) | W3C">親和力聲明產生器</a>；簡單來說，親和力聲明應包含的基本內容如下：</p>

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

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

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

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

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

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

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

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

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

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

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

<h2>政治的現實</h2>

<p><img alt="憤怒貓咪圖樣搭配 &quot;Cats Against Ableism!&quot; 文字的貼紙貼在綠色筆記型電腦上蓋，遠處還有一張紅底白字寫著 &quot;Accessibility&quot; 的貼紙" src="https://jedi.org/blog/archives/cats_against_ableism.png" width="800" height="800">
<br />
「進步」是全部的人一起往前移動一點點，然後每天不斷往前，日積月累之後才發現大家已經站在不同的地方、看到不同的世界；只靠一、兩個人，或者一支團隊，眼界、技術再超前也沒有意義，轉瞬之間灰飛湮滅。</img></p>

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

<hr />

<p>後記：關於<a href="https://jedi.org/blog/archives/006461.html" title="核心價值與選擇 | Jedi's BLOG">核心價值與選擇</a>，以及<a href="https://jedi.org/blog/archives/006462.html" title="世代交替 | Jedi's BLOG">世代交替</a>。</p>]]>
      </description>
      <guid isPermaLink="false">6460@https://jedi.org/blog/</guid>
      <dc:subject>typing</dc:subject>
      <dc:date>2026-01-26T16:39:07+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>為什麼台灣的數位親和力之路至少耗時兩百年（中）</title>
      <link>https://jedi.org/blog/archives/006459.html</link>
      <description>
        <![CDATA[<p>前情提要：本文<a href="https://jedi.org/blog/archives/006458.html" title="為什麼台灣的數位親和力之路至少耗時兩百年（上） | Jedi's BLOG">上篇</a>從歷史、文化、法律等面向，說明<u>台灣</u>社會背負的親和力障礙，本篇（中篇）接續未完的話題，從公務體系的文化展開，談談我們在 <abbr title="行政院公共數位創新空間">PDIS</abbr> 的努力。</p>]]>
        <![CDATA[<h2>內容目錄</h2>
<ul>
  <li><a href="https://jedi.org/blog/archives/006458.html#ableism_h">能力歧視主義（健全主義）</a>（上篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006458.html#eugenics_law_h">優生保健法</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#discrimination_type_h">微歧視的型態</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#legally_discrimination_h">合法歧視</a>（上篇）</li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006458.html#person_with_disabilities_h">誰是身心障礙者</a>（上篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006458.html#population_h">身心障礙者人口統計</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#classification_h">身心障礙分類系統</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#reverse_ableism_h">反向健全主義</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#:::_h">網頁導盲磚</a>（上篇）</li>
    <li><a href="https://jedi.org/blog/archives/006458.html#territories_h">各方山頭</a>（上篇）</li>
  </ul></li>
  <li><a href="#government_h">公務體系及主管機關</a></li>
  <li><a href="#pdis_h">PDIS 與數位韌性</a><ul>
    <li><a href="#design_systems_h">設計制度</a></li>
    <li><a href="#w3c_h">參與 W3C</a></li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006460.html#component_libraries_h">元件庫</a>（下篇）</li>
  <li><a href="https://jedi.org/blog/archives/006460.html#outsourcing_h">業務委外</a>（下篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006460.html#rfp_h">標案需求規格</a>（下篇）</li>
    <li><a href="https://jedi.org/blog/archives/006460.html#gov_website_h">薛丁格的政府網站</a>（下篇）</li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006460.html#digital_documents_h">數位文件</a>（下篇）</li>
  <li><a href="https://jedi.org/blog/archives/006460.html#badge_statement_h">無障礙標章及親和力宣告</a>（下篇）</li>
  <li><a href="https://jedi.org/blog/archives/006460.html#reality_h">政治的現實</a>（下篇）</li>
  <li>後記<ul>
    <li>其一：<a href="https://jedi.org/blog/archives/006461.html" title="核心價值與選擇 | Jedi's BLOG">核心價值與選擇</a></li>
    <li>其二：<a href="https://jedi.org/blog/archives/006462.html" title="世代交替 | Jedi's BLOG">世代交替</a></li>
  </ul></li>
</ul>

<h2>公務體系及主管機關</h2>

<p>世界各國的公務體系都有各自的獨特文化，以及奠定整個體系的法理邏輯，<u>台灣</u>自不例外。這些獨特的體系文化及邏輯使得政府機關跟任何商業團體、人民團體相當不同，也導致不同國家的法律政策基本上不可能直接搬移到另一個國家。</p>

<p>我們可以先試著思考：「數位親和力的主管機關是誰？」</p>

<p>許多人的第一反應是「難道不是<abbr title="數位發展部">數發部</abbr>嗎？」畢竟<abbr title="數位發展部">數發部</abbr>是<cite>網站無障礙規範</cite>的主管機關。然而並非如此&#x2E3A;<cite>網站無障礙規範</cite>放在<abbr title="數位發展部">數發部</abbr><abbr title="數位政府司">政府司</abbr>，該司主要職掌政府數位服務、行政院所屬各機關資通訊系統等的規劃及推動，能夠處理的範圍只涵蓋部分政府機關，形式也非監督或管理；按<abbr title="數位政府司">政府司</abbr>的<a href="https://moda.gov.tw/press/press-releases/13358" title="公私協力共同推動無障礙網路環境  數位平權再進一步｜新聞發布 - 公告訊息｜moda — 數位發展部 Ministry of Digital Affairs">公開說法</a>，其自身定位為<q>協調角色</q>而非治理角色，<q>提供相關諮詢工具</q>而不涉入處理人民的平權法益。</p>

<p><abbr title="數位發展部">數發部</abbr>雖然宣稱<q>將建立完善的無障礙檢測和認證機制</q>，及<q>提供全面的技術支援，包括無障礙設計指南、檢測工具和專業諮詢服務</q>，夢想很美好但現實很殘酷，目前就連<abbr title="數位發展部">數發部</abbr>提供的<a href="https://jedi.org/blog/archives/006437.html" title="Freego 檢測相容性 | Jedi's BLOG">檢測工具都還相當不可信</a>。</p>

<p>從法規上來看，國家整體數位親和力的主管機關應該是<cite><abbr title="身心障礙者權益保障法">身權法</abbr></cite>的主管機關&#x2E3A;<abbr title="衛生福利部">衛福部</abbr>；但<cite><abbr title="身心障礙者權益保障法">身權法</abbr></cite><a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=D0050046&amp;flno=2" title="身心障礙者權益保障法 &#167;2 | 全國法規資料庫">第二條</a>第二項規定著<q>涉及各目的事業主管機關職掌者，由各目的事業主管機關辦理</q>，這種法條實際上展現出政治權力關係的現實：任何一個部會都沒有足夠的實質力量能夠去左右其他（平級的）部會；這種「把一件事切割成若干領域，各自列管進行」是<u>台灣</u>政府相當擅長的治理模式，優點是容易產生立即可執行的行動項目，很方便給出交代，缺點是隨著事情面向越發多元複雜，好像每個方面都有作為，但各方面組合起來沒有明顯的進展，幾乎必然導向見樹不見林的結果。</p>

<p>「數位親和力」在上述法律架構中，歸屬在哪個「目的事業」？是不是數位輔助科技（輔具）屬於衛生目的事業？數位教材屬於教育目的事業？線上打卡系統屬於勞工目的事業？大眾交通工具售票劃位系統屬於交通目的事業？線上銀行服務屬於金融目的事業？報警求救資通訊系統屬於警政目的事業？數位圖書屬於文化目的事業？數位產品及服務已經與現代日常生活的所有面向難以分割，早已超出「通訊傳播目的事業」的範圍。</p>

<p><u>台灣</u>政府為了應對這類跨越眾多目的事業的事務，會由行政院政務委員召集跨部會小組來聯繫及推動。能處理數位親和力事務的是身心障礙者權益推動小組（以下簡稱身權小組，其成員包括諸多部會次長、學者專家、身心障礙者團體代表等，執行秘書固定由<abbr title="衛生福利部">衛福部</abbr>次長擔任。</p>

<p>這裡有個小插曲：<abbr title="數位發展部">數發部</abbr>於<time datetime="2022"> 2022 年</time>掛牌成立後，<cite>行政院身心障礙者權益推動小組設置要點</cite><em>沒有</em>跟著修訂，<abbr title="數位發展部">數發部</abbr>未列入<abbr title="身心障礙者權益推動小組">身權小組</abbr>，自然沒有參與小組會議。我開始在 <abbr title="行政院公共數位創新空間">PDIS</abbr> 從事顧問服務後注意到這個情況，主動向當時的<abbr title="數位發展部">數發部</abbr>部長提起，最後終於遊說成功，<abbr title="數位發展部">數發部</abbr>於<time datetime="2023-10">當年十月</time>正式納入<abbr title="身心障礙者權益推動小組">身權小組</abbr>。</p>

<p><abbr title="身心障礙者權益推動小組">身權小組</abbr>雖然<q>接受涉及違反〔身心障礙者權利〕公約之申訴</q>，但其主要任務卻是協調、研究、審議、諮詢、調查，而且每年只有三場定期會議；實際上<abbr title="身心障礙者權益推動小組">身權小組</abbr>也沒有提供接受申訴的窗口，在其網站上僅提供司法院、監察院、行政院所屬若干部會、各縣市政府的陳情電話號碼及網頁。 <cite><abbr title="國際審查委員會（IRC） 2022 年 8 月 6 日就中華民國（臺灣）施行身心障礙者權利公約（CRPD）第二次國家報告結論性意見">CRPD 第二次國際審查意見</abbr></cite>直接點出<q>行政院身心障礙者權益推動小組尚未
在政府內部建立有效的協調機制</q>。</p>

<p>實質上能夠對<q>構成各種形式歧視之事件進行調查，並依法處理及救濟</q>的單位，其實是監察院國家人權委員會（以下簡稱人權會）；由此來看，<abbr title="監察院國家人權委員會">人權會</abbr>更像是<u>台灣</u>數位親和力的主管機關。 <cite><abbr title="國際審查委員會（IRC） 2022 年 8 月 6 日就中華民國（臺灣）施行身心障礙者權利公約（CRPD）第二次國家報告結論性意見">CRPD 第二次國際審查意見</abbr></cite>一方面肯定<u>台灣</u>成立<abbr title="監察院國家人權委員會">人權會</abbr>，另一方面指出<q>沒有任何立法措施指定國家人權委員會作〔做〕為獨立機制，以促進和保障身心障礙者的權利</q>。<abbr title="監察院國家人權委員會">人權會</abbr>網站上的「<a href="https://nhrc.cy.gov.tw/cp.aspx?n=9741" title="無障礙網頁宣言 | 國家人權委員會">無障礙網頁宣言</a>」目前還是抄錄<time datetime="2007"> 2007 年</time><abbr title="行政院研究發展考核委員會">研考會</abbr>版的<cite>無障礙網頁開發規範</cite>內容，這個版本早已跟不上現今網頁科技。</p>

<h2>PDIS 與數位韌性</h2>

<p>以政府角度發展數位親和力，需要有個位階夠高且能夠跨部會協商的編組，編組成員不但要具備數位技術的實務能力，也要對公務體系文化有足夠的敏感度。<time datetime="2023">2023 年</time>，行政院資訊長重新啟用她在政務委員時期成立的公共數位創新空間 (<abbr title="Public Digital Innovation Space">PDIS</abbr>) 小組，招募新成員，定位調整為研發暨快速反應團隊，兼協助<abbr title="數位發展部">數發部</abbr>及國家資通安全研究院（以下簡稱資安院）規劃、執行相關任務。（註：行政院資訊長係由<abbr title="數位發展部">數發部</abbr>部長兼任，同時兼任<abbr title="國家資通安全研究院">資安院</abbr>董事長。）</p>

<p>這一代 <abbr title="行政院公共數位創新空間">PDIS</abbr> 雖然「繼承」了名號跟部分資源，跟先前的 <abbr title="行政院公共數位創新空間">PDIS</abbr> 可以說是完全不同&#x2E3A;成員幾乎不重疊、許多工作整個重頭來過。行政院資訊長當時提出一個重要的<dfn>數位韌性</dfn>策略：<strong>數位服務是現代治理的基礎建設，每次進步都要同時更親和、更可靠、更安全，三個面向彼此提攜，絕不能只偏重發展其中某一、兩個面向。</strong>這個策略與聯合國<cite>通用數位公共基礎建設安全框架</cite>也相當契合。</p>

<p>我在這個契機之下，加入 <abbr title="行政院公共數位創新空間">PDIS</abbr> 擔任<em>無障礙設計總顧問</em>；一同加入的夥伴共六人，分別擔任設計制度、無障礙設計、韌性架構、軟體架構、資料架構、應用架構等領域的總顧問，我們因此自稱「<a href="https://hex.pdis.nat.gov.tw" title="HEX Blog | HEX">HEX 工作小組</a>」。同仁之中，我跟<em>設計制度總顧問</em>的合作最為密切（背後的故事是：行政院資訊長一開始先招募她，她很擔心會像先前在 GitHub 的工作經驗那般發生親和力領域的職業倦怠，期待有個能夠對等搭配的同仁一起，於是我才獲得這個機會），我們很快協調好她主攻我主守，我們初期共同設計製作<a href="https://jedi.org/blog/archives/006406.html" title="名片觸摸設計與貝爾曼截角 (Berman Corner) | Jedi's BLOG">運用貝爾曼截角的名片</a>，也一起<a href="https://jedi.org/blog/archives/006415.html" title="運用行為模型及動機諮商工具以促進親和力 | Jedi's BLOG">跟世界各國的政府設計團隊交流</a>；我們六人歷經迭代討論，定調出共通的數位韌性願景：</p>

<blockquote>
<p>韌性是信任：</p>
<p>系統在變動或極端的環境下，持續提供美好的服務，並能在故障時優雅復原。</p>
</blockquote>

<p>我用這個願景來描繪<cite>身心障礙者權利公約</cite>勾勒的數位親和力：</p>

<div>
<p>數位服務的障礙風險並非來自個別使用者的身心功能，而是使用者身心功能與各種 <cite><abbr title="國際健康功能與身心障礙分類系統">ICF</abbr></cite> 環境因素之間的錯位失配 (<span lang="en">mismatch</span>) 所致。</p>
<p>使用者的身心功能、裝置設備、操作空間場域、情境脈絡等從未停止改變，這是再自然、再正常不過的事。確實理解這個現實，從數位系統的設計階段即納入實際／潛在使用者及使用情境，預先規劃合理的彈性餘裕，就能應對更多樣極端的環境配對，避免數位系統輕易失效。數位系統應尊重個別使用者主動（在作業系統或應用程式）揭露的合理調整需求，促進使用者順利完成相關任務。</p>
<p>上述這樣的數位系統，能夠培植使用者對系統的信任，因為使用者能夠感受到這個數位系統真心協助使用者、能有效回應使用者的期待；即使系統不幸發生災難性的損壞，使用者也更願意等待甚至能協助系統復原，從而增進系統韌性並產生正向循環。</p>
</div>

<h3>設計制度</h3>

<p><a href="#designsystems">設計制度</a>是實現這個願景所不可或缺的工具。<dfn>設計制度 (<span lang="en">design system<em>s</em></span>)</dfn> 是一系列（複數型態）用於規範設計的文件，用以確保設計的品質可靠性及一致性；實際涵蓋在設計制度中的文件並不固定，會依機關組織的形態、規模、目標等而有所不同，例如可能包含下列任一種或多種文件：</p>

<ul>
<li>內容策略指引 (<span lang="en">content strategy guide</span>)</li>
<li>文案語感指引 (<span lang="en">copywriting style guide</span>)</li>
<li>撰稿體例 (<span lang="en">edit style</span>)</li>
<li>視聽傳播風格指引 (<span lang="en">media/communication guide</span>)</li>
<li>互動體驗指引 (<span lang="en">user interface / user experience guide</span>)</li>
<li>操作互動邏輯指引 (<span lang="en">interaction guide</span>)</li>
<li>品牌識別及形象系統 (<span lang="en">corporate/brand identity system</span>)</li>
<li>配色表 (<span lang="en">color palette</span>)</li>
<li>字體排印 (<span lang="en">typography</span>)</li>
<li>路徑及檔案命名慣例 (<span lang="en">path and file naming convention</span>)</li>
</ul>

<p>這些文件的實際名稱沒有固定的規定或格式。舉例來說，<cite>中華民國國徽國旗法</cite>部分條文屬於「品牌識別及形象系統」，<cite>憲法訴訟書狀規則</cite>部分條文屬於「字體排印」，行政院<cite>文書處理手冊</cite>部分章節及附錄的內容屬於「撰稿體例」。</p>

<p>通常在數位服務團隊中，會遵循訂定完成的設計制度文件，再根據工程開發採用的數位技術或程式語言，進一步製作及維護可重用的資源庫 (<span lang="en">resource libraries</span>)，這可能包括元件庫 (<span lang="en">component/pattern library</span>)、公用程式 (<span lang="en">utilities</span>)、模版 (<span lang="en">templates/snippets</span>) 等。請注意<strong>這些資源庫只是設計制度的衍生物，不是設計制度本體</strong>。</p>

<p>前代 <abbr title="行政院公共數位創新空間">PDIS</abbr> 在<time> 2021</time>～<time>2022 </time>期間開發過一套名為「<a href="PDIS Design System v5.1">PDIS 設計系統</a>」的設計制度，部分用於<time datetime="2022"> 2022 年</time>成立架設的<abbr title="數位發展部">數發部</abbr>網站；<abbr title="數位發展部">數發部</abbr>首任部長<a href="https://www.youtube.com/watch?v=ZPjgEO0CjoA&t=988s" title="Why did Taiwan choose to borrow from UK website design? | Should Governments Design Websites Like Amazon? ⎸ #InnoMinds S2EP1 (part 1) | TaiwanPlus Docs | YouTube">在訪談中明確表示</a> <q lang="en">Our website design system is a carbon copy of the GDS design system. So much so that if you open the MoDA website and the GDS website, they look like clones of each other.</q> 這段說法的意思是，「<abbr title="數位發展部">數發部</abbr>網站採用的 <a href="PDIS Design System v5.1">PDIS 設計系統</a>完全等於<u>英國</u>的 <a href="https://design-system.service.gov.uk" title="Home | GOV.UK Design System" lang="en">GOV.UK Design System</a>，<abbr title="數位發展部">數發部</abbr>網站就跟<u>英國</u>政府網站一模一樣。」</p>

<p>訪談播出之後，<abbr title="行政院公共數位創新空間">PDIS</abbr><sub>HEX</sub> 設計制度總顧問收到許多不同國家數位服務部門的人員關切，包括<u>英國</u> <abbr title="Government Digital Service" lang="en">GDS</abbr> 團隊成員，大家都很納悶及好奇，因為兩邊網站明明不一樣，也絲毫看不出<abbr title="數位發展部">數發部</abbr>網站哪裡採用 <abbr title="GOV.UK Design System" lang="en">GDS</abbr> 設計制度，是不是哪裡有誤解？</p>

<p>「<a href="https://github.com/PDIS/design-system" title="PDIS/design-system: PDIS Design System | GitHub">PDIS 設計系統</a>」其實是<q>使用 <a href="https://getbootstrap.com" title="Bootstrap · The most popular HTML, CSS, and JS library in the world.">Bootstrap 5</a> 為基礎，經由修改一部分 <a href="https://sass-lang.com" title="Sass: Syntactically Awesome Style Sheets">SASS</a> 來自訂風格呈現</q>，無論是規範制度或元件庫都跟 <abbr title="GOV.UK Design System" lang="en">GDS</abbr> 沒有任何相似性。設計制度總顧問跟我討論之後，決定擱置前代遺留的「PDIS 設計系統」不動，重新開發新版「PDIS<sub>HEX</sub> 設計制度」，後來稱為「<a href="https://guide.nics.nat.gov.tw" title="政府網站設計原則">政府網站設計原則</a>」（註：因為開發經費等因素，這套設計制度後來移轉給<abbr title="國家資通安全研究院">資安院</abbr>接手，部分內容已經跟 <abbr title="行政院公共數位創新空間">PDIS</abbr><sub>HEX</sub> 的原始規劃有所出入）。</p>

<p>我們希望這套新的設計制度「具有<u>台灣</u>特色、適合<u>台灣</u>政府機關使用」，設計制度總顧問為此投入大量私人資源，訪談<u>英國</u>、<u>尼德蘭</u>、<u>德國</u>、<u>冰島</u>、<u>日本</u>等多國數位政府團隊，跑遍世界各地接洽多位跟<u>台灣</u>有著文化聯繫的設計師，合作發展插圖、圖示、色彩、視覺、字型等設計，開發架設 <a href="https://github.com/PDIS/lighthouse" title="PDIS/lighthouse | GitHub">Lighthouse 自動化檢測儀表板雛形</a>；我在另一邊投入編寫<a href="https://github.com/PDIS/alt-text-guideline" title="PDIS/alt-text-guideline: 替代文字指南。 | GitHub">替代文字指南</a>，並準備預計用於設計制度自我親和力宣告的<a href="https://github.com/PDIS/a11y-templates" title="PDIS/a11y-templates: localized document templates for accessibility related documents and reports | GitHub">文件模版</a>。</p>

<p>在技術方面，設計制度總顧問跟我一致認為 <span lang="en">Bootstrap</span> 等網頁開發框架會大幅增加泛用難度及技術債，所以我們從一開始就提倡要以全世界最經典正統的網頁開發框架&#x2E3A;<a href="https://html.spec.whatwg.org/multipage/" title="HTML Standard">HTML</a> 及 <a href="https://www.w3.org/Style/CSS/" title="Cascading Style Sheets">CSS</a> 網頁標準為基礎，運用<a href="https://guide.nics.nat.gov.tw/technology/progressive_enhancement/index.html" title="漸進增強 | 政府網站設計原則">漸進增強</a>策略加上 <a href="https://muan.co/posts/javascript" title="JavaScript dos and donts @ Mu-An Chiou">JavaScript</a>，做為實作設計制度的前端架構，並分別陸續參與全球資訊網協會 (<span lang="en">World Wide Web Consortium, W3C</span>) 若干工作小組及社群小組，包括：</p>

<ul>
<li>親和力教育及外展工作小組 (<span lang="en">Accessibility Education and Outreach Working Group, EOWG</span>)</li>
<li>親和力指引工作小組 (<span lang="en">Accessibility Guidelines Working Group, AGWG, &quot;Silver&quot;</span>)</li>
<li>友善多樣化網際網路應用程式工作小組 (<span lang="en">Accessible Rich Internet Applications Working Group, ARIA WG</span>)</li>
<li>親和力檢測工具規則社群小組 (<span lang="en">ACT Rules Community Group, ACT-R</span>)</li>
<li>階層樣式表工作小組 (<span lang="en">Cascading Style Sheets Working Group, CSS WG</span>)</li>
<li>開放使用者介面社群小組 (<span lang="en">Open UI Community Group, Open UI</span>)</li>
</ul>

<h3>參與 W3C</h3>

<p>設計制度總顧問跟我的「參與 <abbr title="全球資訊網協會">W3C</abbr>」，指的是實際出席小組線上會議、認領及執行小組工作項目、在 <abbr title="全球資訊網協會">W3C</abbr> 的 GitHub 儲存庫 (<span lang="en">repository, repo</span>) 直接提出文件修訂意見或討論、透過郵遞論壇提出意見及討論或投票等。我們這麼做的理由其實很簡單：因為我們遇到的挑戰，別人也會遇到；我們的使用需求，可以藉由眾人之力得到普遍支持的解決方案。舉例來說，如果我們總是在用複雜的方法來製作「可展開的彈出式資訊提示」，那麼透過網頁標準的討論，論述這個使用方式的需求，倡議可行的技術規格，讓所有主流瀏覽器都願意支援用簡單乾淨的語法格式達到相同效果，遠比疊床架屋地維護複雜的網頁開發框架更合理也更有效。</p>

<p>尤其是在跟政治、法律有關的技術議題更是如此，每次線上會議我都會看到<u>美國</u>聯邦政府或<u>歐盟</u>國家的文官積極參與，因為這些工作最終的結果可以成為國際標準，而各國的國內法都將直接引用這些國際標準&#x2E3A;換句話說，如果各國政府有需要在國際標準裡解決的實際狀況，或者需要國際標準涵蓋哪些國內法需要的面向，都會直接把議題帶進相關小組操作。</p>

<p>這種實質參與對於<u>台灣</u>的政府文官來說幾乎不可能，光是線上會議時間通常在台灣時區的半夜，就是偌大的阻力。另一個挑戰是文官長久以來被訓練成要揣摩上意才能生存，即使是在 <abbr title="全球資訊網協會">W3C</abbr> 這種「以個人身分（不是代表整個會員組織的身分）表達及參與討論」的團體裡，想要在郵遞論壇裡表示支持增刪標點符號的語句編輯修訂前，<u>台灣</u>的文官需要先寫一份簽呈，一路往上級用印批准之後，才敢回信寫出「<samp>+1</samp>」兩個字。</p>

<p>有些政府機關乾脆在資訊業務委外服務案裡，要求承商每個月翻譯、整理某些 <abbr title="全球資訊網協會">W3C</abbr> 工作小組的公開會議記錄，寫成月報就當成「參與成果」；也有一些文官秉持著自己單位才是主管機關的態度，「應該是別人要來遵守、配合我們的規範才對」，「我們寫的這些文字都簽到上面發布實施了，哪裡有什麼好討論的」，「那些別人訂出來的標準，我們有行政裁量權下的解釋空間」，認為完全沒必要去參與或討論。這些都是我實際聽過的話語，我年輕的時候可能會覺得是單純的傲慢，現在則可以看懂：文官的利益跟國家利益並未對齊。</p>

<p><abbr title="數位發展部">數發部</abbr>有個相當領先的數位憑證皮夾（分散式識別符，<span lang="en">Decentralized Identifier, DID</span>），是政府公務體系內相當罕見積極參與 <abbr title="全球資訊網協會">W3C</abbr> 工作小組及網頁標準的實例，正是因為曾經有位制度工程師為了信念而奉獻犧牲，常態熬夜上線開會參與，加上長官同樣支持而願意變通出勤規則，才能把網頁標準變成<u>台灣</u>想要的樣子。這在<u>台灣</u>是極其可貴的罕見特例。</p>

<p>設計制度總顧問跟我都不是政府文官，沒有這些麻煩事，而能夠實質參與。我們利用<abbr title="全球資訊網協會">W3C</abbr> 帶來的機會，讓我們這套新的設計制度能夠對<u>台灣</u>也對世界有實質幫助。</p>

<hr />

<p><strong>因為篇幅過長，本文拆成上、中、下三篇。</strong>接下來關於公務體系面臨的挑戰，請繼續閱讀<a href="https://jedi.org/blog/archives/006460.html" title="為什麼台灣的數位親和力之路至少耗時兩百年（下）| Jedi's BLOG">下篇</a>。</p>]]>
      </description>
      <guid isPermaLink="false">6459@https://jedi.org/blog/</guid>
      <dc:subject>typing</dc:subject>
      <dc:date>2026-01-26T16:38:23+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>為什麼台灣的數位親和力之路至少耗時兩百年（上）</title>
      <link>https://jedi.org/blog/archives/006458.html</link>
      <description>
        <![CDATA[<p><cite>報導者</cite>在<time datetime="2025-12-08">去年十二月上旬</time>有一系列兩篇報導：<cite><a href="https://www.twreporter.org/a/digital-accessibility-for-people-with-vision-impairment-1" title="看不見的他們，與他們未被看見的需求&#x2E3A;人人可用的數位服務如何打造？ | 報導者 The Reporter">看不見的他們，與他們未被看見的需求&#x2E3A;人人可用的數位服務如何打造？</a></cite>和<cite><a href="https://www.twreporter.org/a/digital-accessibility-for-people-with-vision-impairment-2" title="發包採購只能硬背系統畫面？政府與學校聘僱視障者，卻未普及數位無障礙 | 報導者 The Reporter">發包採購只能硬背系統畫面？政府與學校聘僱視障者，卻未普及數位無障礙</a></cite>（以下分別簡稱<cite><abbr title="看不見的他們，與他們未被看見的需求&#x2E3A;人人可用的數位服務如何打造？">未被看見</abbr></cite>及<cite><abbr title="發包採購只能硬背系統畫面？政府與學校聘僱視障者，卻未普及數位無障礙">只能硬背</abbr></cite>），採訪引用我的說法，系列第二篇報導<cite><abbr title="發包採購只能硬背系統畫面？政府與學校聘僱視障者，卻未普及數位無障礙">只能硬背</abbr></cite>最後引用我說<q>（台灣的數位親和力要能夠做好，還要）大約 100～200 年〔……〕需要幾個世代的成長。這件事沒辦法透過任何法規、指引或制度，一夕之間改變</q>。我不是這兩篇報導的主要受訪人，只是個側面旁徵的對象；在這兩篇報導的脈絡中，我那段話做為結尾顯得有些突兀，沒有辦法交代清楚。</p>

<p>其實我以往都講「一百年」，然而近年的工作經驗讓我體會到先前太樂觀，考慮諸多脈絡交織，而後修正成兩百年。我（從<time datetime="1997"> 1997 年</time>）踏入親和力領域已經將近 30 年，現在也許時機正好，可以用一些篇幅講講「兩百年」背後承載的故事，特別是回顧我<time datetime="2023"> 2023 年</time>起在 <a href="https://pdis.nat.gov.tw" title="行政院公共數位創新空間">PDIS（行政院公共數位創新空間，<span lang="en">Public Digital Innovation Space</span>）</a>的工作。</p>]]>
        <![CDATA[<h2>內容目錄</h2>
<ul>
  <li><a href="#ableism_h">能力歧視主義（健全主義）</a><ul>
    <li><a href="#eugenics_law_h">優生保健法</a></li>
    <li><a href="#discrimination_type_h">微歧視的型態</a></li>
    <li><a href="#legally_discrimination_h">合法歧視</a></li>
  </ul></li>
  <li><a href="#person_with_disabilities_h">誰是身心障礙者</a><ul>
    <li><a href="#population_h">身心障礙者人口統計</a></li>
    <li><a href="#classification_h">身心障礙分類系統</a></li>
    <li><a href="#reverse_ableism_h">反向健全主義</a></li>
    <li><a href="#:::_h">網頁導盲磚</a></li>
    <li><a href="#territories_h">各方山頭</a></li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006459.html#government_h">公務體系及主管機關</a>（中篇）</li>
  <li><a href="https://jedi.org/blog/archives/006459.html#pdis_h">PDIS 與數位韌性</a>（中篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006459.html#design_systems_h">設計制度</a>（中篇）</li>
    <li><a href="https://jedi.org/blog/archives/006459.html#w3c_h">參與 W3C</a>（中篇）</li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006460.html#component_libraries_h">元件庫</a>（下篇）</li>
  <li><a href="https://jedi.org/blog/archives/006460.html#outsourcing_h">業務委外</a>（下篇）<ul>
    <li><a href="https://jedi.org/blog/archives/006460.html#rfp_h">標案需求規格</a>（下篇）</li>
    <li><a href="https://jedi.org/blog/archives/006460.html#gov_website_h">薛丁格的政府網站</a>（下篇）</li>
  </ul></li>
  <li><a href="https://jedi.org/blog/archives/006460.html#digital_documents_h">數位文件</a>（下篇）</li>
  <li><a href="https://jedi.org/blog/archives/006460.html#badge_statement_h">無障礙標章及親和力宣告</a>（下篇）</li>
  <li><a href="https://jedi.org/blog/archives/006460.html#reality_h">政治的現實</a>（下篇）</li>
  <li>後記<ul>
    <li>其一：<a href="https://jedi.org/blog/archives/006461.html" title="核心價值與選擇 | Jedi's BLOG">核心價值與選擇</a></li>
    <li>其二：<a href="https://jedi.org/blog/archives/006462.html" title="世代交替 | Jedi's BLOG">世代交替</a></li>
  </ul></li>
</ul>

<h2>能力歧視主義（健全主義）</h2>

<p>一切的根本，源自<u>台灣</u>社會文化（至少<time datetime="2025">此刻</time>仍然）根深蒂固的健全主義。「<dfn>健全主義 (<span lang="en">ableism</span>)</dfn>」或譯為「<dfn>能力主義</dfn>」，是一種「認為身心健全者（能力者）比身心障礙者（失能者）更為主流且優越」的社會性偏見，而對身心障礙者的系統性歧視；健全主義最具代表性的表現，是起源於十九世紀後期、興盛於二十世紀前期的優生學 (<span lang="en">eugenics</span>) 實踐，例如<u>美國</u>最高法院於<time datetime="1927"> 1927 年</time>判決的<cite>巴克訴貝爾案</cite>（<span lang="en">Buck v. Bell, 274 U.S. 200</span>)、<u>納粹德國</u>於<time datetime="1933"> 1933 年</time>制定的<cite>遺傳病病患後代防止法</cite> (<span lang="de">Gesetz zur Verhütung erbkranken Nachwuchses</span>)、<u>日本</u>於<time datetime="1948"> 1948 年</time>制定的<cite>舊優生保護法</cite>〔<span lang="ja">法律第百五十六号（昭二三・七・一三）優生保護法</span>〕等。</p>

<p><dfn>優生學</dfn>指的是以人為手段來提高人口素質的研究領域，倫理上最具爭議的環節在於「人口素質」要怎麼定義、由誰定義。在二十世紀歷經多次人口清洗及種族屠殺滅絕的慘痛經驗後，許多國家把優生學視為帶有污名的邊緣科學 (<span lang="en">fringe science</span>)；<u>美國</u>最高法院於<time datetime="1942"> 1942 年</time>判決的<cite>史金納訴奧克拉荷馬州案</cite> (<span lang="en">Skinner v. State of Oklahoma, ex rel. Williamson, 316 U.S. 535</span>) 部分推翻<cite>巴克訴貝爾案</cite>，<u>德國</u>聯邦議院最終在<time datetime="2007"> 2007 年</time>宣告<cite>遺傳病病患後代防止法</cite>的設計及其應用都是國家社會主義的不公正，<u>日本</u>於<time datetime="1996"> 1996 年</time>刪除<cite>舊優生保護法</cite>各項涉及優生學的條文後改訂為<cite>母體保護法</cite>（<span lang="ja">母体保護法</span>）。</p>

<h3>優生保健法</h3>

<p><u>台灣</u>在<time datetime="1984"> 1984 年</time>制定實施<cite>優生保健法</cite>，現行條文<a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=L0070001&amp;flno=1" title="優生保健法 &#167;1 | 全國法規資料庫">第一條</a>第一項毫不諱言立法目的包括<q>提高人口素質</q>，<a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=L0070001&amp;flno=11" title="優生保健法 &#167;11 | 全國法規資料庫">第十一條</a>第一項更要求<q>醫師發現患有礙優生之遺傳性、傳染性疾病或精神疾病〔……〕無法治愈者，認為有施行結紮手術之必要時，應勸其施行結紮手術</q>，前述所謂「有礙優生者」的範圍依同法<a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=L0070001&amp;flno=11" title="優生保健法 &#167;15 | 全國法規資料庫">第十五條</a>以<cite>優生保健法施行細則</cite><a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=L0070002&amp;flno=10" title="優生保健法施行細則 &#167;10 | 全國法規資料庫">第十條</a>訂定，包括第一項第二款<q>無能力照顧嬰兒者</q>、第三款<q>可將異常染色體或基因傳至後代者</q>，儘管不是強制性的結紮節育，毫無疑問仍然是<a href="#ableism">健全主義</a>的<a href="#eugenics">優生學</a>那種「低劣的人不要追求那種生活比較好」、「同樣低劣的後代乾脆不要出生比較好」偏差觀點的歧視。</p>

<p>這裡需要稍微多做解釋：<em>婚前健康檢查、產前健康檢查等照護或公共衛生措施本身並非歧視，也不必然落入能力歧視主義的優生學</em>，歧視往往發生在「檢查什麼項目」、「如何處置檢查結果」等環節；「不歧視」的平等處置重點在於協助準新人或孕婦（及其家庭組成）理解、準備、克服未來可能發生的養育挑戰，協助新生兒從出生起就能盡量不受到環境及體制可能造成的障礙所侷限。當然，孕婦本人的生產或不生產意願是另一個議題，應確保孕婦本人能夠充分知情，並盡量支持孕婦在不受脅迫干涉下的自由決定，這點還請勿混淆討論。</p>

<p>華語的「健全」、「能力」、「優生」都是帶有正面語感的詞彙，受指責「健全主義」、「推行優生學」的人搞不好還沾沾自喜，因此我自己更傾向使用容易領會的「<dfn>能力歧視主義</dfn>」，表示是種憑著身心能力而歧視他人的系統結構。不過嘛，能力歧視主義的信徒多半自認公平公正，對「歧視」這個詞相當反彈，無法接受自己確實歧視身心障礙者而強烈否認；當然，部分原因是許多人對於歧視的樣態極度缺乏警覺，誤以為只有屠殺、強迫絕育、肢體攻擊、限制人身自由才算歧視。考慮到這個現實，我在那些想更聚焦的場合裡，也會用「健全主義」這個譯法。</p>

<h3>微歧視的型態</h3>

<p>大約從<time datetime="2010"> 2010 年</time>起，研究身心障礙領域的學者提出一種健全主義者的歧視型態：微歧視（原文 <span lang="en">microaggressions</span> 其實是措詞更強烈的「微侵犯」；不過也有學者把微歧視細分成微侵害、微侮辱、微忽視等三種分類，如果依字面翻譯成微侵犯可能會顯得太過狹義），其最早在<time datetime="2013"> 2013 年</time>的定義如下：</p>

<blockquote><p>針對身心障礙者的<dfn>微歧視</dfn>是一種隱性的健全主義表現，具體指的是那些在日常生活中有傷身心障礙者尊嚴的短暫卻很頻繁的言語、行為或環境資訊&#x2E3A;有意或無意地表達了對身心障礙者的敵意、貶低、輕視或侮辱。</p></blockquote>

<p>身心障礙領域學者將健全主義微歧視歸納出若干類型，我在 <abbr title="行政院公共數位創新空間">PDIS</abbr> 從事顧問服務的經驗中，很不幸地能夠親身驗證其中一些。</p>

<p>有一次我向幾位內政部文官說明「有障礙的公務資訊系統，在過去曾經造成身心障礙公務員無法順利使用、執行業務，結果身心障礙者被『調整』去做跟專業職能毫不相關的事情，可能影響到<cite>憲法</cite><a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=A0000001&amp;flno=18" title="憲法 &#167;18 | 全國法規資料庫">第十八條</a>保障的<q>服公職</q>權利。」幾位文官對我的說明相當不以為然，反駁道「可以參加公職考試就已經受到保障了，能不能順利使用公務資訊系統對此沒有影響。」我接著說明「雖然可以參加並通過考試取得公職資格，但就職後卻被迫無法執行業務，造成『看似可以服公職，實際上卻不能』的現實。」幾位文官繼續否認，說道「每個人本來就都要想辦法把公務系統用好，這不是公務資訊系統的問題。」</p>

<p>我原本提出的狀況是第一種<dfn>否認身分</dfn>類型的微歧視（否認其他身分），即以身心功能弱勢來定義及對待身心障礙者，否認其同時具備的專業職能身分，未積極設法發揮其專業職能。接著幾位文官的第一波反駁則形成<dfn>次等公民</dfn>類型的微歧視，把身心障礙者的基本權益排在其他人之後；容我改寫<u>喬治</u>·<u>歐威爾</u><cite>動物農莊</cite>那諷刺的戒律，這類型的微歧視即指「所有人一律平等，但身心健全人比其他人更加平等。」幾位文官的第二波反駁則是第二種<dfn>否認身分</dfn>類型的微歧視（身心障礙者的主觀感受不被理解、反被否認），即否認身心障礙者切身經歷的障礙，甚至認為身心障礙者有別於身心健全者的需求是常理之外的、徒增負擔的累贅。</p>

<p>後來在另一個機會場合，我向幾位數位發展部（以下簡稱數發部）文官說明同一件事，幾位文官不解地提出「資訊系統不用做什麼處理啊，我們在身心障礙者的電腦螢幕套上一個放大鏡就好了。」這般自以為是地認為自己理解關於身心障礙的經驗，已經不只是否認身分類型的微歧視，而是對身心障礙嚴重缺乏覺識，對於身心障礙的型態譜系渾然不知，錯誤地認為「身心障礙者」只有一個面貌、遭遇同一種挫折。前述這種想法，完全符合能力歧視主義者的典型論述。</p>

<p>在最近一份數位發展部委託執行的 <cite><time datetime="2024">113 年</time>身心障礙者數位近用現況與需求調查報告</cite>中，撰寫人以能力歧視主義觀點，把身心障礙者數位參與不足歸因於「身體條件限制」及「身心能力限制」：</p>

<blockquote><p>最新調查結果顯示，身心障礙者家戶連網率低於八成，個人上網率低於五成五且三年未見提升，即便是已上網，網路應用多元性也不如一般民眾。究其原因可能與臺灣人口年齡結構迅速老化有關，許多高齡者或重度身障者因身體條件限制無法操作數位設備，或因年齡過大或過小而缺乏學習動機與能力，導致數位參與不足。</p></blockquote>

<p>至於是否<u>台灣</u>的數位服務普遍歧視身心障礙者而造成參與侷限，在這份調查報告裡完全沒有分析討論。延續能力歧視主義觀點，調查報告提出的對應「建議」也顯現出「次等公民」類型微歧視：</p>

<blockquote><p>在數位政府服務方面，身心障礙者因生理功能受限，在獲取網路資訊時或許需要藉助特殊網頁設計的協助。調查發現，曾使用政府機關網站或 APP 的身心障礙網路族，最常遇到的問題為找不到內容及網頁內容或選項標示不清，因此建議政府機關網頁或 APP 能夠加強內容指引、標示清晰，並輔以強化語音溝通、大字體與內容簡化等友善設計的建議，應有助於使用者能更輕鬆地操作及截取〔擷取〕訊息。</p></blockquote>

<p>對於任何網站、網頁、行動應用程式 (<span lang="en">App</span>)，<q>找不到內容</q>或<q>網頁內容或選項標示不清</q>等情況，代表根本連基礎功能都沒做好、內容策略嚴重出錯，絕對不是<q>需要特殊網頁的協助</q>。<strong>這些需求絲毫不特殊，都是正常、普通的核心使用需求。</strong>從資訊產品的使用者測試角度來分析，明明是「使用者反應出設計上的疏失」，調查報告卻以使用者的身分（身心障礙者）而將其排除在常理之外，簡直成為促成障礙的推手。</p>

<p>我還記得在<time datetime="2023"> 2023 年</time>（也算是近年內）去輔導某縣市地方政府，在其官方網站英文版網頁赫然看到該府把<q>聽語障</q>翻譯為 <q lang="en">deaf-and-dumb</q> 這個極具歧視性的字眼，經過我提出後，府內文官才急忙修正；都到了<time datetime="2020">二十一世紀的 20 </time>年代還發生這種政治災難等級的情況，顯現該府文官對於身心障礙議題的敏感度相當低落。</p>

<h3>合法歧視</h3>

<p><time datetime="2025-12-18">去年底</time>行政院<a href="https://www.ey.gov.tw/Page/9277F759E41CCD91/6ad4b44c-3015-4325-9533-5deeb444fed7" title="政院通過「身心障礙者權益保障法」部分條文修正草案 落實身心障礙者權利公約 強化身心障礙者保護機制 (行政院全球資訊網-本院一般新聞)">通過<cite>身心障礙者權益保障法</cite>（以下簡稱<cite>身權法</cite>）部分條文修正草案</a>送交立法院，修正條文新增第十條之一：<q>機關（構）、學校、事業機構、法人或團體於訂定影響身心障礙者權益之政策、法規或規章時，應提供身心障礙者可近用之資訊及表示意見之機會。</q>在能力歧視主義，尤其是次等公民類型微歧視的現實之下，立意良善的這一條條文草案存在著根本性的大漏洞：<em>由誰如何決定哪些政策、法規、規章會影響身心障礙者？</em></p>

<p>舉例來說，<cite>資通安全管理法</cite>、其子法<cite>資通安全管理法施行細則</cite>、因應前述法規提供的<cite>資通安全維護計畫範本</cite>等，絕對會影響身心障礙者權益；這一點在 <cite lang="en">ISO/IEC 40500:2025</cite> 國際標準第 5.7 小節，以及聯合國開發計劃署<cite>通用數位公共基礎建設安全框架 (<a href="https://www.dpi-safeguards.org" title="UN Universal Safeguards for Inclusive Digital Public Infrastructure" lang="en">The Universal Digital Public Infrastructure Safeguards Framework</a>)</cite> 等具指標性的國際文件均有諸多著墨。然而主管前述法規的<abbr title="數位發展部">數發部</abbr>資通安全署是否認為這些法規適用<cite><abbr title="身心障礙者權益保障法">身權法</abbr></cite>修正草案第十條之一，而應提供身心障礙者可近用之資訊及表示意見之機會？</p>

<p>換個方向來思考，<strong>任何會影響到人的法規，怎麼可能不影響身心障礙者？</strong>然而過去曾有<abbr title="數位發展部">數發部</abbr>高階文官在會議中私下表示「更優先關注於如何確保（少）部分人持續可以使用民生關鍵資訊系統，而不是盡可能讓所有民眾都可以使用」，很難讓人有信心這<cite><abbr title="身心障礙者權益保障法">身權法</abbr></cite>第十條之一可以發揮出多少力量。</p>

<p>我並不是在指責特定文官，也不是要指責特定的政府機關，更不是要反對特定的法律條文；上述這些能力歧視的情況相當常見，遍及各個層級及機關體系，以及民間各種營利或非營利團體，超越政黨派系與族群。</p>

<p>能力歧視主義下的<u>台灣</u>社會文化，產生許多詭異的情況，例如只有依<cite><abbr title="身心障礙者權益保障法">身權法</abbr></cite><a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=D0050046&amp;flno=5" title="身心障礙者權益保障法 &#167;5 | 全國法規資料庫">第五條</a><q>領有身心障礙證明者</q>（所謂<dfn>法定身心障礙者</dfn>），才能「享受」到同法<a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=D0050046&amp;flno=16" title="身心障礙者權益保障法 &#167;16 | 全國法規資料庫">第十六條</a>各項關於公平及不歧視的保障；換句話說，任何人如果未領有身心障礙證明、不是「法定身心障礙者」，這個人因身心功能而受到歧視、無法公平參與社會，竟然是一件<u>台灣</u>現行法律可以接受的情況。</p>

<p>在<u>台灣</u>，有兩個領域對上述這個法律情況稍微做出調整。教育部依<cite>特殊教育法</cite>訂定實施<cite>特殊教育學生及幼兒鑑定辦法</cite>（以下簡稱<cite>特教生鑑定辦法</cite>），實務上有許多無法取得法定身心障礙者資格的學生，能夠依<cite><abbr title="特殊教育學生及幼兒鑑定辦法">特教生鑑定辦法</abbr></cite>取得<dfn>法定特殊教育學生及幼兒</dfn>資格，從而「享受」教育部主管業務範圍內的平等及不歧視權益。</p>

<p>勞動部在<time datetime="2017-04-10"> 2017 年</time>對<cite>就業服務法</cite><a href="https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=N0090001&amp;flno=5" title="就業服務法 &#167;5 | 全國法規資料庫">第五條</a>第一項提出函釋說明：<q>放寬身心障礙就業歧視之「申訴」資格</q>，不限於已取得身心障礙證明者。另一方面，勞動部勞動力發展署<cite>推動職務再設計服務計畫</cite>多年來逐步擴大適用對象，除了法定身心障礙者，目前還包括中高齡及高齡者、經診斷為失智症者、經診斷為精神疾病者、符合聽力閾值條件之單側聽損及非對稱聽損者、具法定特殊教育學生資格者等。</p>

<p><u>台灣</u>現行<cite>身心障礙者鑑定作業辦法</cite>、<cite><abbr title="特殊教育學生及幼兒鑑定辦法">特教生鑑定辦法</abbr></cite>、<cite>推動職務再設計服務計畫</cite>有個共通點：主要依據醫學診斷（年齡可視為依照出生證明書所做的推論）判定是否具備適用對象資格。這就帶出了接下來的問題：誰是身心障礙者？</p>

<h2>誰是身心障礙者</h2>

<p>主要根據醫學診斷來「鑑定」身心障礙者資格的方法，稱為<dfn>生物醫學模式</dfn>，這是<a href="ableism">健全主義</a>的標準起手式：設想一個完美的「健全人」形象，塑造一個可以輕易推翻或忽視其他視角的權威意見，運用量化統計的敘述，去評判一個人的解剖構造或生理功能有多像或多不像健全人。</p>

<p>任何身心障礙者資格的「鑑定」方法，都有個對應的「基準」，這個基準如何設立，往往跟整個社會文化及法律架構如何對待身心障礙者有關。<a href="ableism">健全主義</a>社會通常著重在「福利資源」的考量，認為：身心障礙者必然是等著被拯救的對象（<dfn>無助性假設</dfn>類型的<a href="#microaggressions">微歧視</a>），健全人（階級）以展現自身的寬裕及包容為內在目的（<dfn>間接獲益</dfn>類型的<a href="#microaggressions">微歧視</a>），在「行有餘力」的前提下（次等公民類型的<a href="#microaggressions">微歧視</a>），發放以財貨為主的資源，或有限度地提供透過財貨驅動的「例外服務措施」，稱為<dfn>慈善模式</dfn>。慈善模式並非利他，此處<em>切勿誤解</em>成「反對健全主義是在鼓吹利己」；實際上，慈善模式隱含間接獲益類型<a href="#microaggressions">微歧視</a>，恰恰說明了慈善模式的幽微深處乃是利己的展現。</p>

<p>架構於<a href="#charity">慈善模式</a>的<a href="#biomed">生物醫學模式</a>，合稱<dfn>慈善／生物醫學模式</dfn>，是<u>台灣</u>目前看待身心障礙者的主要架構。<u>台灣</u>政府在這個架構中，經常考量著「（『額外』提供的）福利資源會佔用多少政府年度預算額度」來調整「鑑定基準」；舉例來說，從<time datetime="2012"> 2012 年</time>起實施的<a href="https://jedi.org/blog/archives/006115.html" title="TCF 新制身心障礙鑑定&#x2E3A;聽覺功能障礙試算表 | Jedi's BLOG">聽覺功能障礙鑑定基準</a>，係由耳鼻喉科醫師建議修改美國醫學會、美國耳鼻喉科學協會<strong>用於鑑定保險理賠金額</strong>的計算公式而來，意味著把身心障礙者的身分視為一種保險理賠的討價還價來處理。</p>

<p>在<cite>國際審查委員會（IRC） 2022 年 8 月 6 日就中華民國（臺灣）施行身心障礙者權利公約（CRPD）第二次國家報告結論性意見</cite>（以下簡稱 <cite>CRPD 第二次國際審查意見</cite>）第 18 點，國際審查委員措詞嚴厲地表示：<q>國際審查委員會對政府依然採取慈善／生物醫學模式作為看待身心障礙者的主要架構感到失望。</q></p>

<h3>身心障礙者人口統計</h3>

<p><u>台灣</u>政府持續採用慈善／生物醫學模式數十年，已經造成許多嚴重的後果。首先是造成政府自己長期嚴重<a href="https://jedi.org/blog/archives/006348.html" title="台灣的身心障礙者人口比例 | Jedi's BLOG">低估身心障礙者人口</a>，進一步強化<u>台灣</u>政府以「健全國民」為本位的政策規劃慣性，徹底忽略國民身心功能的多樣性及變化，輕視科技的演變，無視環境及情境可能造成的巨大差異，往往導致資源錯置，許多政績徒有帳面上的增長或只能累積價值有待商榷的物質；這種規劃慣性又增強<a href="#ableism">健全主義</a>的影響力，形成恐怖的惡性循環，使得能力歧視難以根除。</p>

<p>國際審查委員在<cite><abbr title="國際審查委員會（IRC） 2022 年 8 月 6 日就中華民國（臺灣）施行身心障礙者權利公約（CRPD）第二次國家報告結論性意見">CRPD 第二次國際審查意見</abbr></cite>第 109 點 b 項相當委婉地詰問：<q>報告的數據顯示 5.03% 人口有身心障礙，這一數據遠低於其他國家，也低於世界衛生組織 2011 年全球障礙者處境報告所提到至少 15% 的人口為身心障礙者。國際審查委員會尚未收到這種差異的解釋。</q>國際審查委員其實是客氣地指出<u>台灣</u>政府這種<a href="#ableism">健全主義</a>式的身心障礙者認定方式（慈善／生物醫學模式的鑑定基準）有問題，因此接著在第 110 點 c 項建議<u>台灣</u>政府：<q>建構一套直接而簡單的方法來準確辨別身心障礙者。</q></p>

<p>可惜<u>台灣</u>政府忽略上述意見的內涵，曲解建議事項的目的，截至<time datetime="2025-04-30"> 2025 年四月三十日</time>止的<cite>落實身心障礙者權利公約結論性意見之行動回應表辦理情形</cite>中，看不到負責的主管機關及對應的行動管考。國際審查委員到底建議什麼方法？其他<cite>身心障礙者權利公約</cite>締約國實務上都是在進行人口普查（不論是全面普查或抽樣調查後推估）時，<em>直接詢問人民的障礙經驗及感受</em>，以此來「準確辨別身心障礙者」，直接而簡單。國際審查委員指的就只是如此。</p>

<h3>身心障礙分類系統</h3>

<p>當然這並非要求<em>僅</em>詢問「您是否為身心障礙者？」（這個問法問到的是關於身心障礙者的身分認同，而不是障礙與否）。世界衛生組織在<cite>國際健康功能與身心障礙分類系統</cite>（<span lang="en">International Classification of Functioning, Disability and Health; ICF，以下簡稱 <cite>ICF</cite>）附錄五當中強調：<q><abbr title="國際健康功能與身心障礙分類系統">ICF</abbr> 完全不是用於人口分類的工具，而是用於「人的健康特質在個別生活情境及環境影響脈絡之中」的分類工具</q>，因為<q>身心障礙乃是由健康特質與情境因素交互作用所產生。</q>舉例來說，美國公平就業機會委員會曾<a href="https://www.eeoc.gov/laws/guidance/deafness-and-hearing-impairments-workplace-and-americans-disabilities-act" title="Deafness and Hearing Impairments in the Workplace and the Americans with Disabilities Act | U.S. Equal Employment Opportunity Commission">具文說明</a>：就算某個人聽力完全正常，但是如果「雇主認為這個人有聽力損傷，因而拒絕雇用或終止任用」，這個情況下，這個聽力正常者就會被視為聽覺功能障礙者，雇主因歧視身心障礙者而違法。</span></p>

<p>換句話說，應詢問在主要的各活動領域中，是否發生活動限制或參與侷限？發生的頻率或程度如何？與哪些環境因素或身體功能、構造相關？藉由這種方式來辨別身心障礙，稱為<dfn>生物心理社會模式</dfn> (<span lang="en">Biopsychosocial model</span>)，是世界衛生組織在 <cite><abbr title="國際健康功能與身心障礙分類系統">ICF</abbr></cite> 採用的模式，符合<cite>身心障礙者權利公約</cite>前言第⒠點所指<q>身心障礙是功能損傷者與阻礙他們在與其他人平等基礎上完整及切實地參與社會之各種態度及環境障礙相互作用所產生之結果</q>。</p>

<p><u>台灣</u>從<time datetime="2024-07-01"> 2024 年七月一日</time>起，法定身心障礙者的綜合障礙等級會依「鑑定」的活動參與及環境因素等級而有所增減，衛生福利部（以下簡稱衛福部）因此在<cite>落實身心障礙者權利公約結論性意見之行動回應表辦理情形</cite>主張已經完成<cite><abbr title="國際審查委員會（IRC） 2022 年 8 月 6 日就中華民國（臺灣）施行身心障礙者權利公約（CRPD）第二次國家報告結論性意見">CRPD 第二次國際審查意見</abbr></cite>第 37 點 a 項（<q>修正 2021 身心障礙者權益保障法草案，確保其更準確地反映 CRPD 第 1 條中對身心障礙者的定義。</q>）而解除管考追蹤。然而上述日期後實施的<cite>身心障礙者鑑定作業辦法</cite>，依舊是個先採用<a href="#biomed">生物醫學模式</a>判定具備法定身心障礙者資格後，才得以酌調綜合障礙等級的制度；如前所述，以生物醫學的意見為權威，可以輕易推翻或忽視其他視角，這是<a href="#ableism">健全主義</a>的實踐，並不符合<cite>身心障礙者權利公約</cite>的定義。</p>

<p><abbr title="衛生福利部">衛福部</abbr>緊抱著<a href="#biomed">生物醫學模式</a>不放，關鍵原因出在同樣擺脫不掉的<a href="#charity">慈善模式</a>，無法區分權益跟福利，或者更糟糕地把所有權益都當成福利，「為了避免有心人詐騙獲得其不應擁有的『額外福利』，一定要用數值化的、可鑑別假詐的醫療診斷方式來做為必要條件」。法律名稱花了將近一個世代（三十年），才從<time datetime="1980"> 1980 年</time>的<cite>殘障福利法</cite>演變到<time datetime="2007"> 2007 年</time>的<cite>身心障礙者權益保障法</cite>，法律內涵真正理解身心障礙的典範轉移之路還很遙遠。<time datetime="2026-01">今年初</time>立法院法制局<cite>身心障礙者權益保障法部分條文修正草案評估報告</cite>明確建議立法委員<q>基於障礙立法中福利基礎與權利基礎之觀點差異，〔……〕建議明定權益與福利關係</q>，<q>涉及權益與福利關係之條文，建議規定時仍宜予以區隔，以凸顯權益與福利二者關係之不同</q>，正好呼應了我上述觀點。</p>

<h3>反向健全主義</h3>

<p>持續採用慈善／生物醫學模式數十年的另一個嚴重後果，是造成身心障礙者逐漸看低及物化自己，誤以為存活的競爭力在於極力爭取施捨及照顧，甚至甘願犧牲隱私等基本權利及自由。因為「慈善施捨」殘酷地限量，容易減少很難增加，促使<a href="#ableism">健全主義</a>下的法定身心障礙者建構出<dfn>反向健全主義</dfn>：設想一個受盡磨難、令人同情的「障礙者」形象，去評判一個人的解剖構造或生理功能有多像或多不像障礙者。</p>

<p><a href="#reverse_ableism">反向健全主義</a>實際上在強化<a href="#ableism">健全主義</a>那套「身心障礙者就要有身心障礙者的樣子」的能力歧視觀點。法定身心障礙者期待更多願意施捨的健全人，同時又對「企圖加入身心障礙者行列」的非健全人感到戒慎，餅要大、分餅的人不能多；何況「若身心障礙者團體人數增長太多，就不像弱勢族群」了。我在<time datetime="2020"> 2020 年</time>出席教育部召開的研商會議，親耳聽聞法定聽覺功能障礙者團體強烈反對<cite><abbr title="特殊教育學生及幼兒鑑定辦法">特教生鑑定辦法</abbr></cite>基準多納入對華語語音很重要的聆聽頻率閾值，理由正是<q>會侵佔現有（法定）身心障礙者團體的資源。</q></p>

<p>同類功能障礙者團體之間這般爭奪資源，不同類功能障礙者團體之間也如此。行政院研究發展考核委員會（以下簡稱研考會，已於<time datetime="2014"> 2014 年</time>合併改制為國家發展委員會，以下簡稱國發會）曾於<time datetime="2005"> 2005 年</time>參考全球資訊網協會 <cite lang="en">Web Content Accessibility Guidelines 1.0</cite> 制定<cite>無障礙網頁開發規範</cite>，以及使該規範產生法律效力的<cite>政府網站無障礙化作業規定</cite>。然而在前者（<cite><abbr title="無障礙網頁開發規範">開發規範</abbr></cite>）已完成而後者（<cite><abbr title="政府網站無障礙化作業規定">作業規定</abbr></cite>）尚在議論的階段，若干視覺功能障礙者團體主張：視覺功能障礙者是無障礙網頁的主要受益者，<cite><abbr title="政府網站無障礙化作業規定">作業規定</abbr></cite>應額外照顧視覺功能障礙者的使用便利，最後<cite><abbr title="政府網站無障礙化作業規定">作業規定</abbr></cite>硬生生地多出了<cite><abbr title="無障礙網頁開發規範">開發規範</abbr></cite>從未描述過的「A+ 等級」及該等級獨有的「導盲磚」。</p>

<h3>網頁導盲磚</h3>

<p><dfn>網頁導盲磚</dfn>是個很有問題的設計花樣 (<span lang="en">design pattern</span>)，因為它是以連續三個冒號 (<samp>:::</samp>) 組成的字符圖案 (<span lang="en"><abbr title="American Standard Code for Information Interchange">ASCII</abbr> art</span>)，增加學習障礙、閱讀障礙、前後脈絡理解障礙、視覺辨認障礙等障礙風險，全世界除了<u>台灣</u>以外任何地方都沒有這種設計；更精確地說，在<u>台灣</u>也只有經淡江大學盲生資源中心體系養成的視覺功能障礙者，才會學習使用這種設計。</p>

<p>全球資訊網協會在<time datetime="2008"> 2008 年</time>發布 <cite lang="en">Web Content Accessibility Guidelines (WCAG) 2.0</cite> 為正式的網頁推薦標準（幾年後亦通過成為 <cite lang="en">ISO/IEC 40500:2012</cite> 國際標準），包括對這類字符圖案提出明確的規範。<strong>二十多年來，綜觀<u>台灣</u>所有設置<a href="#:::">網頁導盲磚</a>的網頁，我沒有看過任何一個能符合 <cite lang="en"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.*</cite>／<cite lang="en">ISO/IEC 40500</cite> 國際標準規範。</strong></p>

<p>自從<time datetime="2008"> 2008 年</time>起，我輔導公部門網站親和力都建議直接設定 <em>AA</em> 等級為目標，因為依照<cite>政府網站無障礙化作業規定</cite>，AA 是唯一比 A+ 等級更高但又不必設置（問題很多的）<a href="#:::">網頁導盲磚</a>的等級，因而可以兼顧法遵需求與真正的網頁親和力。</p>

<p>註：<a href="#:::">網頁導盲磚</a>後來改稱「定位點」，這其實是個很容易造成混淆的說法。因為 <abbr title="HyperText Markup Language" lang="en">HTML</abbr> 網頁標準從一開始就有個錨點 (<a href="https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element" title="The a element | HTML Standard">a</a>) 元素，目前版本的標準中也有<a href="https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/" title="Landmarks Pattern | APG | WAI | W3C">地標定位</a>的設計，這兩者都跟前述的「定位點」不同。實際上，捨棄<a href="#:::">網頁導盲磚</a>而改用地標定位，才是目前最推薦、最符合各種網頁標準的做法，也有部分視覺功能障礙者團體明確支持採用這種方式。</p>

<p>我在<time datetime="2010"> 2010 年</time>到<time datetime="2016"> 2016 年</time>期間參與<u>台灣</u><cite>網站無障礙規範 2.0 版</cite>的準備工作，不出意料地，有位視覺功能障礙者團體代表提出增設<a href="#:::">網頁導盲磚</a>納入規範。我在會議上說明這個設計花樣容易滋生諸多障礙，團體代表當時發言回應：<q>雖然現在可能造成其他人的一些障礙，但是可以讓我們視障者用自己已經熟悉的方法來使用網頁，不必重新學習。</q></p>

<p><u>台灣</u>從<time datetime="2017"> 2017 年</time>起實施的<cite>網站無障礙規範</cite>及<cite>各級機關機構學校網站無障礙檢測及認證標章核發辦法</cite>再也沒有<a href="#:::">網頁導盲磚</a>，這段不堪的黑歷史似乎終於可以逐漸淡出退場；然而事與願違，<a href="#:::">網頁導盲磚</a>仍然充斥各公部門網站，屢見不鮮，連目前主管上述法規的<abbr title="數位發展部">數發部</abbr>網站，以及做為<cite><abbr title="網站無障礙規範">規範</abbr></cite>官方網站的「無障礙網路空間服務網」也不例外。</p>

<p><time datetime="2025">去年</time>某場會議上，有位擔任網頁無障礙檢測員的視覺功能障礙者，分享檢測經驗時說道：「即使網站設計並未違反<cite>網站無障礙規範</cite>，但因為網站沒有採用對視覺功能障礙者最方便的設計方式，就會把檢測結果判定為『不通過』。」</p>

<p>這些情況對身心障礙者整體而言很不利。有一群自稱「無障礙標章受害者」的資訊服務業廠商，提出的論點包括「台灣的網站無障礙標章不符合國際標準」，令人難以否認。無法守住這一點，接下來也很難扭轉「把網站無障礙標章當成對視覺功能障礙者的額外恩惠」的觀點，以及總是把網頁親和力視為「驗收前的點綴」的不合理常態。</p>

<h3>各方山頭</h3>

<p>在<a href="#abilism">健全主義</a>下，身心障礙者團體間彼此競爭資源及權力，這個情況盛行到甚至有個名稱：<dfn>弱弱相殘</dfn>。不同「障礙類別」的身心障礙者團體分別「佔領」不同領域範圍，彼此卻缺乏互相理解及溝通。舉例來說，<u>台灣</u>建築物無障礙勘檢領域主要由肢體功能障礙者團體關注，幾乎完全忽略聽覺功能障礙、心智功能障礙等面向；<u>台灣</u>網頁無障礙檢測領域主要由視覺功能障礙者團體關注，幾乎完全忽略聽覺功能障礙、心智功能障礙、平衡功能障礙等面向。</p>

<p><abbr title="衛生福利部">衛福部</abbr>社會及家庭署（以下簡稱社家署）於<time datetime="2022"> 2022 年</time>出版<cite>臺灣易讀參考指南</cite>，「易讀」在<u>台灣</u>是心智障礙者團體關注的領域，因此這份指南的內容主要也是由心智障礙者團體、服務心智障礙者的機構人員所完成。然而<cite>臺灣易讀參考指南</cite>從頭到尾都沒有提到：這是只考慮到平面印刷出版品的易讀參考指南（而且其中談到字體尺寸時還誤用字號單位，與出版業界不符），有許多指南內容並不完全適合數位出版品（電子書、網頁、數位資訊看板、LED 廣告看板等）的情境。</p>

<p>另一方面，全球資訊網協會 <cite lang="en"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2</cite> 推薦標準（即 <cite lang="en">ISO/IEC 40500</cite> 國際標準）早已包含許多易讀指引項目，適用各種數位科技及出版品，<u>歐盟</u>國、<u>美國</u>等國家均以此納入國家法律；雖然<u>台灣</u>參照國際標準的<cite>網站無障礙規範</cite>（目前由<abbr title="數位發展部">數發部</abbr>主管）僅適用於「網站」，至少在網站情境的易讀規範還是有效。</p>

<p>我在 <abbr title="行政院公共數位創新空間">PDIS</abbr> 從事顧問服務期間，<a href="https://gov.tw/ijh" title="《臺灣易讀參考指南》與 W3C 網頁標準之比較統整 | Google 文件">比較統整</a><cite>臺灣易讀參考指南</cite>與<cite>網站無障礙規範</cite>當時參照的 <cite lang="en"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.1</cite>，雖然多數內容大致概念相符，但在媒材特性、例外情況、判別基準、優先順序及重要程度等細節並未對齊貼合；尤其在字體尺寸相關的規範方面，<u>中</u><u>日</u><u>韓</u>語系跟<u>歐</u><u>美</u>語系無法以相同量化基準來判定，因而 <cite lang="en"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2</cite> (<cite lang="en">ISO/IEC 40500</cite>) 對<u>中</u><u>日</u><u>韓</u>語系文字沒有定下明確的基準&#x2E3A;問題是，<cite>網站無障礙規範</cite>也沒有對<u>台灣</u>華語定下基準。我認為這跟參與<cite>網站無障礙規範</cite>的身心障礙者團體代表多少有些關係：過半數主要成員幾乎沒有殘存視覺功能的情況下，數位內容的字體尺寸大小很難成為優先要處理的細項（註：<a href="https://jedi.org/blog/archives/006429.html" title="像素、點、其他長度單位，以及觸控目標尺寸（下篇）| Jedi's BLOG">觸控目標尺寸</a>也遇到相似的情況。）</p>

<p>我<time datetime="2024">前年</time>曾建議<abbr title="數位發展部">數發部</abbr>數位政府司（以下簡稱政府司）向衛生福利部<abbr title="衛生福利部">衛福部</abbr><abbr title="社會及家庭署">社家署</abbr>聯繫這項議題，私心期待一方面可以牽線促成公務體系的跨部會合作機會，一方面讓不同身心障礙者團體彼此體認到大家都在同一條路上。不過，就我理解及掌握到的情況，這項議題最後只有司署兩方的科級單位「在電話中描述<cite>臺灣易讀參考指南</cite>的共通性原則考量」，沒有再進一步深入，身心障礙者團體間也沒有因此產生交流。</p>

<p>其實在<time datetime="2024-01">同年一月</time>，<abbr title="數位發展部">數發部</abbr>數位國際司曾邀請行政院身心障礙者權益推動小組的成員召開會議，想要推進 <cite lang="en"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.1</cite> 官方授權翻譯版本的相關工作（註：到<time datetime="2025-12-31">去年底</time>為止，相關工作的進度仍然很有限），幾乎所有與會者都表示對 <cite lang="en"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr></cite> 內容很陌生，不知道要從何著手。</p>

<p>身心障礙者團體尚未產生綜效，政府機關間的橫向聯繫整合也不理想，兩方面都不是說改變就能改變的；除了縈繞各方的<a href="#ableism">健全主義</a>揮之不去，公務體系也有盤根錯節的「歷史共業」，相當不利於數位親和力。</p>

<hr />

<p><strong>因為篇幅過長，本文拆成上、中、下三篇。</strong>接下來關於公務體系文化脈絡，以及我們在 <abbr title="行政院公共數位創新空間">PDIS</abbr> 的努力，請繼續閱讀<a href="https://jedi.org/blog/archives/006459.html" title="為什麼台灣的數位親和力之路至少耗時兩百年（中）| Jedi's BLOG">中篇</a>。</p>]]>
      </description>
      <guid isPermaLink="false">6458@https://jedi.org/blog/</guid>
      <dc:subject>typing</dc:subject>
      <dc:date>2026-01-26T16:26:30+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>9,000</title>
      <link>https://jedi.org/blog/archives/006457.html</link>
      <description>
        <![CDATA[<p>最近體會到「下坡」不是在於能力的改變，而是在於周圍的流逝越來越快、越來越難煞停；前一刻還在稜線，下一瞬已沒入溪谷。頭上看得到的芎頂越來越小，除了還牽著的那隻手，已經無暇在意明日會如何。</p>

<p>牽著，已經足夠。</p>]]>
        
      </description>
      <guid isPermaLink="false">6457@https://jedi.org/blog/</guid>
      <dc:subject>kitchen</dc:subject>
      <dc:date>2026-01-21T18:32:42+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>NAL-NL3 助聽器處方公式</title>
      <link>https://jedi.org/blog/archives/006456.html</link>
      <description>
        <![CDATA[<p><img alt="MedRx Studio 實耳測量模組計算 NAL-NL3 處方目標之範例畫面" src="https://jedi.org/blog/archives/MedRx_Studio_NAL-NL3_REM.png" width="800" height="498"></img></p>

<p>自從<u>澳洲</u>國家聲學實驗室 (<span lang="en">National Acoustic Laboratories, NAL</span>) <time datetime="2024">去年</time>預告 <time datetime="2025">2025 年</time>即將推出新的非線性助聽器處方目標公式 <a href="https://www.nal.gov.au/nal_products/nal-nl3-the-next-generation-fitting-system/" title="NAL-NL3: The Next Generation Fitting System | NAL" lang="en">NAL-NL3</a>，我就一直很期待，尤其預告中還提到這一版採用模組化設計，除了「主要聆聽情境的處方目標」之外，還會單獨針對「特定聆聽情境」計算處方目標。</p>

<aside>
<p>這段期間還有個插曲：我在<time datetime="2024">去年</time>看到預告後，迫不及待地前往 <abbr title="National Acoustic Laboratories" lang="en">NAL</abbr> 網站，卻看到伺服器錯誤的訊息；幾經嘗試之後，發現只要是從<u>台灣</u>、<u>香港</u>、<u>澳門</u>、<u>中國</u>連線過去都是如此，透過虛擬私人網路服務繞道其他國家則可以順利連上。我在接下來幾個月不斷找跟<u>澳洲</u>那邊有聯繫的人幫忙，最後終於在<time datetime="2025-10">今年十月</time>解除相關限制，可以直接連上網站查詢相關資訊。</p>
</aside>]]>
        <![CDATA[<p><time datetime="2025-04">今年四月</time>有人來信表示目前 <abbr title="National Acoustic Laboratories" lang="en">NAL</abbr> 已經沒有線上銷售 <a href="https://jedi.org/blog/archives/006251.html" title="NAL-NL2 助聽器處方軟體介面 | Jedi's BLOG">NAL-NL2 處方軟體</a>，當時我想 NAL-NL3 應該不久就會推出。然而 NAL-NL3 處方軟體遲遲沒有出現，我開始覺得也許這一版走上 <a href="https://jedi.org/blog/archives/006271.html" title="DSL v4.1 助聽器處方軟體介面 | Jedi's BLOG">DSL 處方軟體</a>的後路，不再提供「單機版」軟體，而只授權給各種聽力儀器設備廠商運用。</p>

<p><time datetime="2025-11">今年十一月</time>，<a href="https://jedi.org/blog/archives/006307.html" title="助聽器公司不說的事：實耳測量 | Jedi's BLOG">實耳測量</a>儀器廠商 <a href="https://medrx-diagnostics.com/" title="MedRx Diagnostic and Hearing Instrument Fitting Technologies" lang="en">MedRx</a> 刊出<a href="https://medrx-diagnostics.com/blog/medrx-now-featuring-nal-nl3" title="MedRx adds NAL‑NL3 to REM &amp; HIT">實耳測量模組及助聽器分析模組增加 NAL-NL3 處方計算</a>的消息，是全世界第一個正式與 <abbr title="National Acoustic Laboratories" lang="en">NAL</abbr> 合作推出具備 NAL-NL3 處方目標計算功能的軟體。</p>

<p>任何人都可以免費下載 <a href="https://medrx-support.com/Studio/" title="MedRx Studio Downloads" lang="en">MedRx Studio</a> 軟體，從 1.3.2 版起即內建 NAL-NL3 處方計算；即使沒有實際的儀器，仍然可以在軟體中選擇 <samp lang="en">Simulated</samp> 以模擬模式來計算處方目標。除了新增的 NAL-NL3，以往常用的 NAL-NL2（<a href="https://jedi.org/blog/archives/006252.html" title="NAL-NL2.dll 檔案版本 | Jedi's BLOG">dll 檔案版本</a> 2.0.14.0）、DSL（<a href="https://jedi.org/blog/archives/006272.html" title="DSLmio.dll 檔案版本 | Jedi's BLOG">dll 檔案版本</a> 5.2.6）處方公式也都能運用。<br />
<img alt="MedRx Studio 選擇 REM 設備硬體對話窗，畫面中只呈現一個 Simulated 選項" src="https://jedi.org/blog/archives/MedRx_Studio_NAL-NL3_Hardware.png" width="510" height="376"></img></p>

<p>使用上，請務必先詳細閱讀 <a href="https://medrx-diagnostics.com/blog/your-nal-nl3-questions-answered" title="Your NAL-NL3 Questions Answered">NAL-NL3 常見問答集</a>。NAL-NL3 延續 NAL-NL2 的設計，<a href="https://jedi.org/blog/archives/006249.html" title="NAL-NL2 助聽器處方公式的魔鬼細節 | Jedi's BLOG">處方目標受到非常多因素影響</a>，包括助聽器配戴者的年齡、性別、配戴經驗、主要聆聽語言是否為聲調語言，以及助聽器本身的聲學特性及訊號處理特性等，都會改變處方目標，請務必確實輸入。</p>

<p>另外還要特別注意，<span lang="en">MedRx Studio</span> 軟體預設採用的音量單位是 <samp>EqSPL (dB)</samp> (<span lang="en">Transfer equivalent sound-pressure level in decibel</span>)，不適合用來搭配語音類型的測試音，也無法顯示語音頻譜；用滑鼠游標在 <samp>EqSPL (dB)</samp> 文字上點擊一下就可以切換成常用的 <samp>SPL (dB)</samp> 了。 </p>]]>
      </description>
      <guid isPermaLink="false">6456@https://jedi.org/blog/</guid>
      <dc:subject>occupation</dc:subject>
      <dc:date>2025-12-29T21:13:42+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>在台灣的 Auracast 的應用推廣設想</title>
      <link>https://jedi.org/blog/archives/006455.html</link>
      <description>
        <![CDATA[<p>前一陣子，有位聽力學界的教授來信討論「在台灣可以如何推廣 <a href="https://www.bluetooth.com/auracast/" title="Auracast | Bluetooth® Technology Website" lang="en">Auracast</a> 這樣的技術和應用」。我當時的想法大致如下……</p>]]>
        <![CDATA[<hr />

<p>我覺得這個問題要從幾個角度來討論。</p>

<p>首先是 <span lang="en">Auracast</span> 的使用操作邏輯，我認為現有的使用體驗還不夠理想。</p>

<p><a href="https://jedi.org/blog/archives/006308.html" title="助聽器公司不說的事：T 線圈 | Jedi's BLOG">感應線圈迴路</a>的優勢之一，在於操作足夠簡便，接收端（使用者）只需要把音源切換到 <samp>T</samp> 或 <samp>M+T</samp> 模式，之後基本上就可以（暫時）不必再理會，只要進入線圈範圍就會開始接收訊號，離開線圈範圍就自然失去訊號，從一個線圈區域移動到另一個線圈區域也是自動地轉移銜接。接收端（使用者）即使還沒進入線圈區域，也可以提早切換到 <samp>T</samp> 或 <samp>M+T</samp> 模式，設定後就不必再理會。當然相對地，感應線圈迴路的技術眉角在於規劃舖設，也就是服務提供端要如何框出有效的區域，以及如何避免區域間的干擾等。</p>

<p><span lang="en">Auracast</span> 的操作卻複雜得多。接收端（使用者）必須在進入有效訊號範圍內，接收到 <span lang="en">Auracast</span> 通知，才能開始選擇要接收的頻道、輸入密碼（如果需要），使用者移動到另一個區域（例如從車站移動到車上）之後，每次都需要重複上述操作。除了已經預先配置好的成套設備（就是導覽設備那種），其他使用情境不論是助聽輔具或消費級耳機設備等，目前幾乎都需要依賴額外的 <span lang="en">Auracast Assistant</span> 設備（例如智慧型手機）來進行上述操作。</p>

<p>在 <span lang="en"><cite><a href="https://www.bluetooth.com/blog/explained-how-to-join-an-auracast-broadcast/" title="Explained: How to join an Auracast™ broadcast | Bluetooth® Technology Website">Explained: How to join an Auracast™ broadcast</a></cite></span> 的描述中，如果是「不使用 <span lang="en">Auracast Assistant</span>」的情境，目前設想的操作機制是在接收端設備有個按鈕，可以接收或切換公開（不設密碼的） <span lang="en">Auracast</span> 訊號源，但是這仍然需要「使用者知道目前所在的區域有 Auracast」的前提，無法事先決定；若採用接收到 <span lang="en">Auracast broadcast advertisements</span> 的時候直接在設備上發出聲音提示的機制，實務上則可能很惱人，也很容易打斷重要聆聽，並不理想。</p>

<p>目前也有些 <span lang="en">Auracast Assistant</span> 實作自動加入已儲存的 <span lang="en">Auracast</span> 廣播的功能，在某個程度上改善使用體驗，但只對於常態的生活作息有幫助，只要稍微離開「舒適圈」就沒用了。</p>

<p>我目前的想像中，如果要改善使用體驗，可能需要定義某個共用的廣播名稱，例如就叫「PA」之類的 (<span lang="en">public announce</span>)，可以讓接收端自動連上；而實務上雖然名稱相同，實際的廣播 ID 仍然會不同，所以還需要在接收端可以自動轉移到訊號較強的另一個廣播 ID 的機制。至少要能夠有這樣的機制，<span lang="en">Auracast</span> 的易用程度才能夠跟感應線圈迴路相較。</p>

<p>第二個要討論的是 <span lang="en">Auracast</span> 的使用情境。</p>

<p>最顯而易見的就是團體導覽系統，不再贅述。需要略加補充說明的是 <span lang="en">Auracast</span> 在個人化導覽（例如位置定位／地點信標／二維條碼等導覽機制）派不上用場。</p>

<p>近 10 年來台灣也開始仿效國外舉辦耳機派對／默日狂歡，這是很適合運用 <span lang="en">Auracast</span> 的情境；尤其這類活動早已實踐「同一個場地提供多組 DJ 頻道」的做法，運用 <span lang="en">Auracast</span> 可以無限制地擴充頻道數量，也可以讓參與者使用自己慣用的耳機。</p>

<p>上述這兩種使用情境，都是屬於「跟著人」的設備模式，只要提供導覽／舉辦活動的單位願意買入，就能夠攜帶設備到處提供服務。</p>

<p>研討會或會議場合，尤其是提供同步口譯或有多軌議程的情況，都是 <span lang="en">Auracast</span> 擅長發揮的情境。但是並不表示 <span lang="en">Auracast</span> 適合用於所有的課堂情境，畢竟其延遲時間最短也要 30 毫秒，在幼兒園至中學階段並不是那麼合用。</p>

<p>上述這種使用情境，多半屬於「固定地點」的設備模式，需要管理場地的單位願意買入（跟空間的整體音響設備搭配），才能提供服務；稍微例外的是台灣由於幾乎沒有什麼場地是把同步口譯納入規劃，所以同步口譯的服務提供商反而會自行準備額外的音訊設備，又回到「跟著人」的設備模式。</p>

<p>而在「固定地點」的設備模式中，台灣多數場地的管理單位大概都是找單一的音響系統商做統包，而不會去在意（或根本缺乏相關知識）採用的技術。例如，試想「學校教室要如何全面採用 <span lang="en">Auracast</span>」？各種主要的阻礙關鍵就會浮現了。</p>

<p>居家電視聆聽輔具很適合 <span lang="en">Auracast</span>。然而現行的方案多半是把 <span lang="en">Auracast</span> 廣播發射器外接到電視機，意味著只能廣播單一音訊內容；如果是電視機直接整合 <span lang="en">Auracast</span> 的話，才有辦法支援雙語 (<span lang="en">dual sound</span>)、多語配音 (<span lang="en">dubbing</span>)、口述影像 (<span lang="en">audio description</span>) 分別以不同頻道廣播。</p>

<p>在英國等國家，居家電視聆聽輔具是生活輔具補助的項目，實務上包括「免費到民眾家裡舖設感應線圈迴路連接電視機」及「免費提供紅外線無線耳機系統」等，但是台灣沒有提供這類的輔具補助。沒有補助的主要原因是沒有任何身心障礙團體提出過有這類需求，其實台灣的市場上也看不到這類輔具產品，這又有幾個原因：首先是台灣從很早以前就實施電視節目非隱藏式字幕（當時主要是政治目的，推行國語運動以及打壓方言，而不是親和力考量），然後很多台灣人很喜歡把電視聲音開很大聲（跟卡拉 OK 開很大聲的習慣是相通的），不論在戶外、醫院、公共運輸系統上也都習慣把影片跟手機音量開很大聲，直到最近一、兩年台灣社會才開始宣導寧靜環境，多數人對於「聲音開很大聲」的情況也是容忍而不大干涉，這兩個原因導致電視聆聽輔具在台灣的需求很難顯現。</p>

<p>電影院也適合運用 <span lang="en">Auracast</span>（用途需求跟電視很像），但是台灣的電影院基本上除了保留輪椅座位區，在法規上幾乎沒有什麼其他的無障礙規範，包括同樣因為盛行非隱藏式字幕所以也不像美國那樣有著（多語）字幕機的借用機制；另一方面，做為口述主要需求者的視障者團體，近年來在台灣主推的方案是口述影像共融，這種模式也會降低電影院採用 <span lang="en">Auracast</span> 的需求。</p>

<p>第三要從法規跟文化面來討論。</p>

<p>美國以 <a href="https://www.ada.gov" title="The Americans with Disabilities Act | ADA.gov" lang="en">Americans with Disabilities Act (ADA)</a> 規範第二條適用對象（州政府及地方政府）及第三條適用對象（對公眾提供服務之商業組織及非營利組織）應提供聆聽輔助系統，這大概是目前最能推動採用 <span lang="en">Auracast</span> 的主力（全稱為 <q lang="en">Auracast Broadcast Audio used as part of an Assistive Listening System</q>），但目前 <span lang="en">Auracast</span> 是否能夠滿足 <abbr title="Americans with Disabilities Act" lang="en">ADA</abbr> 的要求還沒有確立下來，預計最快也要到 2027 年之後才有定論。</p>

<p>台灣的法規對此則毫無要求。這也是為什麼台灣幾乎沒有建置感應線圈迴路的原因。沒有需求也導致沒有廠商提供相關服務或產品，沒有服務或產品導致台灣的聽障者團體幾乎對感應線圈迴路沒有認知而沒有提出過相關需求，故從未倡議相關法規。</p>

<p>台灣的各種建築空間向來是以「拍攝起來好看、氣派」為優先考量，還不用談到聆聽輔助系統，絕大多數的空間聲響簡直可以說是悲劇；更令我感到詫異的是，我到過許多空間聲響特性很糟的助聽器公司以及社會福利機構（含輔具資源中心）。在空間聲響特性普遍不佳的情況之下，台灣發展出的廉價解決方案是……跑馬燈。跑馬燈本身的問題跟障礙非常多，近年來開始逐漸接替跑馬燈的是各種（同樣設計得很有問題的）資訊看板，這些在「只求有」的前提下是最便宜的方案，尤其「看得到、好驗收」完全適合台灣的採購相關法規要求，反而成為在台灣推廣 <span lang="en">Auracast</span> 的最大競爭對手。</p>

<p>就算在最應該講究語音聲學效果的會議室場合，在台灣都不是那麼容易。以我在衛生福利部開會的經驗來說，雖然各會議室都在座位上配置發言麥克風，但並不是每一間會議室的桌上發言麥克風都配備 3.5㎜ 耳機插口，就算配備耳機插口我也敢說幾乎沒有人使用，因為衛生福利部自己用膠帶把這些插口封住了（我大概是唯一每次開會都會把膠帶撕開，使用這些插口的人）；我也遇過很多公家機關的會議室雖然配置含耳機插口的桌上發言麥克風，但是音訊線路卻不連接，導致這些插口沒有聲音訊號。更多會議室完全沒有配置麥克風等設備，也經常在會議中遇到堅持不使用麥克風發言的人，彷彿比較在乎「我有發言」，而不真的在乎其他人能否順利聆聽。若深究下去，我傾向於認為這是潛藏在台灣文化中的能力歧視 (<span lang="en">ableism</span>)。</p>

<p>總而言之，我認為以台灣的現狀來說，很難去期待有辦法以聆聽輔具策略的角度來推廣 <span lang="en">Auracast</span>。我認為最值得嘗試的路線，是先從前面提過的耳機派對／默日狂歡展開，先針對活躍的一般消費級聆聽設備使用者（而不是音響迷，也不是聽障者團體）帶動各種 <span lang="en">Auracast</span> 設備的使用及普及，以及凸顯 <span lang="en">Auracast</span> 的優勢，這樣才能帶動接收端設備的能見度及普及，接著才有辦法讓發射端的使用者（機關團體）增加買入意願，然後「這麼巧地，很多助聽器也能支援」的情況下，聽障者團體才會逐漸發現到自己的需求。</p>

<hr />

<p>相關資訊補充：在國外的聽障者社群間，可以發現有幾間無線音訊廠商<a href="https://forum.hearingtracker.com/t/auracast-transmitter-tests/101142" title="Auracast transmitter tests - Hearing Aid Forum - Active Hearing Loss Community">相當努力地在跟使用者互動</a>，想要開拓 <span lang="en">Auracast</span> 使用情境及完善相關產品線。對這塊領域有興趣的朋友不妨關注 <a href="https://www.homespotdigital.com" title="HomeSpot" lang="en">HomeSpot</a>、<a href="https://www.flairmesh.com/" title="Flairmesh" lang="en">FlooGoo</a>、<a href="https://avantree.com" title="Avantree" lang="en">Avantree</a>、<a href="https://www.moor.com.tw" title="魔耳科技" lang="en">MoerLab</a>（隨意排序，先後不代表任何意義）等廠牌的相關討論。</p>]]>
      </description>
      <guid isPermaLink="false">6455@https://jedi.org/blog/</guid>
      <dc:subject>occupation</dc:subject>
      <dc:date>2025-11-23T09:01:31+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>遊戲控制器、搖桿、特殊開關、滑鼠</title>
      <link>https://jedi.org/blog/archives/006454.html</link>
      <description>
        <![CDATA[<p>突然發現我在過去五年多期間，這個主題的相關部落格文章已經累積二十篇以上，缺少某個整合的目錄，閱讀查詢起來很不方便，所以現在整理在此。</p>]]>
        <![CDATA[<h2>遊戲控制器（遊戲把手／遊戲手柄／<span lang="en">Gamepad</span>）</h2>

<ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006261.html" title="Microsoft Xbox Adaptive Controller（及配件）開箱記錄 | Jedi's BLOG">適應性控制器 (<abbr title="Xbox Adaptive Controller" lang="en">XAC</abbr>)</a>（<a href="https://jedi.org/blog/archives/006263.html" title="微軟適應性控制器輸入規格 | Jedi's BLOG">輸入規格</a>、<a href="https://jedi.org/blog/archives/006264.html" title="微軟適應性控制器 Windows 10 應用程式 | Jedi's BLOG">Windows 應用程式</a>、<a href="https://jedi.org/blog/archives/006269.html" title="微軟適應性控制器搭配 Windows 7 使用 | Jedi's BLOG">搭配 Windows 7 使用方法</a>）</li>
<li><span lang="ja">HORI</span>（任天堂周邊廠）：<a href="https://jedi.org/blog/archives/006277.html" title="HORI Flex Controller 彈性控制器 | Jedi's BLOG">彈性控制器 (<abbr title="Switch Flex Controller" lang="en">SFC</abbr>)</a>（<a href="https://jedi.org/blog/archives/006278.html" title="Xbox Adaptive Controller 與 Switch Flex Controller 規格比較 | Jedi's BLOG">規格比較</a>）</li>
<li>索尼：<a href="https://jedi.org/blog/archives/006416.html" title="Sony PlayStation Access Controller | Jedi's BLOG">Access 控制器 (<abbr title="PlayStation Access Controller" lang="en">PSAC</abbr>)</a>（<a href="https://jedi.org/blog/archives/006393.html" title="Sony 的適應性控制器專案 (Project Leonardo) | Jedi's BLOG" lang="en">Project Leonardo</a>）</li>
<li>羅技：<a href="https://jedi.org/blog/archives/006262.html" title="Logitech Switch | Jedi's BLOG">適應性遊戲套件 (<abbr title="Adaptive Gaming Kit" lang="en">AGK</abbr>)</a></li>
<li><a href="https://jedi.org/blog/archives/006265.html" title="用遊戲控制器操作 Windows 電腦 | Jedi's BLOG">用遊戲控制器操作 Windows 電腦</a>（<a href="https://jedi.org/blog/archives/006267.html" title="實際示範：用遊戲控制器操作 Windows 電腦 | Jedi's BLOG">實際示範</a>、<a href="https://jedi.org/blog/archives/006268.html" title="遊戲控制器電腦操作軟體比較 | Jedi's BLOG">軟體比較</a>）</li>
</ul>

<h2>搖桿 <span lang="en">(Joystick)</span></h2>

<ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006453.html" title="微軟調適型搖桿 (Xbox Adaptive Joystick) 開箱及調整設定 | Jedi's BLOG">調適型搖桿 (<abbr title="Xbox Adaptive Joystick" lang="en">XAJ</abbr>)</a></li>
<li><span lang="en">Warfighter Engaged</span>：<a href="https://jedi.org/blog/archives/006266.html" title="JOYSTIX-L 特製搖桿 | Jedi's BLOG">JOYSTIX-L 特製搖桿</a>、<a href="https://jedi.org/blog/archives/006281.html" title="PALMSTIX 特製搖桿 | Jedi's BLOG">PALMSTIX 特製搖桿</a></li>
<li><span lang="en">Evil Controllers</span>：<a href="https://jedi.org/blog/archives/006273.html" title="Mini XAC Thumbstick 特製搖桿 | Jedi's BLOG">Mini XAC Thumbstick 特製搖桿</a></li>
</ul>

<h2>特殊開關（切換控制／<span lang="en">Switch Control</span>）</h2>

<ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006388.html" title="微軟適應性集線器及適應性按鈕功能介紹 | Jedi's BLOG">適應性集線器、適應性按鈕</a></li>
<li><span lang="en">AbleNet</span>: <a href="https://jedi.org/blog/archives/006282.html" title="AbleNet Blue2 特殊開關 | Jedi's BLOG" lang="en">Blue2</a></li>
<li>羅技：<a href="https://jedi.org/blog/archives/006262.html" title="Logitech Switch | Jedi's BLOG">適應性遊戲套件 (<abbr title="Adaptive Gaming Kit" lang="en">AGK</abbr>)</a></li>
</ul>

<h2>電腦及其他周邊輔助科技</h2>

<ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006385.html" title="微軟適應性周邊開箱 | Jedi's BLOG">適應性周邊</a>（<a href="https://jedi.org/blog/archives/006386.html" title="微軟適應性滑鼠功能介紹 | Jedi's BLOG">適應性滑鼠</a>）、<a href="https://jedi.org/blog/archives/006343.html" title="微軟調適型套件／適應性套件 (Surface Adaptive Kit) 開箱 | Jedi's BLOG">調適型套件 (<abbr title="Surface Adaptive Kit" lang="en">SAK</abbr>)</a></li>
</ul>
]]>
      </description>
      <guid isPermaLink="false">6454@https://jedi.org/blog/</guid>
      <dc:subject>typing</dc:subject>
      <dc:date>2025-09-07T10:15:24+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>微軟調適型搖桿 (Xbox Adaptive Joystick) 開箱及調整設定</title>
      <link>https://jedi.org/blog/archives/006453.html</link>
      <description>
        <![CDATA[<p><img alt="從一個頂角看過去的瓦楞紙箱特寫，側面貼著白色產品標籤，頂端封箱膠帶有個圓形拉環浮貼在另一個側面" src="https://jedi.org/blog/archives/XAJ_01.png" width="800" height="800"><br />
這一天，我又收到這麼一個紙箱；光是看到這封箱膠帶，就知道裡面的東西有意思……</img></p>]]>
        <![CDATA[<p><img alt="I0Y&hyphen;00003 產品標籤特寫" src="https://jedi.org/blog/archives/XAJ_02.png" width="800" height="600"><br />
紙箱上貼著一張標籤，標示內容物為 <q lang="en">I0Y&hyphen;00003</q>，<q lang="en">XBOX JOBURG JO EN/XT/ZH/JA/KO APOC</q>，數量為 1 個……光看這樣實在看不懂是什麼東西，那麼就把封箱膠帶撕開吧！</img></p>

<p><img alt="Xbox Adaptive Joystick 包裝盒特寫" src="https://jedi.org/blog/archives/XAJ_03.png" width="800" height="600"><br />
輕鬆撕開封箱膠帶，外箱很自然地向四面展開，顯露出包裝盒&#11834;哦，原來是微軟的調適型搖桿 <span lang="en">(<a href="https://www.microsoft.com/en-us/d/Xbox-Adaptive-Joystick/8mzbmmcjzqs4">Xbox Adaptive Joystick</a>)</span>。包裝盒靠近我的這一面（綠色那一面）看起來像可以撕開，其餘各面都沒有可以開盒的樣子；不過為了盡量保存，我最後決定不要冒然撕開，而是拿出美工刀，把固定膠的地方切開，好研究看看它是怎麼包裝起來的。</img></p>

<p><img alt="包裝盒以兩處固定膠貼著，拆開後露出包裝盒的大型開蓋拉環" src="https://jedi.org/blog/archives/XAJ_04.png" width="800" height="600"><br />
看起來是從這一面拆開的沒錯；固定膠只有兩處，看起來是稍加用力也就能拆開的設計。拆開後露出了一樣是綠色的大型拉環，這是用來幫助掀蓋的設計。</img></p>

<p><img alt="包裝盒內托特寫，顯示出可順暢開蓋的非直角斜面構造" src="https://jedi.org/blog/archives/XAJ_06.png" width="800" height="800"><br />
掀蓋的手感異常柔順，絲毫沒有阻礙；仔細一看，發現包裝盒內托構造並非呈直角，而是有個大約 74°的銳角，因此上蓋掀開時完全不會卡住（側面兩個角落剛好內接上蓋底面掀開路徑的圓周），這真是厲害的設計！</img></p>

<p>這種包裝設計，是微軟在近幾年間不斷改良發展出來的；<time datetime="2025-03-19">今年三月 19 日</time>微軟刊登一篇 <a href="https://microsoft.design/articles/prioritizing-inclusion-over-convention-rethinking-how-we-design-packaging/" title="Prioritizing inclusion over convention: Rethinking how we design packaging - Microsoft Design" lang="en">Prioritizing inclusion over convention: Rethinking how we design packaging</a> 部落格文章，介紹這段設計的故事，提供 <a href="https://aka.ms/AccessiblePackaging" title="Creating Accessible Packaging: An Inclusive Design Guide (PDF)" lang="en">Creating Accessible Packaging: An Inclusive Design Guide</a>（PDF 格式的指引手冊），以創用 CC「姓名標示&hyphen;非商業性&hyphen;禁止改作」授權釋出給公眾，詳細剖析整套設計的基礎、挑戰與考量、如何促成團隊進行設計，指引手冊包含微軟這套設計所採用的設計制度 <span lang="en">(design system)</span> 及設計花樣 <span lang="en">(design pattern)</span>，進一步描述如何驗證設計是否有效，也提供未來設計的參考及指引方向，亟具參考價值，在此強烈推薦給大家，請務必細讀。</p>

<p>岔題了，讓我們把目光移回剛剛打開的包裝盒。</p>

<p><img alt="掀開包裝盒上蓋，露出調適型搖桿本體，坐落於紙質內托座，也露出內托座的拉取開口" src="https://jedi.org/blog/archives/XAJ_05.png" width="800" height="800"><br />
掀開包裝盒上蓋之後，可以看到搖桿本體，以及它坐落的內托座底下的拉取開口，一副我應該要拉開的樣子。</img></p>

<p><img alt="拉取內托座後，露出底下的配件包裝及紙本文件" src="https://jedi.org/blog/archives/XAJ_07.png" width="800" height="1423"><br />
輕輕拉開，藏在底下的配件盒以及更底下的紙本文件（較一般性的產品使用手冊，像是保固條款之類的內容）順勢帶出&#11834;這裡的包裝設計也很厲害，內托座後端的紙板構造剛好會鉤上配件盒的拉環，自然而然形成照片中那樣的分層展露效果。</img></p>

<p><img alt="配件包裝內的 USB 纜線，及印製在配件包裝蓋內面的簡易安裝使用說明圖例" src="https://jedi.org/blog/archives/XAJ_08.png" width="800" height="1067"><br />
配件盒打開後可以看到 <span lang="en">USB Type A</span> 轉 <span lang="en">Type C</span> 的編織纜線，以及印製在配件盒蓋內面的圖例，說明 <span lang="en">USB</span> 纜線的安裝位置及預設的按鍵對應。</img></p>

<p>從圖例中可以看到，適應型搖桿的主要用法是搭配<a href="https://jedi.org/blog/archives/006261.html" title="
Microsoft Xbox Adaptive Controller（及配件）開箱記錄 | Jedi's BLOG">適應性控制器</a>；適應性控制器左、右各有一個 <span lang="en">USB Type A</span> 接口，接在哪一邊會影響到適應型搖桿的預設按鍵（及搖桿）對應。</p>

<p>簡單來說，就是把適應型搖桿想成「半個」 <a href="https://www.xbox.com/zh-TW/accessories/controllers/xbox-wireless-controller" title="Xbox 無線控制器 | Xbox">Xbox 控制器</a>，接在左邊就是對應左半邊的按鍵跟搖桿，接在右邊就是對應右半邊的按鍵跟搖桿。當然也可以準備兩個適應型搖桿，兩邊都接。</p>

<p><img alt="調適型搖桿側面的 XBOX 圖標特寫" src="https://jedi.org/blog/archives/XAJ_09.png" width="800" height="800"><br />
調適型搖桿本體是白色的，除了按鍵之外幾乎沒有任何標示，側面有個以浮雕方式呈現的 <samp lang="en">XBOX</samp> 圖示及字樣，機身底面的握持處以及白色板機鍵都佈滿防滑的點狀凸起，白色肩鍵呈現霧面但沒有點狀凸起。</img></p>

<p><img alt="調適型搖桿頂面 x1, x2, x3, x4 按鈕及類比搖桿特寫" src="https://jedi.org/blog/archives/XAJ_10.png" width="800" height="800"><br />
<img alt="調適型搖桿肩鍵 x5 及板機鍵 x6 特寫" src="https://jedi.org/blog/archives/XAJ_11.png" width="800" height="800"><br />
上方搖桿部分是黑色的，搖桿頭同樣有著防滑紋路，搖桿面板的上端同樣有個浮雕呈現的 <samp lang="en">XBOX</samp> 圖示，機身頂面還有四個亮面白色按鈕，分別標示 <samp>x1</samp>、<samp>x2</samp>、<samp>x3</samp>、<samp>x4</samp>，肩鍵標示 <samp>x5</samp>，板機鍵標示 <samp>x6</samp>。</img></img></p>

<p><img alt="調適型搖桿底面 USB-C 接口及支架鎖孔特寫" src="https://jedi.org/blog/archives/XAJ_12.png" width="800" height="800"><br />
<img alt="調適型搖桿安裝於攜帶型相機腳架後立起" src="https://jedi.org/blog/archives/XAJ_13.png" width="800" height="1067"><br />
底面末端是 <span lang="en">USB Type C</span> 接口，以及支架鎖孔。調適型搖桿沒有內建電池，也不具無線連線功能，一定要透過 <span lang="en">USB</span> 纜線連接才能使用。支架鎖孔是常見的¼吋螺絲孔規格，一般相機腳架雲台的螺絲就是這個規格；我拿隨身的手機用腳架就能把調適型搖桿立起來，不過真的要使用的話，應該要根據手功能的特性來挑選腳架或固定支架。</img></img></p>

<p><img alt="調適型搖桿機身標示文字特寫" src="https://jedi.org/blog/archives/XAJ_14.png" width="800" height="800"><br />
底面用低對比的灰色印著一些文字，包括另一個型號<q>2080</q>、序號、安規認證標誌、產地標示，以及額定工作電壓電流（5V&hyphen;500㎃）。</img></p>

<p>開箱到這裡告一段落。接下來要來看一下調適型搖桿的相關設定，這會用到 <a href="https://apps.microsoft.com/detail/9nblggh30xj3">Xbox 配件</a>應用程式（或者 <span lang="en">Xbox One</span> 或 <span lang="en">Xbox Series X|S</span> 主機）。直接把調適型搖桿接到 <span lang="en">Windows</span> 電腦上，執行「Xbox 配件」，初次做這項操作時會先看到一連串的簡介畫面：<br />
<img alt="簡介畫面：Xbox 調適型搖桿介紹" src="https://jedi.org/blog/archives/XAJ_15.png" width="800" height="383"><img alt="簡介畫面：打造自己的遊戲風格" src="https://jedi.org/blog/archives/XAJ_16.png" width="800" height="383"><img alt="簡介畫面：根據您的遊戲方式進行調整" src="https://jedi.org/blog/archives/XAJ_17.png" width="800" height="383"><img alt="簡介畫面：取得最新的韌體" src="https://jedi.org/blog/archives/XAJ_18.png" width="800" height="383"><img alt="簡介畫面：深入了解" src="https://jedi.org/blog/archives/XAJ_19.png" width="800" height="383"><br />
哦喔，抓到錯字，在<q>打造自己的遊戲風格</q>那個簡介畫面裡，寫成<q>您也可以將 Xbox 調適型<mark>要趕</mark>直接連接到您的主機或電腦</q>，不知道有沒有其他人注意到？</img></img></img></img></img></p>

<p><img alt="在調適型搖桿的圖案底下，只有一個「需要更新」的按鈕" src="https://jedi.org/blog/archives/XAJ_20.png" width="800" height="383"><br />
果然剛拿到的硬體就是要先來更新韌體，否則無法進一步設定。</img></p>

<p><img alt="Xbox 調適型搖桿圖案標示出各個按鍵對應設定，底下是「設定」按鈕，再底下還有三個按鈕" src="https://jedi.org/blog/archives/XAJ_21.png" width="800" height="701"><br />
完成韌體更新後，終於可以看到設定跟其他功能的按鈕；在這個畫面裡，還可以看到調適型搖桿的各個按鍵都標示了目前（預設）的按鍵對應&#11834;細心的人會注意到這裡的對應有些奇怪：左搖桿鍵、右搖桿、左肩鍵、左板機鍵、X、Y、A、B，感覺像是把一些「左半邊」的按鍵跟一些「右半邊」的按鍵混在一起，這是因為目前是單獨直接連接在電腦上，所以預設的按鍵及搖桿對應會跟接在適應性控制器上的狀況不同。</img></p>

<p><img alt="Xbox 調適型搖桿韌體版本 1.0.9.0，沒有可用的更新" src="https://jedi.org/blog/archives/XAJ_22.png" width="800" height="393"><br />
進到「<samp>設定</samp>」裡，可以看到目前的韌體版本為 1.0.9.0 版；這個畫面還可以修改這支調適型搖桿的名稱（如果同時接了好幾支調適型搖桿，這樣比較不會弄錯），以及可以「開啟控制器助理」。</img></p>

<p>簡單說明一下，這裡提到的「控制器助理」就是我以前在《<a href="https://jedi.org/blog/archives/006264.html" title="微軟適應性控制器 Windows 10 應用程式 | Jedi's BLOG">微軟適應性控制器 Windows 10 應用程式</a>》文中提到的「副駕駛 <span lang="en">(Copilot)</span>」功能，可以把兩支控制器或搖桿當成同一支，而達到用兩個設備（當然可以由兩個人分別操作）合併操作的效果。</p>

<p><img alt="預設設定檔畫面，按鍵對應無法變更，但可以新增設定檔" src="https://jedi.org/blog/archives/XAJ_23.png" width="800" height="565"><br />
回到 Xbox 配件主畫面，按底下的「<samp>…</samp>」按鈕就能進到設定檔管理畫面。一開始只有預設的設定檔，這是不能變更的對應設定，如果想要使用不同的對應，要先新增設定檔。</img></p>

<p><img alt="設定檔 1 的「對應」畫面，各個按鍵均可變更對應" src="https://jedi.org/blog/archives/XAJ_24.png" width="800" height="607"><br />
這裡姑且先新增了一個叫「設定檔 1」的新設定檔，注意到上端有兩個分區，分別是「對應」及「搖桿」；在「對應」區可以變更所有按鍵及搖桿的對應。</img></p>

<p><img alt="設定檔 1 的「搖桿」畫面，可以調整類比搖桿的敏感度曲線" src="https://jedi.org/blog/archives/XAJ_25.png" width="800" height="607"><br />
<img alt="設定檔 1 將類比搖桿的敏感度曲線設定為「積極」的畫面，共有 10 段「曲線調整」可以選擇，並可改變計算方式" src="https://jedi.org/blog/archives/XAJ_26.png" width="800" height="672"><br />
而在「搖桿」區則可以變更類比搖桿的敏感度曲線，而達到不同的操作手感。</img></img></p>

<p>既然能夠做這些設定，當然直接在電腦上用調適型搖桿<a href="https://jedi.org/blog/archives/006265.html" title="用遊戲控制器操作 Windows 電腦 | Jedi's BLOG">操作 Windows 電腦</a>也沒有問題。</p>

<div>
<h2>系列相關文章</h2>
<ul>
<li>遊戲控制器（遊戲把手／遊戲手柄／<span lang="en">Gamepad</span>）<ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006261.html" title="Microsoft Xbox Adaptive Controller（及配件）開箱記錄 | Jedi's BLOG">適應性控制器 (<abbr title="Xbox Adaptive Controller" lang="en">XAC</abbr>)</a>（<a href="https://jedi.org/blog/archives/006263.html" title="微軟適應性控制器輸入規格 | Jedi's BLOG">輸入規格</a>、<a href="https://jedi.org/blog/archives/006264.html" title="微軟適應性控制器 Windows 10 應用程式 | Jedi's BLOG">Windows 應用程式</a>、<a href="https://jedi.org/blog/archives/006269.html" title="微軟適應性控制器搭配 Windows 7 使用 | Jedi's BLOG">搭配 Windows 7 使用方法</a>）</li>
<li><span lang="ja">HORI</span>（任天堂周邊廠）：<a href="https://jedi.org/blog/archives/006277.html" title="HORI Flex Controller 彈性控制器 | Jedi's BLOG">彈性控制器 (<abbr title="Switch Flex Controller" lang="en">SFC</abbr>)</a>（<a href="https://jedi.org/blog/archives/006278.html" title="Xbox Adaptive Controller 與 Switch Flex Controller 規格比較 | Jedi's BLOG">規格比較</a>）</li>
<li>索尼：<a href="https://jedi.org/blog/archives/006416.html" title="Sony PlayStation Access Controller | Jedi's BLOG">Access 控制器 (<abbr title="PlayStation Access Controller" lang="en">PSAC</abbr>)</a>（<a href="https://jedi.org/blog/archives/006393.html" title="Sony 的適應性控制器專案 (Project Leonardo) | Jedi's BLOG" lang="en">Project Leonardo</a>）</li>
<li>羅技：<a href="https://jedi.org/blog/archives/006262.html" title="Logitech Switch | Jedi's BLOG">適應性遊戲套件 (<abbr title="Adaptive Gaming Kit" lang="en">AGK</abbr>)</a></li>
<li><a href="https://jedi.org/blog/archives/006265.html" title="用遊戲控制器操作 Windows 電腦 | Jedi's BLOG">用遊戲控制器操作 Windows 電腦</a>（<a href="https://jedi.org/blog/archives/006267.html" title="實際示範：用遊戲控制器操作 Windows 電腦 | Jedi's BLOG">實際示範</a>、<a href="https://jedi.org/blog/archives/006268.html" title="遊戲控制器電腦操作軟體比較 | Jedi's BLOG">軟體比較</a>）</li>
</ul></li>
<li>搖桿 <span lang="en">(Joystick)</span><ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006453.html" title="微軟調適型搖桿 (Xbox Adaptive Joystick) 開箱及調整設定 | Jedi's BLOG">調適型搖桿 (<abbr title="Xbox Adaptive Joystick" lang="en">XAJ</abbr>)</a></li>
<li><span lang="en">Warfighter Engaged</span>：<a href="https://jedi.org/blog/archives/006266.html" title="JOYSTIX-L 特製搖桿 | Jedi's BLOG">JOYSTIX-L 特製搖桿</a>、<a href="https://jedi.org/blog/archives/006281.html" title="PALMSTIX 特製搖桿 | Jedi's BLOG">PALMSTIX 特製搖桿</a></li>
<li><span lang="en">Evil Controllers</span>：<a href="https://jedi.org/blog/archives/006273.html" title="Mini XAC Thumbstick 特製搖桿 | Jedi's BLOG">Mini XAC Thumbstick 特製搖桿</a></li>
</ul></li>
<li>特殊開關（切換控制／<span lang="en">Switch Control</span>）<ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006388.html" title="微軟適應性集線器及適應性按鈕功能介紹 | Jedi's BLOG">適應性集線器、適應性按鈕</a></li>
<li><span lang="en">AbleNet</span>: <a href="https://jedi.org/blog/archives/006282.html" title="AbleNet Blue2 特殊開關 | Jedi's BLOG" lang="en">Blue2</a></li>
<li>羅技：<a href="https://jedi.org/blog/archives/006262.html" title="Logitech Switch | Jedi's BLOG">適應性遊戲套件 (<abbr title="Adaptive Gaming Kit" lang="en">AGK</abbr>)</a></li>
</ul></li>
<li>電腦及其他周邊輔助科技<ul>
<li>微軟：<a href="https://jedi.org/blog/archives/006385.html" title="微軟適應性周邊開箱 | Jedi's BLOG">適應性周邊</a>（<a href="https://jedi.org/blog/archives/006386.html" title="微軟適應性滑鼠功能介紹 | Jedi's BLOG">適應性滑鼠</a>）、<a href="https://jedi.org/blog/archives/006343.html" title="微軟調適型套件／適應性套件 (Surface Adaptive Kit) 開箱 | Jedi's BLOG">調適型套件 (<abbr title="Surface Adaptive Kit" lang="en">SAK</abbr>)</a></li>
</ul></li>
</ul>
</div>]]>
      </description>
      <guid isPermaLink="false">6453@https://jedi.org/blog/</guid>
      <dc:subject>desire</dc:subject>
      <dc:date>2025-09-06T23:28:42+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>回應金管會「數位金融服務包容性指引（草案）」意見</title>
      <link>https://jedi.org/blog/archives/006452.html</link>
      <description>
        <![CDATA[<p>金融監督管理委員會（金管會）在<time datetime="2025-07-31">今年七月底</time>預告《數位金融服務包容性指引》草案，<a href="https://www.fsc.gov.tw/ch/home.jsp?id=96&amp;parentpath=0,2&amp;mcustomize=news_view.jsp&amp;dataserno=202507310007&amp;dtable=News" title="新聞稿-金管會徵詢外界對「數位金融服務包容性指引(草案) 」意見-金融監督管理委員會全球資訊網">公開徵詢意見</a>，並同步<a href="https://join.gov.tw/policies/detail/4c46b9ff-e859-46cb-b613-69e7e55088dc" title="金管會徵詢外界對「數位金融服務包容性指引(草案) 」意見-眾開講-公共政策網路參與平臺">在公共政策網路參與平臺開放討論</a>。</p>]]>
        <![CDATA[<p>我對此草案發表的初步意見如下：</p>

<blockquote>
<p>指引草案第 8 頁情境例示（C 公司）當中，對於「⒌視障者」舉例內容不當。</p>

<p>草案例示舉例文字內容為：<q>希望在使用 APP 時能有 [...] 等支援手機系統輔助工具。C 公司根據其需求設計友善視障者使用之 APP 版本，且盡可能促進視障者能使用的功能與一般民眾一致，而非僅有簡易功能</q>；既然目的是要提供所有功能，並無道理另外維護不同的 APP 版本（此舉徒增維護成本，並且容易導致數位隔離之風險），而應確保一般人使用之 APP 版本能與手機系統輔助工具相容。</p>

<p>歐盟可及性標準 <a href="https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility" title="ETSI - EN 301 549 V3 the harmonized European Standard for ICT Accessibility">EN 301 549 第 3.2.1 版</a>（<time datetime="2021-03">2021 年 3 月</time>）於 11.7 小節明確要求 <q lang="en">Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.</q> 換而言之，「支援手機系統輔助工具」並不只是「友善視障者使用」版本需求，而是對任何 APP 的普遍性基本要求。</p>

<p>綜上所述，本段文字建議調整為「希望在使用APP時能有 [...] 等支援手機系統輔助工具。<mark>C 公司根據其需求設計 APP 完整支援行動作業系統輔助科技功能，使視障者能完整使用所有 APP 功能。</mark>」</p>
</blockquote>

<p>這項草案的開放討論期預計到<time datetime="2025-09-28">九月 28 日</time>，請大家踴躍回應。</p>]]>
      </description>
      <guid isPermaLink="false">6452@https://jedi.org/blog/</guid>
      <dc:subject>occupation</dc:subject>
      <dc:date>2025-08-26T15:50:43+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>Windows 內建應用程式的廣告</title>
      <link>https://jedi.org/blog/archives/006451.html</link>
      <description>
        <![CDATA[<p><span lang="en">Windows</span> 10 跟 11 內建了一些應用程式，例如 <a href="https://apps.microsoft.com/detail/9NRX63209R7B" title="Windows 版 Outlook">Outlook</a> 和<a href="https://apps.microsoft.com/detail/9WZDNCRFJ3Q2" title="MSN 天氣">天氣</a>，不過微軟從幾年前開始，時不時地開始在這些應用程式裡面塞廣告……</p>]]>
        <![CDATA[<p>總之要減少這些內建廣告的最簡單方法，就是直接修改系統的 <em lang="en">hosts</em> 檔案（對這項操作不熟悉的話，建議使用微軟自己提供的 <a href="https://learn.microsoft.com/windows/powertoys/hosts-file-editor" lang="en">PowerToys Hosts File Editor</a> 工具），把跟廣告有關的網域名稱擋掉。<p>

<p>目前我擋掉的是這些：</p>

<ul>
<li>adsdk.microsoft.com</li>
<li>m.adnxs.com</li>
<li>msft-ssp-apac.adnxs.com</li>
<li>msft-ssp.adnxs.com</li>
<li>ad-delivery.net</li>
<li>securepubads.g.doubleclick.net</li>
<li>ads.as.criteo.com</li>
<li>ib.adnxs.com</li>
<li>shftr.adnxs.net</li>
<li>eb2.3lift.com</li>
<li>px.ads.linkedin.com</li>
</ul>

<p>註一：在 Outlook 裡面還是會看到「<samp>升級您的帳戶：取得最新的進階版 Outlook</samp>」廣告，這大概是寫死在程式裡的；不過若切換到「<samp>焦點</samp>」檢視就看不到這個廣告了。</p>

<p>註二：有可能需要把「天氣」的快取也清乾淨，它位於 <samp><var>%LocalAppData%</var>\Packages\Microsoft.BingWeather_8wekyb3d8bbwe\LocalState\EBWebView\Default\Cache\Cache_Data\</samp></p></p></p>]]>
      </description>
      <guid isPermaLink="false">6451@https://jedi.org/blog/</guid>
      <dc:subject>hack</dc:subject>
      <dc:date>2025-08-02T09:59:23+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>聽覺功能障礙試算表更新</title>
      <link>https://jedi.org/blog/archives/006450.html</link>
      <description>
        <![CDATA[<p>今天（2025 年 8 月 1 日）教育部新的《特殊教育學生及幼兒鑑定辦法》生效（修訂內容請參考我先前寫的《<a href="https://jedi.org/blog/archives/006422.html" title="教育部預告「身心障礙及資賦優異學生鑑定辦法」修正草案 | Jedi's BLOG">教育部預告「身心障礙及資賦優異學生鑑定辦法」修正草案</a>》），我趁機把<a href="https://jedi.org/blog/archives/006115.html" title="TCF 新制身心障礙鑑定&#x2E3A;聽覺功能障礙試算表 | Jedi's BLOG">聽覺功能障礙試算表</a>更新到 2.7 版。</p>

<p>此外，雖然衛生福利部新的《身心障礙者鑑定作業辦法》要<a href="https://jedi.org/blog/archives/006436.html" title="衛生福利部預告「身心障礙者鑑定作業辦法」修正草案，比現行規定略為寬鬆 | Jedi's BLOG">到 2025 年 9 月 1 日才生效</a>，但實際試算之後發現跟現行規定的計算結果沒有出入，所以這一版一起寫進去，下個月不再更新。</p>

<p>這一版還補充勞動部 2022 年 3 月 2 日公告的《勞工職業災害保險失能給付標準》試算供參考。</p>]]>
        
      </description>
      <guid isPermaLink="false">6450@https://jedi.org/blog/</guid>
      <dc:subject>occupation</dc:subject>
      <dc:date>2025-08-01T08:40:11+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
        <item>
      <title>OTC 助聽器在台灣</title>
      <link>https://jedi.org/blog/archives/006449.html</link>
      <description>
        <![CDATA[<p>幾年前，<a href="https://www.fda.gov/" title="U.S. Food and Drug Administration">美國食品藥物管理署</a> <span lang="en">(U.S. Food and Drug Administration, FDA)</span> 基於促進聽力照護服務可及性的企圖，增設「<a href="https://www.fda.gov/medical-devices/hearing-aids/otc-hearing-aids-what-you-should-know" title="OTC Hearing Aids: What You Should Know | FDA">OTC 助聽器</a>」這類醫療器材。霎時之間，許多原本做消費性音樂耳機廠商摩拳擦掌，認為這是獲利機會，想要投入這個市場。</p>

<p>先不論美國這項政策對美國的聽力照護可及性有多少幫助，令人意外地，台灣也有許多消費性耳機廠商想要投入，一方面挑戰美國的 OTC 助聽器市場，另一方面也認為可以開拓在台灣的產品線。</p>

<p>我覺得這是非常躁進且欠缺實際理解的舉動。</p>]]>
        <![CDATA[<p><dfn>OTC 助聽器</dfn>字面上的意思是「臨櫃 <span lang="en">(over-the-counter)</span> 銷售」的助聽器，核心定義是由<em>銷售人員</em>直接在商店櫃台販賣的助聽器；在這個核心定義之上，OTC 助聽器是一種本質上<strong>不驗證助聽處方目標</strong>、<strong>不透過聽力師提供專業服務</strong>的助聽器，因而也稱為「無處方助聽器」；在 FDA 的規範中，由於這類助聽器將由使用者在未經監督照護的情況下自行調整，所以對其增益效能、飽和輸出音量等也有限制，只適合給「覺得自己聽力損失程度不怎嚴重」的成年人購買使用。</p>

<p>台灣在過往幾十年間，幾乎沒有什麼「由聽力師提供專業聽力照護服務」的營業模式；台灣從來沒有任何法規規範「銷售助聽器、提供助聽器服務」的人員資格，在商言商，賣助聽器跟賣吸塵器的差別不大，能說善道的嘴才是市場主流，聽力學素養與專業在利潤面前顯得微不足道。</p>

<p>的確在近十幾年內，陸續有受過完整養成訓練的聽力師（指聽力學系所畢業、經考試院專門技術人員高等考試及格後取得證書的<dfn>國考及格聽力師</dfn>）投入助聽器零售市場服務，但是主要的雇主（或股東）還是本來那些專精於進銷存（進貨、銷售、庫存管理）的醫療器材商，迫使聽力師朝向穿著白袍的銷售員發展，理想中的聽力照護專業在屢屢妥協之中逐漸湮滅殆盡。</p>

<p>最直接的證明，是聽力師進入助聽器零售市場的這些年後，在台灣仍然很難獲得理想的聽力處遇。助聽器業界發現只要靠著話術，一個小時內就有機會賣出要價三、四十萬的助聽器產品，何必投入十幾小時（分成多次，不是一口氣）認真進行完整的聽力學診斷、探求及釐清個別化聆聽活動需求、共同設計及實施聽力處遇計畫、選擇及驗證助聽器處方？</p>

<p>整個業界都如此銷售助聽器，持續超過四十年，結果嚴重扭曲的錯誤印象深植民眾人心。缺乏完善的聽力處遇，造成價格二十萬的助聽器產品只發揮三萬元價值又如何？各家廠商同樣亂做，價格六萬元的助聽器也只能發揮一萬元價值，消費者還是會甘願花二十萬購買高階助聽器產品，沾沾自喜地以為一分錢一分貨。</p>

<p>台灣的市場現實，就是把先進國家「處方助聽器」等級的產品經營成「無處方助聽器」模式。在這個前提之上，符合美國「OTC 助聽器」的產品哪裡來的利基？</p>

<p>如果 OTC 助聽器產品要對消費者有競爭力，勢必得壓低價格，經銷商的利潤空間也隨之降低，尤其台灣倉儲店面租金佔據大幅經營成本，除非能把批發價格降到新台幣百元左右，重現 40 年前百倍利潤（當年助聽器進貨成本約一百元、售價約一萬元）的光景，否則很難打入店面市場。</p>

<p>OTC 助聽器生產商的另一個盤算是乾脆捨棄店面市場，而走線上銷售的管道。</p>

<p>其實美國早在 OTC 助聽器之前，已經存在多年的 DTC 助聽器（<span lang="en">direct-to-consumer</span>，即「網購助聽器」）市場，充斥著廉價的中國廠牌低階擴音輔具，這些產品性能拙劣，連「助聽器」都稱不上，可是對於那些無力比較輔具產品優劣、無法取得完善聽力處遇照護的消費者而言，至少在價格上很有競爭力&#x2E3A;消費者甘願賭下可能被騙的風險也無所謂的程度。</p>

<p>這些低階擴音輔具的利潤，實際上能夠達到成本的十倍以上乃至幾十倍，對於大量消費者不滿意的退貨情況真的不以為意。</p>

<p>OTC 助聽器即使在規格性能上確實優於低階擴音輔具，進入市場的挑戰卻是在於消費者不認為兩者之間有何區別，或無法理解兩者之間的區別，很難創造足夠的利潤去攤平經營成本。</p>

<p>追根究柢，把助聽器設想成單純的電子器材，妄想靠著堆砌規格來增加賣點，或者迷信「人工智慧」、「大數據」這些潮流術語能夠實現人性關懷，就註定是在自找麻煩。</p>

<p>台灣以生產、代工聞名，幾個世代培養出來的硬體思維掛帥，看到什麼都會先想到做（抄）產品，也只會做（抄）產品；然而台灣根本不缺產品，缺的是完整的服務及業務體系，這是再好的產品也無可彌補的核心基礎。</p>]]>
      </description>
      <guid isPermaLink="false">6449@https://jedi.org/blog/</guid>
      <dc:subject>occupation</dc:subject>
      <dc:date>2025-06-26T19:05:08+08:00</dc:date>
            <creativeCommons:license>http://creativecommons.org/licenses/by/3.0/tw/</creativeCommons:license>
      
    </item>
    

  </channel>
</rss>