今天想分享我花了一個月左右打造的新品牌：Accesserty
這是一個專注於提升無障礙網頁體驗的小型工具生態，從搜尋體驗到開發測試，試圖用一套溫和、理性的方式，讓這件事被看見、被理解、被改善。
起點：對於 Chrome Extension 的好奇
在 2023 年時，我出於對 Chrome Extension 的好奇，製作了名為 Report Website Issues 的擴充程式，並分享開發過程。
到了 2025 年，隨著大型語言模型（LLM）的普及，我開始思考能否用它來輔助開發更多可實際解決問題的工具，並設法用 LLM 拆分出角色，幫助我在短時間內建構出一個有邏輯又能運作的產品系統。
發現問題與痛點
1. 搜尋後，使用者其實不知道該點哪個連結
搜尋引擎雖然會綜合 SEO、速度、內容等因素排序網頁，但這些排序結果並不代表網站「好用」或「易於瀏覽」。 許多網站看似在技術層面表現良好，實際上卻充斥著鍵盤操作困難、結構不明、廣告覆蓋等問題，特別是對使用輔助科技的使用者而言。
我開始思考：能不能在搜尋時就直接看到這個網站的可及性狀況？避免來回點選、浪費時間與耐心，讓瀏覽過程更順暢。
2. 使用者想回報問題，卻「無門可報」
即使使用者發現網站有困難，也常因為找不到聯絡方式、或無法準確描述問題而選擇放棄。
更常見的是客服和使用者之間「認知不同」，像是這個我在之前文章中提到的例子：
例如使用者說「我的鍵盤沒辦法瀏覽你們的網頁」，但客服卻說「我的可以喔，麻煩您再試試」，然後差不多就鬼打牆，兩邊都覺得對方很爛，因為前者是談鍵盤焦點，後者可能只是按向下鍵捲動畫面。
因此我認為需要有一個「中介層」：讓使用者能輕鬆描述問題，讓開發者收到後是可解讀、可處理的資訊。
目前 LLM 雖然可以協助，但仍難以精確理解這類回報或是成本太高。
3. 對開發者而言，無障礙是高成本嗎？
近年因應歐盟無障礙相關法規，各大 UI 框架陸續強化了可及性元件，的確減少了開發成本。 但僅靠機器掃描是否合規遠遠不夠 — — 因為「合規」≠「可用」。
舉例來說：一張圖片是否有 alt 屬性，機器可以檢查；但這個 alt 的內容是否正確傳達圖片意義？還是只有寫「圖片1」？這仍需要人來判斷。
目前即使 LLM 可以做初步描述，也需要 API 費用與極高 prompt 精度，而且幻覺仍是風險。
所以更務實的方式是 — — 在開發過程就提供人工判斷的機會與工具。
這就延伸出一個核心概念：
越早期處理可及性問題，成本越低。
從規劃階段讓分析師、設計師、工程師一起考慮無障礙，而不是事後補強。
參考來源：Is Closing the Web Accessibility Design/Development Gap a Bridge Too Far?
解法開始成形：模擬、檢查、回報
基於上述問題，我開始構思一個流程圖，來整理使用者、開發者、合作方之間的互動關係：