本期共享的是 —— AIGC 的用途之一是協助編寫或生成前端代碼。訴諸 AIGC 輔助前端開發有一大坨福利；舉個栗子，快速創建一次性原型，或者輔助我們生成涉及生疏概念的代碼，比如我們不懂貝塞爾曲線，也讓 AI 可以寫出絲滑的動畫特效。

與以前的一大坨發明一樣，AIGC（生成式人工智能）正在改變前端的開發方式，但 AIGC 也是一把雙刃劍。

我們可以嘗試使用 AIGC 來輔助生成可訪問的前端代碼。AI 為我們的需求提供了看似權威的答案，但 AI 也會犯錯，AI 會警告我們大膽復制、小心粘貼，因為當我們提出自己都不知道如何實現的需求時，我們也無法驗證 AI 答案的準確性和可靠性。

我們向三個免費的 AIGC 工具咨詢了若干有關前端可訪問性代碼的典型問題。這些工具是 Google 的 Gemini 和 OpenAI 的 ChatGPT，它們都是在一般數據上訓練的 AI 工具的典型代表。

粉絲請注意，AIGC 不會在每次被問到相同問題時給出相同的答案，換而言之，AIGC 不是“純函數”，相同的輸入不一定得到相同的輸出，大家自己測評的時候不要大精小怪。如果您不知道什么是”純函數”，正好可以向 AIGC 咨詢。

問題 1

由于生產團隊定期致力于使其產品和服務符合 WCAG（Web 內容可訪問性指南），因此前端開發者可能會求助 AIGC，確定它們編寫的代碼是否可訪問。我們咨詢了測評了谷歌的 Gemini 和 OpenAI 的 ChatGPT：

我們的問題是，下述前端代碼是否符合 WCAG 2.2 Level AA？

<p>
  我家的貓吃了我的代碼。
  <a href="news.html" aria-label="貓吃了我的代碼">一鍵三連</a>
</p>

在這種情況下，上述代碼并不符合 WCAG，具體而言，它不符合 SC（Success Criterion）2.5.3 名稱標簽，其中規定：

對于帶有包含文本或文本圖像的標簽的 UI 組件，名稱要包含視覺呈現的文本。

上述代碼中，可見的鏈接文本是“一鍵三連”。但是該鏈接的標簽或名稱是“貓吃了我的代碼”。換而言之，該鏈接的名稱不包含其可見文本，因此代碼無法通過 SC 2.5.3 名稱標簽的規定。

谷歌 Gemini 的測評

針對上述問題，Gemini 的回答是，根據您提供的信息，我無法明確告訴您該代碼片段是否符合 WCAG 2.2 AA 級。確定 WCAG 合法性需要針對內容和代碼的方方面面徹底評估，包括但不限于：

圖片

Gemini 明確表示這個問題超綱了，CPU 要燒壞掉了。之后 AI 繼續提供若干一般性但可靠的指導，接著推薦若干進一步的資源，輔助我們了解該主題。

OpenAI ChatGPT 的測評

針對上述問題，ChatGPT 的回答是，您提供的 HTML 代碼片段不完全符合 WCAG 2.2 AA 級可訪問性標準。雖然它包含某些輔助功能，但存在若干問題：

圖片

B 站方言，ChatGPT 答對了，但沒有完全對......ChatGPT 提供了錯誤的原因，它忽略了代碼片段未通過 SC 2.5.3 名稱標簽這一事實，而是聚焦于標簽和鏈接文本的質量。如果我們的問題指 WCAG AAA 級而不是 AA 級，那么 ChatGPT 關于鏈接文本的說法問題不大，因為 AAA SC 2.4.9 級鏈接目的要求鏈接的目的可以“只從鏈接文本中識別”。雖然但是，A 級 SC 2.4.4 上下文中的鏈接目的有更多的自由度，要求鏈接的目的“可以單獨從鏈接文本確定，或從鏈接文本與其以編程方式確定的鏈接上下文一起確定”。

盡管存在錯誤信息，ChatGPT 提供的改進代碼片段比我們的原始代碼片段更易訪問。它符合 SC 2.4.9 以及 SC 2.4.4。有趣的是，它也符合 SC 2.5.3，盡管這是無意為之。通過讓 -aria-label 屬性的值與鏈接文本相同，可見的鏈接文本會包含在鏈接的名稱中。

粉絲請注意，通過讓可見鏈接文本和 aria-label 屬性的值相同，會使 aria-label 屬性多余，且理想情況下應該將其刪除，作為一般 ARIA 最佳實踐。

問題 2

盡管大多數常見組件都有文檔化的可訪問模式，但眾所周知，它們仍然很難正確使用。當然，這也是我們可能會要求 AIGC 工具輔助的需求。我們再次咨詢 Gemini 和 ChatGPT：

我們的需求是，為我們提供網站創建一組可訪問選項卡的所需代碼。

一組可訪問選項卡的最終模式是 W3C ARIA 創作實踐中的模式。它具有一組選項卡的所有預期語義信息和功能，支持鼠標、鍵盤（帶或不帶屏幕閱讀器）和觸摸。

Gemini 的測評

針對上述需求，Gemini 的回答是，以下是為網站創建可訪問選項卡所需的代碼，其中包含 HTML、CSS 和 JS：

圖片

Gemini 提供的代碼有若干缺陷。最值得注意的是，它沒有預期的鍵盤支持。預期是可以使用向上/向下/向左/向右箭頭鍵循環瀏覽每個選項卡。Gemini 提到的焦點管理也不存在。

Gemini 的代碼已包含預期的 ARIA 角色和屬性，但并不總是正確的。舉個栗子：

• 每個選項卡都包含一個 <li> 以及其中的 <button> 元素。ARIA 屬性 role=tab、aria-controls 和 aria-selected 已應用于 <li> 元素，但應該應用于 <button> 元素，并將 role="none" 應用于 <li>
• 選擇新選項卡時，每個 <li> 上的 aria-selected 屬性的值不會更新，這意味著，屏幕閱讀器始終會宣布“選項卡 1”已被選中，即使它不是當前選項卡選定的選項卡
• 每個具有 role="tabpanel" 的 <div> 元素上的 aria-labelledby 屬性都指向不存在的 id，這意味著，選項卡面板沒有由屏幕閱讀器讀出的易訪問名稱

OpenAI ChatGPT 的測評

針對上述需求，ChatGPT 的回答是，為網站創建可訪問的選項卡涉及 HTML、CSS 和 JS 代碼。以下是如何創建可訪問選項卡的簡單示例：

圖片

ChatGPT 提供的代碼不包含任何 ARIA。這意味著，屏幕閱讀器用戶不會被告知這是一組選項卡，即使它們的樣式看似選項卡。

同理可得，屏幕閱讀器用戶無法辨別當前選擇的選項卡，只能通過瀏覽內容來查找。盡管視力正常的人可能能夠從可見內容中辨別出當前選擇了哪個選項卡，但當前選擇的選項卡按鈕的設計與其他選項卡沒有區別。對于使用屏幕放大或小屏幕設備的任何人而言，這可能都有問題。

選項卡之間的結構和關系在視覺上可能很明顯，但沒有編程結構或關系可以輔助無法在屏幕上看到選項卡的任何人。

機智對待 AIGC

2023 年 10 月，TetraLogical 團隊提出了問題 —— “AIGC 可以輔助我編寫可訪問的前端代碼嗎？”。答案出人意料地簡單 —— 是的，如果你足夠機智，不要盲信你得到的每個答案，并且你大膽復制、小心粘貼。

期望大家禁用 AIGC 工具輔助編寫可訪問的前端代碼毫無卵用。大家總會使用工具來輔助提高知識或生產力 —— 畢竟我們幾十年來一直在使用搜索引擎來實現此目的，而下一個工具是比搜索引擎給力的 AIGC。

那么，我們如何機智地訴諸 AIGC 工具輔助編寫可訪問的前端代碼呢？

我們可以捫心自問：

1. AIGC 工具對其局限性的了解程度如何？
2. 我們如何驗證得到的答案？

Gemini 和 ChatGPT 都明確表示它們可能犯錯，我們應該檢查它們的答案。

不可避免的結論是，當我們求助 AIGC 工具輔助編寫可訪問的前端代碼時，我們不應該盲信得到的答案，而應該使用我們信任的來源來驗證。