初級前端開發(fā)者學(xué)習(xí)JavaScript時(shí)，掌握切換類名是一個(gè)快速有效的技巧。

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

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

利用這個(gè)技巧，我們可以構(gòu)建選項(xiàng)卡。

簡單實(shí)現(xiàn)

如果我們已經(jīng)掌握了切換類名的技巧，需要構(gòu)建一個(gè)選項(xiàng)卡界面，只需添加一些處理點(diǎn)擊事件的代碼，就能實(shí)現(xiàn)簡單的選項(xiàng)卡，例如：

這些選項(xiàng)卡完全可用。 我利用錨鏈接在鏈接和選項(xiàng)卡區(qū)域之間創(chuàng)建跳轉(zhuǎn)鏈接，這在語義上是合理的。選項(xiàng)卡可以通過鍵盤訪問，具有焦點(diǎn)樣式，并且可以使用Return鍵激活。

但這夠了嗎？完美的選項(xiàng)卡？

并非易事

問題在于，我們沒有對鍵盤處理做任何特殊處理，而選項(xiàng)卡界面可能需要鍵盤處理。Heydon Pickering對此進(jìn)行了說明：

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

這帶來了一個(gè)不幸的副作用：如果用戶希望通過鍵盤移動(dòng)到某個(gè)區(qū)域并與其內(nèi)部內(nèi)容交互，他們必須依次遍歷當(dāng)前選項(xiàng)卡右側(cè)的所有選項(xiàng)卡，這些選項(xiàng)卡按焦點(diǎn)順序排列。

事實(shí)證明，選項(xiàng)卡界面還有許多其他的行為方面需要考慮。在Heydon的解釋中，Tab鍵實(shí)際上可以作為一種方法，從選項(xiàng)卡本身跳轉(zhuǎn)到與該選項(xiàng)卡相關(guān)的內(nèi)容，從而移動(dòng)焦點(diǎn)。Shift Tab 將焦點(diǎn)帶回。然后使用箭頭鍵更改選項(xiàng)卡。所有這些都需要更多的JavaScript，甚至一些HTML來允許焦點(diǎn)狀態(tài)……加上一些aria-*屬性，我沒有足夠的專業(yè)知識來解釋它們?yōu)槭裁粗匾?/p>

最終結(jié)果如下：

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

肌肉記憶

如果我們首先學(xué)習(xí)像第一個(gè)演示那樣編寫選項(xiàng)卡，只要沒有人因?yàn)檫@樣做而批評我們，我們就會一遍遍地使用它。我大約在三分鐘內(nèi)編寫了該演示，因?yàn)槲乙呀?jīng)做過很多次了。創(chuàng)建這些選項(xiàng)卡肯定是我肌肉記憶的一部分。

很多人認(rèn)為JavaScript框架是Web上的禍害，因?yàn)樗鼈兯坪跽谝I(lǐng)一個(gè)可訪問性最差的時(shí)代。但是，如果構(gòu)建選項(xiàng)卡的肌肉記憶是使用預(yù)構(gòu)建的選項(xiàng)卡UI，它會帶來所有正確功能，并將樣式主要留給你呢？

這就是Reach UI選項(xiàng)卡（假設(shè)我們使用React……）。

我并不是要你將項(xiàng)目切換到React以便獲得一些免費(fèi)的選項(xiàng)卡，但是React已經(jīng)非常龐大。如果這樣的良好模式成為事實(shí)上的選擇，那么其效果可能是對可訪問性的凈增益。至少對我來說是可能的。它可能會阻止我第359次拙劣地手動(dòng)編寫選項(xiàng)卡界面。

以上是標(biāo)簽：它的復(fù)雜?的詳細(xì)內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！