現在前端已經有非常多成熟的 UI Library。

從 Button、Input、Select，到 Dialog、Tabs 等複雜的互動元件，很多時候不需要從零開始，就能快速建立一套完整的介面。

而 shadcn/ui 也已經提供了許多好用的 Components。

那麼問題來了：

都有 shadcn/ui 了，為什麼還要做自己的 UI Kit？

如果只是把 shadcn/ui 的 Button 換個顏色、調整圓角，再把它叫做「自己的 UI Kit」，好像又少了點什麼。

這是我想透過這 30 天挑戰慢慢探索的問題。

為什麼開始想做自己的 UI Kit？

目前的工作會接觸到不同的網站與系統，而在開發的過程中，常常會發現很多事情其實一直在重複。

Button、Input、Form、Alert、Dialog……

這些常見的 UI 幾乎每個系統都會使用，但目前不同網站大多還是各自處理，沒有一套統一的元件。

即使有共用的 CSS，隨著專案增加、需求改變，維護起來也不一定那麼容易；開發新的系統時，也常常又重新實作一次類似的元件。

久了就會開始想：

這些東西是不是可以不要每次都重做？

而 Accessibility 又是另一個讓我開始思考這件事的原因。

因為工作上的網站有無障礙需求，在申請無障礙標章之前，通常會進行檢測，再集中處理發現的問題。

這個流程做久了，我開始想到一件事：

為什麼有些問題，要等到網站準備申請標章時才回頭修改？

有些 Accessibility 問題，其實並不是網站做到最後才會出現。

Button、表單、Focus、鍵盤操作……很多問題從 Component 被建立的那一刻就已經決定了。

如果等到網站完成後才檢查，就可能變成：

開發完成 → 檢測 → 發現問題 → 回頭修改 Component。

那如果反過來呢？

能不能在設計 Component 的時候，就先把 Accessibility 考慮進去？

如果常用的 Button、Input、Dialog 本身就有一致的 Accessibility 規範，未來使用這些元件建立新系統時，至少有一部分問題可以從源頭開始避免，而不是每次等到最後才重新補救。

為什麼選擇 shadcn/ui？

它給了開發者很大的調整空間。

使用 shadcn/ui 時，元件的程式碼會直接存在自己的專案中，而不是只能從套件中引入一個已經封裝好的元件。

這代表我不只可以「使用」它，也可以直接打開 Component 看：

這個 Button 為什麼這樣寫？
這個 Variant 是怎麼處理的？
這些樣式和 Accessibility 設計又是從哪裡來的？

需要的時候，也可以依照自己的 Design Tokens、元件規範與使用情境去調整。

另外，shadcn/ui 的許多元件本身也建立在具有 Accessibility 考量的基礎上，這點剛好符合這次想打造 Accessible UI Kit 的方向。

所以對我來說，shadcn/ui 剛好落在一個很適合的位置：

不用所有東西從零開始，又能保留足夠的控制權。

這 30 天我也想藉著打造 UI Kit 的過程，好好拆開來看看shadcn/ui到底幫我們做了什麼，以及這些元件在被客製化之後，如何慢慢變成一套符合自己需求的 UI Kit。

至於 shadcn/ui 到底和一般 Component Library 有什麼不同、元件背後又用了哪些東西，就留到後面的文章再慢慢研究。

UI Kit 不只是很多 Components

如果只是建立一個：

components/
├── button/
├── input/
├── checkbox/
├── dialog/
├── tabs/
└── ...

然後裡面放很多 Components，好像還不能算完成我真正想做的東西。

這次除了實作元件，也希望慢慢整理出一套共用規則。

例如：

Design Tokens

顏色、字級、間距、圓角等基礎設定。

Component Rules

元件有哪些 Variant、Size 與 State？Disabled、Error、Loading 又應該怎麼呈現？

Accessibility Rules

Focus 怎麼呈現？鍵盤怎麼操作？什麼時候需要 ARIA？顏色對比是否足夠？

Documentation

Component 怎麼使用？有哪些 States？哪些使用方式應該避免？

這些東西慢慢累積起來，才會從單純的 Components，逐漸形成一套可以持續使用與維護的 UI Kit。

甚至慢慢走向自己的 Design System。

接下來 30 天會做什麼？

接下來 30 天，我會一邊實作，一邊記錄建立這套 UI Kit 的過程。

首先會使用 React、TypeScript、Vite 建立專案，導入 shadcn/ui，並開始規劃 Design Tokens 與樣式架構。

接著實作與客製化 Button、Input、Checkbox、Select、Alert 等常用元件，再慢慢進入 Accordion、Tabs、Dialog、Toast 等互動較複雜的 Components。

而每處理一個 Component，我都希望多做一件事情：

Accessibility Check

除了確認畫面與功能，也實際看看：

• 鍵盤能不能正常操作？
• Focus 是否清楚？
• HTML 語意是否合理？
• Accessible Name 是否完整？
• ARIA 是否真的有必要？
• 客製化後，有沒有不小心破壞原本的 Accessibility？

最後再透過 Storybook、Accessibility Testing、Library Build 與文件，把這些零散的元件整理成一套真正可以使用與持續擴充的 UI Kit。

30 天後，希望留下什麼？

希望最後真的有一套可以拿來使用的 UI Kit。

藉這個機會，好好理解以前只是「用過」的 shadcn/ui，以及 Design System 和 Accessibility 背後的設計。

如果最後還能整理成一個完整的作品，那就更好了。

我想把 shadcn/ui 當成起點。

拆開它、理解它，再一步一步加入自己的 Design Tokens、Component Rules 與 Accessibility 考量。

30 天後，希望得到的不只是一個放著很多 Components 的資料夾。