Dem Web zuhören, Teil Eins: In Zugänglichkeit denken

Listening to the Web, Part One: Thinking in Accessibility

„Wir haben einige Bedenken hinsichtlich der Art und Weise, wie einige der Formularsteuerelemente gestaltet sind. Sie müssen vollständig angepasst werden, damit sie über die Tastatur zugänglich sind und dem Design entsprechen. Dies bedeutet, dass mehr Zeit mit dem Codieren und Sicherstellen verbracht wird nutzbar. Es bedeutet auch eine etwas längere Ladezeit."

„Ja, okay, das ist in Ordnung.

„Wir wollten auch Probleme ansprechen, die wir mit dem Farbkontrast des Haupttextes gefunden haben. So wie die Dinge jetzt sind, wird es für manche Menschen mit Sehbehinderung schwierig sein, sie zu lesen …“

„Hören Sie, Barrierefreiheit ist uns egal. Wir wollen nur, dass die Website so aussieht, wie sie entworfen wurde. Machen wir weiter.“

Dies war ein echtes, leicht paraphrasiertes Gespräch, das ich zwischen meiner damaligen Agentur und einer Designfirma belauschte. Ich war platt.

Uns egal?

Warum sollten Sie sich nicht darum kümmern, sicherzustellen, dass etwas für Menschen nutzbar ist? Warum überhaupt etwas designen? Sind nicht Menschen der Grund, warum wir tun, was wir tun?

Bevor dieses Projekt gestartet wurde, haben wir alles getan, was wir konnten. Die Website war größtenteils brauchbar, aber es blieben viele Probleme, nicht zuletzt, dass dieser Ansatz kein integratives Denken demonstrierte.

In diesem Moment wurde mir klar, dass kein noch so großes technisches Know-how die Menschen von der Notwendigkeit überzeugen kann, eine barrierefreie Benutzererfahrung zu gewährleisten. Wie die meisten Dinge ist das Erstellen barrierefreier Websites ein Prozess, der mit einem Umdenken beginnt.

Überblick

Ich habe diese Beitragsserie geschrieben, um Lesern und insbesondere Entwicklern die Grundlagen der Arbeit mit Barrierefreiheit vorzustellen. Es ist eine Erinnerung an meine persönlichen Erfahrungen der letzten Jahre, Lernen und Wachsen als Entwickler, wobei Zugänglichkeit im Vordergrund stand.

Wir fangen ganz am Anfang an: in Zugänglichkeit denken. Entwickler denken oft an Screenreader, wenn sie an Barrierefreiheit denken, also lassen Sie uns diesen Bereich untersuchen. Wir werfen einen Blick darauf, wer Screenreader verwendet, warum und wie. Dann krempeln wir die Ärmel hoch und machen uns an die Arbeit.

Wir werfen einen Blick auf semantisches HTML , Aspekte von Elementen und wie man barrierefreie Elemente auswählt, die eine angemessene Semantik bieten. Wir werden uns damit befassen, wie Menschen Screenreader verwenden, Befehle, die jeder Entwickler kennen sollte, und wir werden den Deal mit einem Blick auf Probleme und Fehlerbehebungen auf einer Demo-Site besiegeln.

Vor allem hoffe ich, dass Sie nach der Lektüre erkennen, dass die technischen Fähigkeiten nicht das Ziel, sondern das Mittel sind, um einer größeren Vision zu dienen: einer Vision von Bewusstsein, Inklusivität und Empathie.

Achtsamkeit ist der Schlüssel

Bedenken Sie Folgendes: Wenn Sie ein Auto fahren, ist es entscheidend, auf Ihre Umgebung zu achten. Um ein erfolgreicher Fahrer zu sein, müssen Sie andere Fahrer, Radfahrer, Verkehrszeichen und Fußgänger berücksichtigen. Ohne diese Rücksichtnahme auf andere laufen Sie Gefahr, schnell in Schwierigkeiten zu geraten.

In ähnlicher Weise tragen Sie als Designer und Entwickler dazu bei, eine positive Benutzererfahrung für alle sicherzustellen, wenn Sie auf die Menschen und die verschiedenen Arten achten, wie sie Ihre Website nutzen und mit ihr interagieren.

Wenn Sie beim Entwerfen jemanden in einem abgelegenen Gebiet der Welt mit einer schlechten Verbindungsgeschwindigkeit in Betracht ziehen, stellen Sie sicher, dass die Website und alle ihre Assets schnell geladen werden und optimal funktionieren. Wenn Sie in Betracht ziehen, dass jemand mit einem Handheld-Gerät recherchiert und etwas über ein Thema lernt, werden Sie sicher sein, eine Benutzeroberfläche zu entwerfen, die eine Vielzahl von Bildschirmgrößen und -ausrichtungen von Geräten unterstützt. Wenn Sie jemanden in Betracht ziehen, der blind oder schwerhörig ist oder Schwierigkeiten hat, geschriebenen Text auf einer Seite zu verstehen, dann codieren und strukturieren Sie Inhalte so, dass sie dazu beitragen, Bedeutung und Zweck für Menschen zu vermitteln, die Hilfstechnologien verwenden und darauf angewiesen sind um das Netz zu erleben.

Was wirklich passiert, ist, dass Sie, wenn Sie anfangen, an Menschen mit Behinderungen zu denken und zu entwickeln, letztendlich die Benutzerfreundlichkeit einer Website für alle verbessern (z. B. Menschen, die veraltete Browser oder ältere Handheld-Geräte verwenden).

Wenn Sie auf die Fähigkeiten der Menschen achten und Empathie und Mitgefühl zeigen, können Sie Ihren Entwicklungsworkflow und Ihre Best Practices auf eine Weise vorantreiben, die für alle von Vorteil ist.

Wer hört zu?

Als ich eines Nachmittags in einem öffentlichen Bus fuhr, bemerkte ich einen Herrn auf der anderen Seite des Gangs, der sein Telefon auf seltsame Weise mit beiden Händen hielt. Mit seiner linken Hand hielt er das Telefon hoch, wobei das Lautsprecherende fest gegen sein Ohr gedrückt wurde. Seine rechte Hand wischte und gestikulierte fieberhaft Befehle in das Gerät und bewegte sich so schnell, dass ich nicht verstehen konnte, wie er das alles verstehen konnte. Kurz darauf wurde mir klar, dass er die integrierte Screenreader-Software auf seinem Telefon verwendete, um die Inhalte auf der Website oder App zu finden und anzuhören. Dies miterleben zu dürfen, war für mich eine Offenbarung. Die Erfahrung hat mir gezeigt, wie manche Leute Inhalte konsumieren und wie wichtig es ist, dass Front-End-Oberflächen gut ausgestattet sind, um verschiedene Arten von Benutzerinteraktionen zu verarbeiten.

In einem Bericht aus dem Jahr 2014 schätzte die National Health Interview Survey (NHIS), dass 22,5 Millionen erwachsene Amerikaner entweder „Schwierigkeiten“ beim Sehen haben, selbst wenn sie eine Brille tragen, oder überhaupt nicht sehen können. Dies sind fast 10 % der Bevölkerung, und eine beträchtliche Anzahl dieser Menschen kann sich auf Hilfsgeräte und -technologien verlassen, von denen einige Screenreader verwenden, um im Internet zu lesen und zu navigieren.

Personen, die einen Bildschirmleser verwenden, können hören, was auf dem Bildschirm angezeigt wird, indem eine digitale Stimme den Inhalt und die interaktiven Elemente auf der Seite vorliest. Es gibt verschiedene Arten von Menschen, die sich auf Screenreader-Technologie verlassen, einschließlich Menschen mit Sehbehinderung oder gesetzlich blinde Personen. Einige Menschen haben Schwierigkeiten, Text zu lesen, während andere den Text laut lesen müssen, während sie etwas anderes tun. Manche Leute wollen einfach nur einen langen Blogbeitrag hören, während sie das Abendessen kochen! Mit anderen Worten, Screenreader werden nicht nur von Menschen mit Sehbehinderung verwendet.

Wenn man bedenkt, dass mindestens 10 % der Bevölkerung von der Screenreader-Technologie profitieren würden, ist die Zeit, die zum Erlernen und Arbeiten mit einem Screenreader benötigt wird, keine Verschwendung. Dieses Wissen macht Sie zu einer großen Bereicherung für jedes Entwicklungsteam!

Backen Sie Barrierefreiheit von Anfang an ein

Als ich mit der Planungsphase begann, wie ich ein neues Design unter Berücksichtigung der Barrierefreiheit auszeichnen würde, änderte sich meine gesamte Sicht auf die Entwicklung. Ich habe darauf geachtet, native Browser-Steuerelemente und logisch angeordnete Überschriften, Farben, die Kontrasttests bestehen würden, und unauffälliges JavaScript zu verwenden, das dabei half, den Tastaturfokus für komplexe Interaktionen zu verwalten.

HTML

In den ersten Tagen eines neuen Projekts schrieb ich HTML, nachdem ich die Designdateien studiert, mir gedanklich notiert hatte, was als wiederholbare Module sinnvoll war, und mit den Designern gesprochen hatte. Nur einfaches, einfaches HTML ohne Schnickschnack. Dies verschaffte mir einen Ort, an dem ich mit dem Testen mit einem Screenreader für grundlegende Probleme auf niedriger Ebene beginnen konnte, Dinge, auf die ich achten und die ich sofort beheben konnte. Ich stellte sicher, dass alles die richtige Semantik und den richtigen Kontext für das hatte, was die Elemente sein sollten.

CSS

Nachdem die HTML-Struktur als wiederverwendbare Module eines größeren Designsystems geschrieben war, würde ich anfangen, Klassen hinzuzufügen und das CSS zu schreiben, um es an das beabsichtigte Design anzupassen. Wenn die Stile zu einem Modul hinzugefügt wurden, ging ich erneut hinein und testete auf Barrierefreiheitsprobleme. Ich würde nach Elementen mit einer Anzeigeeigenschaft Ausschau halten und darauf achten, dass sichtbare (oder nicht sichtbare) Dinge diesen Zustand bei der Interaktion mit einem Bildschirmleser widerspiegeln. Ich würde auch auf die Elementpositionierung achten. Die Dinge können ziemlich schnell außer Kontrolle geraten, daher musste ich sicher sein, dass die visuelle Reihenfolge der Inhalte mit der Reihenfolge übereinstimmt, die bei der Verwendung eines Screenreaders gefunden würde. Auf diese Weise würde jeder die gleiche Lesereihenfolge für den Inhalt erhalten und jede Möglichkeit von Verwechslungen vermieden werden.

JavaScript

Es mag einige Leser überraschen, wie auch ich selbst, als ich anfing, etwas über die Entwicklung von Barrierefreiheit zu lernen, dass JavaScript eine große Rolle beim Schreiben barrierefreier Schnittstellen spielt. Dies gilt insbesondere, wenn Sie dynamische Widgets wie Akkordeons oder modale Fenster erstellen oder vielleicht ein verstecktes Navigationsmenü für Geräte mit kleinem Bildschirm implementieren. Durch die Verwendung von JavaScript können wir zusätzliche Elemente dynamisch erstellen und einfügen und die erforderlichen Attribute hinzufügen, um die Bedeutung und den Zweck unserer komplexeren Benutzeroberflächen weiter zu vermitteln. JavaScript wird auch verwendet, um den Tastaturfokus für benutzerdefinierte Widgets oder komplexe Interaktionen zu verwalten.

Wir werden im nächsten Teil der Serie etwas tiefer in diese Konzepte eintauchen, aber vorerst ist der wichtigste Punkt, den wir mitnehmen sollten, dass wir die Menschen im Auge behalten und in jedem Schritt des Entwicklungsprozesses auf Barrierefreiheitsprobleme testen sollten. Denken wir daran, dass wir etwas für Menschen tun, nicht für andere Designer oder Entwickler. In den meisten Fällen nicht einmal für uns selbst.

Backen Sie Barrierefreiheit in jede Entwicklungsiteration ein. Testen Sie früh und oft. Denken Sie an Ihr Publikum. Indem Sie diese kleinen zusätzlichen Schritte zu Ihrem Workflow hinzufügen, stellen Sie sicher, dass die Barrierefreiheit von Anfang an bereit und verfügbar ist.

Zurück zum Blog