標籤：它的複雜™

初級前端開發者學習JavaScript時，掌握切換類名是一個快速有效的技巧。

 const button = document.querySelector(".my-button");
const element = document.querySelector(".content");

button.addEventListener("click", function() {
  element.classList.toggle("sparkles");
});

利用這個技巧，我們可以構建選項卡。

簡單實現

如果我們已經掌握了切換類名的技巧，需要構建一個選項卡界面，只需添加一些處理點擊事件的代碼，就能實現簡單的選項卡，例如：

這些選項卡完全可用。 我利用錨鏈接在鏈接和選項卡區域之間創建跳轉鏈接，這在語義上是合理的。選項卡可以通過鍵盤訪問，具有焦點樣式，並且可以使用Return鍵激活。

但這夠了嗎？完美的選項卡？

並非易事

問題在於，我們沒有對鍵盤處理做任何特殊處理，而選項卡界面可能需要鍵盤處理。 Heydon Pickering對此進行了說明：

與同頁面鏈接不同，選項卡不會將用戶移動到關聯的內容區域/面板。它只是在視覺上顯示內容。這對希望在不同區域之間切換而無需每次都返回頁面頂部的視力正常的用戶（包括使用屏幕閱讀器的視力正常的用戶）來說是有利的。

這帶來了一個不幸的副作用：如果用戶希望通過鍵盤移動到某個區域並與其內部內容交互，他們必須依次遍歷當前選項卡右側的所有選項卡，這些選項卡按焦點順序排列。

事實證明，選項卡界面還有許多其他的行為方面需要考慮。在Heydon的解釋中， Tab鍵實際上可以作為一種方法，從選項卡本身跳轉到與該選項卡相關的內容，從而移動焦點。 Shift Tab將焦點帶回。然後使用箭頭鍵更改選項卡。所有這些都需要更多的JavaScript，甚至一些HTML來允許焦點狀態……加上一些aria-*屬性，我沒有足夠的專業知識來解釋它們為什麼重要。

最終結果如下：

所以問題變成了：我們切換類名的技能是否對Web有害，因為它們沒有考慮到這些方面？使用任何基本的工具是否會損害Web的可訪問性？我不知道。這個問題對我來說太大了。不過，這是一個值得思考的問題。

肌肉記憶

如果我們首先學習像第一個演示那樣編寫選項卡，只要沒有人因為這樣做而批評我們，我們就會一遍遍地使用它。我大約在三分鐘內編寫了該演示，因為我已經做過很多次了。創建這些選項卡肯定是我肌肉記憶的一部分。

很多人認為JavaScript框架是Web上的禍害，因為它們似乎正在引領一個可訪問性最差的時代。但是，如果構建選項卡的肌肉記憶是使用預構建的選項卡UI，它會帶來所有正確功能，並將樣式主要留給你呢？

這就是Reach UI選項卡（假設我們使用React……）。

我並不是要你將項目切換到React以便獲得一些免費的選項卡，但是React已經非常龐大。如果這樣的良好模式成為事實上的選擇，那麼其效果可能是對可訪問性的淨增益。至少對我來說是可能的。它可能會阻止我第359次拙劣地手動編寫選項卡界面。

以上是標籤：它的複雜™的詳細內容。更多資訊請關注PHP中文網其他相關文章！