10 Punkte von GN⁺ 2024-03-20 | 3 Kommentare | Auf WhatsApp teilen

Barrierefreiheit in SwiftUI schnell umsetzen

  • Zeigt, wie sich Barrierefreiheit in einer SwiftUI-App schnell nachrüsten lässt, wenn sie übersehen wurde.
  • Barrierefreiheit ist eine wichtige Funktion, die 16 % der Nutzer benötigen, wird während der Entwicklung jedoch oft ignoriert.
  • Eine App, die Barrierefreiheit nicht berücksichtigt, kann bei Nutzern einen negativen Eindruck hinterlassen.

Barrierefreiheit der App prüfen

  • Es ist wichtig, Barrierefreiheit auf einem echten Gerät zu testen.
  • Das Kontrollzentrum so einrichten, dass sich Barrierefreiheitsfunktionen schnell aktivieren lassen.

Textgröße prüfen

  • iOS bietet 12 Textgrößen; diese sollten getestet werden, um zu prüfen, ob die App mit jeder Größe gut funktioniert.
  • Es muss geprüft werden, ob die UI auch bei der größten Textgröße noch gut funktioniert.

Screenreader prüfen

  • Für Nutzer, die Screenreader verwenden, sollte die Barrierefreiheit mit Tools wie VoiceOver überprüft werden.
  • Schon einfache Anpassungen wie das Hinzufügen von Accessibility-Labels zu Bildern können große Verbesserungen bringen.

Barrierefreiheit schnell umsetzen

  • Nachdem die Probleme erkannt wurden, sollten sie zügig einzeln behoben werden.

Scrollbarer Inhalt

  • Wenn die Textgröße zunimmt, lässt sich das Problem lösen, indem der Inhalt in eine Scroll View erweitert wird.
  • Mit einem benutzerdefinierten View-Modifier namens a11yScrollView() wird der Inhalt nur dann scrollbar gemacht, wenn es nötig ist.

Code-Smell beim Schaffen von Platz

  • Statt Spacer() sollte der Modifier frame() verwendet werden, um ein zuverlässigeres Layout zu erstellen.

Größe von Bildern und Icons anpassen

  • Mit dem Property Wrapper @ScaledMetric lassen sich Bilder und Icons dynamisch an die Textgröße des Nutzers anpassen.

Inhalt ausrichten

  • Mit A11yHStack lässt sich Inhalt abhängig von der Textgröße des Nutzers ausrichten.

Screenreader verbessern

  • Mit accessibilityLabel, accessibilityElement(children:), accessibilityRepresentation usw. lässt sich die Kompatibilität mit Screenreadern verbessern.

Native Komponenten verwenden

  • Nach Möglichkeit native SwiftUI-Komponenten verwenden, um Performance und Barrierefreiheit zu verbessern.

Stakeholder überzeugen

  • Wie man innerhalb einer Organisation Einfluss nimmt, damit Barrierefreiheit wichtig genommen wird.
  • Die Bedeutung von Barrierefreiheit hervorheben, indem rechtliche Anforderungen und geschäftliche Vorteile betont werden.

Fazit

  • Beschreibt den gesamten Prozess, wie sich Barrierefreiheitsprobleme in einer App identifizieren und beheben lassen.
  • Stellt verschiedene Werkzeuge und Techniken vor, die SwiftUI zur Verbesserung der Barrierefreiheit bietet.

Meinung von GN⁺

  • Dieser Artikel ist für App-Entwickler sehr nützlich, weil er erklärt, warum Barrierefreiheit wichtig ist, und konkrete Wege aufzeigt, sie praktisch zu verbessern.
  • Apps ohne Berücksichtigung von Barrierefreiheit verschlechtern die User Experience und können rechtliche Probleme verursachen; deshalb ist es wichtig, Barrierefreiheit schon in einer frühen Entwicklungsphase mitzudenken.
  • Wer moderne Frameworks wie SwiftUI nutzt, kann die Vorteile nativer Komponenten bestmöglich ausnutzen, um Performance und Barrierefreiheit gleichzeitig zu verbessern.
  • Es ist auch sinnvoll, Bibliotheken oder Tools aus der Community zu nutzen, um Barrierefreiheit zu verbessern; so lässt sich der Entwicklungsprozess vereinfachen und effizienter gestalten.
  • Die Verbesserung der Barrierefreiheit einer App ist nicht nur eine technische Frage, sondern auch Ausdruck sozialer Verantwortung und von Inklusion; wichtig ist, dass alle Nutzer einen Dienst gleichberechtigt verwenden können.

3 Kommentare

 
aer0700 2024-03-21

Vielleicht ist die Berücksichtigung von Barrierefreiheit ja auch eine Möglichkeit, loyale Kunden für meinen Service zu gewinnen.
Wenn ähnliche Konkurrenzdienste diese Funktion nicht unterstützen, aber nur unsere App sie anbietet, werden die Kunden schließlich unsere nutzen.

 
godrm 2024-03-20

Oho, das sollten wir auch bei Let’s Swift vorstellen, haha.

 
GN⁺ 2024-03-20
Hacker-News-Kommentare
  • Zusammenfassung des ersten Kommentars:

    Der Entwickler stimmt der Aussage des Autors nicht zu, er werde „nicht aufhören, bis die App von allen genutzt werden kann“. Alle von ihm entwickelten Apps werden so gebaut, dass sie möglichst vielen Nutzern gerecht werden, ohne dabei Geschäftsanforderungen oder wichtige/kernige Aspekte der App zu opfern. Andernfalls würde es zu einem Produkt führen, das nicht nutzbar ist.

  • Zusammenfassung des zweiten Kommentars:

    Der Entwickler gibt sein Bestes, damit auch Menschen mit Sehbehinderung seine App nutzen können. In einer aktuellen App hat er eine Möglichkeit gefunden, die sowohl für Menschen ohne Behinderung leicht zu nutzen ist als auch Menschen mit Behinderung einen Vorteil bietet. Er hat eine Funktion für „Long-Press-Hilfe“ hinzugefügt: Wenn man ein beliebiges UI-Element lange gedrückt hält, erscheint ein Popover, das dieses Element erklärt. Diese Funktion arbeitet gut mit Accessibility-Labels und Hinweisen.

  • Zusammenfassung des dritten Kommentars:

    Positive Bewertung eines praxisnahen Artikels. Accessibility ist wichtig, aber es sei problematisch, Entwickler zu faul zu nennen, nur weil sie ihre Apps nicht von Grund auf barrierefrei gestalten. Es gibt viele Konzepte zu lernen, konkurrierende Prioritäten, Werkzeuge, an die man sich gewöhnen muss, und außerdem muss oft erst ein Business Case für Accessibility geschaffen werden. Die meisten Entwickler und Designer kennen die WCAG-Regeln nicht gut. Auch passende Markenfarben zu finden, die die Anforderungen an den Farbkontrast erfüllen, ist schwierig.

  • Zusammenfassung des vierten Kommentars:

    Der Entwickler hat mit Flutter eine App gebaut, ohne besonders auf Accessibility zu achten, erhielt aber eine Beschwerde von einem sehbehinderten Nutzer, der die App seit sechs Monaten verwendete. Flutter übernimmt den größten Teil der Accessibility automatisch, und auch benutzerdefinierte Funktionen funktionieren für sehbehinderte Nutzer gut, ohne dass größere Anpassungen nötig sind.

  • Zusammenfassung des fünften Kommentars:

    Es wird infrage gestellt, warum man Accessibility-Optionen visuell priorisieren und ein Medium kommentieren sollte, das auf Präzision und hoher Touch-Dichte basiert. Vielleicht wäre es besser, eine auf Nutzer mit Accessibility-Bedarf zugeschnittene App anzubieten, etwa eine Version für „geringes Sehvermögen“ oder „niedrige Touch-Genauigkeit“.

  • Zusammenfassung des sechsten Kommentars:

    Frage nach rechtlicher Haftung oder Schonfristen, wenn eine neue App oder ein Startup viel schneller erfolgreich wird als erwartet. Wenn unklar ist, ob eine Idee überhaupt funktioniert, ist Accessibility womöglich keine große Sorge; außerhalb Kaliforniens dürfte es rechtlich meist kein großes Problem sein, nach unerwartetem Erfolg Ressourcen einzuplanen, um Accessibility-Probleme zu beheben.

  • Zusammenfassung des siebten Kommentars:

    Der Entwickler berichtet von den Erfahrungen seines Vaters, der nach einem Schlaganfall einen elektrischen Rollstuhl nutzte. Dadurch habe er die Bedeutung der ADA-Compliance erkannt und betont, dass Entwickler eine große Rolle dabei spielen können, die Welt zugänglicher zu machen. Er fordert Entwickler auf, sich darum zu bemühen, ihre Arbeit für möglichst alle Menschen zugänglich zu machen.

  • Zusammenfassung des achten Kommentars:

    Ein Nutzer berichtet von seinen Erfahrungen mit den iPhone-Optionen „Größerer Text“ und „Display-Zoom“. Es geht dabei nicht nur um Menschen mit Behinderung, sondern um Flexibilität und Kontrolle für alle Nutzer, damit sie die Oberfläche an ihren eigenen Nutzungsstil anpassen können. Manchmal möchte man sich den Bildschirm vorlesen lassen oder nur bestimmte Teile davon.

  • Zusammenfassung des neunten Kommentars:

    Communities, die Accessibility benötigen, neigen im Allgemeinen dazu, zuerst darum zu bitten und erst später zu klagen. Die ADA ist ein starkes Gesetz, aber wenn man sich bemüht, ist sie in der Regel kein Problem. Um das Jahr 2000 herum schrieb der Entwickler unter Aufsicht eines Anwalts einen Accessibility-Leitfaden und arbeitete später auch mit sehbehinderten Nutzern zusammen, um Apps barrierefreier zu machen. Wenn jemand darum bittet, sollte man helfen — so gewinnt man starke Fürsprecher für die eigene Arbeit.

  • Zusammenfassung des zehnten Kommentars:

    Der Grund für den Erfolg der App sei, dass keine Zeit mit vermeintlich unnötigen Dingen wie Accessibility (a11y) oder Internationalisierung (i18n) verschwendet wurde. Historisch gesehen hätten sich erfolgreiche Produkte anfangs nie auf Accessibility oder Internationalisierung konzentriert. Jetzt, da die App erfolgreich ist, könne man über Accessibility nachdenken und Ressourcen dafür einsetzen.