這個系列會分享我這些年累積下來 React Component 的開發經驗，
也藉此機會嘗試一下我發現的新玩具。
這系列不是走理論派，
我想嘗試透過實務開發再帶入理論的方式來分享這些知識。
內容會涵蓋：
全部都 不會很詳細 的解釋，至少在這個系列我認為不太適合講太多理論。
其實不算是製作大專案，至少我並不崇尚大專案。
但是我們會用 Monorepo 下去拆模組，
方便元件開發時的獨立性，
也能順便測試實際專案在導入時的情況，
這也是大多開源元件庫的架構方式。
製作開源元件庫，是一件非常有趣的事情，
但元件庫要走向 production 最大的障礙，
主要出在 accessibility。
當前台灣開發生態比較沒有重視，
甚至根本就不知道這個東西的存在，
其原因可能是 沒有打進歐美市場 跟 政府立案問題，
包含美國，歐洲甚至一些亞洲國家，都有可達性標準相關立法，
沒有合格是無法在該國營運。
The more your tests resemble the way your software is used, the more confidence they can give you.
Kent C. Dodds
我太常寫出 ? 了，
這次會實際操演一遍 Test-driven development，會先寫單元測試在實作。
如果有緣可以在嘗試做 E2E 的文章。
現在落筆時間是 Sep 2022，
這個系列描述的技術跟版本，
至少不會有超過 3 年以上太久遠的部分，
因為很多是在這個時間點算新，
有些知識跟寫法可能還找不太到中文相關的文章，
要去翻原文文件跟 repository 的 issue (至少我是這樣)。
並不是指完全不處理 style，
是我傾向 元件庫應該要只封裝元件邏輯，
樣式則是在應用程序開發的階段根據需求套上。
這樣的好處是可以給予設計師最大化的設計彈性，
而且通常元件邏輯其實大同小異更容易共用。
元件邏輯 !== 業務邏輯
現行有蠻多的開源元件庫採用這個模式，
也是我目前採用過感受最好的方案，
兼具彈性，效能，可達性，穩定，開發成本降。
這個系列主要分做兩個部分
當前台灣開發生態比較沒有重視，甚至根本就不知道這個東西的存在，
Accessibility 是基本人權，台灣政府很重視，也是我開發系統的第一優先。我認為您也把Accessibility擺在第一未，例如， 您在接下來的日曆都有鍵盤操作和螢幕報讀(建議用中文報讀)。 這是最重要！當開發測試時，開啟screen reader，把眼睛閉上，不用滑鼠，只用鍵盤，才是真正的產品。
最近發現Google ReCaptcha不符合Accessibility標準，所以不用了. (註: 因為有一個空白的iframe沒有title)
感謝你的留言！！！
撰寫 Accessibility 相關的文章坦白說蠻吃力不討好的，
相較於討論神速入門或是一些概論性的主題。
但這我想保持 "傳遞能幫助到人的知識跟經驗" 這項初衷。
因為這篇主要處理為 WAI 規格也就是國際規格，
故不處理中文報讀。
目前 Google ReCaptcha v3 已經拿掉元件部分，
而是透過一種演算法背景判斷用戶是否為機器人，
或許可以嘗試看看。
撰寫 Accessibility 相關的文章坦白說蠻吃力不討好的，
Accessibility是基本人權, 現在已是技術的核心. 沒有Accessibility就是一個殘缺不全的系統.
目前 Google ReCaptcha v3 已經拿掉元件部分，而是透過一種演算法背景判斷用戶是否為機器人，或許可以嘗試看看。
還是有空白無標題的iframe. 所以我決定自己寫一個Captcha, 帶audio的, 也不是很難.
如果擔心 iframe 會影響螢幕報讀，可以帶 aria-hidden 或是 display: none 直接跳過即可。
後面章節會提到關於 Accessbility Tree 跟 Tabbable 相關資訊可以再繼續關注囉！
這我知道, 但天下都懂, 就是google recaptcha不懂!!! 過去幾年已經有很多人反應過了. 但Google 就是不改. 我想有可能是google認為invisible就是inaccessible吧, 我試圖用Javascript來硬改:
document.addEventListener("DOMContentLoaded", () => {
//硬改google Recaptcha...
});
(DOMContentLoaded就是jQuery的ready, 我不用jQuery的) 問題是, Gooogle Recaptcha總是在DOMContentLoaded的Event過後才出現的. 所以用DOMContentLoaded是抓不到的.
當然, 我已用開發者模式的console證明可以硬改, 但並沒有意義.
本想再用無限迴圈試或找其他的Event, 總會等到你google的, 只是有時候你會看到google recaptcha遲遲不出現, 再折騰也沒意義, 而且專案無法等, 山不轉路轉, 不是自己寫(不難), 就是改用有Accessibility的HCaptcha或其他的captcha.
如果是要監控 google recaptcha 是否已經在畫面上，
可以用 MutationObserver
他可以持續監控整個 DOM 有哪些異動，包含新的元素生成。
可以考慮試試看。
謝謝您的建議, MutationObserver應該可以做到. 看似我只需要去監控google Recaptcha的上層element就可以了. 晚上再試試看.
只是還要用FreeGo測看看FreeGO會不會等到這個callback完成. 理論上FreeGo應該只會等DOMContentLoaded事件. 而Google ReCaptCha是在DOMContentLoaded之後發生的, FreeGO可能看不到這個callback了, 自然就看不到這個callback硬改的title了.
我有試過在Google ReCaptCha自己的Callback中硬改它的空白iframe的title, 但證明它的callback是在把ReCaptCha加入上層element之前呼叫的, 當然是在DOMContentLoaded之後發生的
關鍵還在DOMContentLoaded, 不過, 我基本上是放棄Google ReCaptCha了. 這只是它在無障礙上的一個障礙.
MutationObserver看起來還是很好用, 用來增強UX. 感謝.
iThome鐵人賽
看影片追技術