Responsible Web Apps

Lucas Dohmen: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcasts! Heute geht es um responsible web applications und dafür habe ich mir die Joy Heron eingeladen. Hallo Joy!

Joy Heron: Hallo!

Lucas Dohmen: Die Joy ist bei uns Senior Consultant und war auch schon häufiger im INNOQ Podcast zu Gast. Deswegen überspringen wir jetzt mal die Vorstellung. Aber erstmal müssen wir nochmal sagen, was habe ich denn gerade gesagt? Ich habe gesagt responsible web applications, davon haben wahrscheinlich die meisten noch nicht gehört. Bevor wir aber dahin kommen erstmal: Warum? Was hat dich dahingebracht dich mit diesem Thema zu beschäftigen? Was waren so deine Gedanken, die dich dahingebracht haben?

Joy Heron: Ja, also das was das bedeutet. Also das ist eben eine Mischung aus zwei Wörtern. Einmal responsive, einmal accessible. Das Wort entstammt daher, dass ich versucht habe so irgendwie… Ja, so wie war das so? Ich habe irgendwie gesagt: Ich möchte euch so vorstellen, wie man responsive und accessible Webanwendungen so von Anfang an gestalten kann. Also das Thema kommt daher, dass ich gemerkt habe…, also ich bin sehr lange so ein großer Fan von Mobile First Entwicklung. Oder responsive Webentwicklung, dass wir eben Rücksicht auf alle möglichen Devices betrachten bei der Entwicklung und dass man das von Anfang an macht. Und ich habe seit vielleicht zwei Jahren, so eineinhalb/zwei Jahren, mich so ein bisschen tiefer mit diesen Accessibility Thema Barrierefreiheit und ich habe gemerkt, dass das eben auch, also es gibt einige Dinge, die so ähnlich sind. Also mit responsive design und accessible design. Und die spielen sehr gut zusammen, ich finde man sollte eigentlich beiden von Anfang an betrachten. Und dieser Begriff responsible web applications kam daher, dass ich versucht habe responsive und accessible web applications sehr schnell zu sagen und da ist irgendwie responsive… oder responsible rausgekommen. Weil das zu lange ist. Und so das ist halt, ich kann nicht gute Marketing Begriffe erzeugen, wenn ich es versuche, aber anscheinend, wenn ich es aus Versehen so sage, dann kommen gute Begriffe raus, die man merken kann. Genau und so ich finde halt der Begriff, ich habe das nicht absichtlich so gemacht, aber ich finde es eigentlich gut. Weil responsible heißt ‚Verantwortungsvoll‘ auf Englisch und ich finde wir haben irgendwie die Verantwortung vor allem. Also ich rede da von der Entwicklerperspektive, weil ich Entwicklerin bin. Aber wir haben so irgendwie eine Verantwortung dafür zu sorgen, dass unsere Webanwendungen sowohl responsive also auch accessible sind. Das heißt wirklich, dass die für alle mögliche Geräte, die ich mir vorstellen kann, funktionieren und auch, dass sie für alle möglichen Benutzergruppen gut funktionieren.

Lucas Dohmen: Okay.

Joy Heron: Das sind die beiden Themen und die sind zum Teil so sehr verwandt miteinander.

Lucas Dohmen: Also kann man sagen so für alle Menschen und für alle Geräte soll die Seite benutzbar sein?

Joy Heron: Genau.

Lucas Dohmen: Okay, wir haben ja schonmal eine ganz ausführliche Folge dazu aufgenommen zu dem Thema intrinsic design. Das ist ja ein bisschen so das weitergedachte responsive web design. Ich würde auf diese Folge verweisen, wer sich da jetzt nochmal näher mit beschäftigen will, sonst nehmen wir ja quasi die gleiche Folge nochmal auf. Aber vielleicht kannst du ganz kurz zusammenfassen was so deine Erfahrung ist. Warum muss man so früh schon beachten, dass man responsive web design macht? Und was sind die Kosten, wenn man es nicht tut?

Joy Heron: Ja, genau. Also ich habe dazu ein Gesetzt erstellt. Also ich weiß nicht wie man… Ich habe ein Gesetzt gemacht, also gefunden.

Lucas Dohmen: Erlassen!

Joy Heron: Also da sage ich halt: In allen meinen Erfahrungen, allen Projekten ist es so, dass es nicht… Es gibt keine nicht responsive Webseiten. Also man denkt da kommt man zu Kunden und die sagen: Ja. aber wir haben eigentlich so nur Anforderungen auf Desktopgeräten, weil alle Mitarbeiter so irgendwie ein 27-Zoll Monitor haben und da gibt es keine Einschränkungen mit dem Platz auf dem Bildschirm. Aber dann irgendwann später kommen diese Anforderungen immer in meiner Erfahrung. Also es gibt halt nie den Fall, dass man sagen kann: Also wir werden diese Anwendungen wirklich nur für den Rest unseres Lebens auf so einen 27-Zoll Bildschirm machen. Und das habe ich immer wieder erfahren. Zum Beispiel mit so einen…, also eine Anwendung hätte nur auf Desktops verwendet werden sollen, bis plötzlich man das bei einer Messe auf iPad Geräten vorstellen wollte. Und dann hatten wir irgendwie so in einem Monat die Zeit das doch ein bisschen responsive zu machen. Und da… Also das ist das erste Gesetz, das eben diese Anforderung‚ wir haben keine Mobilgeräte‘ eigentlich Quatsch ist und dass es das nicht gibt. Und mein zweites Gesetz ist, dass alles was wir tun können, um jetzt schon die Grundlagen zu schaffen für so ein responsive design später, darüber werden wir uns freuen. Also in dem Beispiel, was ich erwähnt habe, also ich persönlich, ich kann einfach nicht ab, wenn ich das Bildschirm kleiner ziehe und alle Inhalte so nicht innerhalb von dem Viewport bleiben. Also wenn die irgendwie das Layout zerstören oder sowas. Das persönlich kann ich nicht leiden, deswegen baue ich immer irgendwie ein bisschen responsive Verhalten in meine Anwendungen ein, auch wenn der Kunde das nicht explizit anfragt. Weil ich weiß das die Anforderung irgendwann mal kommt, das hilft schon das im Hinterkopf zu haben. Aber ich baue das einfach so, also ich lege die Grundlagen für so ein responsive design immer hin, auch wenn ich nicht unbedingt sofort für Mobile optimiere. Das heißt, wenn man das tut, also vom Anfang an irgendwie schauen, wie kann ich so ein Layout gestalten, dass das irgendwie ein bisschen responsive ist? Das sorgt dafür, dass ich später die Möglichkeit habe das für Mobile zu optimieren. Wenn man das andersrum macht und sagt: Ich nagele mich fest, mein Layout ist immer so mindestens 900 Pixel breit. Und versuche später das dann auf Mobile runterzusenken, da hat man keine Chance und muss das von Anfang an neu bauen.

Lucas Dohmen]: Ja.

Joy Heron: Und das ist der zweite Punkt. Also wenn man so überlegt, also wie teuer so eine Entscheidung ist, wenn man da nochmal umbauen muss, das geht sowohl für responsive als auch für accessible. Also im Wesentlichen, wenn die Grundlagen von Anfang an nicht gelegt sind, muss man die ganze Anwendung neu bauen. Also alle Arbeit, dann kostet das doppelt. Also mindestens doppelt. Also irgendwie, das ist natürlich eine Einschätzung. Aber so ist das, also du baust die Anwendung einmal, merkst, dass das dann doch responsive Verhalten braucht, dann schmeißt du das alles weg und musst komplett neu bauen. Und das ist halt teurer, das ist klar, dass das teurer ist. Lucas Dohmen]: Genau.

Joy Heron: Und was ich versuche immer, auch Kunden so zu erklären ist, dass mit heute, mit modernem CSS und modernem HTML ist das so, dass wir, wenn wir halt ein bisschen mehr Zeit vielleicht investieren in dem responsive design, ist es genauso teuer. Also da haben wir was und es ist wirklich nicht viel teurer. Es kann sein, wenn man noch nicht die Fähigkeiten hat…, irgendwie so, man hat noch nicht gelernt, wie CSS Grid funktioniert oder wie Flexbox funktioniert jetzt bei CSS, könnte es sein, dass man ein bisschen mehr Zeit für das responsive design benötigt, aber wir sind dann… Also da diese Zeit, wenn man später das nochmal machen muss, dann muss man dieses nachher auch lernen.

Lucas Dohmen]: Ja. Da lohnt es sich einfach früher zu investieren. Okay, super. Okay, und wer da mehr drüber wissen will, der hört einfach mal oder die hört einfach mal in die Folge 74 rein, da haben wir ganz ausführlich darüber gesprochen. Dann lasst uns doch jetzt mal auf den anderen Aspekt von responsible web applications schauen, nämlich die accessiblity. In der Folge 71, da hat unser Kollege Andreas zusammen mit dem Stefan gesprochen und die haben ganz ausführlich darüber geredet, warum accessibility denn so wichtig ist eben auch in internen Anwendungen und wie das halt so ist, wenn das nicht so ist. Und ich glaube das perfekte accessible design zu bauen ist eine große Herausforderung, aber ich glaube dein Anspruch ist so ein bisschen zumindest mal diese 90% hinzubekommen. Ist das richtig?

Joy Heron: Genau. Also da komme aus der Richtung, dass ich gerne so, ich bin kein Screenreader Benutzer zum Beispiel. Dann ist es für mich sehr schwierig das wirklich so 100% für Screenreader zu optimieren. Aber, also wenn man einiges lernt, kann man so sich das irgendwie 70/80% schon schaffen so für eine Webseite. Und das finde ich unglaublich wichtig, dass man irgendwie so einfach die Grundlagen lernt, damit man so eine Webseite baut, die mehr oder weniger so accessible ist. Und was ich damit meine ist, dass… Also ich verwende zwei Tools hauptsächlich, um accessibility zu testen, wenn ich Anwendungen schreiben. Zum einen, also ich benutzte Mac bei der Entwicklung und da kann man zum Beispiel dann so eine Einstellung so für den Safari einschalten, dass die Links in der Webseite so per Tab erreichbar sind. Und dann ich zum Beispiel die Keyboard-Accessibility von der Webseite ganz gut testen. Das heißt die kann durchgehen und schauen: Okay, wenn man kann mit der Tastatur in der Anwendung so sich durch navigiert, folgt das so einer sinnvollen Reihenfolge? Kann ich alle Elemente so erreichen mit dem Keyboard? Und so weiter und so fort. Und kann ich irgendwie navigieren? Gibt es genug Navigationsmöglichkeiten innerhalb von der Anwendung, dass ich mit Tastatur so gut so über die Seite navigieren kann? Das ist eine und dann verwende ich nachher auch einen Screenreader. Also wenn ich Screenreader benutze sind in der Regel auch so Tastaturbenutzer. Also wenn die Keyboard-Reihenfolge von der Benutzbarkeit von der Seite so richtig ist, dann ist das auch ein guter Schritt, sage ich mal so. Und dann also verwende ich auch so einen Screenreader und da finde ich ist er ein sehr gutes Werkzeug, um so eine Webseite zu testen, weil da hört man während man… Also man bekommt so einen komplett anderen Blick auf die Anwendung, die man entwickelt, weil es einem vorgelesen wird. Also da muss man durch die ganze Anwendung durchgehen und dann muss man überlegen: Also, wenn ich das nicht sehe, habe ich genug Information, um zu verstehen was das ist? Und dann solche Dinge, also wenn ich merke irgendwie da wird mir etwas vorgelesen, was total sinnlos ist und ich habe keine Ahnung was das ist hier. Und vielleicht ist das so ein visuelles Icon, was nicht da sein muss und dann kann ich das verstecken für Screenreader. Oder ich merke, es gibt irgendetwas visuelles so auf der Seite, was für einen sehenden Benutzer vielleicht klar ist, aber wo ich, wenn ich mit dem Screenreader dadurch gehe, da merke ich: Ich habe keine Ahnung, was das ist. Da ist auch ein Hinweis darauf, dass ich so vielleicht irgendwie etwas ergänzen kann, um es so auch für Screenreader-Benutzer zur Verfügung zu stellen. Aber ich glaube da ist es ganz wichtig zu erwähnen, also accessibility heißt nicht nur Screenreader-Benutzer. Es heißt einfach so Menschen, die assistierende Technologien benutzen in irgendeiner Form. Aber für mich sind das eben die zwei Werkzeuge, die ich verwende. Also wenn man es hinkriegt, dass ein Screenreader so damit gut klarkommt, dann ist das Basis für accessibility. So in der Richtung ziemlich gut. Ja, genau.

Lucas Dohmen: Okay. Und wie ist das, wie muss ich mir das vorstellen? Also wenn du jetzt so einen Screenreader anmachst, schließt du dann deine Augen, damit du dann auch mitbekommst, wie das… also, dass du das nur noch hörst die Webseite? Oder lässt du deine Augen auf und schaust auch, ob irgendwas übersprungen wird? Wie muss ich mir das vorstellen?

Joy Heron: Ich habe gehört, dass man die Augen schließen soll. In der Regel mach ich das nicht unbedingt.

Lucas Dohmen]: Okay.

Joy Heron: Also ich glaube, dass auch wenn man die Augen nicht schließt, kann man die Informationen gut, also gut mitbekommen. Es ist tatsächlich, also das sind unsere persönlichen Präferenzen. Für mich ist es einfacher Dinge zu verstehen, wenn ich etwas sehe. Und was der Screenreader Voiceover zum Beispiel macht ist, dass er auch die textuelle Beschreibung von den Labels und so weiter, auch auf so einen Balken auf dem Screen so vorließt. Und ich glaube deswegen ist es für mich so einfacher da mitzubekommen was los ist. Ja.

Lucas Dohmen: Und ist das bei Screenreadern auch so wie bei Browsern, dass ich eigentlich quasi verschiedene Screenreader ausprobieren müsste, wenn ich jetzt… also, wenn ich dafür das Budget und die Zeit hätte das zu tun oder funktionieren die alle im Kern gleich?

Joy Heron: Wenn man dafür die Zeit und Budget hätte, dann wäre das super. Bei mir…, also ich finde halt da müssen wir schauen, was wir leisten können. Und für mich ist das so, also bei mir funktioniert der Safari zuverlässig, aber ich habe zum Beispiel Probleme auf Mac mit Firefox. Ich weiß jetzt nicht, warum das mit Firefox manchmal einfach nicht so gut funktioniert. Und das ist dann schwierig, ich weiß nicht wie so Menschen Screenreader auf dem Mac verwenden, ich weiß nicht, ob sie das Firefox einfach nicht verwenden oder ob ich einfach so die Steuerung in Firefox nicht verstehe. Für mich ist das so, ich glaube auf jeden Fall, wenn das in Voiceover funktioniert, ist es besser, als wenn ich es gar nicht teste. Das ist so mein Anspruch und dann oft ist es so, wenn ich das getestet habe und ich wirklich 100% sicherstellen möchte, dass das für… Also das ist das irgendwie wahrscheinlich Barrierearm, dass es irgendwie benutzbar ist für jemanden mit Screenreader. Das heißt aber nicht, dass es für Screenreader optimiert ist, das ist eine andere Stufe der accessibility. Und wenn ich wirklich möchte, dass es für Screenreader so optimiert ist, muss ich dann zu einem Screenreader-Benutzer gehen und den fragen das zu testen. Aber ich finde es wirklich so eine Frechheit muss ich zugeben, wenn man einfach die Anwendung gar nicht testet und dann so einen Screenreader-Benutzer/Screenreader-Experten fragt: Bitte teste das mal! Und dann sind so viele Dinge falsch, dass man wirklich nicht so viel davon mitnehmen kann. Der sagt dir: Dieser ganze Bereich ist für mich nicht erreichbar. Da kann er dir nicht so die unterschiedlichen Kleinigkeiten erzählen, was man da verbessern kann, sondern es ist ganz hier irgendwie… Die ganze Seite ist schlecht. Also deswegen finde ich, wenn man wirklich für Optimierung, für optimierte Screenreader usability, muss ein echter Screenreader-Benutzer das verwenden. Aber wir sollten lernen, dass die Grundlagen damit wir zu dem Punkt kommen: Wir wissen zumindest sind alle Elemente meiner Seite mit einer Tastatur so erreichbar; zumindest ich habe mir so Gedanken gemacht, wie die Navigation der Seite ist, also das es funktioniert und so weiter und so fort.

Lucas Dohmen: Ja, ich meine das passt ja auch gut zu deiner Beschreibung, dass man mit diesen grundlegenden Prinzipien, die du vorstellst, ja zumindest mal so auf 70–80% kommt und man hat das mit einem Screenreader gut getestet, mit dem funktioniert es schonmal gut. Und wenn man darüber hinauswill, dann braucht man wahrscheinlich ein accessibility Audit wo sich das einer wirklich mal in Ruhe anschaut, das auch mal durchtestet. Und das ist natürlich auch was, wie ein User-Test, andere Arten von User-Tests, die man einfach auch zusätzlich einplanen muss als Budget, als Zeit und so weiter. Aber dass man zumindest mal weiß: Also grundsätzlich ist diese Webseite benutzbar und auch accessible.

Joy Heron: Genau.

Lucas Dohmen: Dann habe ich noch eine Frage, weil ich mir zumindest… Das in meiner Erfahrung das so ist, wenn ich auf dem iPhone dieses Voiceover nochmal benutze, wir sind ja beide Mac und iPhone User muss man dazu noch auch ergänzend sagen, dass da doch die accessibility nochmal ein bisschen anders ist, weil man ja viele Sachen doch, darüber, dass man da drüber hovert mit dem Finger, vorgelesen bekommt. Hast du damit auch Erfahrung, wie du das auf dem iPhone machst? Oder machst du das nur auf dem Mac deine Tests?

Joy Heron: Nein, tatsächlich mache ich nur auf den Mac meine Tests, aber jetzt habe ich Lust das mal zu machen!

Lucas Dohmen: Okay. Alles klar!

Joy Heron: Sorry, ich habe das tatsächlich noch nie verwendet auf dem iPhone.

Lucas Dohmen: Alles klar! Denn lass uns doch mal kurz in diesen Bereich gehen: Was müssen wir denn tun? Also ich glaube eine Sache, die wir alle schonmal gehört haben, ist, man sollte semantisches HTML benutzen. Kannst du da vielleicht mal ein paar Beispiele geben welche semantischen Dinge direkte Auswirkungen auf Screenreader Benutzer/Benutzerinnen haben?

Joy Heron: Ja, das kann ich machen. Also die Punkte, die ich auflisten würde, die sind alle unter der Webseite responsibleweb.app zu finden. Also was ich vielleicht dazusagen möchte, also ich finde der Punkt mit, es ist manchen Menschen HTML superwichtig. Und für mich ist es so, also das spiel mit dem responsive Webentwicklung auch sehr gut zusammen. Und der Grund dafür, also mit responsive web design ist es so, dass ich so… Ich möchte so einen Container, da sage ich immer so, das hatte ich auch in der intrinsic design Folge erwähnt, ich möchte irgendwie so einen Layout-Container drumherum, der responsive ist, der sich anpasst an meine Viewport Breite und dann möchte ich dadrin, dass die Inhalte sich zerquetschen, wenn die nicht genug Platz haben. Und das Ding ist, dass HTML, also bietet sehr gut diese Container, da muss man nicht irgendwie alles in meinem Dokument, div-Elemente definieren, sondern ich kann so wirklich semantisch sagen, also was ist dieser Bereich. Und vielleicht als erstes kann man so erwähnen, es gibt in HTML so, die heißen Landmarks oder so. Ich glaube das ist role landmark, das sind so diese Regionen in HTML und das ist vor allem… Also das ist der header, main und der footer diese Bereiche. Und der Header, man kann sich das so vorstellen, der Header wäre so oben auf der Webseite vielleicht oder vielleicht links. Aber das ist der Bereich so, wo ich ein Nav-Bar finde so was über die ganze Seitennavigation so etwas anbietet. Dann gibt es den Main Bereich, das ist mein Hauptinhaltsbereich und der Footer unten. Also ich kann das mir so vorstellen, also wenn ich ein Design betrachte. Aber das bietet auch eine Ebene für Screenreader, die können auch genau diese drei Regionen auch finden. So ein Header ist da, wo die Navigationen links sind, der Main ist der Hauptinhaltsbereich, der Footer, das ist der Bereich wo ich vielleicht zusätzliche Informationen finde, der Link zu dem Datenschutz und so weiter und so fort. Und das sind so etablierte Muster in der Struktur von unseren Webseiten und wir müssen nicht dafür… Wir sollten nicht dafür divs verwenden, sondern wir sollten das echte HTML Element verwenden. Weil dann gibt es zum Beispiel für Screenreader, ich glaube der IE11 ist da noch nicht so… also der ist ein bisschen alt. Aber alle anderen Browser, die neueren, da gibt es für Screenreader so Tastaturkürzel, wo man eben sagen kann, wenn ich auf der Seite bin, dass ich zu dem Header springen kann oder dass ich zu dem Footer springen kann oder dass ich zu dem Main-Bereich springen kann. Und das ist zum Beispiel ein Beispiel: Das Layout für die ganze Seite finde ich sollte man diese Tags, diese HTML-Tags verwenden.

Lucas Dohmen: Und wie ist das mit Überschriften? Also ich glaube wahrscheinlich kennen alle irgendwie H1, H2, H3. Ich glaube das machen wir viele oftmals so nach Bauchgefühl, was man da am besten nimmt, was am besten vom Design passt. Was muss man denn da beachten?

Joy Heron: Ja, das ist genau ein Fehler, den fast jeder Entwickler macht. Und ich habe das auch, also am Anfang gemacht. Weil wenn wir entwickeln benutzen wir oft Bootstrap oder irgendetwas anderes. Und wir Entwickler sind so schlau, dass wir denken wir sind Designer auch und dann sind uns einfach auch… Also dieser Titel hier, wenn ich ein H2 setze für diesen Titel, das ist mir zu groß. Also nehme ich lieber den H5, der sieht für mich besser aus. Und das ist ein Fehler, das ist Punkt ein Fehler. Und der Grund ist, dass die Heading-Ebenen, das sind so H1 bis H6 HTML-Tags, die Heading-Ebenen sind nicht dafür da, um uns visuell zu zeigen, also wie diese Heading aussieht. Sondern die ist dazu da so die Dokumentstruktur auf eine sinnvolle Weise aufzubauen. Man kann sich das vorstellen so diese Heading-Ebenen da kann man zum Beispiel so… Das sollte man sich irgendwie so wie ein Table of Contents, Inhaltsverzeichnis ist das auf Deutsch, so betrachten. Also das ist eine sinnvolle Reihenfolge von Heading-Ebenen und zum Beispiel, dass die H2 Punkte…, die H3 Unterpunkte zu dem H2 da oben gehören. Und es ist so, wenn man Heading-Ebenen rauslässt, dass für so jemanden, der auch diese assistierenden Technologien verwendet, das einfach total verwirrend ist dann, wenn sie denken, dass sie etwas einfach verpasst haben. Wenn sie von einen H2 zur Heading-Ebene zur H4 so gelangen, denken sie: Wo ist das H3 da drin? Also habe ich irgendwelche Inhalte verpasst? Und das ist genau dieser Punkt, den wir vermeiden wollen. Wir wollen nicht vermeiden, dass… Wir wollen wirklich eine einheitliche Dokumentstruktur aufbauen und das kann man mit Heading-Ebenen sehr gut machen. Also das ist auch so ein Punkt, wenn es Heading-Ebenen gibt, es gibt so für Screenreader zum Beispiel die können, und glaube aber euch wahrscheinlich auch noch für andere assistierenden Technologien also auch, die können einfach die ganzen Heading-Ebenen vorlesen, um irgendwie so eine Übersicht von der ganzen Seite zu bekommen und können dann direkt zu einer Heading-Ebene springen. Und das ist ein sehr guter Weg wie man, also innerhalb der Seite, navigieren kann und wir sollten den auch verwenden. Auch für unsere interne so Enterprise Anwendungen so überlegen: Welche Bereiche gibt es in meiner Anwendung aktuell? Und so dann wirklich die richtige Heading-Ebene dafür verwenden und notfalls das mit CSS kleiner machen, wenn es kleiner sein muss. Ein H2 muss nicht visuell groß sein, das ist Quatsch. Also man kann den auch so mit CSS kleiner machen und anders stylen je nach Kontext, damit das visuell passt. Aber so die HTML-Ebene sollte richtig sein.

Lucas Dohmen: Okay, also das heißt also die H-Tags sind quasi ein Outline unseres Dokumentes und nicht irgendwelche visuellen Elemente.

Joy Heron: Genau.

Lucas Dohmen: Und das bedeutet auch, also wenn ich mir jetzt vorstelle ich habe so eine Unter-Überschrift. Also ich habe jetzt so den Case Podcast 84 Responsible Web und darunter setze ich irgendwie einen Untertitel: Joy Heron erzählt uns viele Interessante Dinge über Web Applikationen. Dann ist diese Unter-Überschrift kein H-Tag, richtig?

Joy Heron: Also aus dem Bauchgefühl hätte ich ‚nein‘ gesagt. Weil für mich sollte der H2 wirklich sagen: Also was kommt hier hin? Und wenn das nur so ein kleiner Schnipsel von Text ist, ist das eher so… ist das nicht irgendwas, wo ich dahin springe, das ist alles was da ist und da geht man nicht weiter. Also da würde ich eher so ein p-Tag oder so, keine Ahnung, was anderes nehmen. Ja.

Lucas Dohmen: Ja, okay. Cool! Ich glaube das war jetzt eine sehr allgemeine Frage, aber okay. Gut. Wie ist das denn beispielsweise mit Listen? Was muss ich denn bei Listen beachten?

Joy Heron: Man sollte die einfach… Also man sollte sie oft verwenden. Also ich glaube wir denken oft: Ah Listen sind das, wo ich diese Punkte oder diese Zahlen in der UI sehen möchte. Und das stimmt vielleicht ein bisschen, aber vieles kann eine Liste sein. Also auf der HTML-Ebene, was nicht unbedingt wie eine Liste aussehen muss in der UI. Also ein gutes Beispiel ist, wenn wir so eine Anwendung haben, also haben wir sehr oft so Listen-Ansichten von irgendwas. Typischerweise wenn wir so eine CRUD-Anwendung bauen, haben wir so diese eine Ressource, wo es alle unsere Entitäten auflistet, die wir… Also wir können da daraufklicken und kommen in so eine Sicht von diesem Ding, was auch immer das ist. Und es gibt keinen Grund für diese Ansicht, das mit div-Tags zu implementieren. Wir können dafür einfach eine Liste nehmen und dann die einzelnen Elemente sind so li-Elemente. Wir können entweder so, wenn wir merken, dass es eine Reihenfolge gibt von li-Elemente, die wir auf der Seite haben, dann können wir eine Ordered List nehmen, das ist dieses ol. Oder wir können so bei der Unordered…, also das ist eben in sehr vielen Fällen so, es gibt keine Ordnung von den Elementen, die auftauchen, dann können wir so ein ul, so Unordered List nehmen. Man sollte vielleicht beachten, ich glaube, wenn man so das Styling mit Flexbox oder Grid anpasst, kann es sein, dass diese Listen, also da sollte man das mit Screenreader testen… Also man muss manchmal auch den Role List auch auf die Liste setzen, damit das noch für einen Screenreader wie eine Liste ist. Aber der Vorteil, also da meine ich… Also wenn man zum Beispiel display grid auf eine ul setzt, dann verliert dieses ul seine Liste-Charakteristik auf HTML-Ebene. Da kann man eben in dem HTML sagen: ul role gleich List. Und dann bleibt das bestehen. Aber der Vorteil davon ist, dass wenn das für Screenreader oder… ja, genau. Also ich teste das für Screenreader, deswegen sage ich immer Screenreader, aber man kann Screenreader, wenn ich das sage wirklich durch assistierende Technologie ersetzen. Aber da ist das so, wir können… Also es gibt mehr Kontext. So eine Liste kann für Screenreader oder andere assistierende Technologien sagen, wie viele Elemente kommen in dieser Liste vor? Damit ich da ein bisschen so den Kontext habe, was so auf mich zukommt zum Beispiel. Das ist der Vorteil von Listen. Und dann gibt es auch zum Beispiel eine Definition List… oder Description List? Ich verwechsele immer, das ist Description List, der dl. Und das ist zum Beispiel, da kann ich… das ist so wie ein… Also das ist ein dl und da drin ist ein dt, da definiere ich so ein Wort und dann mit dd-Tag, der direkt danach folgt, kann ich sagen, was dieses Wort bedeutet in dem Kontext. Also das kann ich auch für einige Kontexte so, die gruppierte Informationen zum Beispiel verwenden. Es gibt dafür so… Das ist irgendwie besser, als wenn ich nur Text so beschreibe.

Lucas Dohmen: Ich glaube, wenn ich mich nicht ganz irre, hieß DL früher Definition List und irgendwann wurde es undefiniert, dass es Description List heißt, weil das ein bisschen allgemeiner ist, weil es nicht immer unbedingt Definitionen sein müssen, sondern manchmal auch einfach Beschreibungen. Aber ganz sicher bin ich mir nicht. Und wo wir gerade bei denen sind, bei diesen DLs, ich habe oft diese Situation gehabt, dass ich die gerne benutzt hätte. Also beispielsweise hatte ich eine Ferienhaus Seite und es gibt ein Baujahr und eine Anzahl von Personen und so weiter. Und das gibt es ja für jedes Haus und dann steht dann halt, wie das beschrieben ist. Dafür würde sich die ja total anbieten, aber es ist mir immer schwer gefallen die zu stylen, weil dann in dieser Definition List immer abwechselnd die dts und die dds kommen und keinen Rahmen drumherum haben. Hast du da einen Tipp für mich, was ich da tun kann, um sowas zu…?

Joy Heron: Ja, also das habe ich auch… Also meine erste Variante von dieser responsibleweb.app Webseite habe ich auch sowas irgendwie gesagt: ‚Ach ich finde das doof, dass es manchmal schwierig ist zu stylen, weil man darf irgendwie nicht so verschachtelte Divs innerhalb von der Defintion List setzten.‘ Und jemand, sehr nett, hat mich darauf hingewiesen, dass tatsächlich darf man das aktuell. Also in neueren Browsern ist das jetzt ein Teil von der aktuellen HTML-Spec, dass innerhalb von einem DD man wirklich so ein Div setzen kann, ohne die DTs und die DD-Elementen zu wrappen, dass man das zum Beispiel so mit Flexbox oder so ein bisschen anders stylen könnte. Und das fand ich gut und da haben wir das auch getestet, nämlich es ist auch so, dass ältere Browser, da muss man das testen natürlich. Aber zum Beispiel der IE11, der kommt so mit diesem Div auch klar. Also das ist halt nicht Teil des Specs zu dem Zeitpunkt, aber die älteren Browser haben das auch erlaubt. Insofern ist das etwas, was man muss das einfach in allen Browsern testen, die relevant sind, aber das ist jetzt so, dass wir das tun können, dass wir so ein DD, also ein DL-Element und dann die eigentlichen Begriffe jeweils so in ein div-Tag Wrapper setzen können, damit wenn wir das für das Styling später benötigen.

Lucas Dohmen: Gut. Ein ganz wichtiges Thema in accessiblity und allgemein in Web ist auch immer Formulare. Welche Dinge muss ich denn in meinen Formularen beachten?

Joy Heron: Ja, also bei Formularen ist das so, man sollte auf jeden Fall das HTML-Label-Element verwenden für ein Input Feld und man sollte dieses Label halt, es gibt so Label… Es gibt so ein for… Also Label for eine ID. Also dann kann man das ID von dem Input-Feld mitverbinden. Das sollte man auf jeden Fall tun. Also quasi ein Label für jedes Input-Feld verwenden und das möglichst mit dem richtigen Input-Feld verbinden. Weil wenn man so mit einem Screenreader dadurch geht und einfach auf das Input-Feld klickt, was das tut, ist wenn man das vorgelesen bekommen würde zum Beispiel, würde dieses Input-Feld dann nicht einfach Input-text heißen, sondern zum Beispiel name-Input-text. Damit ich weiß, dass ich so einen Namen an der Stelle angeben muss. Und das ist sehr, sehr wichtig, weil ansonsten ist halt so, wenn du nur so dir jemand sagt: Füge irgendwelchen Text hier ein. Dann möchtest du das tun, aber was ist das für ein Text? Also ist das irgendwie… Ja, klar, dass wir das tun sollen. Es ist auch wichtig, dass wir so den Placeholder für die Input-Felder nicht dafür verwenden. Also einige Leute denken sie seien schlau oder es gibt irgendwelche Designvorschläge, die sagen: Also es ist so total langweilig, dass der… Also im Standard HTML ist das Label immer vor dem Input-Feld. Immer. Es gibt das Label, das sagt dir was das ist und dann kommt dein Input-Feld direkt danach in der Regel oder eigentlich direkt da drunter, wenn man ein gutes Form-Design macht. Und dann der Placeholder in dem Input-Feld ist zum Beispiel dafür gedacht, dass man so ein Beispiel sagen kann, was man da eingeben kann. Zum Beispiel der Label wäre name und der Input-Feld hätte den Placeholder John Smith. Also was, das ich ungefähr weiß, wie das auszusehen hat. Und es ist sehr wichtig, also nicht nur für zum Beispiel Screenreader-Benutzer an der Stelle, dass man die Formularfelder so implementiert, sondern auch für Menschen, die… wie heißt das nochmal? Also die Menschen, die schnell den Kontext verlieren können, wenn sie ein Formular ausfüllen. Es gibt einige Menschen, die so ein bisschen kognitiv beschränkt sind und wenn sie so ein langes Formular ausfüllen müssen, ist das so, sie könnten auf ein Input-Feld klicken und manchmal, also einige Entwickler kommen auf die Idee, dass sie das Placeholder verwenden für das Label. Und die klicken in dem Feld und dann vergessen sie was davorgestanden hat. Also wenn dieses Label name plötzlich verschwindet, dann wissen sie nicht mehr: Was tue ich hier an dieser Stelle? Also das sollten wir nicht… für solche Benutzer, wir sollten Rücksicht auf sie nehmen. Es gibt keinen guten Grund da das Label verschwinden zu lassen. Wir sollten denen diese Information weiterhin als Hilfe einfach da stehen lassen. Punkt. Es gibt wirklich keinen Grund so mit diesen Muster Label, Input-Feld, Label, Input-Feld, Label, Input-Feld, es gibt keinen Grund da davon wegzugehen. Vor allem, weil es sehr wichtig ist, dass… Also es gibt so viele so Service und so weiter, wo alle möglichen Menschen so dieses Formular ausfüllen müssen. Zum Beispiel, wenn wir so überlegen irgendwie, so diese Impf Registrierungen oder so. Also das ist so vielleicht ein, ich weiß nicht, das ist ein gutes Beispiel vielleicht. Also wir sollten sicherstellen, dass jeder Benutzer, der da draufkommt, sollte dieses Formular ausfüllen können. Jeder Benutzer. Und da sollten wir einfach die etablierten Muster verwenden. Punkt. Also ich finde da sollten wir nicht so wild, so anders stylen und so fort. Also da nicht… auch zum Beispiel dieses Design von material-Design, die hatten auch Probleme. Die haben diesen Rand rundum das Label, also rundum das Input-Feld entfernt, weil sie dachten das sei schöner. Die haben rausgefunden, dass Benutzer nicht klarkommen, weil sie das nicht als Input-Feld erkennen. Und dann haben sie in späterer Version das irgendwie zurückgedreht. Also wir sollten nicht zu wild mit unseren Designvorstellungen da rumgehen, wir sollten einfach so etablierte Muster weiterverwenden.

Lucas Dohmen: Ja, definitiv. Ich meine es gilt ja auch ganz unabhängig von Screenreader auch für so Sachen wie Links. Viele sind ja auch sehr kreativ was ihre Links angeht, aber etwas blau, in einen beliebigen Blauton ist und unterstrichen ist, das erkennt halt jeder Mensch als Link.

Joy Heron: Ja.

Lucas Dohmen: Aber wenn es etwas ganz anderes ist, ist es manchmal gar nicht mehr so leicht zu erkennen, auch jetzt für mich, dass das jetzt ein Link ist.

Joy Heron: Genau.

Lucas Dohmen: Und ich finde auch das mit diesen Placeholdern, das stört mich manchmal auch schon in den Formularen. Es ist ja manchmal so: Erst der Vorname, dann der Nachname. Und manchmal andersrum. Und dann habe ich es ausgefüllt, habe ich das jetzt richtigrum ausgefüllt? Dann muss ich in das Feld reingehen, das ausschneiden, gucken, was stand da vorher, wieder einfügen. Also da bin ich auch schon genervt von, wenn ich das machen muss.

Joy Heron: Ja und das ist eben so ein Punkt. Also ich finde, wenn man diese… Das ist ein großer Punkt für mich: Wenn wir die accessibility von der Seite verbessern, da erhöhen wir immer die Benutzbarkeit von der Seite. Immer. Dann lernt man einfach da so mehr darüber, wie navigiere ich innerhalb von dieser Seite? Und wie kann ich zum Beispiel… da dieses Navigationsthema mit accessibility, da kann ich sehr viele so Ideen auch rüberbringen für das mobile-Seiten zum Beispiel. Weil auf mobile ist das auch so, ich habe auch diesen Fall, also dass ich nicht alles auf einmal auf dem Bildschirm sehe, sondern dass ich irgendwie durch die Anwendung navigieren muss. Und zum Beispiel, wenn ich an einer Stelle in der Anwendung so, eine Stelle in der Anwendung bin und an dem Zeitpunkt im nächsten Schritt so irgendwo das hin navigieren muss, dann kann ich einen Link auch so mit diesem Hash… Ne, dieses Anchor-Links, so nennt man sie, oder?

Lucas Dohmen: Ja!

Joy Heron: Wenn ich halt… Ich kann zu anderen Elementen in meiner Webanwendung verlinken mit so diesen… ja, genau. Und dann kann ich das auch, also das hilft der accessiblity so von der Seite, aber das verbessert auch das responsive Verhalten von der Seite an der Stelle.

Lucas Dohmen: Sehr cool! Es gibt noch ein paar andere Tipps auf der Seite, aber ich würde gerne noch eine Sache mit dir besprechen und das ist das Thema, was man auch manchmal mit Accordions löst, was man auf verschiedene Art und Weisen lösen kann. Nämlich das Problem: Ich habe auf einer Webseite einfach viel Content und ich möchte jetzt Teile davon vielleicht ausblenden, weil die optional sind oder weil ich die nur bei Interesse anklicken möchte. Und das gilt sowohl für Benutzer, die sehen können, als auch für die, die nicht sehen können, möchte ich ja auch ausblenden können. Wie kriege ich das so hin, dass das für beide Gruppen funktioniert?

Joy Heron: Ja, das kann ich gerne erzählen. Also ich habe, also für eine neue Anwendung, die ich gebaut habe mit dem Jan Stępień, das heißt spacy, da habe ich das HTML-details Element verwendet. Das ist ein Element, was das eigentlich von… Also eigentlich anbietet, ich habe dann ein Details-Element und dann da ein Summary drin und per Default ist das eingeklappt, außer wenn ich so ein open-Attribut setzte. Und dann hat das quasi so ein Accordion, was von HTML so ausgeliefert wird, ich muss nichts tun. Funktioniert. Das habe ich verwendet, das fand ich sehr gut, dass es das jetzt gibt. Dass man das einfach für moderne Browser verwenden kann. Was es auch geben kann ist, also wir müssen… dass ich so ein Custom-Element nicht in jeden Projekt schreiben müsste. Dass man eben so einfach so einen Button baut, der so einen Bereich ein und ausklappt. Und einen Fehler, den ich schon gesehen habe, war dieses aria-expanded Attribut. Also aria-expanded ist ein Attribut, was ich so an einen Button packen kann, um das Button zu sagen, welcher Zustand hat der Inhalt-Bereich aktuell? Ist der eingeklappt oder ausgeklappt? Und was das tut ist, dass es…Ja, genau. Also was es tut, dass es irgendwie diesen Button diesen Kontext gibt, damit ein Screenreader weiß… Also der Screenreader würde das dann vorlesen als so Toggle-Button collapsed oder expanded und so weiter und so fort. Und der Fehler, den ich gesehen habe, ist, dass an einigen Stellen, jemand hat so ein Toggle gebaut, der das getan hat, aber er hat das Attribut an den Inhalt gesetzt und nicht an den Button. Und das ist an der Stelle nicht richtig, weil das Attribut ist wirklich so ein Attribut von dem Button und das andere muss ich dann selber bauen. Das ist eigentlich… da muss ich dieses Verhalten wieder, wie so ein Toggle-Button funktioniert und was es tut, das muss ich selber mit JavaScript bauen. Da habe ich auf der responsibleweb.app so mein Custom-Element, den ich oft verwende an der Stelle, also auch die JavaScript Implementierung davon gemacht, da kann man schauen. Aber dieses Verhalten muss ich dann an der Stelle selber bauen. Deswegen habe ich mich gefreut, als ich gemerkt habe, dass dieses Details-Element eigentlich tut was ich möchte, weil das bedeutet das ich kein JavaScript brauche, damit dieses Accordion funktioniert. Und das ist auch der Punkt, also wenn ich das baue, mache ich das auch mit progressive enhancement, das heißt, wenn JavaScript nicht enabled ist aus irgendwelchen Gründen oder für ältere Devices, wo ich einfach… Ja genau, dann ist das per Default ausgeklappt und ich klappe es erst ein, wenn JavaScript tatsächlich aktiviert ist. Das ist zum Beispiel mit der Webseite selber, dieses responsibleweb.app, da verwende ich neueres JavaScript Syntax tatsächlich und da auf meinem Android Browser, da habe ich irgendwie klassische, also ES6 Syntax verwendet. Auf meinem Android Browser, wo ich das getestet habe, habe ich gemerkt, das JavaScript funktioniert nicht. Also wenn bei diesen Table of Contents bei dieser Webseite, also auf mobile habe ich das eingeklappt und einklappbar/ausklappbar gemacht. Aber auf meinem Android Handy, da funktioniert JavaScript nicht, aber das ist per Default ausgeklappt und der Benutzer merkt nicht, dass irgendetwas da schiefgegangen ist. Weil das heißt, dass es einfach ausgeklappt ist. Und da habe ich mich gefreut.

Lucas Dohmen: Ja, sehr cool! Gut Joy, dann sage ich mal alle Hörerinnen und Hörer, die das weiter interessiert sollten auf jeden Fall weiter auf responsibleweb.app mal draufgehen und dann auch noch ein paar weitere Tipps sich anschauen. Wir packen den Link natürlich auch noch in die Shownotes und dann danke ich dir auf jeden Fall für diese ausführliche Erklärung. Und den Hörerinnen und Hörern sage ich mal: Bis zum nächsten Mal! Ciao!

Joy Heron: Tschüss!