了解輔助功能：第 5 部分
- PHPz原創
- 2023-08-31 20:33:02861瀏覽
這是我們要討論的最後一個原則。從廣義上講，它規定網站的內容和導航必須易於理解。雖然實施許多這些建議的責任在於外掛程式或主題的「最終用戶」（或發佈內容的任何人），但這些外掛程式和主題的開發人員可以實施一些建議。
可讀（3.1）
第一條準則指出內容應該「可讀且易於理解」。許多建議與內容的閱讀程度以及不常用單字、縮寫和首字母縮寫的使用有關，這些都與開發人員無關。
我們可以實施的一項建議是網頁的人類語言應該能夠以程式設計方式識別。為此，應透過 lang 屬性在 元素上指定語言。此外，應使用 dir 屬性來指示內容是否從右到左。
WordPress 透過提供 language_attributes() 來簡化此操作，它會列印所需的屬性。在主題的 header.php 中：
<html <?php language_attributes(); ?>>
language_attributes() 函數設定網站的語言，並在必要時設定方向，並過濾輸出，允許外掛程式（例如多語言外掛程式）根據需要更改屬性。
可預測 (3.2)
第二條準則指出，網站應該以可預測的方式呈現和運作。透過確保主題的 HTML 標記結構良好且符合邏輯，可以實現許多建議。除此之外，還有大量的「不要做」的建議——建議不要進行破壞網頁自然和邏輯行為的更改。
焦點行為
我們在本系列的第四篇文章（「可操作」）中提到不使用 tabindex。此建議在此基礎上聲明，當某個項目獲得焦點時，不應將其視為觸發頁面狀態的某些變更。
例如，接收焦點的表單按鈕不應導致該表單提交，接收焦點的連結不應導致該連結被啟動。這並不是說當相應的項目獲得焦點時，工具提示或導航選單的子選單不應出現。這些例子並不構成狀態的改變。粗略地說，您可以將獲得焦點的項目與懸停在其上的項目等同起來。
不要妨礙焦點
您應該避免從接收焦點的元素上移除焦點。例如，您絕對不應該執行以下操作：
$('a').on('focus',function(){ $(this).blur(); });
在需要使用者輸入時幫助使用者 (3.3)
確保識別錯誤
預設情況下，與主題開發人員相關的唯一表單是登入/註冊、搜尋和評論表單。其中，主題開發人員通常只關注後兩者。由於搜尋表單永遠不會導致“錯誤”，因此我們本節重點關注評論表單。
WordPress 在通知用戶錯誤以及確切地告知他們錯誤是什麼方面做得非常好。然而，它是透過允許用戶離開原始頁面並向他們呈現「死胡同」錯誤頁面來實現這一點的。
如果使用者回到原始頁面，表單將失去焦點，他們將不得不再次找到它。更好的解決方案是阻止使用者在正確填寫表單之前提交表單。但是，在執行此操作時，必須向使用者傳達輸入的值無效的訊息，否則您實際上已經將他們困住了。
有大量可用的客戶端驗證腳本，並且建立您自己的簡單驗證腳本也非常容易。重要的是：
- 使用者離開具有無效值的欄位（或嘗試提交表單）後出現的錯誤訊息應傳達存在錯誤以及錯誤所在的位置（即標識欄位）。
- 應使用 ARIA 屬性將錯誤訊息識別為警報：
role="alert"。 - 在適當的情況下，錯誤訊息應盡可能明確地告知使用者輸入的值未被接受的原因。
這是一個簡單的範例，基於 WebAIM 自己的可存取表單驗證範例（我鼓勵您閱讀），如果名稱欄位為空，它會新增錯誤訊息。
jQuery(document).ready(function($) {
$('#author').on( 'blur', function( e ){
var value = $(this).val();
if( !value ){
if( $('#author-error').length > 0 ){
$('#author-error').remove();
}
$( '<p id="author-error" class="alert alert-error" role="alert"></p>' )
.insertAfter( $('#author') )
.text( 'Name field error: Please provide a name' );
}else if( $('#author-error').length > 0 ){
$('#author-error').remove();
}
});
});
WebAIM 範例還可以防止使用者使欄位無效，並將他們返回到欄位以修正錯誤。如果您這樣做，我建議您在值為空時不要將使用者返回到該字段，否則您會讓那些意外給予字段焦點但無意的用戶感到沮喪提交表格。
如本系列前面所述，您不應僅依靠顏色或位置來傳達意義。在這種情況下，錯誤訊息應該從文本中明顯看出，它們相關的欄位也應該如此。
提供標籤
主題只能使用 comment_form() 來顯示評論表單，而這會以可存取的方式處理標籤。同樣，預設搜尋表單也不需要進一步的工作。但是，在自訂或設計這些表單時，您應該：
確保標籤始終可見
標籤必須始終可見。具體來說，這意味著佔位符不構成標籤，並且不應用作搜尋。造成這種情況的原因有幾個：
- 对屏幕阅读器的支持不一致。
- 占位符通常采用柔和的颜色，可能难以阅读。
- 由于当字段获得焦点时占位符会消失，因此可能会给有认知障碍的人带来可用性问题。
在适当的情况下提供进一步说明
如果表单字段需要进一步的说明，可以在字段之后提供这些说明，但仍然使用 aria-scribedby 属性显式链接到该字段。该属性引用的元素的内容在field的标签后面读出。
以 W3C 网站为例：
<form>
<label for="fname">First name</label>
<input name="" type="text" id="fname" aria-describedby="fname-description">
<p id="fname-description">A bit of instructions for this field linked with aria-describedby. </p>
</form>
但是，您应该注意，屏幕阅读器对此的支持并不一致。
确定必填字段
必填字段应使用 aria-required="true" 属性进行标记。由 comment_form() 生成的默认 WordPress 评论表单已处理此问题，因此您需要在此处执行任何操作。但是，如果您选择自定义评论表单，则应该注意这一点。
结论
本文总结了我们关于 W3C 可访问性原则的粗略主题开发人员指南以及如何实施这些原则。在本系列的最后一篇文章中，我们将研究一些简单的方法，以进一步推动并积极鼓励和帮助我们的主题（或插件）的最终用户生成可访问的内容。
以上是了解輔助功能：第 5 部分的詳細內容。更多資訊請關注PHP中文網其他相關文章！