Accessibility mit Blazor

Autor

Simon Gubler

Thema

Softwareentwicklung

Lesezeit

8 - 10 Minuten

Abstrakt

Der Artikel erklärt praxisnah, wie sich die Barrierefreiheit (Accessibility) von Webseiten verbessern lässt. Er empfiehlt drei zentrale Testwerkzeuge: WAVE zur schnellen visuellen Problemerkennung, axe Dev Tools für detaillierte Analysen ohne Seitenmanipulation und NVDA als Screenreader für realitätsnahe Tests. Ein zentrales Thema ist die richtige Verwendung von HTML-Landmark-Elementen wie <main>, <section>, <nav>, <header> und <footer>. Diese sollten mit aria--Attributen und Labels ergänzt werden, um Screenreadern klare Navigationsstrukturen zu bieten. Anhand von Blazor-Beispielen zeigt der Autor, wie Accessibility in Frameworks wie MudBlazor umgesetzt und typische Probleme, z. B. fehlende aria-labels, behoben werden können. Besonders hervorgehoben wird, wie man versteckte, aber dennoch fokussierbare Inhalte – etwa in Drawer-Komponenten – korrekt ausblendet oder nur bei Bedarf rendert.

Einführung

In vielen Webseitenprojekten soll auch noch die “Accessibility verbessert” werden. Doch was heisst das? Wie kann man die Accessibility einer Webseite messen und wie soll die HTML-Struktur am besten gestaltet werden? Diese Fragen möchte ich in diesem Blogpost aus einer praktischen Perspektive beantworten, ich möchte Ihnen zeigen, wie Sie in möglichst kurzer Zeit die wichtigsten Punkte verbessern können. Ausserdem werden am Beispiel von Blazor gezeigt, wie man konkret eine barrierefreie Seite implementieren kann.

Mit welchen Tools kann ich die Accessibility testen und messen?

Die wenigsten von uns haben Sehprobleme oder haben Erfahrung, eine Webseite blind zu bedienen. Deshalb sind die richtigen Werkzeuge sehr wichtig um die grössten Probleme der Webseite sichtbar zu machen. Drei dieser Werkzeuge würde ich besonders empfehlen:

WAVE Web Accessibility Evaluation Tools

axe Dev Tools

Screenreader (zB. NVDA)

So gut die beiden oben beschriebenen Tools sind, finden sie nur einen Bruchteil der Probleme die man feststellt, wenn man die Seite mit einem Screenreader bedienen würde. Und umgekehrt gilt: Nicht alle Issues, die in der Analyse gezeigt werden führen zu Probleme bei der Navigation mit einem Screenreader.

Das Prinzip eines Screenreaders ist ganz einfach: Er liest das aktuell fokussierte Element vor in der Webseite. Wenn Sie den Fokus wechseln liest er auch dieses Element vor und berücksichtigt dabei die Struktur der Webseite. So weiss der Benutzer zum Beispiel, wenn der Fokus vom Header-Bereich in den Main-Bereich wechselt. Bedingung dafür ist, dass die Webseite entsprechende Strukturen hat.

Falls Sie Windows verwenden würde ich NVDA empfehlen, da es oft als das Standardtool in dieser Umgebung angegeben wird. Der erste Eindruck nach dem Start von NVDA kann einschüchternd sein, denn die Software startet sofort mit Vorlesen und das ziemlich laut! Deshalb empfehle ich, gleich nach dem Start mit der Taste NVDA (standardmässig Caps Lock) + S die automatische Stimme abzuschalten und die Einstellungen anzupassen.

Unter “Allgemein” sollte die Sprache auf “Deutsch” angepasst werden und unter “Sprachausgabe” kann die Stimme und die Lautstärke angepasst werden. Nun können Sie Ihre gewünschte Webseite testen. Wechseln Sie den Sprachmodus wieder mit NVDA+S und öffnen Sie im Browser die Seite. Nun tabt sich NVDA durch die Webseite und liest jedes fokussierte Element vor. Die Textform der gesprochenen Worte vom Screenreader können Sie mit NVDA+N, “Werkzeuge (z)”, “Sprachausgaben betrachter (s)”. Das kann hilfreich sein, um den Stand der Webseite zu dokumentieren. Ein weiterer Trick um besser zu verstehen, was NVDA “sieht” ist die Elementlisten-Anzeige. Diese können Sie mit NVDA+F7 erreichen. Besonders interessant ist die “Sprungmarken”-Ansicht. Dort sind die Bereiche der Webseite aufgelistet. Die nötigen HTML-Strukturen um die Bereiche zu definieren werden im nächsten Kapitel vorgestellt.

Welche HTML-Strukturen machen eine Seite accessible?

Die wichtigsten Elemente sind die sogenannten Landmark-Elemente. Beispielsweise <main> oder <section>. Mit diesen Elementen können Sie die Webseite in semantisch klare Bereiche einteilen. Unter <main> kommt der Hauptteil der Seite, in einer <section> befindet sich ein wichtiger Teil der Webseite. Weitere wichtige Elemente sind <nav>, <header>, <footer>.

Wichtig bei <section> ist: eine Section braucht einen Namen. Idealerweise ist dieser Name in einem Titel-Element gleich beim Start der Section vorhanden.

<section>
  <h2>Links</h2>
  <a href="..." >Beispiels-Link</a>
</section>

Was passiert nun in diesem Beispiel wenn der Fokus auf den Beispiels-Link gesetzt wird? Eigentlich sollte der Screenreader den Bereich und den Link vorlesen, also “Links Beispiels-Link” aber das tut er nicht. Er liest nur “Beispiels-Link” vor. Weshalb? Der Grund ist, dass der Titel nicht eindeutig verlinkt ist. Der Section-Tag braucht das “aria-labelledby”-Attribut, das auf die ID vom Titel-Tag zeigt. Hier ist das korrigierte Beispiel:

<section aria-labelledby="links_titel">
  <h2 id="links_titel">Links</h2>
  <a href="..." >Beispiels-Link</a>
</section>

Alternativ zu “aria-labelledby” können Sie auch mit “aria-label” die Sektion direkt betiteln:

<section aria-label="Links">
</section>

Bei Formularen ist es ebenfalls sehr wichtig, dass die Eingabefelder mit einem Label verknüpft sind:

<form>
  <label for="Name">Name</label>
  <input type="text" id="Name">
</form>

Der Screenreader liest dann korrekt das Feld vor wenn der Fokus auf das Textfeld gesetzt wird. Wichtig ist, dass die ID keine Sonderzeichen (zB. Klammern) enthält. Ansonsten bleibt der Screenreader stumm.

Wie gut kann ich Accessible Websites mit Blazor implementieren?

Frameworks

Die grossen Frameworks wie MudBlazor oder DevExpress Blazor haben gerade in letzter Zeit grosse Verbesserungen im Bereich der Accessibility erfahren. Schön ist, dass die Formular-Elemente von beiden Frameworks die Labels standardmässig mit Input-Elementen verknüpft werden. Was auch oft gut funktioniert, ist dass man die Komponenten mit Aria-Attributen konfigurieren kann.

Trotz diesen erfreulichen Tendenzen gibt es auch viel Verbesserungspotential in den Frameworks. Viele Komponenten sind auch sehr komplex und können sehr verwirrende Sprachausgaben bewirken mit dem Screenreader. Auch ist zumindest bei Mudblazor die Tastaturnavigation nicht überall möglich. Doch ich bin sicher, dass diese Issues in der Zukunft angegangen werden.

Tricks mit Blazor

Die folgenden zwei Beispiele können Sie mit mit der MudBlazor-Beispiels-Solution nachvollziehen. Um die Solution zu erstellen führen Sie folgendes Statement aus:

dotnet new mudblazor --interactivity WebAssembly --name MyApplication --all-interactive

Wir haben in der MudBlazor-Beispielseite mit Hilfe vom axe Dev Tools ein Issue gesehen: Der Button, der das Menu öffnet und schliesst hat keinen Text. Wir können das Problem einfach beheben, indem wir dem MudIconButton ein “aria-label”-Attribut hinzufügen.

Hier ein Auszug:

...
<MudIconButton 
  Icon="@Icons.Material.Filled.Menu" 
  OnClick="@((e) => DrawerToggle())" 
  aria-label="@ToggleMenuButtonAriaLabel" />
...

@code {
  private bool _drawerOpen = true;
  private void DrawerToggle()
  {
    _drawerOpen = !_drawerOpen;
  }
  private string ToggleMenuButtonAriaLabel 
    => _drawerOpen 
    ? "Menu schliessen" 
    : "Menu öffnen";
}

Mudblazor generiert dann bei geschlossenem Menu dieses HTML:

<button aria-label="Menu öffnen" type="button" ...

Der Code dafür ist einfach: Mittels einer Boolean-Variable kann der Open-Status vom Drawer gesteuert werden. In diesem Beispiel enthält der Drawer eine Combobox.

<MudButton OnClick="() => drawerIsOpen = true">Show drawer</MudButton>
<MudDrawer Anchor="Anchor.Right" @bind-Open="drawerIsOpen">
    <h4>Drawer</h4>
    <label for="pet-select">Choose a pet:</label>

    <select name="pets" id="pet-select">
      <option value="">--Please choose an option--</option>
      <option value="dog">Dog</option>
      <option value="cat">Cat</option>
    </select>
</MudDrawer>

@code 
{
    private bool drawerIsOpen = false;
}

Wie kann man das Problem lösen? Eine Lösung wäre, den Drawer-Inhalt mit dem aria-hidden-Attribut zu dekorieren. Dadurch weiss der Screenreader, dass der Inhalt nicht zugänglich ist. Eine andere Lösung ist, den Drawer nur zu rendern, wenn der Boolean-Wert auf True ist. Das ist in Blazor sehr einfach möglich.

Erst wenn der Wert von drawerIsOpen auf true wechselt “sieht” der Browser nun das HTML-Element für den Drawer und der Inhalt ist fokussierbar.

<MudButton OnClick="() => drawerIsOpen = true">Show drawer</MudButton>

@if (drawerIsOpen)
{
    <MudDrawer Anchor="Anchor.Right" @bind-Open="drawerIsOpen">
        <h4>Drawer</h4>
        <label for="pet-select">Choose a pet:</label>

        <select name="pets" id="pet-select">
          <option value="">--Please choose an option--</option>
          <option value="dog">Dog</option>
          <option value="cat">Cat</option>
        </select>
    </MudDrawer>
}

@code 
{
    private bool drawerIsOpen = false;
}

Worauf sollte bei accessible Webseiten noch geachtet werden?

Einige wichtige Punkte sollen hier zur Vollständigkeit kurz erwähnt werden:

• Bilder sollten immer einen alt-Text enthalten. Diesen kann der Screenreader vorlesen

• Achten Sie auf einen guten Farbkontrast in Texten oder Icons. Ist der Kontrast zu klein, erkennen Menschen mit Sehschwäche den Inhalt nicht mehr

• Achten Sie auf ein gutes Fokus-Management. Sorgen Sie zum Beispiel dafür, dass der Fokus bei einem modalen Dialog in den Dialog springt und dort “gefangen” bleibt, bis der Dialog geschlossen wird.

Fazit

Accessibility wird häufig vernachlässigt, weil ihre Vorteile nicht sofort sichtbar sind. Doch mit den richtigen Tools und einer durchdachten HTML-Struktur kann die Zugänglichkeit einer Webseite schnell und einfach verbessert werden. Der Effekt kommt nicht nur Menschen mit visuellen Einschränkungen zugute – laut WHO betrifft das rund 2,2 Milliarden Menschen weltweit – sondern auch Power-User profitieren davon, wenn eine Webseite vollständig mit der Tastatur bedienbar ist.