Smashing Podcast Folge 4 mit Heydon Pickering: Was sind inklusive Komponenten?

Heute spreche ich mit Heydon Pickering über sein neues Buch „ Inclusive Components “. Heydon ist bekannt für seine Arbeit und seine Veröffentlichungen zum Thema Barrierefreiheit – was bedeutet „Inclusive Design“ eigentlich und wo kommen Komponenten ins Spiel? All das und mehr erklärt Heydon in dieser Folge. Sie können unten anhören oder abonnieren, wo immer Sie Ihre Podcasts erhalten.

Notizen anzeigen

• Das Buch Inclusive Components vom Smashing Magazine
• Heydons Projekt Every Layout mit Andy Bell
• Heydons Website Heydonworks
• Heydon auf Twitter

Abschrift

Drew McLellan: Er ist freiberuflicher Berater für Barrierefreiheit im Web, Schnittstellendesigner und Autor. Seine Arbeit konzentriert sich auf barrierefreies User Experience Design sowie auf das Schreiben und Redigieren für das Smashing Magazine. Er ist Autor des gefeierten Buches Apps For All über das Design barrierefreier Webanwendungen und hat gerade mit Smashing Magazine ein neues Buch veröffentlicht, Inclusive Components, in dem es wieder um die Erstellung barrierefreier Webschnittstellen geht. Er ist also eindeutig ein Experte für barrierefreies Design, aber wussten Sie, dass er der erste männliche Mensch war, der mit einem Schnellboot über die Sydney Harbour Bridge gesprungen ist? Meine Smashing-Freunde, heißen Sie bitte Heydon Pickering willkommen. Hallo Heydon. Wie geht es dir?

Heydon Pickering: Ich zerschmettere. Ich bin auf Marke.

Drew: Ich wollte heute mit Ihnen über das Thema Ihres neuen Buches Inclusive Components sprechen.

Hedon: Ja.

Drew: Offensichtlich nur ein Titel mit zwei Wörtern, aber ich habe das Gefühl, dass jedes dieser Wörter eine Menge Gewicht hat. Beginnen wir am Ende, wie es offensichtlich logisch ist, Komponenten. Geht es hier um eine Art komponentenbasiertes Design? Was ist das?

Heydon: Ja, ich nehme an, es ist schon eine Weile her, dass Leute, Frontend-Entwickler, Designer und alle, die an der Erstellung von Schnittstellen mitarbeiten, begonnen haben, über Dinge in Bezug auf Komponenten nachzudenken und Dinge in verdauliche und wiederverwendbare Häppchen zu unterteilen. Und ich nehme an, wenn Sie aus welchen Gründen auch immer nicht mit dieser Arbeitsweise vertraut sind, es ist wirklich ein bisschen wie bei elektronischen Komponenten. Mein Vater ist Elektroingenieur. Er arbeitet in der analogen Welt der Leiterplatten und des Lötens und so weiter.

Heydon: Tatsächlich hat er einige Komponenten hergestellt, sehr kleine Komponenten, die verwendet wurden, um den Strom zu regulieren, der in Elektromagneten am CERN fließt. Und als Kind hatte er großes Vertrauen in mich, weil er mich dazu brachte, tatsächlich einige der Bits für sie zu löten. Ich denke, diese Charge wurde jetzt ausgemustert, also mach dir keine Sorgen mehr über meine schlechte Lötarbeit, meine schlechte Lötarbeit als Teenager, meine Beteiligung am CERN. Aber ja, ich denke, es ist analog zu … Oh, da sind zu viele Analoga drin.

Heydon: Es ist analog zu analogen Leiterplatten, da die Idee darin besteht, dass Sie einzelne Verantwortlichkeiten für einzelne Teile oder Komponenten haben und zusammen die Schaltung bilden und zusammen den Strom im Fall einer Schaltung oder der, denke ich, die Schnittstelle oder das Ergebnis in irgendeiner Weise, in einem Designsystem oder in einer Schnittstelle, wie sie sich durch ein Designsystem manifestiert. Also inklusive Komponenten, weil ich die Tatsache ansprechen wollte, dass zwar Barrierefreiheit im Allgemeinen zurückbleibt, wenn wir das vorantreiben, was wir in verschiedenen Bereichen tun, und ich wollte Barrierefreiheit und im weiteren Sinne bringen sinnvolles, integratives Design, um diese Art des neuen Denkens und der Herstellung von Dingen mit Komponenten oder Modulen oder wie auch immer Sie sie nennen möchten, zu berücksichtigen.

Heydon: Die Idee war also, Barrierefreiheit in Designsysteme zu bringen, aber gleichzeitig systemisch zu denken, wenn es darum geht, Barrierefreiheit anzugehen. Denken Sie darüber nach, ein Problem an einem Ort in Bezug auf die Zugänglichkeit zu lösen und sicherzustellen, dass sich das Muster [unverständlich 00:03:16] im gesamten Designsystem einfach ausbreitet.

Drew: Wie sieht es praktisch aus, komponentenbasiert zu arbeiten? Was könnte ein Beispiel für eine Komponente sein?

Heydon: Es gibt also verschiedene Möglichkeiten, Komponenten zu konzipieren und zu codieren. Ich neige dazu, direkt ins Wesentliche zu gehen, über den konzeptionellen Kram hinauszugehen und darüber nachzudenken, wie ich den Code organisieren könnte. Ich konzentriere mich inzwischen viel auf benutzerdefinierte Elemente, oder wenn keine benutzerdefinierten Elemente, dann auf normale Elemente, aber mit einer Art JavaScript-Verhalten, das auf eine Art isolierter, komponentenbasierter Weise an sie angehängt ist. Ich mag die Idee von Komponenten, die interoperabel sind. Und damit meine ich, dass sie über verschiedene Frameworks und Systeme und Ansätze und technische Stacks hinweg verwendet werden können. Und benutzerdefinierte Elemente sind insofern gut, weil sie nativ sind. Sie können sie an einem Ort definieren und dann beispielsweise in einer React-Anwendung oder in einer View-Anwendung oder in einer Angular-Anwendung oder einer beliebigen größeren Zustandsverwaltungstechnologie verwendet werden verwenden.

Heydon: Für mich ist eine Komponente also normalerweise ein benutzerdefiniertes Element. Ich habe kürzlich an einem Projekt gearbeitet, das sich nicht so sehr auf Zugänglichkeit konzentriert, obwohl ich versucht habe, es so zugänglich wie möglich zu machen, namens Every Layout, und es geht darum, zu versuchen, eine ganz bestimmte Art von Algorithmen für zu isolieren CSS-Layout. Und sie sind als benutzerdefinierte Elemente definiert und stellen sich gewissermaßen selbst bereit und führen ihr eigenes CSS aus und funktionieren als eine Art Primitive innerhalb des größeren Systems.

Drew: Ich meine, in der Praxis sprechen wir davon, dass eine Komponente so etwas wie ein Formularfeld sein könnte?

Heydon: Ja, also könnte es etwas so Einfaches wie eine Eingabe sein. Sagen Sie, wie eine Texteingabe, oder es könnte etwas Komplexes sein, wie eine Registerkartenschnittstelle. Die Idee mit Inclusive Components war also, das Konzept einer Komponente mit ihrem hoffentlich einzigen Zweck, wie eine Texteingabe, zu nehmen und dann über all die verschiedenen Dinge nachzudenken, die verschiedene Arten von Menschen stolpern und versuchen könnten, sie zu vermeiden Ihnen. Vermeiden Sie nicht die Menschen, vermeiden Sie die Probleme. Es geht nicht so sehr darum, Menschen einzubeziehen, sondern darum, Menschen nicht willkürlich auszuschließen.

Heydon: Das scheint für mich der einfachste Weg zu sein, sich einem integrativen Designprozess zu nähern, darin, die potenziell ausschließenden Elemente von etwas zu identifizieren und zu versuchen, sie zu umgehen. Bei einer Texteingabe mit einem Label gibt es also eine Reihe verschiedener Dinge, über die Sie sich vielleicht Gedanken machen sollten. Sie müssten also zunächst einmal wissen, ob es tatsächlich richtig beschriftet ist oder nicht. Verwenden Sie also ein Label-Element und zeigt dieses Label-Element mit einem for-Attribut auf das Textfeld, sodass die beiden Dinge programmgesteuert miteinander verknüpft sind, sodass ein Screenreader-Benutzer, wenn er die Eingabe fokussiert, tatsächlich hört, wie das Label angesagt wird? Das ist also eine Sache, um es richtig zu machen.

Heydon: Dann, auf einer eher visuellen Ebene, sicherstellen, dass das Etikett eindeutig diesem Feld zugeordnet ist und nicht einem anderen Feld, und das ist eine Frage des weißen Raums und dergleichen. Wenn Sie außerdem sicherstellen, dass das Label nicht vorhanden ist, tun Sie nichts Ausgefallenes wie das Platzieren des Labels unter der Formulareingabe, denn wenn Sie beispielsweise eine virtuelle Tastatur aufrufen, kann dies verdeckt werden. Es geht also darum, solche Dinge zu berücksichtigen.

Heydon: Stellen Sie sicher, dass die Eingabe selbst einen Fokusstil hat, also wenn Sie sie mit einer Tastatur fokussieren, ob Sie ein gewohnheitsmäßiger Tastaturbenutzer sind, der Tastaturen zum Navigieren oder auf andere Weise verwendet, stellen Sie sicher, dass aus dem Fokusstil klar hervorgeht, dass dies der Fall ist Eingabe, auf die Sie sich konzentrieren. Sicherstellen, dass, ich meine, Dinge wie die automatische Vervollständigung, sich darüber Gedanken machen, ob die automatische Vervollständigung in dem Kontext angemessen und hilfreich ist oder nicht. Und viele dieser Dinge beziehen sich direkt auf Behinderungen, aber viele von ihnen sind in Bezug auf die Benutzerfreundlichkeit etwas breiter angelegt und machen die Dinge einfach so verständlich wie möglich.

Heydon: Ziemlich oft gibt es eine sehr feine Linie oder vielleicht eine verschwommene Linie zwischen dem, was die Benutzerfreundlichkeit für alle anspricht, und dem, was Behinderung anspricht. Und dann, um es noch schwieriger zu machen, kognitive Behinderungen. Wenn also etwas für jemanden ohne kognitive Behinderungen nicht sehr brauchbar ist, wird es noch schwieriger, es für jemanden zu trainieren und zu verwenden, der diese Art von Herausforderungen hat.

Heydon: Es geht also nur darum, über all diese Dinge an einem Ort nachzudenken. Und wirklich, das Buch ist nur mein, es ist mein Denkprozess, während ich mich jedem von ihnen nähere. Also habe ich es zunächst als Blog gemacht. Und jedes Muster oder jede Komponente ist ein Blogbeitrag, und der Text ist einfach so, dass ich sage: „Also, lasst uns jetzt dieses potenzielle Problem ansprechen. Wie gehen wir vor? Okay, das haben wir abgehakt. Ich denke, wir sind dort in Ordnung.“ Und ich versuche keineswegs zu sagen, dass diese perfekt sind und dass ich an alles gedacht habe, weil das nicht möglich ist.

Drew: Dasselbe gilt für einen komponentenbasierten Ansatz bei der Arbeit an einzelnen Teilen einer Benutzeroberfläche. Ich denke, das ermöglicht es Ihnen, wirklich tief in dieses bestimmte Element einzusteigen und sicherzustellen, dass Sie es wirklich stark optimiert haben, so wie Sie es am besten können kann, damit es für alle zugänglich ist. Besteht die Gefahr, dies mit vielen verschiedenen Komponenten zu tun und sie dann alle auf einer Seite zusammenzufügen? Besteht die Gefahr, dass Sie Probleme erstellen, die Ihnen nicht bewusst waren, weil Sie sie einzeln und nicht zusammen testen?

Heydon: Das ist ein wirklich guter Punkt, und ich wollte das eigentlich früher ansprechen. Ich bin froh, dass du das gesagt hast. Ich denke also, dass wir in vielerlei Hinsicht philosophisch entschieden haben, dass wir die Dinge in diese einzelnen Komponenten aufteilen müssen. Und das hat Vorteile, denn wenn es isoliert ist, ist es einfacher, es zu testen und als eine Sache zu behandeln. Und Sie können in Bezug auf unsere Arbeitsweise gewissermaßen die Dinge einfacher verwalten. Wir müssen auch bedenken, dass diese Dinge letztendlich den gleichen Raum teilen und sich zu einem größeren System zusammenfügen müssen.

Heydon: Und ich glaube nicht, dass wir uns komischerweise genug Mühe und Gedanken darauf werfen. Ich denke, wir gliedern die Dinge mehr in Komponenten, um unser Leben als Ingenieure einfacher zu machen, damit wir wissen, woran wir zu welcher Zeit arbeiten. Und dann vernachlässigen wir oft die Tatsache, dass diese Dinge in dynamischen Systemen leben werden und sie sein müssen …

Heydon: Ich meine, das Every-Layout-Projekt, obwohl es mehr um visuelles Design und um Layout geht, dreht sich alles darum, diese kleinen CSS-Grundelemente, diese kleinen Layout-Grundelemente, so zu gestalten, dass sie sich algorithmisch selbst verwalten können. Es ist so, dass Sie sie aus einer schmalen Spalte nehmen und sie dann in eine breite Spalte stellen können, und dann bestimmt der Code selbst, wie viele Elemente nebeneinander vorhanden sein sollen, oder ob er sich auf andere Weise neu konfigurieren soll. Weil wir es uns nicht leisten können, ständig einzugreifen, und es muss ein System sein, das irgendwie selbstbewusst und intelligent ist, denke ich.

Heydon: Es gibt immer Dinge, die man vergessen kann. Vielleicht erstellen Sie also eine Registerkartenoberfläche, Sie haben eine Reihe von Registerkarten, Sie wählen zwischen der Registerkarte und die Registerkarte entspricht einem Registerkartenfeld, das etwas öffnet. Und dann kommt jemand und sagt: „Nun, was ist, wenn ich ein Tab-Interface in ein Tab-Interface oder eine andere Komponente in ein Tap-Interface einfügen möchte?“

Heydon: Und natürlich, ich meine, es ist teilweise eine technische Frage, ob das möglich wäre, aber ja, man muss die Entscheidung treffen, ob man die Dinge so flexibel wie möglich macht, damit es geht möglich, Dinge auf komplexe Weise zu verschachteln oder einfach harte Regeln zu schreiben, die besagen: „Sie können hier nichts hineinstecken, weil die Komplexität in Bezug auf den Code wahrscheinlich zu hoch wäre, aber möglicherweise auch in Bezug auf wie der Benutzer das Ding wahrnehmen und benutzen kann.“ Ich bin dafür, Regeln zu schreiben, die besagen: „Verschachteln Sie nicht Unmengen komplexer Funktionen in sich selbst“, weil es einfach unwahrscheinlich ist, dass die Leute wirklich in der Lage sein werden, sich damit auseinanderzusetzen.

Drew: Ist es möglich, einen vollständig algorithmischen oder automatisierten Ansatz für barrierefreies Design zu wählen?

Heydon: Das glaube ich nicht. Nein. Wir haben also automatisierte Tools und ich möchte automatisierte Tools in keiner Weise herabsetzen. Ich denke, sie sind sehr nützlich, aber ich benutze sie als eine Art Frühwarnsystem, um zu versuchen, einen Eindruck davon zu bekommen, wo die Problembereiche liegen. Also, wenn ich ein Audit für eine Organisation durchführte, die einen Rat brauchte, wie sie ihre Produkte zugänglicher machen kann. Es ist also eine gute Art der Finanzierung dort, wo die Problembereiche liegen, aber ich meine, Sie können eine Schnittstelle haben, die technisch zu 100 % zugänglich ist, vielleicht sogar ein gutes Werkzeug, um es zu beurteilen, sagen wir gegen die WCAG , die Richtlinien für die Zugänglichkeit von Webinhalten oder eine andere Akzeptanzspezifikation. Und obwohl es sich um eine 100%ige Art aller Kästchen handelt, kann es aus verschiedenen Gründen immer noch völlig unbrauchbar sein.

Heydon: Um zum Beispiel auf das zurückzukommen, was wir zuvor gesagt haben, es kann einfach zu komplex sein. Man kann jemanden mit Links einfach überwältigen und es gibt einfach keine Möglichkeit, dass er da durchkommt, und dann wird es zu einer sehr stillschweigenden Sache und einer schwierigen Sache, die man festhalten kann, aber es wird die Leute zwangsläufig entfremden. Aber es gibt auch, man kann sehr leicht falsch positive Ergebnisse und solche Dinge bekommen. Ich hatte neulich etwas, ich sagte neulich, es war neulich, ich arbeitete für eine Organisation, und natürlich wollten sie eine Leuchtturmschule mit 100 % Barrierefreiheit haben, und da war ein Iframe, der dynamisch eingefügt wurde durch ein analytisches Skript oder so etwas. Sie kennen solche Dinge, bei denen es sich um eine Art leicht groben Code handelt, der einfach in die Seite geschmissen wird, um eine solche Aufgabe zu erledigen.

Heydon: Jetzt würde ich empfehlen, Analytics überhaupt nicht zu verwenden, und ich habe ihnen empfohlen, zumindest das Do-Not-Track-Protokoll zu unterstützen, damit die Leute sich abmelden können. Leider funktioniert dieses Protokoll nicht mehr wirklich, weil es nie richtig unterstützt wurde. Aber dieser Iframe sagte, dass er keinen Titel hat. Die Idee ist also, dass, wenn Sie einen Iframe haben, dieser ein Titelattribut haben sollte, denn das ist die beste Art, seit langem zu identifizieren, wofür der Iframe für einen Screenreader-Benutzer bestimmt ist. Aber dies war ein Iframe, der auch so eingestellt war, dass er keine anzeigt, also war er für einen Bildschirmleser überhaupt nicht wahrnehmbar, weil keine anzeigen, genau wie es Dinge in einem Bildschirmleser visuell verbirgt, es im Wesentlichen aus dem entfernen wird Schnittstelle, so dass es nicht angetroffen oder in irgendeiner Weise angekündigt wird.

Heydon: Es war also ein Fehlalarm. Ich meine, es hat mich gebeten, einen Iframe zu identifizieren, der überhaupt nicht da war, um wahrgenommen zu werden. Daher wird es bei automatisierten Tests immer diese Art von Fehlern und Problemen geben. Aber letztendlich geht es um Wissen, obwohl es einfach eine Sache ist, an der Programmierer, denke ich, nicht wirklich glauben wollen, dass sie daran beteiligt sind, und sie es ein bisschen eklig finden, aber es geht um menschliches Verhalten und darum wie Menschen Dinge verstehen, und das ist eine sehr schwierige Sache, nur eine Art binäre Art von oder boolesche Art von Regeln zu haben.

Heydon: Also, ich meine, ich habe vor einiger Zeit mit einem Entwickler gesprochen, als ich mich darüber beraten habe, und sie haben immer wieder gesagt: „Nun, solange wir automatisierte Tests haben, geht es uns gut, nicht wahr? Es ist nur, dann können wir einfach weitermachen.“ Und ich sagte: „Sie müssen immer noch manuell testen. Es gibt keinen automatisierten Test, der Ihnen wirklich sagen kann, ob die Verwendung der Benutzeroberfläche per Tastatur auf die eine oder andere Weise unmöglich ist.“ Es gibt diskrete Dinge, nach denen Sie suchen können, aber das Gesamterlebnis ist immer noch etwas, das vom Menschen beurteilt werden muss. Ja.

Drew: Manchmal besteht die Gefahr bei automatisierten Tools darin, dass sie Elemente isoliert betrachten oder eine Schnittstelle isoliert betrachten und den größeren Kontext nicht sehen.

Hedon: Ja.

Drew: Sicher, wenn ich Lighthouse für Leistungsprüfungen verwende, treffe ich manchmal als Entwickler die Entscheidung, es aufzunehmen, es kann viel mehr CSS geben, als auf dieser einen Seite verwendet wird, und genau genommen lade ich zu viel CSS herunter, aber eigentlich , weiß ich, dass der Benutzer, sobald diese Datei geladen ist, bereits das CSS hat, wenn er zur nächsten Seite navigiert. Es handelt sich also um eine Optimierung, die über mehrere Seiten hinweg vorgenommen wird und das Tool, wenn es eine Seite isoliert betrachtet, als Fehler ansieht.

Heydon: Ja, absolut. Du denkst voraus und triffst ein Urteil, und bis wir zu fortgeschrittener KI kommen, um das vorherzusehen, dann ja, dann brauchst du wirklich Menschen, die sich das ansehen und es durchgehen und gehen … ich meine, also sollten automatisierte Tests Es muss, wie ich schon sagte, eine Art Frühwarnsystem, ein Diagnosesystem vorhanden sein, aber es sollte auch Schulungen geben, wenn Sie daran interessiert sind, dass sich Ihre Organisation wirklich um sie kümmert und die Dinge integrativer und zugänglicher macht . Es muss Fragen und Antworten geben.

Heydon: Ich würde also Skripte schreiben für „So sollte es funktionieren, wenn Sie mit dieser Komponente über eine Tastatur interagieren“ oder „So sollte es funktionieren, wenn Sie mit einem Screenreader damit interagieren und nicht wirklich durchgehen es. Wenn Sie dies tun, sollte dies also geschehen. Wenn Sie dies tun, sollte dies geschehen. Wenn Sie dies tun, sollte dies erscheinen“ oder so etwas. Also, und die Art von Journey-Zeug, wie Sie sagen, automatisierte Tools sind sich dessen nicht bewusst. Sie sehen nur: „Oh, das hat hier keinen Alt-Text.“ Und tatsächlich sollte es in vielen Fällen vielleicht keinen Alt-Text haben. Außerdem kann es nicht beurteilen, ob Sie den Alt-Text gut geschrieben haben oder nicht. Daher denke ich, dass ein Bild ohne Alternativtext wahrscheinlich besser ist als ein Bild mit irreführendem oder einfach nur schlechtem Alternativtext. Und das ist wieder ein Urteilsspruch, nicht wahr?

Drew: Eines der Dinge, mit denen ich in der Vergangenheit beim Erstellen von Dingen auf zugängliche Weise gekämpft habe, ist, mein Wissen über bewährte Verfahren auf dem neuesten Stand zu halten, denn jedes Mal, wenn ich auf eine Dokumentation oder irgendeine Art von Empfehlung verweise, ist es so Es scheint, als hätte ich das Richtige getan und dachte, ich würde das Richtige tun. Die Empfehlungen sind weitergegangen und jetzt sollte ich etwas anderes tun. Und das ist eine bekannte Geschichte aus allen Bereichen der Arbeit im Web. Aber ich denke, die Gefahr besteht natürlich bei Zugänglichkeitsproblemen darin, dass, wenn Sie nicht die bewährten Verfahren befolgen, wenn Sie etwas in Ihrer Benutzeroberfläche belassen, das jetzt nicht bewährt ist, dies Ihre Benutzer negativ beeinflussen könnte Weg. Hilft ein komponentenbasierter Ansatz zum Erstellen einer Schnittstelle oder einer Website überhaupt dabei?

Heydon: Ich denke nur in dem Sinne, dass, weil Sie eine Komponente haben, die dann natürlich in allen Fällen und nicht nur in Bezug auf die Zugänglichkeit darin besteht, dass Sie diese Komponente an einer Stelle definieren, die dann an verschiedenen Stellen verwendet wird Stellen, zumindest wenn sich Aspekte oder Browserunterstützung oder was auch immer ändert und Sie die Komponente aktualisieren möchten, müssen Sie es nur an einer Stelle tun und dann, wo immer sie verwendet wird, wird diese Verbesserung oder diese Änderung zu spüren sein. Insofern halte ich es sicherlich für sinnvoller, die Dinge in Komponenten zu unterteilen.

Heydon: Aber ja, wie gesagt, das betrifft nicht nur die Zugänglichkeit, das kann alles beeinflussen, was sich ändert. Aber andererseits bin ich mir nicht sicher, wie viele Änderungen es gibt … ich meine, es wird einige bahnbrechende Änderungen in Bezug auf die HTML-Zugänglichkeit geben, was offensichtlich ein sehr enger Bereich ist. Aber in Bezug auf die Codequalität oder wie der Code funktioniert, werden die Dinge offensichtlich sehr langsam in die HTML-Spezifikation eingeführt und nicht ganz so langsam, aber ziemlich langsam in die ARIA-Spezifikation. Und dann spiegelt ein Großteil von ARIA sowieso nur das wider, was im zugrunde liegenden Basis-HTML enthalten ist.

Heydon: Ich denke, mehr noch als die Technologie verändert sich die Wahrnehmung und das Verständnis dieser Dinge im Laufe der Zeit. Ich meine, es gab kürzlich in der WebAIM-Umfrage, dass sie festgestellt haben, dass die Websites, die ARIA verwenden, schwerer zugänglich sind als Websites, die es nicht verwenden. Diese Technologie, die speziell entwickelt wurde, um Menschen dabei zu helfen, Websites zugänglicher zu machen, machte es also noch schlimmer. Es ist also wirklich nur eine Wissenslücke, keine Technologielücke oder ein Technologiemangel. Es sind Leute, die einfach die Technologie nehmen und sie missbrauchen, weil sie leider nicht wirklich verstanden haben, wie sie funktionieren soll. Hoffentlich können einige meiner Texte dabei helfen. In manchen Bereichen sowieso.

Drew: Aber eine Art gut strukturiertes komponentenbasiertes System würde es Ihnen ermöglichen, sobald Sie feststellen, dass etwas veraltet ist oder Sie eine schlechte Entscheidung getroffen haben und es jetzt besser wissen, es Ihnen ermöglichen würde, das Problem einfacher zu beheben über Ihre Anwendung.

Heydon: Ja, genau. Ja, ja, absolut. Ich meine, es dreht sich alles um Effizienz, nicht wahr? Und dieses trockene Prinzip oder was haben Sie, und sehen Sie, deshalb war ich wohl ursprünglich sehr aufgeregt über diese Gelegenheit, weil sich die Leute immer beschweren, dass es zusätzliche Arbeit ist, Dinge zugänglich zu machen, und es ist schwierig und ärgerlich und all das. Und so war es eine Art Gelegenheit zu sagen: „Nun, wissen Sie, wie Sie dieses Zeug wirklich herstellen, diese Komponentensysteme effizient bauen? Holen Sie sich Ihre Zugänglichkeit für diese eine Komponente, die Sie erstellen, und dann mussten Sie sich nicht mehr um die Zugänglichkeit kümmern, abgesehen von gelegentlichen Spezifikationsänderungen oder -aktualisierungen oder was auch immer.“

Heydon: Oder einfach, ich meine, wahrscheinlich die meiste Zeit, wird die Iteration einfach auf Benutzerfeedback und laufender Forschung basieren, die Sie natürlich so weit wie möglich mit einer heterogenen Gruppe von Menschen durchführen sollten. Sie sollten also Leute bekommen, die unterschiedliche Geräte verwenden und unterschiedliche Surfgewohnheiten haben und unterschiedliche Hilfstechnologien und dergleichen verwenden. Und wissen Sie, es kommen immer wieder Dinge hoch. Ich denke, ich habe eine Komponente wirklich festgelegt, denke, sie ist wirklich felsenfest, und dann recherchiere ich ein bisschen und finde heraus, dass ich einige ziemlich schlechte Annahmen getroffen habe. Aber ja, mit einem Komponentensystem müssen Sie es nur an einer Stelle reparieren.

Drew: Kann eine Komponente jemals vollständig inklusiv sein oder ist es ein Spektrum, in dem Sie immer mehr auf Inklusivität hinarbeiten?

Heydon: Ja, es wäre möglich, dass eine Komponente, sagen wir, WCAC-fehlerfrei ist, alle WCAC-Kriterien erfüllt, aber wie gesagt, das bringt Sie nur so weit und es könnte immer noch völlig unbrauchbar sein oder unmöglich zu verstehen, selbst wenn diese technischen Kriterien erfüllt sind. Also ja, das ist etwas, worüber ich viel rede. Ich versuche, die Leute davon zu überzeugen, dass Barrierefreiheit wie jeder andere Bereich des Designs ist, dass sie nur ein Teil des Designprozesses ist und nichts perfekt gestaltet werden kann, genauso wie nichts perfekt zugänglich sein kann. Ich denke, leider denken viele Leute nur daran, sicherzustellen, dass es mit Screenreadern kompatibel ist, was offensichtlich ein sehr enger Bereich in Bezug auf Zugänglichkeit und Inklusion im Allgemeinen ist.

Heydon: Also wird es Leute geben, einige gute Leute, mit denen ich wie bei der Paciello Group zusammengearbeitet habe, die sagen würden: „Nun, eigentlich möchte ich als zugängliche UX-Person bekannt sein.“ Es geht also nicht nur um diese Übung zum Ankreuzen von Kästchen, es geht vielmehr darum, tatsächlich zu versuchen, die Erfahrung für eine größere Anzahl von Menschen besser und wertvoller zu machen und sich mehr in Richtung breiterer Prinzipien und Dinge zu bewegen, die weniger binär sind. Aber letztendlich ist es all das, und WCAC und andere solche Kriterien können nur wirklich das wirklich harte und schnelle „Das ist falsch“-Zeug identifizieren, nehme ich an.

Drew: Was sollte ich also als Entwickler anders machen, wenn ich an das Design, die Planung und den Bau einer Komponente herangehe? Gibt es irgendetwas, das ich bei meiner Arbeit berücksichtigen sollte, um sicherzustellen, dass diese Komponente am Ende so umfassend wie möglich ist?

Heydon: Also, ich meine, je nachdem, was Sie bauen, gibt es unterschiedliche Kriterien, die erfüllt werden müssen. So verfügt beispielsweise nicht jede Komponente über barrierefreie Bilder mit alternativem Text, da möglicherweise überhaupt keine Bilder verwendet werden. Es könnte nur textbasiert sein oder was auch immer. Einige sind möglicherweise nicht interaktiv. In Bezug auf die spezifischen Anforderungen würde es sich also zwischen den Komponenten ändern, aber hoffentlich hilft Ihnen ein Teil meines Schreibens und das Buch „Inklusive Komponenten“, sich in eine Disziplin des inklusiven Denkens zu begeben oder sie anzunehmen.

Heydon: Also, wenn Sie sich diesen Dingen nähern, denken Sie nicht nur, na ja, im Grunde nehmen Sie einfach die Denkweise von „Wenn es für mich funktioniert, funktioniert es wahrscheinlich für alle anderen“, denn es ist einfach nicht der Fall, dass das So wie du oder ich stöbern, ich meine, wir werden es wahrscheinlich ganz anders machen, nur wir zwei, oder?

Drew: Richtig.

Heydon: Und wir sind westlich, weiß, Englisch als Muttersprache. Und ja, die Menge an Vielfalt in Bezug auf die Leute, die das konsumieren, ich meine, Performance-Leute sprechen auch immer darüber, Leute, die daran interessiert sind, sich für bessere Leistung einzusetzen. Sie sind es gewohnt, ein hochspezialisiertes Setup in einem guten Netzwerk zu verwenden, und viele Ihrer Benutzer oder viele Ihrer potenziellen Benutzer werden dies sicherlich nicht tun, und dasselbe gilt für die Zugänglichkeit. Es geht im Grunde nur darum, wirklich nicht mehr an sich selbst zu denken. Buchstäblich nur das. Und natürlich versuchen, auch über Ihre unmittelbaren Kollegen und Menschen in Ihrer gleichen sozialen Gruppe hinaus zu erreichen.

Heydon: Hoffentlich ist es wirklich nur „Hier ist, was ich für dieses Zeug gelöst habe“ und worüber ich damals nachgedacht habe. Sie können einige dieser Ideen wiederverwenden und genau das anwenden, was ich angewendet habe, wenn das für Sie nützlich oder relevant ist. Hoffentlich geht es in dem Buch mehr darum: „Hier ist eine Fallstudie einer Person, die versucht, inklusiv zu denken. Sehen Sie, an welche Art von Dingen sie gedacht haben, wenn Sie etwas völlig anderes entwerfen, verwenden Sie vielleicht einfach die gleiche Art zu denken und versuchen Sie, sich für die Vielfalt der Benutzer und ihre Vorgehensweise zu öffnen.“

Drew: Also das Buch selbst, wie haben Sie entschieden, wie Sie es strukturieren? Es scheint sehr praktisch zu sein, was ich an einem Buch mag, aber wie haben Sie es strukturiert?

Heydon: Sehr ähnlich wie das vorige Buch war eigentlich Inclusive Design Patterns und ich hatte mit diesem Buch anfangs eine Menge Schwierigkeiten, weil ich versuchte, es nach abstrakten Kriterien zu organisieren. Also habe ich angefangen, ein Kapitel zu schreiben, in dem es nur um die Zugänglichkeit der Tastatur ging, aber das war sehr schwierig, weil ich jedes Mal, wenn ich über eine andere Art der Zugänglichkeit der Tastatur sprach oder über das, worüber man nachdenken muss, dann ich musste musste irgendeine Art von Komponente heraufbeschwören und dann diese Komponente fallen lassen und dann zu etwas anderem übergehen.

Heydon: Daher war es für mich einfach sinnvoller, die Dinge nach Komponenten selbst zu organisieren. Inclusive Design Patterns tut dies und jetzt ist Inclusive Components wirklich nur eine Fortsetzung, die nur verschiedene Komponenten abdeckt. Es ist insofern anders, was die Funktionen betrifft, es ist ein bisschen anders, weil es auch Live-Codebeispiele und Zeug enthält, was ich für die vorherigen Bücher nicht so oft gemacht habe. Aber ja, es ist buchstäblich nur „Wir werden diese Komponente machen“, ob es sich um eine Tap-Oberfläche oder einen zusammenklappbaren Abschnitt oder einen Themenumschalter oder eine Benachrichtigungs-Flash-Karte oder einen Toaster oder wie auch immer sie heißen, und dann einfach alles wird dann um diese Komponente herum organisiert.

Heydon: Also heißt es: „Das ist es, was wir tun, und dies sind die Dinge, die wir berücksichtigen sollten, während wir es tun, um integrativer zu sein“, denn so arbeite ich und so arbeiten andere Leute. Und sobald ich damit anfing, arbeitete ich wirklich nur noch und schrieb während der Arbeit Notizen. Und so schrieb sich das Ding irgendwie von selbst, und dann bestand die ganze Anstrengung wirklich darin, sicherzustellen, dass ich einen anständigen Job machte, um diese Dinge nicht unzugänglich zu machen, denke ich.

Drew: Ja, ich meine, das Inhaltsverzeichnis liest sich wirklich fast wie eine Dokumentation oder wie eine Selbsthilfeanleitung oder so. Direkt in Kapitel eins, Umschalttasten. Wenn Sie einige Toggle-Buttons implementieren möchten, gehen Sie zu diesem Kapitel, lesen Sie es und Sie erhalten alles, was Sie darüber wissen müssen, was ein Ansatz ist, den ich wirklich mag. Ich sehe Dinge wie zusammenklappbare Abschnitte, Benutzeroberflächen mit Registerkarten, Themenschalter, Datentabellen, jede Menge echtes, wirklich praktisches Zeug, das wir alle jeden Tag bauen, und ich denke, wir alle könnten wahrscheinlich besser bauen.

Heydon: Ja, das war genau die Idee, denn es ging nicht nur darum, dass ich meine Komponenten herstelle, es war ein Fall, und Sie haben es dort angesprochen, was ich froh bin, dass Sie das getan haben, nämlich um Gemeinsamkeiten zu identifizieren Muster, die wir alle verwenden. Also, ich meine, es gibt überall Tab-Schnittstellen und sie sind alle unterschiedlich implementiert und sie sind alle unterschiedlich implementiert, sehr schlecht. Ich meine, ich habe schreckliche Tab-Oberflächen implementiert und ein wenig darüber gelernt, wie schlecht sie für die Leute waren, und dann habe ich versucht, sie ein bisschen besser und ein bisschen besser und ein bisschen besser zu machen. Ich habe in meiner Zeit wahrscheinlich 15 oder 16 verschiedene Versionen von Registerkartenschnittstellen erstellt, da ich diese Art von Dingen nun schon seit Jahren mache.

Heydon: Und weißt du, sie werden hoffentlich jedes Mal ein bisschen besser. Aber es ist nur eine gemeinsame Sache. Es war eine übliche Sache, die ich ziemlich oft zwischen verschiedenen Websites verwendete, die ich verwende und die jeder verwendet. Ein Teil der Idee war also zu sagen: „Nun, lasst uns eigentlich ein Designsystem machen, eine Art barrierefreies Designsystem für das Web.“ Jetzt werden die Leute sich verzweigen und ihre eigenen Versionen dieser Dinge machen, aber das Kernmaterial herunterzukriegen und die Zugänglichkeit ist eine Kernsache, die in den Dingen enthalten sein sollte. Es sollte kein Add-On sein, es sollte kein Entweder-Oder sein, es sollte kein Feature sein. Es sollte eine Kernsache sein. Und wenn Sie das Kernmaterial zusammenbringen, dann ja, hoffentlich würden die Leute sich die Kapitel ansehen und sagen: „Oh, okay, die habe ich gemacht. Ich habe die gesehen. Mal sehen, wie man es so integrativ wie möglich macht“, und dann haben sie hoffentlich einen gewissen Nutzen daraus.

Drew: Nun, was ich daran mag, ist, dass ich sicherlich weiß, dass ich in der Vergangenheit einige Schnittstellenfunktionen hatte, die ich implementieren musste, und ich weiß, dass es aus Sicht der Zugänglichkeit schwierig sein wird , sagen wir eine Art Flyout-Menü, Dropdown-Menü oder so ähnlich. Ich denke: „Okay, hier sind Drachen in Bezug auf die Zugänglichkeit. Ich muss sicherstellen, dass ich das richtig mache.“ Und so suche ich bei Google danach, wie es geht, finde eine seriöse Quelle, die sagt: „Verwenden Sie diese Methode“, ich verwende diese Methode, ich implementiere sie und mache weiter, aber ich habe tatsächlich nichts gelernt. Ich habe nicht erfahren, warum die Lösung das war. Und was ich wirklich an der Art und Weise mag, wie Sie in dem Buch darauf eingehen, ist, dass ich zwei Dinge gleichzeitig tun kann. Ich kann herausfinden, wie ich es tun sollte, und ich kann herausfinden, warum ich es so tun sollte, weil alles sehr sorgfältig erklärt wird. Also ich finde es aus dieser Sicht wirklich gelungen.

Heydon: Oh, großartig. Darauf wollte ich hinaus. Das ist gut. But yeah, that seems to be my thing. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Ja.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.