Einfache Schritte zur Gewährleistung der Barrierefreiheit in Ihren Angular-Projekten

Wenn wir Apps erstellen, konzentrieren wir uns normalerweise auf die Bereitstellung und nicht auf andere Aspekte wie Barrierefreiheit und Tests (aber das Testen wird in einem anderen Beitrag behandelt). Heute möchte ich über Barrierefreiheit sprechen. Meistens glauben wir, dass Barrierefreiheit nur dazu dient, Menschen mit Behinderungen bei der Nutzung unseres Produkts zu helfen, aber tatsächlich verbessert sie das Erlebnis für alle Benutzer.

Im Dezember habe ich etwas Zeit damit verbracht, etwas über Barrierefreiheit zu lernen, und ich kann die Teilnahme an diesen kostenlosen Kursen nur wärmstens empfehlen.

• Barrierefreiheit lernen: https://web.dev/learn/accessibility

• Erstellen Sie zugänglichere Angular-Apps https://codelabs.developers.google.com/angular-a11y#3

Dieses Wochenende habe ich mir die Zeit genommen, die Fähigkeiten zu testen, die ich gelernt habe, indem ich ein kleines Formular erstellt habe, das von Anfang an Barrierefreiheit beinhaltet, einschließlich der Formulareinrichtung und -validierung. Lass es uns tun!

Ich wollte das Formular „Brief an den Weihnachtsmann“ erstellen, in dem mein Sohn seinen Namen, seine E-Mail-Adresse und eine Nachricht an den Weihnachtsmann senden kann, aber ich möchte ein barrierefreies Formular mit klaren und zugänglichen Bestätigungen und einer Benachrichtigung erstellen, wenn die Nachricht eingeht wurde erfolgreich gesendet.

Endlich habe ich ein Formular wie dieses erhalten:

---

Das Hauptziel des Formulars besteht darin, Informationen von Benutzern zu sammeln. Wenn Formulare nicht barrierefrei sind, schließen wir einen erheblichen Teil der Personen aus, z. B. Benutzer mit Seh- oder Motorbehinderungen, Personen, die einen vorübergehenden Unfall hatten oder deren Hände beschäftigt sind.

Ich begann, die Barrierefreiheit zu verbessern, indem ich semantische HTML-Elemente wie

,

und

verwendete und Inhalte hierarchisch mit Überschriften (

bis

) organisierte. Dies hilft Screenreadern dabei, korrekt auf der Seite zu navigieren, und verbessert außerdem die Suchmaschinenoptimierung.

<header>
  <h1 id="Write-Your-Letter-to-Santa">Write Your Letter to Santa</h1>
</header>
<main>
  <h2 id="Fill-Out-the-Form">Fill Out the Form</h2>
</main>
<footer>
</footer>

Das Hauptziel des Formulars besteht darin, Informationen von Benutzern zu sammeln. Wenn Formulare nicht barrierefrei sind, schließen wir einen erheblichen Teil der Personen aus, z. B. Benutzer mit Seh- oder Motorbehinderungen, Personen, die einen vorübergehenden Unfall hatten oder deren Hände beschäftigt sind.

Ich begann, die Barrierefreiheit zu verbessern, indem ich semantische HTML-Elemente wie

,

und

verwendete und Inhalte hierarchisch mit Überschriften (

bis

) organisierte. Dies hilft Screenreadern dabei, korrekt auf der Seite zu navigieren, und verbessert außerdem die Suchmaschinenoptimierung.

<label for="name">Name</label>
<input>



<p>But forms are more than just input and label; they need validations or error messages that should only appear when relevant, such as after a field has been interacted with (touched) or when the form is submitted. But how do I notify the user with a message?</p>

<p>First, the notifications should be announced by screen readers using aria-live with a visually clear design for users who do not use assistive technologies and avoid unnecessarily interrupting the user.</p>

<blockquote>
<p>Learn more about aria-live and roles</p>
</blockquote>

<p>There are different ARIA roles to use with the notifications for specific scenarios, using role="alert" for critical or high-priority messages, such as errors. It automatically interrupts the user and announces the content immediately, or role="status" for non-critical updates, such as confirmations or status changes.<br>
</p>

<pre class="brush:php;toolbar:false">    <div>



<p>But how are those messages announced? You have assertive, which stops the current message, or polite, which waits to announce by screen readers without interruption.<br>
</p>

<pre class="brush:php;toolbar:false">@if ((nameCtrl.invalid && nameCtrl.touched) || (nameCtrl.invalid && isSubmitted)) {
  <div>



<p>For example, aria-live="polite" waits to announce the content after completing its current task. It is perfect for notifications like when a message has been sent:<br>
</p>

<pre class="brush:php;toolbar:false">    @if (messageSent) {
      <div>



<p>But what happens when I want content only for screen readers? We can create a utility class like .visually-hidden for content that is only meant to be accessible to screen readers and not visible to sighted users.<br>
</p>

<pre class="brush:php;toolbar:false">.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Es trägt dazu bei, sicherzustellen, dass wichtige Informationen an Benutzer übermittelt werden, die sich auf Bildschirmleseprogramme verlassen, ohne das visuelle Layout zu beeinträchtigen.

<span>



<p>Another key point is also is the color, with adequate contrast, the text should have sufficient contrast with its background according but most easy way is using the color-contrast-checker extension.<br>
</p>

<pre class="brush:php;toolbar:false">input.ng-invalid.ng-touched {
  border-color: #e74c3c; 
  background-color: #fdecea; 
}

Perfekt, wir können unser Formular barrierefrei erstellen!! Hey, mal kurz? Was passiert, wenn @Jörgen de Groot morgen eine neue Funktion hinzufügt, wie ich steuern kann, dass die Zugänglichkeit nicht beeinträchtigt wird?

Der es-lint ist dein Freund, füge ihn zuerst mithilfe der Schaltpläne hinzu:

<header>
  <h1 id="Write-Your-Letter-to-Santa">Write Your Letter to Santa</h1>
</header>
<main>
  <h2 id="Fill-Out-the-Form">Fill Out the Form</h2>
</main>
<footer>
</footer>

Der es-lint stellt eine Reihe von Barrierefreiheitsregeln wie „accessibility-label-has-associated-control“ bereit, um sicherzustellen, dass jedem Beschriftungselement ein zugehöriges Formularsteuerelement zugeordnet ist (ähnlich wie „accessibility-label-for“, aber strenger).

<label for="name">Name</label>
<input>



<p>But forms are more than just input and label; they need validations or error messages that should only appear when relevant, such as after a field has been interacted with (touched) or when the form is submitted. But how do I notify the user with a message?</p>

<p>First, the notifications should be announced by screen readers using aria-live with a visually clear design for users who do not use assistive technologies and avoid unnecessarily interrupting the user.</p>

<blockquote>
<p>Learn more about aria-live and roles</p>
</blockquote>

<p>There are different ARIA roles to use with the notifications for specific scenarios, using role="alert" for critical or high-priority messages, such as errors. It automatically interrupts the user and announces the content immediately, or role="status" for non-critical updates, such as confirmations or status changes.<br>
</p>

<pre class="brush:php;toolbar:false">    <div>



<p>But how are those messages announced? You have assertive, which stops the current message, or polite, which waits to announce by screen readers without interruption.<br>
</p>

<pre class="brush:php;toolbar:false">@if ((nameCtrl.invalid && nameCtrl.touched) || (nameCtrl.invalid && isSubmitted)) {
  <div>



<p>For example, aria-live="polite" waits to announce the content after completing its current task. It is perfect for notifications like when a message has been sent:<br>
</p>

<pre class="brush:php;toolbar:false">    @if (messageSent) {
      <div>



<p>But what happens when I want content only for screen readers? We can create a utility class like .visually-hidden for content that is only meant to be accessible to screen readers and not visible to sighted users.<br>
</p>

<pre class="brush:php;toolbar:false">.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Lesen Sie gerne mehr über die Barrierefreiheit von es-lint, fügen Sie diese Regeln zur Datei (.eslintrc.json) hinzu und passen Sie den Schweregrad („Warnung“, „Fehler“ usw.) nach Bedarf an:

<span>



<p>Another key point is also is the color, with adequate contrast, the text should have sufficient contrast with its background according but most easy way is using the color-contrast-checker extension.<br>
</p>

<pre class="brush:php;toolbar:false">input.ng-invalid.ng-touched {
  border-color: #e74c3c; 
  background-color: #fdecea; 
}

Nach dem Ausführen von npm run lint tada!! Wir haben einen Linter für unseren Code!

Rekapitulieren

Ich hoffe, wenn Sie mit der Erstellung Ihres nächsten Projekts beginnen, beachten Sie diese Tipps, um die Zugänglichkeit zu vereinfachen und unsere Apps für alle Benutzer zu verbessern.