Heim > Artikel > Web-Frontend > Barrierefreiheit verstehen: Teil 5
Barrierefreiheit verstehen: Teil 5
- PHPzOriginal
- 2023-08-31 20:33:02790Durchsuche
Dies ist das letzte Prinzip, das wir besprechen möchten. Im Großen und Ganzen besagt es, dass der Inhalt und die Navigation einer Website leicht verständlich sein müssen. Während die Verantwortung für die Umsetzung vieler dieser Empfehlungen beim „Endbenutzer“ des Plugins oder Themes (oder demjenigen, der den Inhalt veröffentlicht) liegt, gibt es einige Empfehlungen, die von den Entwicklern dieser Plugins und Themes umgesetzt werden können.
Lesbar (3.1)
Die erste Richtlinie besagt, dass Inhalte „lesbar und leicht verständlich“ sein sollten. Viele der Vorschläge beziehen sich auf das Leseniveau des Inhalts und die Verwendung ungewöhnlicher Wörter, Abkürzungen und Akronyme, die für Entwickler nicht relevant sind.
Ein Vorschlag, den wir umsetzen können, ist, dass die menschliche Sprache von Webseiten programmgesteuert identifizierbar sein sollte. Geben Sie dazu über das Attribut lang 属性在 元素上指定语言。此外，应使用 dir an, ob der Inhalt von rechts nach links geschrieben ist.
WordPress powered by language_attributes() 来简化此操作，它会打印所需的属性。在主题的 header.php in:
<html <?php language_attributes(); ?>>
language_attributes() Die Funktion stellt die Sprache und ggf. die Ausrichtung der Website ein und filtert die Ausgabe, sodass Plugins (z. B. mehrsprachige Plugins) die Eigenschaften nach Bedarf ändern können.
Vorhersehbar (3.2)
Die zweite Richtlinie besagt, dass Websites vorhersehbar aussehen und sich verhalten sollten. Viele der Empfehlungen können umgesetzt werden, indem Sie sicherstellen, dass das HTML-Markup Ihres Themes gut strukturiert und logisch ist. Darüber hinaus gibt es jede Menge Ratschläge, die Sie nicht tun sollten – Empfehlungen, die Sie davon abhalten, Änderungen vorzunehmen, die das natürliche und logische Verhalten der Webseite beeinträchtigen.
Fokusverhalten
Wir haben im vierten Artikel dieser Serie („Actionable“) darüber gesprochen, tabindex nicht zu verwenden. Diese Empfehlung baut darauf auf und besagt, dass ein Element, das in den Fokus gelangt, nicht als Auslöser einer Änderung des Seitenstatus angesehen werden sollte.
Zum Beispiel sollte eine Formularschaltfläche, die den Fokus erhält, nicht dazu führen, dass das Formular gesendet wird, und ein Link, der den Fokus erhält, sollte nicht dazu führen, dass der Link aktiviert wird. Dies bedeutet nicht, dass Tooltips oder Untermenüs von Navigationsmenüs nicht angezeigt werden sollten, wenn das entsprechende Element den Fokus erhält. Diese Beispiele stellen keine Statusänderung dar. Grob gesagt können Sie das Element, das den Fokus hat, mit dem Element gleichsetzen, über dem sich der Mauszeiger befindet.
Blockieren Sie nicht den Fokus
Sie sollten vermeiden, den Fokus von dem Element zu entfernen, das den Fokus erhält. Folgendes sollten Sie zum Beispiel niemals tun:
$('a').on('focus',function(){ $(this).blur(); });
Helfen Sie dem Benutzer, wenn Benutzereingaben erforderlich sind (3.3)
Stellen Sie sicher, dass Sie Fehler identifizieren
Standardmäßig sind die einzigen für Theme-Entwickler relevanten Formulare die Anmelde-/Registrierungs-, Such- und Kommentarformulare. Von diesen konzentrieren sich Theme-Entwickler normalerweise nur auf die beiden letztgenannten. Da die Suche nach einem Formular nie zu einem „Fehler“ führt, konzentrieren wir uns in diesem Abschnitt auf Kommentarformulare.
WordPress leistet hervorragende Arbeit, indem es Benutzer über Fehler informiert und ihnen genau sagt, um welchen Fehler es sich handelt. Dies geschieht jedoch dadurch, dass Benutzer von der Originalseite weg navigieren können und ihnen eine „Sackgasse“-Fehlerseite angezeigt wird.
Wenn der Benutzer zur ursprünglichen Seite zurückkehrt, verliert das Formular den Fokus und er muss es erneut finden. Eine bessere Lösung wäre, den Benutzer daran zu hindern, das Formular abzusenden, bevor er es korrekt ausgefüllt hat. Dabei müssen Sie dem Benutzer jedoch mitteilen, dass der eingegebene Wert ungültig ist, andernfalls haben Sie ihn effektiv abgefangen.
Es stehen unzählige clientseitige Validierungsskripte zur Verfügung, und es ist sehr einfach, ein eigenes einfaches Validierungsskript zu erstellen. Wichtig ist:
- Die Fehlermeldung, die angezeigt wird, nachdem der Benutzer ein Feld mit einem ungültigen Wert verlässt (oder versucht, ein Formular abzusenden), sollte mitteilen, dass ein Fehler vorliegt und wo er sich befindet (d. h. im Identifikationsfeld).
- Fehlermeldungen sollten mithilfe des ARIA-Attributs als Warnungen identifiziert werden:
role="alert". - Gegebenenfalls sollten Fehlermeldungen den Benutzer möglichst klar darüber informieren, warum der eingegebene Wert nicht akzeptiert wurde.
Dies ist ein einfaches Beispiel, das auf WebAIMs eigenem Beispiel zur barrierefreien Formularvalidierung basiert (ich empfehle Ihnen, es zu lesen), das eine Fehlermeldung hinzufügt, wenn das Namensfeld leer ist.
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();
}
});
});
Das WebAIM-Beispiel verhindert außerdem, dass Benutzer Felder ungültig machen, und gibt sie an Felder zurück, um Fehler zu korrigieren. Wenn Sie dies tun, empfehle ich Ihnen, den Benutzer nicht zum Feld zurückzubringen, wenn der Wert leer ist. Andernfalls werden Sie Benutzer frustrieren, die versehentlich den Fokus auf das Feld legen, ohne die Absicht zu haben, das Formular abzusenden. Wie bereits in dieser Serie erwähnt, sollten Sie sich nicht ausschließlich auf Farbe oder Platzierung verlassen, um Bedeutung zu vermitteln. In diesem Fall sollten die Fehlermeldungen sowie die zugehörigen Felder aus dem Text ersichtlich sein.
Tags bereitstellen
Themes können
nur zum Anzeigen von Kommentarformularen verwenden, und dies behandelt Tags auf zugängliche Weise. Ebenso erfordert das Standardsuchformular keine weitere Arbeit. Wenn Sie diese Formulare jedoch anpassen oder entwerfen, sollten Sie Folgendes tun:
comment_form()Stellen Sie sicher, dass die Etiketten immer sichtbar sind
Das Etikett muss jederzeit sichtbar sein. Konkret bedeutet dies, dass Platzhalter keine Tags darstellen und nicht in der Suche verwendet werden sollten. Dafür gibt es mehrere Gründe:
- 对屏幕阅读器的支持不一致。
- 占位符通常采用柔和的颜色，可能难以阅读。
- 由于当字段获得焦点时占位符会消失，因此可能会给有认知障碍的人带来可用性问题。
在适当的情况下提供进一步说明
如果表单字段需要进一步的说明，可以在字段之后提供这些说明，但仍然使用 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 可访问性原则的粗略主题开发人员指南以及如何实施这些原则。在本系列的最后一篇文章中，我们将研究一些简单的方法，以进一步推动并积极鼓励和帮助我们的主题（或插件）的最终用户生成可访问的内容。
Das obige ist der detaillierte Inhalt vonBarrierefreiheit verstehen: Teil 5. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!