[敲打鍵盤] 為什麼台灣的數位親和力之路至少耗時兩百年(中)

前情提要:本文上篇從歷史、文化、法律等面向,說明台灣社會背負的親和力障礙,本篇(中篇)接續未完的話題,從公務體系的文化展開,談談我們在 PDIS 的努力。

內容目錄

公務體系及主管機關

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

我們可以先試著思考:「數位親和力的主管機關是誰?」

許多人的第一反應是「難道不是數發部嗎?」畢竟數發部網站無障礙規範的主管機關。然而並非如此⸺網站無障礙規範放在數發部政府司,該司主要職掌政府數位服務、行政院所屬各機關資通訊系統等的規劃及推動,能夠處理的範圍只涵蓋部分政府機關,形式也非監督或管理;按政府司公開說法,其自身定位為協調角色而非治理角色,提供相關諮詢工具而不涉入處理人民的平權法益。

數發部雖然宣稱將建立完善的無障礙檢測和認證機制,及提供全面的技術支援,包括無障礙設計指南、檢測工具和專業諮詢服務,夢想很美好但現實很殘酷,目前就連數發部提供的檢測工具都還相當不可信

從法規上來看,國家整體數位親和力的主管機關應該是身權法的主管機關⸺衛福部;但身權法第二條第二項規定著涉及各目的事業主管機關職掌者,由各目的事業主管機關辦理,這種法條實際上展現出政治權力關係的現實:任何一個部會都沒有足夠的實質力量能夠去左右其他(平級的)部會;這種「把一件事切割成若干領域,各自列管進行」是台灣政府相當擅長的治理模式,優點是容易產生立即可執行的行動項目,很方便給出交代,缺點是隨著事情面向越發多元複雜,好像每個方面都有作為,但各方面組合起來沒有明顯的進展,幾乎必然導向見樹不見林的結果。

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

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

這裡有個小插曲:數發部掛牌成立後,行政院身心障礙者權益推動小組設置要點沒有跟著修訂,數發部未列入身權小組,自然沒有參與小組會議。我開始在 PDIS 從事顧問服務後注意到這個情況,主動向當時的數發部部長提起,最後終於遊說成功,數發部正式納入身權小組

身權小組雖然接受涉及違反〔身心障礙者權利〕公約之申訴,但其主要任務卻是協調、研究、審議、諮詢、調查,而且每年只有三場定期會議;實際上身權小組也沒有提供接受申訴的窗口,在其網站上僅提供司法院、監察院、行政院所屬若干部會、各縣市政府的陳情電話號碼及網頁。 CRPD 第二次國際審查意見直接點出行政院身心障礙者權益推動小組尚未 在政府內部建立有效的協調機制

實質上能夠對構成各種形式歧視之事件進行調查,並依法處理及救濟的單位,其實是監察院國家人權委員會(以下簡稱人權會);由此來看,人權會更像是台灣數位親和力的主管機關。 CRPD 第二次國際審查意見一方面肯定台灣成立人權會,另一方面指出沒有任何立法措施指定國家人權委員會作〔做〕為獨立機制,以促進和保障身心障礙者的權利人權會網站上的「無障礙網頁宣言」目前還是抄錄研考會版的無障礙網頁開發規範內容,這個版本早已跟不上現今網頁科技。

PDIS 與數位韌性

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

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

我在這個契機之下,加入 PDIS 擔任無障礙設計總顧問;一同加入的夥伴共六人,分別擔任設計制度、無障礙設計、韌性架構、軟體架構、資料架構、應用架構等領域的總顧問,我們因此自稱「HEX 工作小組」。同仁之中,我跟設計制度總顧問的合作最為密切,初期就共同設計製作運用貝爾曼截角的名片,也一起跟世界各國的政府設計團隊交流;我們六人歷經迭代討論,定調出共通的數位韌性願景:

韌性是信任:

系統在變動或極端的環境下,持續提供美好的服務,並能在故障時優雅復原。

我用這個願景來描繪身心障礙者權利公約勾勒的數位親和力:

數位服務的障礙風險並非來自個別使用者的身心功能,而是使用者身心功能與各種 ICF 環境因素之間的錯位失配 (mismatch) 所致。

使用者的身心功能、裝置設備、操作空間場域、情境脈絡等從未停止改變,這是再自然、再正常不過的事。確實理解這個現實,從數位系統的設計階段即納入實際/潛在使用者及使用情境,預先規劃合理的彈性餘裕,就能應對更多樣極端的環境配對,避免數位系統輕易失效。數位系統應尊重個別使用者主動(在作業系統或應用程式)揭露的合理調整需求,促進使用者順利完成相關任務。

上述這樣的數位系統,能夠培植使用者對系統的信任,因為使用者能夠感受到這個數位系統真心協助使用者、能有效回應使用者的期待;即使系統不幸發生災難性的損壞,使用者也更願意等待甚至能協助系統復原,從而增進系統韌性並產生正向循環。

設計制度

設計制度是實現這個願景所不可或缺的工具。設計制度 (design systems) 是一系列(複數型態)用於規範設計的文件,用以確保設計的品質可靠性及一致性;實際涵蓋在設計制度中的文件並不固定,會依機關組織的形態、規模、目標等而有所不同,例如可能包含下列任一種或多種文件:

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

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

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

前代 PDIS期間開發過一套名為「PDIS 設計系統」的設計制度,部分用於成立架設的數發部網站;數發部首任部長在訪談中明確表示 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. 這段說法的意思是,「數發部網站採用的 PDIS 設計系統完全等於英國GOV.UK Design System數發部網站就跟英國政府網站一模一樣。」

訪談播出之後,PDISHEX 設計制度總顧問收到許多不同國家數位服務部門的人員關切,包括英國 GDS 團隊成員,大家都很納悶及好奇,因為兩邊網站明明不一樣,也絲毫看不出數發部網站哪裡採用 GDS 設計制度,是不是哪裡有誤解?

PDIS 設計系統」其實是使用 Bootstrap 5 為基礎,經由修改一部分 SASS 來自訂風格呈現,無論是規範制度或元件庫都跟 GDS 沒有任何相似性。設計制度總顧問跟我討論之後,決定擱置前代遺留的「PDIS 設計系統」不動,重新開發新版「PDISHEX 設計制度」,後來稱為「政府網站設計原則」(註:因為開發經費等因素,這套設計制度後來移轉給資安院接手,部分內容已經跟 PDISHEX 的原始規劃有所出入)。

我們希望這套新的設計制度「具有台灣特色、適合台灣政府機關使用」,設計制度總顧問為此投入大量私人資源,訪談英國尼德蘭德國冰島日本等多國數位政府團隊,跑遍世界各地接洽多位跟台灣有著文化聯繫的設計師,合作發展插圖、圖示、色彩、視覺、字型等設計,開發架設 Lighthouse 自動化檢測儀表板雛形;我在另一邊投入編寫替代文字指南,並準備預計用於設計制度自我親和力宣告的文件模版

在技術方面,設計制度總顧問跟我一致認為 Bootstrap 等網頁開發框架會大幅增加泛用難度及技術債,所以我們從一開始就提倡要以全世界最經典正統的網頁開發框架⸺HTMLCSS 網頁標準為基礎,運用漸進增強策略加上 JavaScript,做為實作設計制度的前端架構,並分別陸續參與全球資訊網協會 (World Wide Web Consortium, W3C) 若干工作小組及社群小組,包括:

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

參與 W3C

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

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

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

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

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

設計制度總顧問跟我都不是政府文官,沒有這些麻煩事,而能夠實質參與。我們利用W3C 帶來的機會,讓我們這套新的設計制度能夠對台灣也對世界有實質幫助。


因為篇幅過長,本文拆成上、中、下三篇。接下來關於公務體系面臨的挑戰,請繼續閱讀下篇

jedi.org: