Barrierefreiheit in digitalen Produkten aus der Sicht einer Softwaretesterin

28. August 2024 - von Magdalena Nuckowska

Editor's Note: Barrierefreiheit in digitalen Produkten ist ein wichtiges Thema, das wir bei Apps with love versuchen, so gut wie möglich zu berücksichtigen, wenn wir Software für unsere Kund*innen entwickeln. Kürzlich waren wir an der Aktualisierung einer App beteiligt, die nicht «nur» den WCAG-Standards, sondern auch spezifischen Anforderungen des amerikanischen Marktes entsprechen muss.

Magdalena Nuckowska, Softwaretesterin bei unserer langjährigen Partnerin Sagiton, war ins Testing der besagten App involviert. Im folgenden Blogpost erläutert sie die Komplexität des Testens von Barrierefreiheit und teilt ihre wichtigsten Erkenntnisse aus diesem Projekt sowie ihre Expertise zum Thema Testen von Barrierefreiheit im Allgemeinen.

Sollte das Design und die Entwicklung einer App den Richtlinien und Standards für Barrierefreiheit entsprechen? Für Apps with love ist dies eine Selbstverständlichkeit - die Sicherstellung, dass eine Applikation von Personen mit unterschiedlichen Fähigkeiten genutzt werden kann, ist ein wesentliches Merkmal jedes digitalen Produkts. Eine App barrierefrei zu gestalten ist nicht nur eine ethische und in vielen Fällen auch eine rechtliche Verpflichtung, sondern kann auch soziale und wirtschaftliche Aspekte beeinflussen.

In diesem Artikel erfährst du, was die gängigsten Accessibility Vorschriften sind und welche Schritte das Qualitätssicherungsteam von Apps with love zusammen mit Partner*innen ausgearbeitet hat, um ein digitales Produkt auf Accessibility Kriterien zu testen. Ausserdem erfährst du, welche Vorteile die Einhaltung der Vorschriften mit sich bringt und auf welche Herausforderungen du im Qualitätssicherungsprozess stossen könntest. Zur besseren Veranschaulichung des Themas sind auch nützliche Tipps in Form eines konkreten Projektbeispiels integriert.

Icons Arten von Beeinträchtigungen - berühren
Icons Arten von Beeinträchtigungen - siehe
Icons Arten von Beeinträchtigungen - hören
Icons Arten von Beeinträchtigungen - sprechen
Einschränkungen, die Menschen daran hindern, digitale Produkte auf «normale» Weise zu nutzen, gibt es in vielen verschiedenen Formen - wenn du (noch) nicht betroffen bist, dann ist es sicher jemand in deinem Umfeld (Grafik von Microsoft).

Vorschriften, Normen und Regeln

Barrierefreies Design und barrierefreie Entwicklung von digitalen Produkten sollten über die blosse Einhaltung von Vorschriften hinausgehen - es geht darum, für möglichst viele Menschen eine gute Nutzungserfahrung zu bieten. Es geht darum, ein Produkt zu schaffen, das für alle Benutzer*innen intuitiv und einfach zu bedienen ist und eine logische Navigation bietet.

Dennoch müssen wir bei der Konzeption, der Entwicklung und dem Testen einer Software natürlich die Grundlagen berücksichtigen, nämlich Gesetze und Normen. Die gängigsten Normen und Gesetze im Bereich der Barrierefreiheit sind:

  • Die Web Content Accessibility Guidelines WCAG (aktuelle Version: 2.2.), veröffentlicht von der Web Accessibility Initiative (WAI) des World Wide Web Consortium (W3C). Die WCAG sind in den meisten Teilen der Welt die am meisten anerkannten Standards.

  • The Americans with Disabilities Act (ADA): Ein Bundesgesetz über Bürgerrechte, das 1990 in den Vereinigten Staaten von Amerika eingeführt wurde, um die Diskriminierung von Menschen mit Behinderungen bei alltäglichen Aktivitäten zu verbieten.

  • Section 508 des Rehabilitationsgesetzes in den USA: Ein Bundesgesetz, das von den Behörden verlangt, Menschen mit Behinderungen den gleichen Zugang zu elektronischen Informationen und Daten zu gewähren, der mit dem von Menschen ohne Behinderungen vergleichbar ist, es sei denn, dies würde die Behörde unangemessen belasten.

  • In der Schweiz ist die Einhaltung des Accessibilitystandards eCH-0059 (genauer: eCH-0059 Version 3.0), der auf den WCAG 2.1 basiert, für alle digital verfügbaren Informationen und Dienste der öffentlichen Hand verbindlich. Dies stützt sich auf Artikel 8 Absatz 2 der Bundesverfassung, der die Nichtdiskriminierung von Menschen mit einer körperlichen, geistigen oder psychischen Behinderung vorschreibt.

Mehr über die Grundlagen der Barrierefreiheit, Gesetze, Vorschriften und Standards findest du in einem früheren Blogartikel über Barrierefreiheit. Dieser Artikel konzentriert sich mehr auf die praktischen Aspekte des Testens gegen die WCAG und die US-Vorschriften. Dies insbesondere, da wir kürzlich die FELFEL-App mit Blick auf diese Vorschriften getestet haben, da FELFEL die App im Amerikanischen Markt lanciert.

Testing gemäss WCAG, ADA und Section 508

Je nach Zielmarkt, Zielgruppe und Standort oder Sitz des Unternehmens, ist die Einhaltung von Accessibility Vorschriften zwingend. Die wichtigsten Merkmale der oben genannten Vorschriften sind in der nachstehenden Tabelle aufgeführt.

WCAG ADA Sektion 508
Rahmenwerk Internationaler Standard US-Bundesrecht US-Bundesrecht
Anwendbarkeit Global US-spezifisch
Titel I: Private Einrichtungen, Beschäftigung
Titel II: Öffentliche Dienste und Kommunalverwaltung
Titel III: Private Einrichtungen, öffentliche Unterkünfte und Dienstleistungen
US-Bundesbehörden und Auftragnehmer
Entwicklungsbehörde World Wide Web Konsortium (W3C) Vereinigter Staaten Kongress US Access Board
Konformitätsstufen WCAG A, AA, AAA Teilweise WCAG A, AA WCAG A, AA
Geltungsbereich Alle digitalen Inhalte Öffentliche Einrichtungen, Arbeitgeber Bundesweite Informations- und Kommunikationstechnologie (IKT)

Quellen: WCAG vs. ADA vs. Section 508 & Website Compliance Standards Requirements

Zusammenfassend lässt sich sagen, dass die WCAG für alle digitalen Produkte weltweit gelten, während der ADA und Section 508 nur für die USA gelten. Darüber hinaus gelten die WCAG für Anwendungen in allen Sektoren und für alle Zielgruppen, während der ADA für den privaten Sektor und einige Bereiche des öffentlichen Sektors gilt und die Section 508 nur für Bundesbehörden und deren Auftragnehmenden. Diese Regelungen unterscheiden sich in ihrem Schwerpunkt. WCAG gilt für alle digitalen Inhalte, einschliesslich Websites, Applikationen und Dokumente. ADA konzentriert sich auf die Festlegung von Antidiskriminierungsregeln für öffentliche Einrichtungen, Arbeitgebende und Unternehmen. Section 508 verpflichtet Bundesbehörden, Nutzer*innen mit Behinderungen den gleichen Zugang zu elektronischen Informationen und Daten zu ermöglichen wie Menschen ohne Behinderungen. Es ist zu beachten, dass Section 508 derzeit auf den WCAG-Standards Level A und AA basiert. Nach der Aktualisierung im April 2024 wird in Titel II des ADA auch festgelegt, dass Websites, Anwendungen, mobile Anwendungen und digitale Inhalte WCAG 2.1, Level AA entsprechen müssen.

Der WCAG-Standard ist der am weitesten verbreitete und hat viele Überschneidungen mit regionalspezifischen Vorschriften wie dem amerikanischen ADA oder dem Schweizer eCH-0059. Aus diesem Grund konzentriert sich der Rest dieses Artikels auf die Beschreibung der Barrierefreiheit im Kontext dieser speziellen Norm.

Accessibility von digitalen Produkten testen

Beim Testen, ob ein digitales Produkt die Kriterien der Barrierefreiheit erfüllt, stellt sich oft die Frage: Wie soll man beginnen? Der Prozess kann komplex sein und variiert je nach Produkt, Erwartungen der Stakeholder, Zeit und Budget. Wir haben die Erfahrung gemacht, dass es sich lohnt, in folgenden Schritten vorzugehen:

  1. Anforderungen definieren: Bestimme, welches Gesetz oder welche Verordnung für deine Applikation gilt und inwiefern das Produkt die entsprechenden Anforderungen erfüllen muss. Zum Beispiel, welches WCAG-Level der Massstab ist. In einigen Fällen ist dies durch Vorschriften festgelegt, in anderen können die Anforderungen auch durch (Product Owners) POs bestimmt oder in Abstimmung mit allen Stakeholdern definiert werden.

  2. Testing: Überprüfe, ob die Applikation die definierten Anforderungen erfüllt. Dieser Schritt erfordert oft einen intensiven Austausch zwischen dem Entwicklungsteam und den POs.

    • Beratung zwischen QAs: Die Komplexität von Problemen mit Accessibility kann eine tiefere Analyse und Betrachtung aus verschiedenen Perspektiven erfordern. Es hilft, wenn mehr als ein Paar Augen in den Testprozess involviert ist.

    • Absprache mit Design- und Entwicklungsteam: Einige Anforderungen an die Barrierefreiheit können nicht allein auf der Frontend-Seite einer App getestet werden. Der Einblick aus der Design- und Code-Perspektive ist entscheidend, um beurteilen zu können, ob einige Kriterien erfüllt sind oder nicht.

  3. Ergebnis und Reporting: Fasse die Testergebnisse zusammen, damit sie klar präsentiert werden können: Welche Anforderungen wurden vollständig, teilweise oder gar nicht erfüllt? Dieser Schritt kann mit der Erstellung einer Liste von Empfehlungen für die App abgeschlossen werden, damit die Abweichungen in Zukunft behoben oder angegangen werden können.

  4. Beratung und Entscheidungsfindung: Analysiere die Resultate und entscheide über die möglichen Verbesserungen für die App - in der Regel erfolgt dies in Form eines Austauschs zwischen den Produktverantwortlichen und dem Projektmanagement.

Guidelines fürs Testen von Accessibility

Da wir bei Apps with love die Barrierefreiheit einiger digitaler Produkte getestet haben, verfügen wir über einen grossen Erfahrungsschatz, der uns einige hilfreiche Tipps ermöglicht:

Bestimme die grundlegenden Merkmale deiner Applikation

  • Betriebssysteme: Lösungen für Barrierefreiheit können sich z.B. zwischen Android und iOS unterscheiden - unterstützende Apps sowie Accessibility-Tools sind möglicherweise nur für eine bestimmte Plattform oder begrenzte (neueste) Systemversionen verfügbar

  • Desktop vs. mobile Anwendung: Dies beeinflusst die Testmethoden und -techniken stark, da es die Verwendung von Betriebssystemen, Bildschirmgrössen, möglichen unterstützenden Technologien, Hilfsmittel, Bildschirmnavigation usw. bestimmt. Aus diesem Grund werden einige der Accessibility Kriterien auf dem Desktop erfüllt, aber nicht auf der mobilen Anwendung und umgekehrt.

  • Web vs. native Anwendung: Bestimmt Themen wie mögliche unterstützende Technologien oder Bildschirmnavigation. Zum Beispiel könnten einige der Navigationslösungen für eine mobile Plattform für eine native App verfügbar sein, aber nicht für die andere. Es kann auch die Frage der Konsistenz der App zwischen verschiedenen Betriebssystemen beeinflussen.

  • Geräte, auf denen die App verwendet werden soll: Dies bestimmt u.a. Bildschirmgrössen und unterstützende Technologien (z.B. ob das Gerät mit Bluetooth oder einer USB-basierten Tastatur verbunden werden kann).

  • Zielgruppe deiner App: Das Produkt, seine Kompatibilität mit unterstützenden Technologien, die Navigation usw. müssen an die Bedürfnisse der Enduser*innen angepasst werden, wobei verschiedene Arten von Behinderungen zu berücksichtigen sind. 

  • Ziel der App: Die Hauptfunktionalitäten der Applikation beeinflussen die Art und Weise, wie Nutzer*innen mit der App interagieren. Die Analyse von Nutzungszenarien kann Erkenntnisse über mögliche Schwachstellen und den Bedarf an zusätzlicher Unterstützung für die User*innen liefern.

Um Barrierefreiheit testen zu können, müssen diese grundlegenden Fragen beantwortet werden, da sie den gesamten Prüfprozess bestimmen. Einige der Anforderungen sind so gestaltet, dass sie nur für bestimmte Arten von Anwendungen gelten und für andere nicht relevant sind. 

Kenne deine Anforderungen

Es ist immer eine gute Idee, sich an die offizielle Informationsquelle für die definierten Anforderungen zu wenden. Das Lesen von spezifischen Kriterien reicht aber möglicherweise nicht aus, um diese im Testprozess direkt anwenden zu können. Je nach Komplexität der Anforderungen benötigt eine QA möglicherweise zusätzliche Unterstützung, um sie richtig zu interpretieren und im Testprozess anzuwenden. Es gibt verschiedene Quellen für praktisches Wissen, wie z. B. Interpretationen von Accessibility Anforderungen und Beispiele, die sehr hilfreich sein können, um diese gründlich zu verstehen. 

Solche Beispiele und ausführliche Erläuterungen werden beispielsweise auf der W3C  Website aufgeführt. Für das Kriterium 1.3.4 «Orientierung» werden zum Beispiel folgende Informationen gegeben: 

Definition: Der Inhalt ist nicht auf eine einzige Bildschirmausrichtung, wie Hoch- oder Querformat, beschränkt, es sei denn, eine bestimmte Bildschirmausrichtung ist unerlässlich.

Dazu kommen ausführlichere Erläuterung des Kriteriums, einschliesslich des Ziels (Geräte können in jeder Ausrichtung verwendet werden), was zu tun ist (Inhalte dürfen nicht auf die Darstellung im Hoch- oder Querformat festgelegt werden) und was wichtig ist (Personen könnten Geräte mit einer fixen Ausrichtung montiert haben, bspw. Personen im Rollstuhl). 

Ausserdem werden die Intention des Kriteriums, die Vorteile (Nutzende mit Sehschwäche können Inhalte in der für sie optimalen Ausrichtung ansehen), Beispiele für die Umsetzung (eine eReader-Web-App kann den Inhalt eines Buches sowohl im Hoch- als auch im Querformat anzeigen) und Testregeln beschrieben.
Ein separater Link führt zu einer Seite mit Beispielen für die erfolgreiche und misslungene Umsetzung dieses Kriteriums.

Am Ende dieses Blogposts befinden sich Websites, die einen Einblick in die verschiedenen Accessibility Kriterien geben.

Eine zweite Meinung einholen 

Es gibt ein Sprichwort (möglicherweise stammt es von Konfuzius): «Wer fragt ist ein Narr für eine Minute. Wer nicht fragt, ist ein Narr sein Leben lang.» Dies gilt insbesondere, für den Qualitätssicherungsprozess eines digitalen Produkts und ist von entscheidender Bedeutung, wenn es darum geht, die Einhaltung der Accessibility Kriterien zu prüfen. Aufgrund der Komplexität und des universellen Charakters der Vorschriften können Tester*innen oft nicht sicher sein, ob eine Anwendung ein spezifisches Kriterium erfüllt oder ob die Anforderung überhaupt relevant oder auf das betreffende Produkt anwendbar ist. 

Einige Accessibility Kriterien werden dem Design- oder Entwicklungsteam besser bekannt sein, weil sie schon früh im Entwicklungsprozess in die App integriert wurden und aus einer «Blackbox-Perspektive» (wenn man nur das User Interface der App, nicht aber den Code anschaut) manchmal schwer zu erkennen sind. Natürlich kann es nie schaden, sich mit anderen QAs auszutauschen. Jede Person versteht die Anforderungen vielleicht ein wenig anders. Das kann zu einer unterschiedlichen Bewertung führen, ob ein Kriterium von der Applikation erfüllt wird oder nicht. Die Etablierung eines gemeinsamen Verständnisses der spezifischen Anforderungen durch verschiedene Tester*innen kann die Qualität der Testergebnisse erheblich verbessern.

Die beste Möglichkeit, ein digitales Produkt auf Barrierefreiheit zu testen, ist natürlich Nutzende, die tatsächlich auf die korrekte Umsetzung von Accessibility Kriterien angewiesen sind, in den Prozess miteinzubeziehen.

QATeam at Work
Ein Teil des Qualitätssicherungs-Teams

Verschiedene Testeinstellungen ausprobieren

Sicherlich keine bahnbrechenden Info, aber dennoch erwähnenswert ist, dass es wichtig ist, die Testeinstellungen während der Bewertung der Accessibility Kriterien eines Produkts zu ändern. Die Verwendung verschiedener Geräte, Betriebssysteme, Hilfstechnologien oder Auflösungen gibt definitiv einen breiteren Überblick über die Anwendung und ihr Verhalten in verschiedenen Umgebungen. So kann eine «Aber auf meinem Gerät funktioniert es»-Situation vermieden werden. Ganz zu schweigen davon, dass Farben, Auflösungen, Kontraste, Grafiken und alle anderen visuellen Elemente auf verschiedenen Geräten völlig anders aussehen können.

Devicewall bei Appswithlove
Ein Teil der Apps with love Testgeräte-Sammlung auf der so genannten «Device-Wall».

Herausforderungen und Vorteile von Accessibility Tests

Es ist gut, wenn sich das QA-Team der verschiedenen Herausforderungen und Risiken beim Testen von Barrierefreiheit bewusst ist, damit diese im Planungsprozess berücksichtigt werden können. Im Folgenden ein paar der häufigsten Herausforderungen und Risiken.

Universeller Charakter der Anforderungen 

Die WCAG-Anforderungen gelten für alle Arten von digitalen Produkten und Sektoren, Desktop, Mobile, Web und Native, sowie für verschiedene Zielgruppen: die allgemeine Öffentlichkeit, aber auch spezifische Gruppen.
Bei der Prüfung von Kriterien, die beispielsweise die Hervorhebung von Bildschirmabschnitten, die Verwendung von Tastenkombinationen/Sondertasten wie «Tab», swipen oder die Abfolge von Gesten betreffen, muss das QA-Team also entscheiden, ob die Anforderung gültig und auf das jeweilige Produkt anwendbar ist oder nicht.

Unterschiede zwischen Plattformen und Geräten

Android- und iOS-Geräte unterscheiden sich in Bezug auf Accessibility Lösungen, unterstützende Technologien und Debugging-Möglichkeiten. Dies kann zu Problemen bei der Implementierung passender Lösungen für die Barrierefreiheit und auch bei der Wahrung der Konsistenz der UX zwischen verschiedenen Geräten und Systemen führen. 

Anforderungen, die im Frontend schwer zu überprüfen sind

Einige der Anforderungen sind aus einer reinen Frontend-Perspektive nicht oder nur schwer zu testen. Dazu gehören zum Beispiel WCAG-Kriterien wie:

  • Zweck der Eingabe bestimmen: Der Zweck jedes Eingabefeldes, das Informationen über die Benutzer*innen sammelt, kann unter bestimmten Bedingungen programmatisch bestimmt werden (WCAG 2.2, §1.3.5)

  • Name, Rolle, Wert: Für alle Komponenten der Benutzeroberfläche (einschliesslich, aber nicht beschränkt auf: Formularelemente, Links und durch Skripte erzeugte Komponenten) können Name und Rolle programmatisch bestimmt werden. Zustände, Eigenschaften und Werte, die von den Benutzer*innen eingestellt werden können, können programmatisch festgelegt werden, und die Benachrichtigung über Änderungen an diesen Elementen ist für User Agents, einschliesslich unterstützender Technologien, verfügbar (WCAG 2.2. §4.1.2.).

Businessanforderungen vs. Anforderungen an Accessibility

Das Design, der Zweck oder einige geschäftliche Aspekte einer Anwendung gehen nicht immer mit den Anforderungen an die Barrierefreiheit einher. Oft sind Farben, Schriftarten, Grössen, Bildschirmausrichtung und viele andere visuelle Elemente ein Teil der Kommunikations- und Marketingstrategie der Marke. Sollten sie geändert werden, damit die Anwendung die Accessibility Kriterien erfüllt? Das ist eine weitere Knacknuss, die es zu lösen gilt.


Es stellt sich die Frage: Lohnt sich die Umsetzung von barrierefreier Software? Die einfach Antwort lautet: ja. Es besteht kein Zweifel daran, dass Barrierefreiheit auf verschiedenen Ebenen wichtig ist und dem Produkt, der Marke und dem Unternehmen auf vielfältige Weise zugute kommen kann - auch wenn es dafür nicht in jedem Fall eine verbindliche Regelung gibt.

  • Ein breiteres Publikum gewinnen - eine benutzerfreundliche und inklusive App zieht ein grösseres Publikum an, was zu einer potenziell grösseren Marktabdeckung und entsprechend einem höheren Gewinn führen kann.

  • Steigern der Brand Loyalty - Barrierefreiheit ermöglicht es Menschen mit Behinderungen, in der digitalen Landschaft zu interagieren und daran teilzunehmen, was ein Produkt sympathischer machen kann. Es zeigt das Engagement für Vielfalt, Gleichberechtigung und Integration, wodurch die Treue zu einer Marke gesteigert werden kann.

  • Verbesserung der allgemeinen UX - die Vereinfachung der Nutzung, der Navigation, des Verständnisses und der Interaktion kann die UX für alle Nutzenden verbessern, nicht «nur» für Menschen mit Behinderungen.

  • Suchmaschinenoptimierung - die Berücksichtigung von Accessibility Anforderungen kann die Sichtbarkeit eines digitalen Produkts in den Suchmaschinen verbessern und damit die Reichweite vergrössern.

  • KI-Optimierung - KI-gesteuerte Plattformen wie Bing und ChatGPT gewinnen derzeit gegenüber den traditionellen Suchmaschinen an Popularität. Die Implementierung von Accessibility Kriterien in einem digitalen Produkt kann der Optimierung der künstlichen Intelligenz dienen.

Die genannten Aspekte können Faktoren wie eine grössere Marktreichweite, ein grösseres Publikum, einer besseren Nutzungszufriedenheit und -treue, ein höherer Markenwert und -wiedererkennungswert beeinflussen und damit potenziell zu höheren Gewinnen führen.

Barrierefreiheit in der FELFEL-App - ein Praxisbeispiel

Die Vorteile von Barrierefreiheit werden von vielen Unternehmen geschätzt, darunter auch von unserer Kundin FELFEL, deren App wir seit einigen Jahren entwickeln und betreiben.

FELFEL ist die schweizweit beliebteste Lösung für Mitarbeitendenverpflegung und Bürokaffee.

Die App ermöglicht es den Nutzenden, die verfügbaren Menüs anzuschauen, den FELFEL-Kühlschrank zu öffnen und ein Gericht ihrer Wahl auszuwählen und zu bezahlen. 

Menüübersicht in der FELFEL App
Detailansicht eines Menüs mit Angaben zu Zutaten und Nährwerten
QR Code als digitaler Badge, um den Kühlschrank zu öffnen
Übersicht über gekaufte Menüs

Um die App inklusiver und benutzerfreundlicher zu gestalten, haben die Produktverantwortlichen von FELFEL beschlossen, dass die App dem Standard WCAG 2.1 Stufe AA entsprechen soll.

Das war aber noch nicht alles: Da das Unternehmen expandiert und vor kurzem in den US-Markt eingetreten ist, musste auch die Einhaltung des ADA sichergestellt werden.
Das Ziel unseres Teams war es, die mobile Version der App auf iOS sowie Android auf die Accessibility Kriterien der WCAG und des ADA zu testen.
Beim Testen der FELFEL-App auf die entsprechenden Kriterien traten einige Zweifel und Fragen bezüglich spezifischer Anforderungen auf. 

WCAG-Anforderung Frage zur Anforderung
Videodateien (1.2.1)
Es wird entweder eine Alternative für zeitbasierte Medien oder eine Audiospur bereitgestellt, die gleichwertige Informationen für voraufgezeichnete reine Videoinhalte enthält.
Es gibt eine Onboarding-Anweisung in Form einer Animation - sollte sie eine alternative Erklärung in Textform enthalten?
Orientierung (1.4.1)
Inhalte beschränken ihre Ansicht und Bedienung nicht auf eine Ausrichtung, wie Hoch- oder Querformat, es sei denn, eine bestimmte Ausrichtung ist unerlässlich.
Sollte die App in beiden Ausrichtungen (Hoch- und Querformat) verfügbar sein, wenn es der ursprünglichen Idee oder dem visuellen Zweck widerspricht?
Abbildungen von Text (1.4.5)
Wenn die verwendeten Technologien eine visuelle Darstellung ermöglichen, wird zur Übermittlung von Informationen eher Text anstelle von Textbildern verwendet, ausser in folgenden Fällen:
- Das Textbild kann visuell an die Anforderungen der Nutzenden angepasst werden;
- Eine bestimmte Textdarstellung ist für die zu vermittelnde Information wesentlich.
Können Textbilder verwendet werden, wenn sie einem bestimmten Zweck dienen, z.B. einer Anweisung im Onboarding?
Nicht-Text-Inhalte (1.1.1)
Für alle Nicht-Text-Inhalte, die den Nutzenden präsentiert werden, gibt es eine Textalternative, die den gleichen Zweck erfüllt, ausser in den im Kriterium aufgeführten Situationen.
Können alle Toggle-Buttons denselben Alt-Text haben wie on/off?

Quelle: https://www.w3.org/TR/WCAG22/

Animation im FELFEL Onboarding
Onboarding Schritt in der FELFEL App
Onboarding-Animation und Textbild in der FELFEL-App - 2 von vielen Accessibility-Kriterien, die sich als schwierig zu bewerten erwiesen

Ausserdem schienen die Accessibility-Lösungen auf den verschiedenen Betriebssystemen unterschiedlich zu funktionieren. Dies betraf Kriterien wie Kontrast, Grössenanpassung, Pointer Cancellation und die Abdeckung von Alt-Texten.


Das Testen der FELFEL-App in Bezug auf Accessibility vermittelte uns einen besseren Einblick, wie Barrierefreiheit in einem digitalen Produkt implementiert werden kann und lieferte uns einige interessante Erkenntnisse, wie zum Beispiel:

  • Berücksichtigen, dass jedes Betriebssystem/jede Plattform unterschiedlich viel Zeit und Ressourcen benötigt, um ausreichend getestet zu werden.

  • Beim Planen des Testprozesses berücksichtigen, dass zusätzliche Zeit benötigt werden kann, um auf Accessibility zu testen.

  • Die Verwendung von Interpretationen der Anforderungen und unserer internen Wissensdatenbank zur Barrierefreiheit hilft enorm, um die Einhaltung der Vorschriften zu gewährleisten, und die Qualität des Produkts zu verbessern.

  • Regelmässige Schulungen des Teams zum Thema Barrierefreiheit helfen dabei, qualitativ hochwertigere Anwendungen zu designen und entwickeln, die den Prüfprozess einfacher und schneller durchlaufen.

Barrierefreiheit als Highlight?

Das Testen von Software auf Accessibility kann ein langer und schwieriger Prozess sein. Die Menge der Vorschriften, ihre Komplexität und Vielfalt können zu Beginn überwältigend sein. Die grosse Herausforderung besteht darin, die Elemente einer Applikation tatsächlich anhand der spezifischen Erfolgskriterien zu überprüfen. Doch je öfter man den Prozess durchläuft, desto mehr Erfahrung und damit auch Fachwissen kann man sammeln.

Das Team von Apps with love ist bestrebt, nicht nur auf dem neuesten Stand bezüglich Barrierefreiheit zu bleiben, sondern diese auch in der Praxis anzuwenden, angefangen beim Design, über den gesamten Entwicklungsprozess bis hin zur Qualitätssicherung. Es liegt in unserem eigenen Interesse und in dem unserer Kund*innen, inklusive, benutzerfreundliche und intuitive Apps zu entwickeln, die auf innovativen Technologien basieren. Daher könnte es von Vorteil sein, Barrierefreiheit nicht als aufgezwungenes Merkmal, sondern als Highlight eines digitalen Produkts zu betrachten. Die korrekte Implementierung von Accessibility Kriterien kann eine Vielzahl von Vorteilen bringen und den Wert einer Applikation erheblich steigern.

Hilfe für barrierefreies Design, Entwicklung und Testing

Hier einige nützliche Tools und Links, mit nützlichen Tipps, Interpretationen und Informationen zu Fragen rund um Barrierefreiheit:

Über Magdalena
Magdalena, besser bekannt als Magda, ist Software-Testerin bei unserer langjährigen Partnerin Sagiton. Sie testet unsere Entwicklungen auf Herz und Nieren und weiss allfällige Bugs klar aber diplomatisch zurückzumelden - eventuell ist dieser Skill auf ihren Master Abschluss in Internationalen Beziehungen zurückzuführen.
Magda träumt von einer Herr der Ringe x Harry Potter Fusion (Gandalf und Dumbledore könnten durchaus als Brüder durchgehen) und hält Nutella entgegen der gängigen Meinung für überbewertet.

Wir haben grad gemerkt, dass du mit Internet Explorer surfst. Unsere Webseite sieht damit leider nicht so schön aus.

Du willst erfahren warum das so ist?
Wir haben darüber geschrieben.

Zum Blog

Du brauchst Hilfe bei der Umstellung?
Melde dich. Wir helfen gern.

Kontakt

Einen neuen Browser installieren?
Hier gibt es Auswahl.

Browser