Moderne Apps

Design und Entwicklung benutzerfreundlicher moderner Apps

Rachel Appel

Rachel AppelWelchen Wert hat Technologie – Internet, Apps und verschiedenste Medien – wenn sie keinen Vorteil für die Menschen darstellt? Leider gibt es viele Softwareprogramme, die nicht für alle Menschen besonders nützlich sind. Designer, Führungskräfte im Unternehmen und Entwickler legen oft mehr Wert auf Sicherheit und Leistung als auf die Barrierefreiheit. Die Barrierefreiheit einer Softwarelösung genießt – wenn überhaupt – meist nur geringe Priorität.

Ihr sollte aber ein wesentlich höherer Stellenwert eingeräumt werden. WebAIM schätzt, dass die Barrierefreiheit für 20 Prozent aller Internetbenutzer eine Rolle spielt. Einige davon nutzen Hilfstechnologien. Wenn man nur die USA betrachtet, sind das bereits mehr als 60 Millionen Menschen. Diese stoßen also unter Umständen bei der Nutzung Ihrer Website oder App oder beim Lesen Ihrer Inhalte auf Schwierigkeiten. Meist bedeuten verlorene Kunden aber auch direkte Umsatzeinbußen. Meine PDF-Datei, "The Importance of Accessibility", gibt noch viele weitere Gründe, die für ein barrierefreies Design sprechen. Sie können sie unter bit.ly/1CIx4k4 herunterladen.

Grundlagen der Barrierefreiheit

Bei Design und Entwicklung einer barrierefreien Website, müssen Sie unterschiedliche mögliche Behinderungen in Betracht ziehen:

  • Einschränkungen der Sehfähigkeit: Zu den Sehbehinderungen gehören geringe Sehbeeinträchtigungen, aber auch Blindheit oder verschiedene Arten von Farbenblindheit.
  • Einschränkungen des Hörvermögens: Menschen mit Hörbehinderung sind vielleicht nur ein wenig schwerhörig, können aber auch komplett taub sein.
  • Einschränkungen der motorischen Fähigkeiten: Es gibt viele körperbehinderte Menschen. Manche haben ein Körperteil verloren oder können es nicht mehr bewegen. Andere haben aufgrund von Unfällen oder Krankheiten Schmerzen, Taubheitsgefühle oder Prickeln in den Gliedmaßen. Menschen mit motorischen Einschränkungen benötigen zudem manchmal ganz besondere Eingabegeräte.
  • Kognitive Beeinträchtigungen: Personen mit Lernstörungen, u. a. ADHS und Legasthenie, haben oftmals Probleme, Informationen zu erfassen. Das hängt ganz von der Präsentation dieser Informationen ab.

Viele Personen benötigen verschiedene Hilfstechnologien. Als Hilfstechnologien bezeichnet man beliebige Tools bzw. Technologien, die tägliche Aktivitäten erleichtern oder überhaupt ermöglichen. Die meisten würden wohl eine Brille nicht zu diesen Tools zählen. Aber auch hierbei handelt es sich letztlich um eine technisch eher einfache Hilfstechnologie. Manche Benutzer könnten ohne Brille keine technischen Geräte verwenden. Gängige Hilfstechnologien sind u. a. Lesegeräte für Blindenschrift, Mundsteuerungen, Kopfsteuerungen, anpassungsfähige Tastaturen sowie Softwareprogramme zur Spracherkennung.

 Barrierefreie Inhalte und Design

Vielleicht haben Sie es schon bemerkt? Barrierefreies Design gilt oft als herausragendes Design. Viele Websites verfügen über zu viel Werbung, was den Lesefluss des Benutzers störend unterbricht. Andere verfügen über umständliche Menüs und eine schwierige Navigation. Layout und Navigation einer Website oder App sind bei Überlegungen zur Barrierefreiheit von großer Bedeutung.

Die Inhalte sollten in klar abgegrenzte Bereiche mit sinnvollen Überschriften eingeteilt werden. Filme, Musik und Animationen sollten Untertitel oder Texttranskripte enthalten. Bei den meisten Softwareprogrammen für die Filmproduktion können heutzutage Transkripte für Untertitel eingegeben werden.

Zu einem guten Design gehört außerdem eine konsequente und schlüssige Navigation. Hierarchische JavaScript-Menüs sind auch für Benutzer ohne Behinderung häufig schwer zu verwenden. Für Personen mit motorischen Einschränkungen sind sie ein Ärgernis. Am besten funktionieren horizontale Links oben auf einer Website oder seitlich vertikal ausgerichtete Links. Bei Smartphone-Apps richten Sie sich am besten nach dem Navigationsschema des Zielgeräts. Weitere Informationen zur Navigation in Windows 8.x erhalten Sie in meiner Kolumne vom August 2013: "Navigationsgrundlagen in Windows Store-Apps" (msdn.microsoft.com/magazine/dn342878).

Die Schriftarten sollten groß und leicht zu lesen sein. Handschriftenähnliche Schriftarten sind eher unleserlich. Aus vielerlei Gründen können einige Buchstaben einer Schriftart für manche Menschen undeutlich erscheinen. Eine Ursache hierfür ist die Legasthenie. Legastheniker können nur schwer zwischen sich ähnelnden Buchstaben unterscheiden. Ungefähr 5 Prozent der Bevölkerung sind von einer Legasthenie betroffen. Manche Buchstaben werden von Legasthenikern spiegelverkehrt oder verdreht wahrgenommen.

Auf dieser Grundlage hat dyslexiefont.com eine Schriftart entwickelt, deren Buchstaben leicht verändert sind. So sind sie auch für Legastheniker einfacher zu lesen. Die Testpersonen sind bis jetzt davon begeistert. Eventuell möchten Sie diese Schriftart für Legastheniker nicht verwenden. Das ist in Ordnung. Es bedeutet nicht, dass Sie Legastheniker diskriminieren. Dennoch sollten Sie sich unbedingt für eine Schriftart entscheiden, die leicht lesbar ist.

Wenn sich Ihre App an Unternehmenskunden richtet, sollten Sie Ihre Schriftart eventuell ebenfalls anpassen. Achten Sie zudem bei der Auswahl der Schriftartfarbe auf hohen Kontrast. Ein hoher Kontrast ergibt sich beispielsweise bei einem hellen bzw. weißen Hintergrund und einem dunklen bzw. schwarzen Text. Aber auch umgekehrt wird ein Schuh daraus. Heller Text auf dunklem Hintergrund funktioniert ebenso gut. Für gewöhnlich ist es eine Frage des Geschmacks und Stils, für welche Version Sie sich entscheiden. Wichtig ist: ausreichend Kontrast.

Mit der Designstrategie Mobile-First können Sie nichts falsch machen. Durch ein Mobile-First-Design werden Sie im allgemeinen dazu gezwungen, den vorhandenen Platz bestmöglich auszunutzen. Auf den meisten Smartphones und kleinen Tablets ist nur wenige Zentimeter Platz für Inhalte. Daher werden in der App normalerweise nur die wichtigsten Informationen angezeigt. In diesem Beispiel ist einfach kein Platz für vertikale Anzeigen.

Es gibt andere gute Designmethoden, die ebenfalls zur Barrierefreiheit beitragen. Denken Sie an die beliebtesten sozialen Netzwerke und Nachrichtenwebsites im Internet. Viele sind nicht barrierefrei oder nur teilweise. Oftmals enthalten sie störende Popups, die Programme zur Sprachausgabe komplett stoppen können und Websitebesucher verärgern. Diese Popups lassen sich oft nur über winzige Schaltflächen schließen, welche häufig nur schwer auffindbar sind. Beim Klicken oder Tippen tut man sich schwer – auch mit gängigen Geräten.

Andere Websites nutzen Serien-Popups. Wenn Sie es endlich geschafft haben, eines zu schließen, wird sofort das nächste angezeigt. Einfach schrecklich. Viele Menschen mit Einschränkungen besuchen solche Websites erst gar nicht. Es ist den Aufwand nicht wert.

Vermeiden Sie Stroboskopeffekte, blinkende Effekte oder Bilder, die ohne Warnung flackern. Diese können bei Menschen, die an Epilepsie leiden, Anfälle auslösen. Außerdem verärgern Sie Ihre Besucher, es sei denn, es handelt sich um absichtliche optische Täuschungen.

Verwenden Sie niemals ausschließlich Farbe, um eine Textstelle hervorzuheben. Beispielsweise werden bei vielen Formularen Pflichtfelder rot markiert. Farbenblinde Menschen erkennen hier aber keinen Unterschied. Verwenden Sie als Text für einen Link nicht nur die Aufforderung "Hier klicken". Programme für die Sprachausgabe kommen damit überhaupt nicht zurecht. Am besten sind hier Beschreibungen.

Programmieren von barrierefreiem Code

Es gibt Programmiermethoden, die Sie für die Entwicklung barrierefreier Websites und Apps verwenden können. Als Entwickler kümmern Sie sich sowohl um Input als auch um Output. Daher sollten Sie bedenken, dass unterschiedliche Menschen auf unterschiedliche Weise mit Ihrer Software interagieren. Dabei verwenden nicht alle nur Maus und Tastatur.

Für diejenigen, die meistens oder ausschließlich die Tastatur nutzen, sollten Sie sicherstellen, dass die Aktivierreihenfolge der Felder deutlich und korrekt aufgebaut ist. Außerdem sollten Sie Felder und Elemente, z. B. Schaltflächen, über das HTML-Element <label> beschriften. So wird eine bessere Deutlichkeit garantiert. Bilder sollten über alt-Attribute mit einer kurzen und prägnanten Beschreibung verfügen. Programme zur Sprachausgabe können nicht hellsehen. Sie verwenden das alt-Tag, um dem Zuhörer das Bild zu beschreiben.

HTML5 enthält einen Satz Elemente, die als semantische Elemente bezeichnet werden. Diese sind erforderlich, damit HTML-Elemente von Maschine und Mensch ganz einfach gelesen und verstanden werden können. Semantische Elemente beschreiben ihre Inhalte, ähnlich wie bei XML. Beispielsweise kann man die folgenden semantischen Elemente ganz einfach verstehen, indem man sie liest: caption, figure, article, footer, header, summary, time, nav, mark und main (Überschrift, Abbildung, Artikel, Fußzeile, Kopfzeile, Zusammenfassung, Zeit, Navigation, Markieren und Hauptmenü) um nur einige zu nennen.

Für Benutzer, die ein Programm für die Sprachausgabe verwenden, sind Skip-Links enorm nützlich. Mit einem Skip-Link kann ein Programm zur Sprachausgabe Navigationselemente und Anzeigen auf einer Website überspringen und direkt zum gewünschten Inhalt wechseln. Man verliert einfach die Lust, wenn man mehrere, unerträgliche und unnötige Wiederholungen von Optionen und Anzeigen abwarten muss. Daher sollten Sie auch die Besucher Ihrer Website nicht dazu zwingen. Gleich nach dem Element <body> wird der erste Skip-Link eingefügt, wie im folgenden Code gezeigt:

<body>
<a href="#maincontent">Skip to main content</a>
<nav><!-- navigation here --></nav>
<main id="maincontent">
<p>The quick brown fox jumps over the lazy dog.</p>

Sobald die Sprachausgabe den Skip-Link erkennt, konzentriert sie sich auf das Element, auf das der Skip-Link mit seiner ID verweist. In unserem vorigen Beispiel bedeutet das, dass der Skip-Link auf das Element <main> mit einer ID "maincontent" verweist. Skip-Links müssen die ersten Elemente sein, aber viele Designer würden den Skip-Link lieber an anderer Position unterbringen. Verbergen Sie ihn doch einfach. Mit einem CSS ist er für Hilfstechnologien dennoch erkennbar, wie im folgenden Code gezeigt:

.skiplink-offscreen {
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

Wie Sie sehen können, handelt es sich um einen Klassenselektor mit absoluter Position und einem Wertattribut, das auf "-10000px" festgelegt wurde. Der Überlauf ist verborgen. Der Code platziert das Element, das diesen Selektor verwendet, an einer Position, an der es vom Benutzer nicht bemerkt, aber von der Sprachausgabe erkannt wird. Sprachausgaben überspringen Elemente mit den hidden- oder display-Attributen, die auf "hidden" oder "none" festgelegt wurden. Darum ist dieser kleine "Hack" sinnvoll.

Entwickeln mit ARIA

Accessible Rich Internet Applications (ARIA) sind ein Satz Standardattribute. Diese Attribute können auf Markupcode wie HTML angewendet werden und tragen dazu bei, dass Hilfstechnologien korrekt funktionieren. Mit ARIA können Sie ein Element nach dessen Status, Eigenschaft oder Rolle festlegen. Anhand dieser Informationen können Sprachausgaben ermitteln, was in der Software vor sich geht.

Beispielsweise kann es sein, dass ein Kontrollkästchen in ARIA einen aktivierten Status hat. Ein Element kann auch die Rolle eines Menüs annehmen. Mit diesen zusätzlichen Information zum Status oder der Rolle erzielt eine Sprachausgabe eine bessere Darstellung des Webseiteninhalts. Diese Attribute ändern zwar nicht das Element, aber sie sorgen dafür, dass das Element sich semantischer verhält. Semantischer Markupcode ist sowohl für den Menschen als auch für die Maschine leichter zu verstehen. Im folgenden Codebeispiel sehen Sie einen Artikel, bei dem ein Bereich semantisch ist, damit eine Sprachausgabe zugehörige Inhalte leichter identifizieren und an den Benutzer übermitteln kann:

<article>
<section aria-labelledby="ProgrammingBestPractices">
  <h2 id="ProgrammingBestPractices">Best Practices for Programmers</h2>
  <ol>
  <li>Take a few minutes a day to refactor small portions of code.</li>
  <li>Learn a new programming language every year.</li>
  </ol>
</section>
</article>

Sie können diesen semantischen und barrierefreien Markupcode auch in HTML-Formularen verwenden. Programme für die Sprachausgabe müssen erkennen können, welche Elemente Formularfelder beschriften oder beschreiben und welche Felder als Gruppe zusammengehören. Der Status von Schaltflächen und Kontrollkästchen ist ebenfalls für die Sprachausgabe von Bedeutung. Ein Formular verfügt über ein gutes Design, wenn Sie wissen, welche Auswirkungen ein Skript auf Hilfstechnologien hat. Code, der automatisch auf ein Steuerelement verweist oder dynamisch den Status der Formularsteuerelemente wechselt, sollte geändert werden.

Mit dem HTML-Element <label> versehen Sie einzelne Formularelemente mit separaten Beschriftungen. In manchen Fällen müssen Sie ein Element jedoch mit mehreren Beschriftungen versehen, z. B. in einer Tabelle. Das ist kein Problem. In diesen Fällen wird das aria-labelledby-Attribut aktiviert. Legen Sie das aria-labelledby-Attribut jedes Elements der Gruppe auf die IDs der Elemente fest, die die Beschriftung vornehmen. Sie können im selben Formular sowohl das Element <label> als auch das aria-labelledby-Attribute verwenden. Es gibt keinen Grund, die Schaltflächen "Senden" oder "Zurücksetzen" zu beschriften, es sei denn, es handelt sich bei diesen Schaltflächen um Bilder. In diesem Fall sollten Sie unbedingt das alt-Attribut festlegen.

Jedes Formular verfügt über Pflichtfelder und über Felder, in die nur bestimmte Datentypen eingegeben werden können. Bei den meisten Formulare wird JavaScript verwendet, um eine Überprüfung auf Pflichtfelder und eingeschränkte Felder auszuführen. Das geschieht, bevor alle Daten zur Verarbeitung zurück an den Server gesendet werden. Es ist schließlich besser, den Benutzer gleich über eventuelle Fehler zu informieren. Eine Sprachausgabe kann nur schwer unterscheiden, was auf der Seite passiert, sobald ein Skript ausgeführt wird. Das können Sie mit den aria-required- und aria-invalid-Attributen, wie in Abbildung 1 gezeigt, umgehen.

Abbildung 1: Barrierefreies HTML-Formular mit ARIA-Attributen

<form>     
  <div>
    <label for="name">* Name:</label>
    <input type="text" id="name" aria-required="true" />
  </div>
  <div>
    <label for="checkboxGroupLabel">* Language</span>
    <ul role="radiogroup" aria-labelledby="checkboxGLabel">
      <li role="checkbox"><input type="checkbox" value="C#"
        name="language" aria-checked="false" />C#</li>
      <li role="checkbox"><input type="checkbox" value="JavaScript"
        name="language" aria-checked="false" />JavaScript</li>
      <li role="checkbox"><input type="checkbox" value="Python"
        name="language" aria-checked="false" />Python</li>
    </ul>
  </div>
  <div>
    <span id="yearsLabel">* Years Experience</span>
    <select name="YearsExperience" aria-labelledby="yearsLabel" >
      <option value="1">1-5 Years</option>
      <option value="6">6-10 Years</option>
      <option value="10">10-20 Years</option>
      <option value="20">20+ Years</option>
    </select>
  </div>
  <div>
    <input type="submit" alt="Submit" />
  </div>
</form>

Ebenfalls in Abbildung 1 sehen Sie ein Beispiel für die aria-required- und aria-labelledby-Attribute sowie für die Nutzung von Rollen. Sie fügen lediglich zusätzlichen, aber unauffälligen, HTML-Code hinzu. Das ist kein großer Aufwand, aber es liefert tolle Ergebnisse.

Hilfstechnologien müssen nicht nur mit statischen Elementen umgehen können. Häufig werden die Inhalte von Websites und Apps durch JavaScript, AJAX-Aufrufe und Apps im SPA-Stil geändert. Manchmal "stolpern" Programme für die Sprachausgabe über ein dynamisches Skript, wie dieses hier. Sie müssen den Status einiger ARIA-Attribute, z. B. aria-invalid, zurücksetzen, nachdem die JavaScript-Validierung ausgeführt wurde.

Testen von barrierefreiem Code

Testen Sie Ihre Arbeit, indem Sie ein Programm für die Sprachausgabe herunterladen und es selbst ausprobieren. Schließen Sie Ihre Augen und nutzen Sie die Sprachausgabe – ganz so, als wären Sie blind. Bitten Sie Ihre Benutzer, die Hilfstechnologien verwenden, um Feedback. So finden Sie heraus, ob Ihre Software ausreichend barrierefrei geworden ist. U. a. können Sie folgende Programme für die Sprachausgabe herunterladen und verwenden:

Nach dem Test mit dem Programm für die Sprachausgabe können Sie WebAIM einsetzen. Sie erhalten eine umfassende Checkliste sowie ein Überprüfungstool für Seiten mit dem Namen Web Accessibility Evaluation (kurz: WAVE). Dieses Tool berichtet Fehler, Warnungen und andere Informationen zum barrierefreien Status einer Seite. Die Verwendung ist einfach. Wechseln Sie zu wave.webaim.org und geben Sie die zu prüfende URL ein. WAVE zeigt die Zielseite inline an und kommentiert Problemstellen und Elemente, die Sie verändern können, um die Barrierefreiheit zu verbessern. Abbildung 2 zeigt das Überprüfungstool in Aktion. Es hat auf einer Seite des MSDN Magazins der Januarausgabe 2015 einige Probleme gefunden.

MSDN Magazin Nach der Überprüfung durch WAVE
Abbildung 2 MSDN Magazin Nach der Überprüfung durch WAVE

Klicken Sie auf die kommentierten Elemente. WAVE zeigt darauf die Informationen zum Fehler oder die Metadaten des Elements an. Das Überprüfungstool sucht nach allem – nach fehlenden Beschriftungen und alt-Attributen ebenso wie nach Kontrastproblemen. Es hebt sie als Fehler oder Warnungen hervor. So können Sie die wichtigeren Probleme zuerst ändern. Sie können eine Einzelplatzversion von WAVE ausführen oder die API zu Ihren automatischen QA-Prozessen hinzufügen.

Zusammenfassung

Ein barrierefreies Design bedeutet normalerweise für alle Benutzer ein besseres Design. Fehlt die Barrierefreiheit, wird ein nicht unwesentlicher Teil der Bevölkerung ausgeschlossen. Es ist also letztlich ganz einfach eine kluge und wirtschaftliche Entscheidung, wenn Sie sich bemühen, Ihre Software barrierefrei zu gestalten. Die Benutzeroberflächen sollten deutlich beschriftete, leicht auffindbare Optionen enthalten. Die Schritte zum Ausführen einer Aufgabe sollten einfach aufgebaut sein. Wenn Sie sich für ein barrierefreies Design entscheiden, ist das Ergebnis ein benutzerfreundliches und praktisches System, das für alle Benutzer gut funktioniert.


Rachel Appel ist Beraterin, Autorin, Mentorin und frühere Microsoft-Mitarbeiterin mit über zwanzigjähriger Erfahrung in der IT-Branche. Sie nimmt an wichtigen Branchenkonferenzen wie Visual Studio Live!, DevConnections und MIX als Rednerin teil. Ihr Fachbereich ist die Entwicklung von Lösungen, bei denen geschäftliche und technologische Aspekte in Einklang gebracht werden und in denen führende Microsoft- und offene Webtechnologien zum Einsatz kommen. Besuchen Sie Rachel Appel auf ihrer Website unter rachelappel.com.

Unser Dank gilt dem folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Frank La Vigne