# 網頁的隱藏維度：國際化與無障礙全景
::: tip 核心導讀
**什麼是 i18n 及其來龍去脈？**
在前端和軟體工程領域，我們常說的 **i18n** 其實就是指 **多語言支援（國際化，Internationalization）**。因為這個英文單字的首字母 `i` 和尾字母 `n` 之間恰好相隔了 18 個字母，為了書寫簡便，業界便發明了這個特定的縮寫。
同理，**無障礙存取（Accessibility）** 也因為首字母 `a` 與尾字母 `y` 之間有 11 個字母，因此被統稱為 **a11y**。
在瀏覽器將程式碼渲染出五彩斑斕的網頁背後，其實還並行著兩條肉眼往往看不見的「暗線」：
當你輸入網址存取網頁時，瀏覽器怎麼知道該給你展示中文還是德文（即 i18n 多語言流程）？在瀏覽器將 HTML 解析成 DOM 樹準備畫圖的同時，又是如何專門為視障人士構建出另一棵「盲文樹」的（即 a11y 無障礙流程）？
本章我們將再次回到「網頁存取與渲染」的微觀流程中，解碼瀏覽器及前端工程在這兩個體現技術人文關懷的領域是如何默默工作的。
:::
---
## 1. 網頁存取中的語言協商 (i18n)
當我們輸入一個網址、按下 Enter，瀏覽器在向伺服器發送 HTTP 請求時，通常會默默附帶一個標頭資訊：`Accept-Language`。
- *例如：`Accept-Language: zh-TW,zh;q=0.9,en;q=0.8`*
這就好比你在餐廳點單前，瀏覽器私下對服務生說：「我的主人優先看繁體中文，如果沒有的話，英文也湊合能看。」這就是 Web 存取時的**初次協商**。
### 1.1 前端工程與字典替換
而在現代前端框架中，頁面的骨架通常是由 JavaScript 在本地動態生成的。在這個階段，前端應用會主動讀取瀏覽器的本地偏好（例如透過 `navigator.language` API），然後從伺服器按需拉取對應的語言「字典包（JSON）」——遇到中文顯示「確定」，遇到英文字典則顯示「Confirm」。
### 1.2 排版的約束：文字長度與 RTL 鏡像
但除了字典替換，真正的國際化在瀏覽器佈局（Layout）階段面臨著深淵般的挑戰。
不同的語言表達相同的含義時，所需的字母長度可能天差地別。例如德語常將多個詞根拼接成巨長的單字。如果我們在撰寫 CSS 時使用絕對固定寬度，很容易在切換德語時出現文字撐破容器的慘狀。因此瀏覽器鼓勵使用彈性盒模型（Flexbox）來自適應不同的文字體量。
更為顛覆的挑戰在於閱讀方向。阿拉伯語（Arabic）、希伯來語（Hebrew）等語言的閱讀習慣是**從右向左（Right-to-Left，簡稱 RTL）**。
當頁面切換到這類語言時，不僅是文字方向要變，**瀏覽器引擎還需要對整個網頁的內容塊進行水平方向的鏡像反轉**！瀏覽器為此提供了原生的 `dir="rtl"` 屬性。我們在撰寫 CSS 時，應當避免使用絕對的方向詞，例如用 Flexbox 的 `justify-content: flex-start` 來替代硬編碼的 `margin-left`，從而讓瀏覽器能夠隨著區域切換自動化反轉佈局。
### 1.3 告別正則：擁抱瀏覽器的 Intl 標準
除了介面排版，瀏覽器底層還自帶了一個強大的「在地化格式引擎」。
對於同樣的數字 `1200.5`，美國人習慣看到 `$1,200.50`，而歐洲許多國家習慣用逗號做小數點 `€ 1.200,50`。日期格式更是千奇百怪。
現代瀏覽器暴露了 **`Intl` 核心物件**（例如 `Intl.DateTimeFormat` 和 `Intl.NumberFormat`）。依靠這個 API，我們在程式碼裡只要指明當前環境代號，瀏覽器便會直接呼叫底層的作業系統資料規範，準確生成符合當地習慣的展示字串。
👇 操作下方元件，觀察在不改變來源資料的前提下，瀏覽器是如何透過底層 API 完成佈局反轉（RTL）與系統級資料轉換的：
---
## 2. 瀏覽器內部的無形之樹 (a11y)
回到瀏覽器渲染引擎。我們都知道，瀏覽器解析 HTML 時會生成一棵 **DOM 樹**，然後再結合 CSS 計算生成用於繪製介面的**渲染樹 (Render Tree)**。
但鮮為人知的是，在網頁存取時，瀏覽器實際上還在並行構建一棵專供作業系統「看」的樹——**AOM 樹（Accessibility Object Model，無障礙物件模型）**。
### 2.1 螢幕閱讀器與語義化的本質
為了讓視力障礙使用者使用電腦，作業系統內建了**螢幕閱讀器（Screen Reader）**輔助軟體（如 macOS 的 VoiceOver）。這類軟體「看不見」螢幕的顏色像素，它們**完全依賴瀏覽器暴露出來的 AOM 樹來朗讀網頁**。
如果開發者用普通 `