在上一篇文章中，我們提到了在網站上，藉由定義清楚不同層級的 Heading 和 Paragragh 可以幫助用戶瀏覽網頁，並提升 Accessbility。
比方說：用戶可以垂直地從網頁標題 (H1) 跳轉到底下的網頁區塊 (H2) 以及更底層的不同次標題 (H3, H4, H5, H6)，或是水平地瀏覽同一層級的標題 (H2 > H2 > H2)，迅速查看有興趣的標題，並且決定是否要慢慢閱讀裡面的內文。
Heading 跟 Paragraph 並不是隨便定義的，背後規劃的邏輯反映了網站的架構以及導覽的方式。在一些大的公司中會有專門的資訊架構師 (Infomation Architect) 或使用者經驗設計師 (UX Designer)，利用卡片排序 (Card Sorting) 或用戶訪談 (User Interview) 等使用者研究方法，去了解他們通常會有怎麼樣的瀏覽行為，並與公司的商業目標做結合，設計最合適的網站架構以及 Heading 們。
而在規模比較小的公司中，有時不會定義地太清楚：有些公司會由工程師包辦，在他們實作刻畫面的時候，按照常理或邏輯去快速地劃分不同的 Heading 層級。這種方式可能有一些風險，按照邏輯劃分的 Heading 導覽，不一定符合特定產品使用者的需求，以及他們的產品使用情境。
因此，我們會鼓勵 UX 設計師應該要與工程師討論，應用使用者研究或設計方法，去替網站架構做規劃。畢竟，不管是使用視覺或是鍵盤操作的導覽，都是使用者體驗裡面很重要的一環，當設計規劃地不好的時候，會導致用戶覺得難用，或是他們無法快速地找到所需要的資訊，流失這些用戶。
接下來我們會分享團隊中不同設計師在各自公司的做法以及經驗，給想要在 Accessibility 中更進一步的各位參考。
在設計文化較為成熟的公司，整體的網站架構通常跟設計或商業策略有關，經常是由管理階層根據研究員的報告以及商業指標進行跨頁面的架構規劃。而單一頁面則常需要仰賴 UX 設計師的專業，整理研究資料的洞見，並且理解網頁區塊的互動關係去設計適合的使用者見面與交付設計稿（包含視覺以及鍵盤切換）。
設計稿 ❶：當公司的設計系統較完善
在設計師 R 的公司裡，公司已經發展了一套完善的設計規範 (Design guideline)，在規範中，清楚標注了 Heading 和其用途，並直接在 Figma 字級系統中，設定了 H1, H2, H3 的大小和字重，並且產品的所有頁面都跟隨這套字級系統，不管是在產品頁或是結帳頁，H1, H2, H3 出現的邏輯都是一樣的，字體也是，工程師在檢查設計稿的時候，就會根據相應的字級直接實作。
以這張截圖為例，H1H3 分別代表了 (H1) 到 (H3)，P1P3 則都是 (p) 段落，不過因為視覺設計的需要區分出了 P1~P3，設計師可以依照自己頁面需求調整想要的 Paragraph 文字大小。
這間公司在 Figma 中建立了完善的字體風格 (text style)，設計師僅需要跟產品經理討論好，並在交付設計稿時，選取相對應的字體效果即可。如此一來，工程師實作時可以直接套用選好的風格，整間公司的所有產品也都會有一致的 Heading 設計以及視覺語言。
註：Heading 與 paragraph 並沒有建議的字重或字體大小，在有些公司裡，有可能 P1 視覺大小比 H3 還要大，一切由公司的設計風格規定。
設計稿 ❷：當設計系統尚未完善
很多新產品或團隊在設計時，可能還沒有一個完善的設計 Heading 的流程，舉例來說，當雲端千眼團隊在設計新版的網站服務的時候，就還沒有一套統一的設計規範以及字級系統。因此，我們團隊決定在設計每個頁面的時候，設計師都會與團隊討論 Heading 的邏輯，並且利用註記的方式，標註 H1, H2, H3 等，讓工程師們知道該個頁面有哪些 Heading。
下面利用兩個案例來介紹我們是如何討論與決定 Heading 邏輯的：
案例1｜扁平的架構：通知中心
雲端千眼團隊決定在新版的服務中，重新設計一個通知中心功能頁面：讓使用者可以在這個頁面收到所有的借閱、帳戶安全相關通知。
首先，因為使用者經常會開啟新的任務視窗，並在不同的瀏覽器分頁中 (tab) 跳轉，我們決定統一所有雲端千眼的頁面的 H1，不管是在哪一頁，H1 都會在左上角並報讀我們的品牌，這樣使用者如果是從別的瀏覽器分頁切到雲端千眼頁面的時候，就可以馬上知道自己的這個分頁是正在看雲端千眼的服務，幫助他們快速繼續使用雲端千眼。
接下來，我們在 H2 放上我們這頁的主要任務：查看通知中心。我們想要讓使用者在這個頁面專注在查看不同的通知，因此我們只有一個 H2，並沒有其他的 H2，讓使用者知道這裡就是雲端千眼的通知中心頁面。
在思考需不需要 H3 時，最初設計師提出可以放入不同種類的通知 H3 在這個通知中心頁面下，讓使用者切換導覽。但當團隊產品經理與設計師實際盤點了各式的通知情境後，我們整理出雲端千眼的通知大致可以分為兩種：借閱書籍、帳戶資訊。
而我們發現，比起這兩個種類的切換，我們產品的通知更需要看中的是時間：我們要呈現最新的通知（借閱與歸還期，帳戶身心手冊過期時間），因此用通知種類去額外細分 H3 反而變成多此一舉，可以維持扁平的架構，直接用時間序列呈現所有通知中心的通知。
以上圖為例，我們團隊簡單地在設計稿上標註了 <H1 雲端千眼線上書庫>，讓使用者知道這是雲端千眼的網站，以及 <H2 通知中心>，告訴使用者這個頁面有通知中心這個區塊。如此一來，工程師就不需要通靈，也可以知道要怎麼在 HTML 上標注不同層級。並且在未來，如果我們團隊開發完畢，開始要追求視覺語言的統一時，也可以輕易回頭找到設計稿中哪裡需要調整大小。
案例2｜複雜三層架構以及隱藏樣式：我的追蹤
這裡有另外一個較為複雜的例子：我的追蹤頁面，這是一個讓讀者可以收藏感興趣的書籍，追蹤這些書籍上架到我們網站的進度。
同樣的，這個頁面中一樣把雲端千眼列為 H1，用戶會首先知道這是雲端千眼的網站，並且緊接著告訴用戶這是我的追蹤頁面 H2，在這個頁面中，團隊設計師發現「是否上架」是使用者在查看追蹤的書籍時最在意的事情，因此在這邊我們將追蹤中的書籍向下細分出了 H3 <即將上架>、 <已上架>。
在討論需不需要有更細的 H4 的時候，因為現行使用者研究中，並沒有發現產品用戶對追蹤書籍有其他的痛點或更細節的使用需求，團隊決定採用 H1~H3 的架構去滿足既有的需求。
此外，眼尖的讀者可能會發現這裡的截圖並沒有像上個通知中心的功能一樣，視覺上有明顯的 H2 標題。這是因為書籍列表資訊表格較為龐大複雜，加上旁邊有導覽列，因此我們決定把我的追蹤文字標題在視覺樣式上隱藏起來。視覺上會比較簡潔並強調書籍資訊重點，但是當螢幕閱讀器報讀的時候，還是會將 H2 報讀出來。這就是通過工程上 HTML 和 CSS 技巧，去滿足內容層級以及設計樣式的平衡。
⭐️ Heading 不能用跳的去定義
前面提到 Heading 有從 H1~H6，一些設計師可能會想要直接只用 H1 和 H4 下去設計，反正也是由大到小。然而，WCAG （無障礙設計規範）建議設計師和工程師依照 Heading 的標籤順序下去設計。
我們也認為，這樣的設計跟經常使用螢幕閱讀器導覽的讀者習慣的操作模式不一致：當網站直接從 H1 接到 H4 時，可能會讓使用者困惑他們是不是操作太快，不小心跳過了你的次標（H2 和 H3），並且花費額外的時間回頭去找。
此外，數字 1234 其實隱含了層級的概念，既然你只有 H4 的話，何不直接將這些 H4 都改成 H2 ，降低使用者思考的負擔呢？
⭐️ 在一個頁面不使用多個 H1
如果你覺得你的網站很多重點，想要用很多個 H1 去強調的話，這就會像拿螢光筆畫滿整本書，很多重點反而變成沒有重點！H1 通常被拿來作為介紹網頁主旨，太多主旨對使用者一點都不友善。
當你只用一個清楚的 H1 並且設計好接下來 H2~H6 層級的時候，其實就在幫助大家更好的瀏覽和閱讀你的網站內容，減少他們不耐煩跳出你的網頁的機會。並且無障礙設計規範也建議只要用一個 H1 去描述這個網站主旨或標題就好。
⭐️ 不建議把 Heading 放在互動元素上
Heading 主要做為描述接下來區塊的用途或目的，它應該是一個簡短的文字敘述，不應該將連結、按鈕等這類互動元素加上 Heading，這樣可以避免 Screen reader 讀者在快速切換的時候，不小心跳過或誤觸這些互動的 UI 元件。
Figma 小工具
- Indeed 公司提供了免費的 Figma A11y Annotation kits，設計師們可以直接利用這些工具去將不同的 H1, H2, H3 等層級標註設計稿上，快速與工程師或產品經理們討論。
- Figma 提供了 accessible protoype 的 beta 版本，可以去嘗試看看，並用 tab 模擬螢幕閱讀器用戶的操作。
儘管很多時候在設計 Accessibility 時，並不會立刻替公司或產品帶來爆炸式的用戶或營收增長，但我們相信這些細節們的總和，會真切地影響每個用戶的感受，以及在未來替團隊帶來正面的設計以及 UX 效益。在這一系列的 Heading 相關文章中，我們簡單地討論了 Heading 的定義以及為什麼設計 Heading 很重要。並且也分享了幾個設計實務上的案例以及好用的小工具，希望可以幫助大家設計更具備包容性的產品以及網頁。
Reference
