部落格

:::

摘錄近期 10 篇 Medium 文章

建立所見即所得編輯器的無障礙檢測工具，以 TinyMCE 為例
一個小程式，幫助撰文者製作符合無障礙網頁規範的文章以 TinyMCE 為例，建立小工具檢測文章內容是否符合無障礙規範情境一間企業幫助政府單位架設內容管理系統網站，文章編輯需要使用所見即所得編輯器的高度自由，又要全網站符合無障礙網頁規範。痛點即使有無障礙網頁知識，但只要碰到所見即所得(WYSIWYG)編輯器，網站建立後的文章內容便不再受控。企業：1. 每當網站被抽測時，就需要花費大量時間幫助業主修復。2. 程式需要特別限制必填欄位，但是有點填鴨式，例如 <a> 在某些情況下，不需要有 title 屬性。3. 額外提供寫作的教育訓練。撰文者：1. 如果企業的編輯器有特別限制必填，則一定要填寫欄位，否則無法儲存。2. 不暸解該欄位意義，於是可能流於表象的填寫，對無障礙網頁沒有真正意義上的幫助，例如圖片 alt 的描述可能會比較模糊。3. 被抽測時，文章沒通過無障礙的機率非常高，就只能等待企業修復。解決方案打造一個編輯器內工具撰寫文章時可以即時檢測無障礙網頁規則。提供該無障礙網頁錯誤的撰寫提示，每次錯誤時，撰文者可以學習一些無障礙網頁規範。錯誤提示提供視覺化顯示，例如圖片錯誤的話，應顯示該圖片，並且點擊後可以將滑鼠鼠標移動到錯誤的位置。使用者點擊檢測按鈕時觸發，或是自動即時檢測，但是不能直接跳出錯誤一直干擾撰文者編寫流程，只需要在按鈕文字後加上錯誤數量和改變顏色。例如，當錯誤在 5 個以下，按鈕文字顯示黃色，10 個以上就變成紅色，以提醒撰文者不要累積太多錯誤再更改，但也不打擾寫作。建立指標，例如通過是 100 分，沒通過就按比例顯示分數。可利用遊戲化方式，鼓勵撰文者學習。即使有錯誤，但仍然讓使用者可以儲存，儲存後在列表和檢測按鈕裡，有警告 icon 提示該文章尚未完成無障礙檢測。實作：以 TinyMCE 為例 https://medium.com/media/f5e61f2f8db14e4deea9583a17bfd9b2/href思路制定格式、寫一次規則後，此格式的程式碼，可以輕易的在不同所見即所得編輯器中製作成外掛，才會更能推廣。無障礙網頁規則通常只會新增的比較多，修正比較少，所以當規則第一次寫好後，維護不至於太困難，所以開發者負擔應該不會太多。先以常見錯誤開發，先解決常見問題，再制定更細部規則。要注意編輯器先天限制，假設編輯器本身圖片沒有給 alt 欄位，這時候即便您有檢查到沒寫 alt，也無濟於事。近期未來發展進階檢查編輯器先天不足與客製化工具的搭配，成為獨家功能，進而開啟獲利模式。 LLM 自動修復若成本足夠低了，而且 AI 也能根據上下文給予圖片有意義的 alt 屬性或其他遵循規則，正確率也很高，就可加入自動修復。在檢測分數後，有一顆按鈕點擊後，串 LLM 自動修復該欄位，並且給予適當的值。例如圖片的 alt，LLM OCR 後，自動判斷怎樣的描述會比較好。但不要直接對內文馬上改，而是先提供預覽或是更動的地方，待點擊「同意變更」之類的按鈕後，再異動內文。 LLM 自動檢測或者，乾脆也不用自己寫規則了。如果未來 AI 夠強，只要編輯器工具列放一顆「一鍵自動檢測修復無障礙」就搞定了。額外要注意的地方通常，網頁頁面的標題和副標題，不會在所見即所得的編輯器裡，這很大一部分是因為網頁排版問題。所以，工程師最好在所見即所得的外層，包一層 <article>，重置標籤 h 系列的順序(<article>表示此內容足夠當作獨立一個頁面的內容)。這樣就不需要特別動到編輯器工具，否則，可能要根據網頁的排版，限制編輯器內建的標題從哪個開始。另外，如果編輯器背景是透明，編輯器內的無障礙網頁檢查，可能沒辦法檢測到編輯器內外的問題。例如，編輯器內文字是白色，但編輯器外的背景也是白色，此狀況下，編輯器內的檢測工具，就沒辦法檢測顏色對比。結論這樣的工具最主要是降低有關於達成無障礙網頁的成本，對開發商、撰文者、最終讀者都有利，並且技術難度不高，剩下的就是體驗問題和自動化成本問題。
讓使用者透過 CUI 客製化網站風格
本篇簡單探討如果使用者可以透過 CUI 改變網站排版與風格，進而打破目前由開發者規劃好的體驗，將有什麼好處和壞處什麼是 CUI 這裡指的 CUI，全名為 Conversational User Interface，中文並無統一的稱呼，通常以「對話式介面」、「交談式介面」常見之，也就是常常看到的「聊天機器人」、「Siri」的介面。使用者可以透過這個介面，使用「自然語言」與「系統互動」達成目的。我沒有找到哪一個組織明定 CUI 這個詞到底定義是不是這樣，但應該是隨著技術發展而逐漸形成的概念。例如，我曾經發想過的一篇文章「如果使用即時通訊 UI 來設計購物車結帳流程，會是什麼樣的感覺？」，整個畫面雖然是「對話」，但其實並不屬於 CUI 的範疇裡，因為不符合「自然語言」這項條件。 CUI 起源即時通訊開始興起時，可以視為 CUI 的前身，其人與人「對話」的方式，為現今 CUI 的高接受度提供了使用前置習慣與經驗。當自然語言處理(Natural Language Processing, NLP)技術的開始進步，結合對話的方式，造就各大社群、即時通訊軟體以及網站紛紛開始建立各式各樣的聊天機器人，人與系統間的互動達成資訊自動化處理、減少人工成本。緊接著 Siri 的出現，開始提供文字以外的自然語言與系統互動，人們開始意識到自然語言交流的潛力，也就開始出現各式各樣的家庭控制中心、物聯網生態，例如 Google Nest，但大概也就僅止於此，普遍大家都還是會覺得「很笨」，或是局限在語言支援度不同。如今，LLM 的爆炸性發展，讓人們對未來 AI 紀元的來臨，不再只是存在於小說裡的幻想，而是實質感受到「可能真的會實現」。 CUI 出現方式目前我們可以看到 CUI 有好幾種出現的方式：獨立專屬的頁面：ChatGPT、Gemini、Perplexity、NotebookLM 依附在瀏覽器裡的功能：Edge Copilot、Monica Chrome Extension Edge Copilot 的問答展示3. 出現在網站或 APP 隨時可展開式的：政府資料開放平臺的小幫手政府資料開放平臺的小幫手 TAIDE 的回答情形4. 依附在應用程式裡：Microsoft 365 Copilot Microsoft Office Excel 的 Copilot 使用情境CUI 分類根據「談任務型智能客服」此篇文章，CUI 可以以下三種分類依場景分類依技術分類依範圍分類我認為 CUI 的下一步我認為，CUI 要走的下一步，會是類似 Microsoft 365 Copilot 這種模式，但不僅是在辦公軟體提升生產力，而是一般網站也可以使用。例如，現在我們可以利用 Edge Copilot 查詢目前頁面並問問題，但是問完問題後，答案或結論都是在對話內容裡面，還需要使用者自行點擊對話內容的連結，觸發事件或前往網頁，這裡就形成一個使用體驗的斷點，有一種把Copilot 和網頁切開成不同世界的感覺。如果我能在網站的 CUI 可以問問題之外還能跟網頁互動，那將會再更提高體驗。例如，我在銀行網頁的 CUI，直接輸入，幫我找某張信用卡資訊，那麼網頁就會自動跳到該張信用卡介紹頁，對話內容可能就會是：已經幫您導至XX 信用卡頁面，這張主要是 blah blah blah…。如此，對話跟頁面就會對得起來，也不用一直懷疑對話內容是不是正確的，然後還要去查詢。因為網頁是不是正確的，一看就知道。基於此原理，那麼要實現「透過 CUI 客製化網站風格」的話，首先就會排除瀏覽器擴充程式的方式建立，因為會有安全性問題，瀏覽器擴充程式要跟網頁進行深度的互動一定會遇到很多限制。再來，因為是一般網站，所以排除放在專屬應用程式裡的方式，雖然某種程度很相像，但專屬應用和一般網站仍舊有所差異，因為一般網站改變排版和風格比較容易，您可以想想如果您改變了 Excel 的排版和風格。第三，依定也是排除專屬網頁的形式，因為整個介面都是對話，結果也在對話裡，沒辦法跟網站互動。也就是說，要完成「透過 CUI 客製化網站風格」這件事，使用常見的「點擊按鈕展開視窗」這種會比較適合，因為是網站開發者自行建立，應該可以針對 LLM 的回應，執行下一步的互動，並且要可以儲存狀態。透過 CUI 客製化網站風格有什麼好處和壞處以下只是我大概腦海一閃的想法，應該會有很大的思考不周，就當作是發想筆記也好，會陸續補充。對開發者可能的好處：不再需要維護多種版面，什麼 dark mode、multi style mode、圖片模式、圖文模式等，都給使用者決定就好。也就是NN Group 在「Generative UI and Outcome-Oriented Design」提到的 Generative UI (GenUI) 概念因為只做一種版面與風格，可以將重點放在資訊的傳遞、效能以及優化 CUI 有關於業務的對話邏輯和操作上。對開發者可能的壞處：品牌識別可能要想別的方法塑造，因為網站的排版、風格甚至網站體驗都交由使用者決定了。安全性問題：也許有可能使用者透過漏洞，對網站造成了某種影響。對使用者可能的好處依據自身狀況，調整喜歡的顏色、排版瀏覽網頁補強無障礙網頁技術設定不足之處，例如：透過 LLM 的程式碼功能，將原本只通過 AA 等級的，改成可以通過 AAA 等級的。對使用者可能的壞處開發者可能會開始偷懶，變成什麼東西都要使用者自行設定，排版變得比現在的 LandingPage 更制式化 DEMO 這是一個很笨的程式也是本篇文章發想起源，我的目的是希望當網頁不符合無障礙 AA 時，使用者可以透過 CUI 補救網頁。但這個很笨的程式只能回答出 CSS ，並且被我特意放置在最後一個引入，才能覆蓋之前的 CSS。希望透過這樣一個小 Demo，能激發出大家的靈感。結論我的理想上網站會有一個客服小幫手，這個小幫手除了可以諮詢網站內容，也會自動引導，也可以改變網站外觀，甚至是要填寫內容時，就直接生成在網頁裡而不是生成在對話視窗裡等等的「下一步」動作，對話視窗內只要留下「復原」或是其他動作快捷按鈕等附加功能。因為這個「下一步」，所以開發者勢必要把精力放在 CUI 的業務對話邏輯和操作上，更近一步把斷點消除，當然，這個「下一步」在什麼時間點要吐出什麼專業的內容跟網頁互動，應該又是另一個訓練的過程，這我就不清楚了。總之一句話，CUI 會變成網站的「控制中心」。其他參考來源： https://blog.tpisoftware.com/ai/chatbocui/ https://en.wikipedia.org/wiki/Conversational_user_interface https://medium.com/uxeastmeetswest/59aa90c4322c https://store.google.com/tw/product/nest_audio?hl=zh-TW https://zh.wikipedia.org/zh-tw/%E8%87%AA%E7%84%B6%E8%AF%AD%E8%A8%80%E5%A4%84%E7%90%86
UX 三刀流 2024 春季班期中作業
作業內容挑選一篇 UX 案例，進行介紹與評論挑選主題無障礙挑選文章 UX Case Study: Slack accessibility redesignhttps://medium.com/@izzy-shehan/19aa6eb6bfae 文章介紹此為 2019 的文章，作者設定了一個擁有閱讀障礙的新進人員情境，並指出 15–20% 的人擁有閱讀障礙為數不少，Redesign 的目標是幫助有同樣情況的人在即時通訊軟體上溝通順利而不會遭受批判。此篇文章以 Slack 為範例進行重新設計，並且聚焦在 Slack 的可讀性方面有些問題，例如顏色對比、資訊結構權重雜亂、沒有輔助使用功能等。並且根據這些缺點提出改善計畫，大致如下：調整顏色行距、間距調整，縮短收合側邊頻道選單時間提示的改善提供文字轉語音服務文章有鎖定位置功能，以便觀看與回應文章評論在僅有閱讀障礙這個條件下，作者提出的改善的確是能大幅增加閱讀的舒適程度、撐出畫面的呼吸空間以及在畫面上固定會呈現在畫面上的物件讓人感覺到放心，最後文章的結論使用動畫模擬操作過程令人一目瞭然，雖然這篇文章很短沒有細部闡述，但其實內含觀察、思考、實驗、解法與結論的完整文章。不禁在想，如果更深入一點點探討，能做到什麼程度？所以從 2018 年之後再也沒碰過 Slack 的我，又再次打開它。 Slack 現況觀察關於 Slack 的無障礙，在協助工具頁面上有提到一些，還有一些關於包容性議題的文章。另外在系統的設定裡，有顏色工具、輔助工具、還有使用鍵盤時會跳出快捷鍵提示。從左至右為： Slack的無障礙設定、主題色選擇、鍵盤操作規定「第一次進 Slack 系統」的情境在不更動任何設定的情況下，很明顯，在顏色方面選單的問題很大：在預設的主題色之下，選單大部分顏色都過不了現有的無障礙規範再過了六年之後，仍舊是沒辦法符合現在無障礙的規範，不免跟 slack 的協助工具提到的有衝突，是蠻諷刺的。列舉一些技術影響行為的問題如下：自定義快捷鍵，導致鍵盤使用者更改與限制鍵盤 Tab 使用方式，導致沒辦法以平常瀏覽網頁的方式進行瀏覽沒有定位點，沒辦法以平常瀏覽網頁的方式跳躍資訊階層雖然在 UI 上有顯示，但技術面上沒有實行，導致鍵盤使用者沒辦法依照標題層級跳躍沒有做 RWD ，如果使用者的螢幕解析度較差，可能會不好做事使用者上傳圖片時，沒有 alt 選單顏色沒通過以及沒有標題層級能透過設定改善更多嗎？在設定裡面，多媒體能設定要不要自動播放、訊息的通知設定以及一些文字格式等，但能設定的東西不多，自然改善的效果有限，只能從源頭就先做起才是最好的方式。結論稍微初步評估了 Slack 的無障礙之後可以發現：現有網站只要稍微多做一些無障礙細節的 redesign，就能幫助到更多人容易地使用，不需要大改 UI 就能夠獲得超出預期的收穫（除非是動線的設計真的有出大問題）。設計時最好不要改變平常瀏覽網頁的主要習慣（除非是在做創新、獨家的應用），否則使用者學習曲線和教育訓練成本會大增。基本上無障礙越早進入越好，否則到最後會累積越來越多問題，修改的成本會大幅上升。而且既然宣稱了對無障礙的重視，那就真的要去實踐，不然除了被看破手腳，在歐美可能還會吃上官司。
我的第一個 Chrome 瀏覽器擴充程式：Report Website issues
大概七年前看到同事有做了一個瀏覽器擴充程式，當時的我也是躍躍欲試，沒想到就這樣過了七年，直接變成大叔了。這次在想 2023 鐵人賽的題目，突然想起了這件事，於是就快速地學習了一下，暸解從 0 到 1 的過程，打鐵趁熱寫篇文章記錄一下。先上擴充程式連結：https://chrome.google.com/webstore/detail/report-website-issues/ligflmchialjgapdcgadgibgkabckglh Chrome 瀏覽器擴充程式：Report website issues目標與需求接觸無障礙網頁設計之後，都沈浸在開發無障礙 UI Framework。後來想想好像應該開發一些成本低、易用、立即有幫助的簡單功能，潛在幫助大家，讓上網的環境更好，於是就有了以下理想、目標、需求：使用者可以簡單回報目前瀏覽網頁的問題：讓使用者輸入最少的情況，只收集「使用者發現的問題分類」、「目前網址」、「時間」、「作業系統/瀏覽器資訊」以及「聯絡資訊（選填）」。我透過收集到的資料，回傳給網站客服。網站客服收到網站回饋。網站工程師修正問題。使用者下次再上網發現問題解決，開心了。我透過收集資料間接幫助修網站，開心了。網站客服發現使用者黏著度上升，開心了。網站工程師修正程式碼提升技能，開心了。可能會有人覺得使用者直接面對網站客服不就好了嗎？我的想法是處於遇到障礙的情境下，使用者跟網站客服的溝通大部分都是雙輸的局面，尤其碰到其實是技術層面的問題。例如使用者說「我的鍵盤沒辦法瀏覽你們的網頁」，但客服卻說「我的可以喔，麻煩您再試試」，然後差不多就鬼打牆，兩邊都覺得對方很爛，因為前者是談鍵盤焦點，後者可能只是按向下鍵捲動畫面。這是個簡單例子，主要描述認識的東西不同，解讀不同。但我也不想讓使用者看太多字或輸入太多東西提高回報障礙，所以中間墊一層可能是比較好的方式，等日後 AI 變很強，就可以幫忙通靈了。那為什麼要用瀏覽器擴充程式？因為這樣子就不需要讓使用者輸入作業系統/瀏覽器版本、時間、網址了，只需要勾選分類，送出！比起前往表單，使用擴充程式的方便性更大。現實考量因為個人開發、只會切版跟簡單 javascript，也不會寫後端，所以必須想一些簡易的方法，還有思考瀏覽器那麼多種要挑哪個來做？於是開始思考眾多限制下的實行方案： Chrome 市場占比高、安裝意願也高，所以只鎖定 Chrome。有需要之後再做 Safari、Firefox、Edge。Edge也可以裝 Chrome 的擴充程式，所以選 Chrome CP值很高啊～！不會寫後端但需要將得到的資訊儲存，然後也因為只鎖定 Chrome，所以只想用 google 的產品：google sheet。要將資料直接存到 google sheet 還是要寫很多程式，所以想到可以跟 google sheet 溝通的 google form，它可以跟 google sheet 連結。實驗如果使用 html 的 <form> ，能不能將資料塞進 google form，於是找到了這篇文章：https://spreadsheet.dev/submit-responses-to-google-form-apps-script 寫一點點 javascript 提升UX，應該不是難事，不知道就問 AI 學習 Chrome 擴充程式確定以上都能實作後，就開始學 Chrome 擴充程式要怎麼做，於是直接去翻最新的書：https://learning.oreilly.com/library/view/building-browser-extensions/9781484287255/，或是一些參考連結（注意開發版本）：你知道這是什麼嗎？ Chrome Extension MV3 With Vite :: 2022 iThome 鐵人賽 Chrome Extension 開發與實作 :: 2017 iT 邦幫忙鐵人賽 [Chrome Extension] API 筆記 | PJCHENder 未整理筆記簡單介紹一下開發 Chrome 瀏覽器擴充程式內容： manifest.json：最重要，包含了擴充程式的所有設置、描述和功能概要，例如需要使用到的權限。如果有使用第 2 點到第 6 點，都要寫在 manifest.json，而這個檔案在最後上架的時候， google 會檢查。最新版本是 V3 ，所以在挑選線上參考連結閱讀時，要注意版本。 Background Script：背景中運行，通常用來監聽事件和處理請求。 popup.html：在擴充程式按一下跳出來的視窗畫面。 options.html：在擴充程式按右鍵，裡面一個叫「選項」的選單按鈕，點擊後會另開視窗，是一個獨立頁面，可以在這個頁面做更多的功能、描述與使用者互動，各位可以開開看自己常用的擴充程式在這一頁有什麼樣的互動。 Content Script：目前所在網頁與擴充程式的交流，例如用了擴充程式，就讓目前網頁有下雪效果。 devtools.html：可以建立一個檢查程式碼時的頁面這次實際用到只有 1, 3, 4，實作完之後，如何測試 Chrome 擴充程式呢？其實很簡單：在 Chrome 的右上角「…」> 擴充功能 > 管理擴充功能打開「開發人員模式」，在左側會有三個按鈕選擇「載入未封裝項目」再選擇你的開發資料夾「開發人員模式」按鈕與「載入未封裝項目」按鈕位置示意圖然後每次修改後，都需要更新擴充程式，更新按鈕在卡片的右下角，點擊後再重新測試你的擴充程式。擴充程式列表裡的項目上架與發佈確定都沒什麼問題之後，就要到 Chrome Web Store Developer 註冊與上架 https://developer.chrome.com/docs/webstore/register/ 跟著文件指示註冊註冊完後需要付款 5 美元開通進到開發者 Dashboard 畫面開發者儀表板畫面示意，左側為選單，右側為列表按新增商品跟著指示走，把資料填一填即可，大致如下：套件壓縮檔可以放 Youtube 連結、首頁連結等可以放五張螢幕截圖，1280*800 或 640*400，JPEG 或 24 位元 PNG (無 alpha 透明層)，至少 1 張小 icon：440*280 Banner：1400*560 可以創建 GA4 資源但有一個重點是，如果你有需要用到使用者的權限，是需要描述清楚的，而且需要附帶一個隱私權政策的網址。如果你沒有，可以使用免費的線上服務，創建一個頁面，裡面寫好隱私權政策的內容，再把網址貼進去即可。最後就是提交了，審核時間不一定，我等了三天，看 Google 心情，後續每次修改，都需要再提交一次，所以如果是要經營的話，要注意上架審核的時間，如果時間急迫又被退件，那就麻煩了。但應該會有不重新審核就可以更新內容的技巧，但那離我太遠了。總結雖然只有用到簡單的 Html、CSS、Javascript 沒遇到什麼困難，但其實這樣就可以打造一個對人有用的產品了，覺得設計師/工程師們都可以多嘗試一點，說不定一個爆紅的產品就又出現了。而我也只想要用這樣可以快速、不複雜的方式打造產品，看能不能多幫助上網會遇到困難的人，能幫一個是一個，所以也用了 ChatGPT 幫我翻譯內容成英文，放到 Producthunt 上看有沒有人會看到而使用。 https://medium.com/media/ebd479cd2d787a57de1f5f9cac59edb0/href最後，邊練習擴充程式的同時，2023 鐵人賽的題目我也想出好了，希望可以順利完賽～！ Neil's Page
我真的需要一個生成式 AI 工具來產生整份網頁設計稿嗎？
Framer AI 使用後的簡易心得 Framer AIChatGPT 問世後，AI 各領域引起了關注，在靈感、知識、素材方面我也都有使用，非常方便。但如今我試用了 Framer AI 之後，我的心裡有這種念頭出現：「我真的需要一個生成式 AI 工具來產生整份網頁設計稿嗎？」這個議題很廣，而且目前各廠商都只是在試驗各種可能，但我用完之後是非常明確產生了這個疑惑。考量到的點有：如何維護？先假設 AI 產出了一個符合我心中 100% 的 UI ，這種情況下如果我只是要修改某個頁面內容，但又不想要破壞整體性，該如何下 prompt？變成我的心思都在想怎麼 prompt，不是專注在設計修正。複雜頁面給的 prompt 會不會太複雜？比方說我給了以下一段文字：「請使用極簡風格、溫暖色調製作網頁，網頁內容必須有頁首、主要內容、頁尾區塊，頁首要有 logo 、選單，選單內的選項要有網站導覽、常見問答、登入，頁尾要深色背景、有logo、隱私權政策連結、copyright 資訊。主要內容分為…」我打到這裡手就痠了，要產出一個我真正想要的內容，必須很深入的描述整個頁面結構，可能要寫出一篇作文了。這跟用 AI 生成照片的過程，CP 值差太多了，然後部分頁面是我要的、部分頁面不是，又回到如何維護問題。電腦效能，設計資源落差將擴大！跑繪圖電腦本身就要有一點等級，再加上 AI ，效能當然要夠強，才能節省時間，然後每次提到這個我們都會想到「啊～以後的電腦運算能力會多強多強…以後就很快很輕鬆」，包含我自己也會這樣，但我們也常忽略軟體面也會更新，所以根本沒有所謂的「很快很輕鬆」這回事。另外，我們也常忽略的通用設計議題，當一個地區或某些人用的設備可能稍微老舊，就可能沒辦法用到新的技術，資源取用就產生落差。生成出來的包含 RWD ，有必要一開始就生成這些？內容都還沒確定下來就在想 RWD 真的是太早了。快速心得是這樣子，所以來下個結論局部特殊鑽研的 AI 功能對於網頁設計來說可能才是好事，較具有靈活性，負擔也比較不會那麼重。例如，我先使用專門研究設計系統的 AI ，產出一份我要的設計系統，包含規範、文件和元件庫，然後請 AI 記住以後都要遵循這個最高原則實行。當我設計 Hero 區塊時，生成 Hero 區塊的幾個排版讓我選擇，其中細項修正例如照片去除物體、影片加聲音、插圖換姿勢、目標物視角修正等還可以用 AI 調整。使用目前已經很流行的 ChatGPT，幫忙文案 SEO 最佳化。將某個區域選取，請 AI 幫我根據設計系統重新修正，包含排版、文案、按鈕位置等。這些都確定後，再用專門產出 RWD 的 AI，選擇參照哪個設計系統，幫我產出網頁 RWD 用、原生行動裝置使用的各項尺寸 UI 稿、原生行動裝置需要用的圖檔等。所以我只需要維護內容最主要、最多的畫面就好，其他用生成的。而以上的這些功能，以 Figma 來說，都只是 plugin 而已，無用無損失，局部 AI 也降低電腦使用的負擔，也激發很多人開發更好用的 Plugin，即便之後 Plugin 沒有維護了，也很容易取得新的替代品，就算沒有替代品，也就是回歸到原本的狀態而已。而又因為我們使用了 AI 產出設計系統，除非 Figma 重大更新，例如命名規則功能產生變化，不然外掛不能用都是小事罷了。也就是說，對於我而言，工具的靈活性才會是重點，因為設計師的腦不斷的在發想，隨時就需要快速修正與驗證。當然 Framer 也可能只是先推出這個 MVP ，再進行後續優化，到時當然樂見其成。現在來正式回答一下問題：「我真的需要一個生成式 AI 工具來產生整份網頁設計稿嗎？」「我不需要，請讓我專注在需要解決的問題，而不是寫 prompt 作文。」 Neil's Page
為什麼我愛上了在設計與切版時使用 Emoji
越少依賴，就越不會出問題，且越貼心。自從專注在無障礙網頁設計之後，始終有一個問題一直盤旋在我的腦海裡，那就是「要如何使用 icon 才能達成好的無障礙設計體驗？」，而在回答這個問題之前，則是要先理解什麼是 icon 以及 icon 會如何影響整個網站視覺。什麼是 icon ? 根據維基百科定義：圖示（icon，中國大陸、香港作圖標）：廣義上指所有「有指示作用」的標誌，在中文中，一般指電腦螢幕的桌面上，用來「指示」使用者執行各種操作的圖像，作為字元顯示的「重要輔助」。應該蠻好理解的，也就是「有指示、輔助作用的標誌」。但同時也點出了第一個問題：icon 很常被拿來純裝飾用，或單獨使用。 icon 會如何影響整個網站視覺？既然是輔助性質，那當然就是 icon 要去搭配主要視覺。例如主視覺是可愛、活潑，通常都會搭配圓角、線條相較粗的 icon，如果主視覺偏向精明幹練、專業的話，通常會搭配直角、線條較細的 icon，來保持整個網站風格的一致性。一樣都是線條類型的icon，左圖呈現風格較為可愛圓潤(https://designmodo.com/linecons-free/)、右圖則銳利幹練(Icons — Windows apps | Microsoft Docs)。所以通常不建議使用兩種以上的 icon 系統，因爲會讓視覺上有怪異的地方，即使是相同系列的 icon，只要粗細不同，體驗就會差異相當大。這裡引出了第二個問題點：切版維護時 icon 不夠用，就會自建或拿別套 icon 來使用。理解了前兩個問題後，回到了我們的核心問題，因為設計跟切版都會影響到，考量切版層面會碰到比較多問題，所以先從切版的角度切入，最後回頭影響設計實務上會比較合理一點。先整理一下剛剛碰到的問題： 1. icon 很常被拿來純裝飾用，或單獨使用：如果只是被拿來用成背景裝飾，那不太會有問題，因為就只是個裝飾，不需要去解釋，有問題的會是在單獨使用，在做無障礙網頁設計時，一般建議 icon 與文字一起使用，或是文字在畫面上隱藏，但在報讀軟體中會讀出來。 <button> <span>訂閱電子郵件</span> <i class="xxx"></i></button> <button> <span class="visually-hidden">訂閱電子郵件</span> <i class="xxx" aria-hidden="true"></i></button> 但實務上也會碰到這樣的情況： <button> <span class="visually-hidden">訂閱電子郵件</span> <svg> ... </svg></button> 然後因為 freego 掃描時會去掃 <svg>，會發現沒有 title，然後 svg 的 title 又要放在第一個子項目，所以又要改成： <button> <span class="visually-hidden">訂閱電子郵件</span> <svg> <title>email icon</title> ... </svg></button> 然後 svg title 又不希望被報讀出來，所以再改一次： <button> <span class="visually-hidden">訂閱電子郵件</span> <svg aria-hidden="true"> <title>email icon</title> ... </svg></button> 或是乾脆直接在 svg 使用 aria-labelledby： <button> <svg aria-labelledby="abc"> <title id="abc">email icon</title> ... </svg></button> 或是直接放棄，就還是維持 icon 搭配文字： <button> <span>訂閱電子郵件</span> <svg aria-hidden="true"> <title>email icon</title> ... </svg></button> 相信到這裡你已經發現到，光是這樣一個簡單的情境，就可以使用很多種不同的方式寫出來，甚至還會被規則、掃描軟體所影響，逼得你不得不拐很多彎才能達成。可以參考一下光是無障礙設計，Font Awesome 就得花一大篇幅再寫注意事項。 2. 切版維護時 icon 不夠用，就會自建或拿別套 icon 來使用。這是很難避免的一種情形，例如客製化的軟體、不講武德的客戶或是專有名詞但又想要有個 icon ，面臨到這種問題時，比較在乎的可能就會自己模擬 icon 風格，畫完送進去類似 icoMoon 的工具產出 iconfont，再引入到檔案。而不在乎、趕時間、或是原本使用 fontawesome 但本身 UI Framework 也有提供 icon的情況，就會直接去拿另一套 icon 來引入，就會造成風格混亂。以上兩個問題，還只是從最源頭的問題發現的，接下來還有實作上的問題，讓我們來一一釐清。 3. 引入一套 iconFont ，就會耗損工時就拿最常見的 Font Awesome，最新版本還要先到後台設定才能開始引入： Font Awesome 6 要先進到設定裡面要進到這裡來，你還得先經過註冊帳號的一系列流程，最後才能拿到手應用。再來，應用時，又有分 Html 、Vue 或是 React。以 Vue 為例，可能還要先跟團隊決定是要用 component 形式的寫法，或是一樣使用平常比較習慣的寫法 <i class=”xxx”></i>，然後寫程式的期間，後者還會碰到有時候沒轉成 svg 的情形（因為 watch 只有一開始偵測到才變成 svg）。再來，import 的時候，可能還要專門弄一個 plugin 檔案（Nuxt 專案的話），接著，又可能會碰到 typescript 的問題跟其他問題，因為層層依賴，所以會有各式各樣的 bug 等著。再再來，每次用的時候，都要把 Font Awesome官網開起來以便隨時查詢代碼、複製代碼或下載圖檔。再再再來，如果客戶使用環境是不能對外連網，就得把整包載入。再再再再來，客戶使用的是 IE 為大宗………. 以上這些，如果目前正在閱讀的你是前端設計師/前端工程師，可以回想看看，這些時間是不是都浪費掉了。我踩過了這些坑，痛到不行。所以後來團隊在開發 Piman 無障礙 UI 框架和延伸的專案時，我們盡量直接使用 Emoji，為什麼呢？符合使用者當下使用的作業系統、服務：emoji 會隨著不同環境而改變，這是最自然的方式。Can I Emoji? (emojipedia.org) 沒有依賴關係：因為是 Unicode。不用需要前置作業：因為是 Unicode 。不用考慮瀏覽器能不能用：因為是 Unicode。不需要考量寫法或是怎麼通過無障礙設計規範：因為是 Unicode。依然可以展現出想表達的意思：例如 page 404 就可以用個尷尬的笑臉，報讀軟體也會把這個「情緒」給表達出來。現代人已經用的非常習慣，甚至取代貼圖了，辨識度佳。可以無痛轉換風格，例如使用 Google Noto Emoji，同樣的使用方式，轉換成不同的風格，不用改寫任何一個 html 內容，只需要引入 font 和寫 font-family。可使用快捷鍵快速尋找，例如 Mac 上如何使用Emoji 表情符號？使用Emoji快捷鍵即可達成? — 瘋先生 (mrmad.com.tw) 當然，缺點也是有的：可能會喪失視覺風格一制性：雖然有這個疑慮，但我個人覺得還好，因為就是視為 emoji 就是個顏文字而已，不是「特別」使用的圖示，所以不太會破壞主視覺。還是解決不了 icon 不夠用的情形，尤其是客製化的情形，而且 Emoji 會隨著環境變化，反而使這個問題更糟，例如在 IE 可能就是黑白，但客製化的 icon 卻是彩色的這種尷尬情況。 Noto Emoji 載入完畢前，呈現會是系統的 emoji 樣式。舊版本或不同服務可能會缺少某些 Emoji，所以不能挑太特別的使用。為什麼 emoji 在不同平台長得不一樣？ | TechNews 科技新報太多的表情符號會造成困擾，只能適時使用。Emojis and Accessibility: The Dos and Don’ts of Including Emojis in Texts and Emails | Easterseals Blog 結論我個人還是看好在無障礙網頁設計上使用 Emoji ，總體來說利大於弊，而且能有效降低工時、減少依賴，可以把時間、資源留給優先度更高的事。而在無障礙網頁設計、web3 必定是未來趨勢的前提下，相信 Emoji 的發展會更蓬勃、更多元！ UI 設計師/前端設計師/前端工程師的你會怎麼想這議題呢？歡迎一起討論！ https://medium.com/media/fc7a605d98c7b947a0adbaf34a3bdd9a/href
Ballpark — 適合線上驗證想法的問卷服務
Ballpark — 適合線上驗證想法的問卷服務前幾天收到 Prototypr.io 電子報，發表了一款線上問卷新服務。來寫寫快速使用後的心得。 Ballpark 官網一看到這封電子報，還沒來得及看完內容我就迫不及待點 CTA 按鈕了！內容如下：前幾天收到 Prototypr.io 電子報，內容提及了 Ballpark 可以把問卷跟 Figma Prototypes 做結合。嘿！這實在是太香了，以下娓娓道來有夠香的原因：目前 Beta 版的價格： Ballpark — Plans and pricing. Start for free. (ballparkhq.com) 有點養套殺節奏，但 Free 版本我覺得非常適合個人、小型工作室以及敏捷開發收集回饋使用。雖然只能建立一個 Project 而且不能封存，但是 Responses 跟 Team members 都是 Unlimited，也就是說可以利用這個服務跟團隊一起快速驗證假設，之後要再開新專案，就先自己手動整理一下資料，或是申請新信箱。免費版本雖然只能用一個專案，但其他優點覺得很可以！問卷與 Prototype 自然的融入，體驗無斷點：以往發線上問卷的時候，想要測試 Prototype 時還要另外發一個連結，點擊後就會跳離問卷，會使得一致性的體驗消失，甚至受測者玩完之後，再回到問卷已經不知道正在做什麼事了。利用 ballpark ，問卷填一填，接續測試，測試還可以給予小提醒，之後趁著記憶猶新再繼續填問卷，體驗無斷點，試試就知道優點！這是官網提供的 example，簡潔明瞭的設計風格、RWD 、QRCode 也都已產出方便分享。第五個步驟就會開始進入 Prototype 的測試，玩完結束後，趁著記憶猶新，直接追問想知道的答案，而且不能再回頭測試了！目前 Prototype 可以接受 Figma 與 Marvel，除了 Prototype 之外，也可以加入影音。編輯簡單，專注在思考如何發問：也許是因為還在 Beta 版以及目前目標使用者很明確，所以沒有像其他發展已久的問卷系統有多樣化的功能，但我個人特別喜歡這種單純，可以讓我專注在思考問題、選擇適合的題型以及加強問卷與 Prototype 之間的聯繫。 ballpark 目前提供的題型答題前的設定：根據不同的題型，會有不同的設定，例如 Prototype 題型，會有是否使用攝影機、麥克風以及螢幕錄影。而每個題型都有的就會有增加影片導覽以及必填設定。如果是比較需要理解的題目，這個前置作業就會變得很重要，例如降低使用者焦躁的心情等等，非常實用的功能！ Summary 與 Responses: 問卷設計完後，下一個重點當然是收到回饋後的分析，畫面如下：除了一般常見的統計之外，我比較想要知道 Prototype 他如何分析。點擊 Heatmap 後，會出現最常點擊、移動熱區以及兩者合併的圖，左下角還可以下載圖片。下方資料區還提供各種數據資訊。點擊 All Responses 會跳到這頁，然後突出 Prototype task 的地方。連 Prototype 常見的簡易分析都有做到了，這真是個殺手鐧！除了在前台的體驗一致，後台的體驗也是一致，真是近年來用過最棒的服務之一了。（螢幕錄影等特殊功能還沒測試他的分析會長什麼樣子，就留待大家試試看。）既然重視體驗，當然也備好了 Template： ballpark 提供各式各樣的 template 供各種場景使用。Roadmap：國外服務看了好幾個都會把 Roadmap 給展示出來讓大家知道，覺得真的是很棒的一件事，暸解他們未來的規劃方向，可以給使用者更多資訊來判斷自己需不需要這項服務，例如近期可能就會開發測試線上網站的功能。 https://portal.productboard.com/ballpark/1-ballpark/tabs/1-short-term-1-6-months ballpark 的路線圖那…缺點呢？價格可能還是第一優先考量，如果專案有封存的需求、分享時密碼保護、下載 CSV等，那就勢必一直升級方案。Starter 年付平約一個月 100 美金，一整年相當於台幣約 35000 左右，對於個人工作室或小型企業可能還是有一點負擔，需要評估使用 ballpark 的效益。另外是目前沒有中文支援，因為CTA 按鈕是不給編輯文字的（呼應我前面講的單純），所以如果很介意一定都要中文的，可能就不適合，不過這項未來應該是會改善，畢竟站在 UX Writing 的角度來說，適合的文案才能更讓人理解如何操作。而跳題等進階題型設定也還沒有出現，目前也沒有在路線圖看到，也許他們想先專注在某些功能上吧。這次快速地熟悉了 ballpark 的核心，希望未來有機會能使用這樣服務，也是驗證這項產品適不適合用在自身的公司身上，但想像中應該是很多可以發揮的地方，拭目以待未來的發展！ Neil's Page
macOS 輔助使用— 旁白系列（一）
macOS 輔助使用— 旁白最近終於幫助公司無障礙前端 UI 框架 — Piman — 開源了，可以展開下一步的研究。這系列主要紀錄 macOS 提供的輔助使用功能，雖然不能真正反反應出真實使用者情況，但親身體驗應該對於未來開發更有幫助。輔助功能設定 macOS 輔助使用路徑：點擊左上角蘋果圖示按鈕，選擇「系統偏好設定」，點選「輔助使用」開始設定。打開輔助使用之後有點想哭…全部體驗過一遍不知道要花多少時間，只好把目標訂小一點，一篇文章記錄一個功能。本次主題：「旁白」對於視力不便的使用者，語音的確可能是讓使用者較容易理解周遭環境的方法。本篇文章就先針對這項功能做紀錄。 macOS 輔助使用：旁白首頁簡介。開啟旁白之前，點擊「打開「旁白」訓練」，先進入教育訓練。進入後會有一個速度平緩的語音，念出「旁白」快速入門的內容，並且觀察到一個小細節：macOS 進入訓練後，焦點注目預設對焦在「繼續」按鈕。而在快速入門的內容中，一開始先提示使用者可以使用方向鍵切換面板內容。「旁白」快速入門的內容練習您學到的內容然後這個視窗沒辦法調整大小，原本想截比較小的圖，文章體驗會比較好一點，但是沒辦法，可能是想讓人專心訓練的情境。「旁白」變更鍵：「旁白」變更鍵說明預設是大寫鎖定鍵，或是 Control+Option。這個很重要，幾乎鍵盤的操作都會使用到。鍵盤輔助說明：鍵盤輔助說明平緩的語音在聽這些說明時，其實蠻難理解的，尤其是沒有說話時的抑揚頓挫，對於視力不便的人，也許會先把說話的速度調快（前往 youtube 理解盲人用手機的速度）。在螢幕上移動：在螢幕上移動練習如何使用鍵盤在畫面上移動，練習與熟悉「旁白」變更鍵的使用方式。在練習的過程中，因為向右鍵是換到下一個練習，所以很容易誤按就中斷練習了，這裡的體驗不太好，如果我是一位剛需要輔助的使用者，這項練習幫助不到我。調整聲音：調正聲音示意圖旁白可以使用「旁白」變更鍵＋Command+Shift+向右鍵切換調整項目，利用這個快速鍵跳出的項目共有聲音、速率、音調、音量、音高以及點字表可以調整，利用「旁白」變更鍵＋Command+Shift＋向上鍵或向下鍵選擇細項。聲音調整項目：由左至右依序為速率、聲音以及點字表但這裡沒有跟說明的是，你必須在旁白開啟的情況下，且持續按著「旁白」變更鍵＋Command+Shift，才會出現調整項目，因為操作時沒辦法同時截圖，只好以手機拍螢幕了。（Genius!）選擇控制項目：選擇控制項目練習選擇選項。在文字欄位中輸入：在文字欄位中輸入這裡可以體會到「旁白」變更鍵有沒有用，因為只單純用 tab 是選取不到輸入框左邊的文字，要使用「旁白」變更鍵+方向鍵才有辦法讓「旁白」朗讀。另外，輸入框如果是密碼類型，「旁白」不會朗讀，取而代之的是音效提示。這個很容易推測是跟資安有關，如果我在公共場合使用電腦，沒戴耳機或是耳機接觸不良或藍芽斷線，朗讀出來就會被其他人聽到。與元件互動：與元件互動好，這一項讓我開始腦弱了…這裡我不確定是不是只適用於macOS的軟體，這裡有幾種情況：我如果在這頁只使用 tab 切換，焦點都只會落在按鈕上。如果使用「旁白」變更鍵+Shift+方向鍵，我可以選取工具列跟進到工具列裡的第一個按鈕。在工具列內，使用「旁白」變更鍵+方向鍵：只可以在工具列內移動。困擾的點就在於，我要怎麼知道我現在會是在一個工具列裡，然後才會使用不同的快捷鍵組合去選取？就算「旁白」有念出工具列文字，也不能確定我就是真正在工具列中。於是我開啟「預覽程式」實地練習看看。開啟預覽程式試試看以一個「旁白」初學者角度體驗，目前感覺比較像是：「旁白」變更鍵＋Shift＋向上、下鍵是在螢幕層級移動。「旁白」變更鍵+向左、右鍵是在同層移動。 Tab 鍵：不管三七二十一，我只想快速找到可以按的按鍵。歡迎回來：歡迎回來這裡小小的插播一下跟操作不相關的事，我在練習途中不小心關掉了訓練課程，然後再次打開時，訓練課程顯示「歡迎回家」，然後停在上一次的課程進度，蠻貼心的。另外訓練時，按右下角的「開始練習」，就不用一定要聽完說明才能練習。在表格中導覽：在表格中導覽這項教學解決我一直以來的疑問，原來要使用快捷鍵念表格的內容，例如：索引3、語言德文、字元計數2。但其實還是很不好選擇，未來如果有必要，先詳細研究 html 的<table>再想想如何解決表格的朗讀與快速選擇問題。選擇日期與時間：選擇日期與時間又是一個困擾的地方，我使用「旁白」變更鍵+方向鍵，只能切換文字跟日期/時間選擇器的位置，無法選擇裡面的值。如果是停在日期/時間選擇器的位置，不需要「旁白」變更鍵我就能調整值了。不確定是我手殘還是電腦開始崩潰了… 使用步進器：跟選擇日期與時間一樣，我可以不需要「旁白」變更鍵就可以使用，所以我也不知道為什麼… Dock：這是 macOS的快捷選單這是 macOS 的快捷選單，也就是這一條東西 macOS Dock 示意圖選單列：選單列：macOS 的選單macOS 的上方選單 macOS 上方選單列示意圖導覽網頁：導覽網頁：就是從前面學到的技巧來瀏覽網頁內容。就是從前面學到的技巧來瀏覽網頁內容。使用轉輪：使用轉輪：把整個網頁可以按的地方變成一整個選單直接選取這是我第一次看到這個名詞，意思就是可以把整個網頁可以變成一整個選單，可以直接跳到某個位置。使用輪轉開啟無障礙網路空間服務網示意圖使用自動網路點：自動網路點教學示意圖說實話真的看不懂，名詞太深奧…其中的「指令」也不知道怎麼按…這真的有用嗎？練習網頁導覽：練習網頁導覽教學示意圖感覺最常用的應該就會是這三項了，雖然還不懂「自然網路點」是什麼意思，但已經可以快速的在網頁中來去自如了。使用多點觸控版：使用多點觸控版教學示意圖練習觸控式軌跡板手勢學示意圖觸控板手勢其實蠻方便的，左右滑、雙指左右滑、雙指旋轉可以很快速地移動焦點，但跟鍵盤操作一樣，很容易會卡死在死胡同裡，單靠聲音的提示蠻容易忽略的。複習旁白：複習旁白教學示意圖暸解更多 Mac 的功能：暸解更多 Mac 的功能教學示意圖終於結束教學課程了！如果需要 help，可以使用「旁白」變更鍵+H（旁白打開時才有用）。需要更深入的設定，就要進到「旁白」工具程式。「旁白」工具程式：接下來我們回到「旁白」的首頁，點擊「打開「旁白」工具程式」會看到左方有很多頁籤，預設為「一般」頁籤，如以下畫面：「旁白」工具程式：一般頁籤的內容「一般」頁籤內容：在旁白啟動時顯示歡迎對話框，提時使用者是否要開啟「旁白」，預設沒有勾選應該是避免一直看到歡迎對話框。歡迎對話框內容：描述旁白功能，有「不要再顯示此訊息」的核取方塊、使用「旁白」和關閉「旁白」的按鈕、更多內容按鈕。2. 作爲「旁白」變更鍵的按鍵：可選擇不同方式的「旁白」變更鍵快捷鍵。「旁白」變更鍵的快速鍵設定切換選項：Control+Option 或 Caps Lock 或兩者同時。3. 可攜式偏好設定：預設關閉，若點擊設定，則出現選擇外接磁碟畫面。這是什麼意思呢？其實就是你可以將目前「旁白」的設定，存到外接的硬碟裡面，這樣您在使用不同 Mac 裝置時，接上此外接硬碟，便可讓新裝置套用原來的「旁白」相關設定。(官網詳細說明請點擊此連結。) 可攜式偏好設定：選擇外接磁碟畫面。4. 允許使用 AppleScript 控制「旁白」：使用 AppleScript 工序指令來自動執行「旁白」作業。什麼是 AppleScript 呢？其實是 Mac 內建的一個軟體， icon 長這樣： AppleScript icon 圖樣，中文名為「工序指令編寫程式」。這邊不太深入探討此一功能，簡單來說就是可以編寫一個工序，讓重複性的動作自動作業，把時間留給更重要的事或是讓使用者輕鬆一點。軟體介面如下： AppleScript 軟體介面示意圖「詳細程度」頁籤內容：詳細程度頁籤內容：語音、點字、文字、宣告、提示語音：可以控制當使用者聚焦在哪個工具時，讓語音念出來的詳細程度，例如預設值碰到圓形按鈕 radio 時，會報讀出名稱、狀態、類型，但如果我們更改成較不詳細的程度，就會只報出名稱。圓形按鈕 radio 詳細程度是預設值時，會報讀出名稱、狀態、類型。圓形按鈕 radio 詳細程度是低時，只會報讀出名稱。其餘的點字、文字、宣告以及提示，都是類似的功能，示意圖如下：圖示為點字、文字、宣告以及提示可調整內容。「語音」頁籤內容：語音內共有兩個內容：聲音與發音。聲音可以調整自己喜歡的音調、語言，發音則可以設定類似快捷鍵的效果，例如遇到顏文字 ;-) 時，報讀「眨眼」，而且還可以設定要在哪些軟體裡面應用和忽略大小寫。聲音設定項目：由左至右為聲音首頁、點擊切換聲音、進階聲音設定。發音：可設定替代報讀。「導覽」頁籤內容：「旁白」導覽功能示意圖「旁白」游標的初始位置：選項可以是鍵盤焦點項目或視窗中的第一個項目。群組行為：有標準、斷點、宣告、忽略。這個比較抽象，需要查查 Apple 文件的說明，點擊右下角問號查看：選擇「旁白」是否需要在內容區域（例如捲動區）或群組（例如工具列）中要求一個動作來與項目互動：標準：「旁白」要求一個動作。您必須按下 VO + Shift + 向下鍵來在區域或群組中和項目開始互動，並按下 VO + Shift + 向上鍵來停止和項目互動。選取此選項時，「旁白」可能會自動與網頁上的某些群組互動，以讓導覽更加順暢。如果您不想讓「旁白」自動與群組互動，請按下 VO + Shift + 向右鍵或向左鍵。若已開啟快速導覽，請按下 Shift + 向右鍵或向左鍵。書籍群組：「旁白」會在您導覽至區域或群組項目時識別其開始點與結束點，但不會需要任何動作來與其互動。宣告群組：當您進入或離開區域或群組時，「旁白」會發出宣告，但不會需要任何動作來與其互動。忽略群組：「旁白」不會識別或宣告區域或群組，且不會需要任何動作來與其互動。【注意】無論設定為何，部分區域（例如表格）會一律要求互動。這會防止您導覽大數量的項目，例如「郵件」收件匣中數千個的項目。 ….恩…有看還是沒有懂，但大意應該就是在導覽時，你可不可以要跳過某些區域這樣的意思。同步鍵盤焦點與旁白焦點核取方塊：選擇是否讓使用鍵盤跟旁白的焦點都在同一個位置，還可以設定滑鼠指標要忽略/跟隨/移動旁白游標。允許游標環繞核取方塊：這個也是說明有看沒有懂，文件寫「在您導覽時，以連續的迴圈上下左右環繞「旁白」游標」。到底說明文件能不能說人話… 略過多餘的標籤核取方塊：只聽取一次重複的標籤。在使用 Tab 鍵時自動進行互動核取方塊：預設勾選。啟用快速搜尋核取方塊：快速搜尋螢幕上的下一個或上一個以特定字母開頭的項目。可以選擇左邊或右邊的 Command 鍵作為快捷鍵，而另一邊就會是原本的 Command 鍵。「網頁」頁籤內容：（因為覺得旁白一次講完體驗會比較好，但medium好像沒有暫時下架機制，所以持續補內容，未完待續）。 Neil's Page
通過臺灣 AA 級無障礙網頁標章且美觀的網站
希望越來越多能兼顧美觀與無障礙網頁的網站收集至啟用日期 2024–08–19。大概每隔一段時間，就會去無障礙網頁設計規範網站，到啟用列表看看已經通過 AA 標章且 UI 也不錯的網站。臺北表演藝術中心 ● 臺北表演藝術中心 ● (org.taipei) 臺中市政府資料開放平臺首頁 — 臺中市政府資料開放平臺 (taichung.gov.tw) 中央研究院社會學研究所包容為導向之科技計畫包容為導向之科技計畫 (ttfi.com.tw) 財團法人職業災害預防及重建中心財團法人職業災害預防及重建中心 (coapre.org.tw) 苗栗縣人民團體全球資訊網苗栗縣人民團體全球資訊網 — 首頁 (miaoli.gov.tw) 財團法人金融消費評議中心官方網站 https://www.foi.org.tw/Article.aspx?Arti=17&Lang=1 大溪學文化資源網 https://daxiculture.tycg.gov.tw/ 臺北市政府文化局文化快遞 https://cultureexpress.taipei/ 臺中社會創新實驗基地 https://tccsiu.taichung.gov.tw/ 客庄小旅行 https://romantichakka.com/zh-tw 國家災害防救科技中心災害告警細胞廣播訊息網 https://cbs.tw/ 臺灣原生樹木推廣及媒合平臺 https://nativetree.forest.gov.tw/ Arts Residency Network Taiwan 藝術進駐網 Arts Residency Network Taiwan 藝術進駐網國家發展委員會地方創生資訊共享交流平臺https://www.twrr.ndc.gov.tw/ Neil's Page
無障礙網頁設計學習與簡易要點
2024/07/23更新：製作了公司內教育訓練文件，覺得自己整理的蠻用心的，所以分享出來。 https://bpio.gitbook.io/edu/v/accessibility 2023/07/01更新：完整系列無障礙網頁設計大叔日記 :: 2022 iThome 鐵人賽顏色對比 AA：一般大小 4.5:1，大文字或圖 3:1AAA：一般大小 7:1，大文字或圖 4.5:1 (大文字定義： 24px 或是粗體 19px ）字級請用相對單位，如 %、em、rem 需要有定位點 ::: 和 accesskey 定位點不用太多，主要使用在版面各主要區塊即可。快捷鍵 accesskey：https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey <h1> 到 <h6> 通常網站 Logo 會使用 <h1> 包起來頁面標題使用 <h2> <h1> 和 <h2> 一個頁面只能出現一次 <h1> 到 <h6> 需要按順序使用 <h3> 到 <h6> 可以重複每個網站的用法都不一樣，而我們的建議是：因為 <h1> 只能出現一次，很適合用在網站 logo 上，輔以整個網站的名稱作為描述。頁面標題使用 <h2>，整個頁面的重點，所以只出現一次就好。章節依序使用 <h3> 至 <h6> 跳至主要區塊需要製作「跳至主要區塊」按鈕，方便跳過每頁都會重複出現的區域。回頂端要注意焦點是否有跟著跳回去。 <noscript> 如果瀏覽器關閉了 javascript，最好使用 <noscript>content</noscript> 顯示內容。因為現代網站幾乎都有 javascript，目前臺灣 NCC 已經沒有此項規定，但建議還是可以順手做，至少真的關閉時，還有一些提示。 SEO 頁籤標題頁面描述 favicon 社群分享圖片 title=”” <a> <iframe> 需要有 title=”” ，如果 <a> 是另開視窗，則要使用blank=”_target” 並且加入 rel=”noreferrer noopener” 和 “另開視窗” 文字。 <svg> 標題要寫在接續在<svg>之後，如： <svg> <title></title> …</svg> 若 svg 僅僅是圖示，可以使用 aria-hidden=”true” focusable=”false” 但因為還是要描述，所以可以再之後補上<span class=”visually-hidden”>description</span> 補充。 alt=”” <img> 需要有 alt=”” 屬性。如果是裝飾性質的圖片（沒有實質意義），還是要寫但沒有值， alt=”” 。 alt 屬性文字內容主要可以根據圖片以及其上下文內容而決定，一般建議最多 150 個字以下（但這沒有任何根據 https://css-tricks.com/just-how-long-should-alt-text-be/）。 <label for=”id”> 在表單內，使用 label 時，for 屬性必須對應到內容的 id。 visually-hidden <button> 必須要有內容，設計時可善加利用 visually-hidden 以及 aria-hidden。 <th> <table> 的 <th> 需要標註是欄或列： <th scope=”row/col”>。 download 下載的檔案不可依賴特定文書商用軟體，且在連結裡要使用 title 寫出完整檔名，例如：<a title=”操作手冊.pdf”> focus 狀態 focus 狀態都要很明顯，焦點提示區域與其相鄰的顏色需具有 3：1 的對比度，且大於選單4.5:1，若無，另外還有至少 2px 厚。非文字圖示非文字對比需大於 3:1 網站導覽若網站有「網站導覽」頁面連結，建議進入網站後，擺在 3 個步驟內就可以把注目焦點放在「網站導覽」頁面連結上。放大確保畫面放大或「只放大文字」200% 畫面都不會破版（firefox 有此設定） Font Awesome Accessibility 常用icon：Font Awesome 關於無障礙的使用方式這些文字設定之下，仍保有外觀完整性 line-height 1.5 以上 letter-spacing 0.14rem 以上 word-spacing 0.16rem 以上段落間距 font-size*2 以上此為英文，中文也可先根據此距離斟酌使用。驗證機制根據 W3C ，目前仍然沒有完美的方式，但有以下建議：如果業主可以不用使用輸入框，推薦使用 google recaptcha v3 若業主想要使用輸入框形式，則有 3 種方式選擇：https://accessibility.ncc.gov.tw/Questions/Detail/100?Category=211. 需要有驗證圖形與聲音提示2. 寄送 email，如 hcaptcha https://www.hcaptcha.com/accessibility3. 撥打客服電話取得驗證碼色盲建議至少針對紅綠色盲做設計。行動裝置方向除非是有其必要性，否則不可以鎖定行動裝置方向，例如學習鋼琴 app，就是有其橫向的必要性。 autocomplete 善用 autocomplete 屬性，方便使用者快速填入過去常使用的值。密碼請使用 autocomplete=”new-password”，避免意外填寫現在的密碼。聲音非語音的聲音 < 語音音訊 20 分貝連結非連結盡量不要用底線。影片不要自動播放、可以加上字幕。必要時使用多種提示引導避免只使用單一種方式，例如圖表除了顏色外，可以加上圖樣來區別。 Neil's Page

前往部落格主頁