Wie sozial ist das Netz wirklich? Technikwürze 42

Barrierefreiheit zwei Punkt null. Wie sozial ist das Netz wirklich? Herzlich willkommen zur Technikwürze Nummer zweiundvierzig vom, was haben wir heute? Den sechszehnten zehnten zweitausendundsechs.

Der Kommentar.

Webschaffende in Agenturen, Unternehmen und Behörden haben es wirklich nicht leicht. Ständig machen neue Buzzwörter die Runde und ständig muss man seine Webangebote anpassen, damit die buzzwordkompatibel bleiben. Zu den am häufigsten diskutierten Trends und Themen der letzten Zeit gehören Web 2.0 und Barrierefreiheit, wahrscheinlich auch Barrierefreiheit 2.0. Dabei werden diese Themen allzu gerne auf die dahinterstehende Technik reduziert.

Vergessen wird, dass es bei den Themen letztendlich um die Menschen geht. Menschen, die zwar alles nutzen, denen die Technik dahinter aber herzlich egal ist. Die Nutzer wollen Inhalte und Funktionen. Die verwendeten Techniken sind eigentlich nur 'n Vehikel, um diese zu transportieren. Der Versuch der Begriffsdefinition Web 2.0. Ebenfalls gemein ist beiden Themen, dass weitestgehend Uneinigkeit darüber herrscht, was sie denn nun wirklich bedeuten.

Web 2.0 ist, wenn du dich statt in der Karaokebar bei YouTube gleich weltweit zum Affen machst. Wenn du sogar für deine Lieblingsdönerbude eine Google Map anlegst oder wenn Yahoo deinen Bürostuhl bezahlt. Der Versuch einer Begriffsdefinition. Was ist Barrierefreiheit? Barrierefreiheit ist auch so ein Wort, das man zurzeit in allen möglichen Pressemitteilungen und Fachartikeln findet. Auch dieser Begriff wird oft für Sachverhalte eingesetzt, die nicht seiner ursprünglichen Bedeutung entsprechen.

Der Begriff Barrierefreiheit kommt ursprünglich aus der Behindertenbewegung und da sollte er auch bleiben. Er bezeichnet bestimmte Qualitäten gestalterischer Lebensbereiche, wodurch diese Menschen mit Behinderung nutzbar sind.

Barrierefrei sind technische Gebrauchsgegenstände, Systeme der Informationsverarbeitung, akustische und visuelle Informationsquellen und Kommunikationseinrichtungen, wenn sie für behinderte Menschen in der allgemeinen üblichen Weise ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe zugänglich und nutzbar sind.

Paragraph vier BGG. Näheres dazu bei behindertenbeauftragte Punkt de. Auch der Begriff der Behinderung ist klar definiert, auch wenn mindestens zweimal. Die defizitorientierte oder die soziologische Sichtweise. Weil aber genau hier ein regelrechtes Minenfeld anfängt und weil diese Diskussion den durchschnittlichen Webentwickler nicht im Mindestens interessiert, lassen wir es damit begnügen und stellen fest: Behinderung ist die mangelnde Fähigkeit, mit schlechtem Design umgehen zu können.

Was ist Barrierefreiheit nicht? Keine Behinderung und schon gar nicht im rechtlichen Sinne sind dagegen:

Ich will das aber so und das hab ich schon immer so gemacht.

Barrierefreiheit bedeutet, Vorkehrungen für Fälle zu treffen, in denen der Nutzer bestimmte Eigenschaften nicht ändern kann. Fälle, in denen der Nutzer bestimmte Dinge ändern kann, aber nicht will, stellen keine Barriere dar. Diesen Sachverhalt nennt man nicht Behinderung, sondern Starrsinn. Und dafür gibt es noch keine passende W3C-Empfehlung.

Das tut's aber nicht in ungeeigneter User Agent wie Handy, Netscape 4 oder Küchenwecker.

Medienunabhängigkeit ist ein wichtiges Ziel barrierefreier Webangebote. Zur Verdeutlichung wird neben den üblichen Screenreadern oft das stark vereinfachende Beispiel der Ausgabe und Bedienung auf mobilen Endgeräten herangezogen. Dass ein barrierefreies Webangebot auch meist mehr schlecht als recht in einem mobilen Kontext funktionieren kann, ist eher zufälliges Nebenprodukt, ganz sicher aber nicht Ziel und Kern. Dazu sind die Nutzungsszenarien einfach zu unterschiedlich.

Handbücher les ich grundsätzlich nicht.

Wir bewegen uns in einem komplexen Medium. Der Versuch, Inhalte und Funktionen über Gebühr zu vereinfachen, führt oft dazu, dass lediglich optische Komplexität gegen strukturelle Komplexität ausgetauscht wird. Wenn Sie eine komplexe Anwendung haben, dann sollten Sie nicht so tun, als wäre diese ganz einfach. Auch von den Nutzern kann erwartet werden, dass sie sich zumindest mit den grundlegenden Funktionen Konvention des Webs vertraut machen.

Wer sich um 20 Uhr vor das Internet setzt und wartet, dass die Tagesschau anfängt, ist eventuell im falschen Medium. Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus bräuchte, sagte Ken Olsen 1977. Ein weiteres Zitat. Der Zuschauer will einfach nur unterhalten werden. Die Fernbedienung bietet genug Interaktionsmöglichkeiten, sagt du Helmut Thoma 2006. Mein Rechner ist noch auf dem Stand von 1999.

Diesem Typ Nutzer sollte man gesagt werden, dass er mit einem seit 1999 nicht mehr aktualisiertem System primär ein Sicherheitsrisiko für sich und andere darstellt. Auch von einem Screenreader oder anderen assistiver Software, die im ähnlichen Zeitraum nicht mehr aktualisiert wurde, kann man nicht erwarten, dass sie mit den neuen Möglichkeiten des Webs auch nur ansatzweise zurechtkommen. Ähnliches gilt sinngemäß für Richtlinien, die seit 1999 nicht mehr aktualisiert wurden.

Let's be honest, Screenreader are the Netscape 4 of assistive technologies, sagte Bruce Lawson. Barrierefreiheit gleich Search Engine Optimization. Auch immer wieder gern gehört: Barrierefreiheit ist gut für Suchmaschinen. Begründet wird es oft damit, dass der größte Nutzer des Webs schließlich auch blind sei, der Google Bot. Dumm nur, dass die meisten Nutzer mit Behinderung eben nicht blind sind.

Die Reduzierung auf die rein technischen Aspekte des Zugangs ist eine unzulängliche Vereinfachung und sie birgt die Gefahr, dass ein Suchmaschinenoptimierer dem Kunden für wenig Geld mehr Leistung, sprich ein höheres Ranking, mit weniger Aufwand verspricht und auch liefern wird. Und damit zum eigentlichen Problem: Was muss passieren, damit Menschen mit Behinderung von den neuen Möglichkeiten des Netzes profitieren können?

Inwieweit spielt das Thema soziale Benachteiligung, digitale Spaltung, eine Rolle in der Diskussion um Barrierefreiheit? Wie sieht die weitere technische Entwicklung aus? Wird es Browser und Hilfsmittel geben, die Inhalte und Funktionen quasi von selbst zugänglich machen können? Der Praxisteil: Was geht und was nicht geht. Schauen wir uns doch mal ein paar typische Funktionen von modernen webbasierten Anwendungen an. Aus dem statischen Medium wird ein dynamisches Echtzeitmedium.

Im Beispiel die Einfach-für-alles-Live-Suche. Aus dem passiven Einbahnstraßenmedium wird ein aktives, kollaboratives Werkzeug. Einfaches Beispiel ist zum Beispiel Flickr, ein komplexes Beispiel Basecamp. Im Web werden die Grenzen zwischen den einzelnen Anbietern aufgehoben. Beispiele APIs, Mashups, Microformats. Die Grenzen zwischen dem lokalen Desktop und dem Web da draußen verschwimmen. Lokale Anwendungen werden webifiziert. Beispiele sind iTunes und Excel 2007.

Onlineanwendungen bilden klassische Desktopfunktionen nach. Beispiele sind Zoho, Google Office, Live Clipboard und dotMac. Typisch für alle genannten Beispiele ist ein Mehr an Dynamik. Dynamik, in denen die Richtlinien und Verordnungen zur Barrierefreiheit nicht so vorgesehen war oder sogar ausgeschlossen ist. Bei einfachen Beispielen dynamischer Funktionen lassen sich die Richtlinien noch ohne Weiteres erfüllen.

Wenn man JavaScript abschaltet, dann bleibt bei der Livesuche bei Einfach für alle eine ganz normale Suche übrig. Mit etwas weniger Komfort zugegeben, ohne Verbesserungsvorschläge, aber funktional. Die Forderung der BITV lauten in sechs Punkt eins: Es muss sichergestellt sein, dass mittels Markup-Sprache geschaffene Dokumente verwendbar sind, wenn die zugeordneten Stylesheets deaktiviert sind.

Des Weiteren steht in sechs Punkt zwei: Es muss sichergestellt sein, dass Äquivalente für dynamische Inhalte aktualisiert werden, wenn sich der dynamische Inhalt auch ändert. Damit sind die Forderungen der BITV zumindest auf dem Papier erfüllt. Übrigens sind diese Bedingungen der ersten Priorität, also Pflichtprogramm für alle, meine lieben Freunde. Überraschung, es geht. Hm, oder geht's doch nicht?

Diese Vorgehensweise entspricht dem Ansatz des Progressive Enhancement, der schrittweisen Verbesserung, der Graceful Integration und des Unobstrusive Scripting. Man baut eine klassische Webapplikation, die bei jeder Interaktion des Nutzers einen Rundweg zum Server einlegt und ein statisches Resultat der Interaktion in Form einer kompletten neuen HTML-Seite zurückliefert. Damit bekommt man eine Webanwendung, die auf allem läuft, was krudes HTML verarbeiten kann.

Im nächsten Schritt fängt man diese Interaktion per Script ab und tauscht die Daten mit dem Server per XML-HTTP-Request aus. Dieser schickt dann nur ein Codefragment zurück, das im Übrigen nicht XML sein muss, sondern auch übliches, handelsübliches HTML sein kann. Dieses Fragment wird dann per DOM-Scripting an die Stelle der manipulierten Daten eingesetzt. Nun rufen alle hurra, weil die Anwendung mit und ohne JavaScript funktioniert und damit barrierefrei sein muss. Sorry, falsch.

Wenn Screenreader, Lupenprogramme und ähnliche grundsätzlich kein JavaScript unterstützen würden, dann wäre dieser Ansatz in Ordnung. Sie tun es aber und in den aktuellen Versionen sogar ziemlich intensiv. Hilfsmittel setzen immer auf Browser auf und im Regelfall ist dies der Marktführer in der Werkseinstellung.

Von diesem Browser bekommen die Hilfsmittel natürlich auch Informationen durchgereicht, dass sich in der Seite oder der Anwendung etwas geändert hat und sie versuchen, das Beste daraus zu machen. Man könnte nun eine Screenreader-Nutzer darauf hinweisen, dass sie besser JavaScript abschalten sollten. Aber wie realistisch ist das? Hilfsmittel haben ja gerade deswegen die Fähigkeit, JavaScript zu verarbeiten, weil ansonsten noch größere Teile des Webs nicht mehr zugänglich wären.

Screenreader lesen das vor, was auf dem Monitor steht. Wie das dahin kommt, ist dem Programm völlig egal. Moderne Hilfsmittel verstehen sogar die verpönten onMouseOver und onClick Events und machen diese und die Ergebnisse per Tastatur zugänglich. Eingebaut wurden diese Fähigkeiten offensichtlich, um mit dem Code zurechtzukommen, wie er von Dreamweaver und Co. Generiert wird. Probleme haben die Hilfsmittel jedoch mit modernen Formaten des DOM Scripting und Ajax.

Besonders, wenn die Inhalte ausgetauscht werden, die in der linearen Abfolge hinter dem gegenwärtigen Punkt des Nutzers liegen. Die Probleme liegen also nicht in den beiden Szenarien JavaScript an und JavaScript aus, sondern genau dazwischen. JavaScript wird interpretiert, aber nur unvollständig oder fehlerhaft. Erschwerend kommt hinzu: Was ist, wenn es prinzipiell nicht ohne Dynamik geht? Was ist, wenn bei deaktiviertem JavaScript eine weiße Seite übrig bleibt?

Die Alternative zu Google Office und Co. ist der Doppelklick auf Excel im Programmordner. Der Anwender kostet dieser Doppelklick aber fünfhundertfünfundsiebzig Euro. Wohingegen die meisten Webangebote kostenlos sind. Das Beispiel der zurzeit wie Pilze aus dem Boden schießenden webbasierten Office-Anwendungen zeigt es überdeutlich. Selbst wenn die Richtlinien statische Alternativen für dynamische Webinhalte verlangen, manchmal geht es einfach nicht.

Die wirklich spannende Aufgabe ist es also, die direkte Zugänglichkeit dieser Applikation für die Hilfsmittel von Menschen mit Behinderung herzustellen. Was soll das Hilfsmittel denn machen? Wie soll der Screenreader sich verhalten? Welche Information soll die Anwendung liefern und in welcher Form? Soll er piepsen und sagen: "Mm, es hat sich was geändert.

Bitte drücken Sie OK, um zur geänderten Stelle zu gehen." Wenn sich, um beim obigen Beispiel zu bleiben, eine Zelle in der Tabellenkalkulation geändert hat, ist dies wahrscheinlich noch vertretbar. Was ist aber, wenn sich mehrere Zellen geändert haben? Und vor allem, warum werden diese Ansprüche an eine webbasierte Applikation gestellt, wenn das Pendant auf dem Desktop diese Funktion nicht mitbringt?

Eine periodische Information des Nutzers über aktuelle Änderungen macht ebenso wenig Sinn, wenn die Änderungen auch ohne Zutun des Nutzers stattfinden. Sonst laufen wir Gefahr, dass der Nutzer die Benachrichtigung unterbindet und dann wirklich alle wichtigen Durchsagen verpasst. Hier fehlt das Input vom tatsächlichen Nutzern von Hilfsmitteln. Sonst operieren Webentwickler weiterhin im luftleeren Raum.

Und ebenso wichtig: Die Hersteller von Hilfsmittel müssen endlich den Zustand beenden, dass ihre Produkte mit Spaghetti-Code aus dem vergangenen Jahrtausend besser zurechtkommen als mit modernen Techniken der Webentwicklung. Achtung, provokante These: Hilfsmittel brauchen keine Hilfen. Ein Hilfsmittel wie ein Screenreader ist eigentlich gar kein Hilfsmittel, sondern die natürliche Schnittstelle des blindenden oder stark sehbehinderten Nutzers zum Computer.

Bei einer grafischen Benutzeroberfläche käme ja auch niemand auf die Idee, von einem Hilfsmittel zu sprechen. Und trotzdem behandeln wir den akustischen Zugang zum Computer immer noch so, als wäre er etwas ganz Besonderes. Wenn Sie einem Blinden helfen wollen, mähen Sie ihm den Rasen in seinem Vorgarten. Das hilft bestimmt. Ein Blick in die noch junge Geschichte des Web zeigt, dass Fortschritte in Richtung Barrierefreiheit immer zuerst auf der Seite der Anbieter stattfinden.

Die Hilfsmittel zogen und ziehen erst später nach. Das war bei Flash 6 der Fall, dessen Accessibility Features ab Windows Ice 4.1 und Jaws 4.5 unterstützt werden. Das war bei alternativen Browsern wie Firefox der Fall, der auch erst mit der neuesten Screenreader-Generation wirklich brauchbar ist. Ja, das war sogar bei HTML4 der Fall, wobei zum Beispiel das INS um DEL bis heute nicht von Jaws verstanden werden. Und so wird es auch bei Ajax und Co. sein.

In der Zwischenzeit kann man nur um Geduld bitten und gemeinsam mit Nutzern von Hilfsmitteln nach besseren Lösungen suchen. Doch, die Rettung naht. Die Accessibility Task Force des Webstandards Project arbeitet an einer ganzen Reihe von Testszenarien, in denen das Verhalten von Hilfsmittel in Bezug auf modernes Scripting geklärt werden sollen. Bis dahin muss man sich das Wissen aus den Weblogs und anderen Veröffentlichungen leider selbst zusammensuchen.

Erste Ergebnisse lassen sich zum Beispiel im Artikel Ajax and Screenreaders: When can it work? von James Edwards nachlesen. Wobei, die Resultate sind leider vorsichtig ausgedrückt eher gemischt. Die Aussichten stehen aber nicht schlecht. Für viele der bisher wirklich problematischen Dinge liegen aktuelle Lösungen vor oder man steht unmittelbar vor der Lösung der Probleme. So haben in den letzten Wochen und Monaten Webentwickler wie Christian Heilmann, Aral Balkan et al.

Methoden entwickelt, damit sich Flash-Filme besser als bisher an die geänderten Nutzereinstellungen anpassen. So gibt es mittlerweile verlässliche Methoden, um herauszufinden, ob sich im Browser die Schriftgerüsse geändert hat, ob der Benutzer eigene Farbschemata eingestellt hat und sogar, ob er einen Screenreader benutzt. Zukunftsaussichten, Hilfsmittel gegen eingebaute Barrierefreiheit.

Eine Lösung für die diskutierten Probleme könnte in Zukunft das sein, was Peter Korn von Sun Access by Contract nennt. Hilfsmittel verstehen sich traditionell als Lösungen, die auf ein vorhandenes System aufsetzen und Funktionen nachrüsten, die das Host-System nicht von sich aus bietet. Nicht nur alternative Betriebssysteme gehen mittlerweile den umgekehrten Weg.

Desktops wie Gnome und KDE, Solaris und sogar Mac OS zehne haben ab Werk Hilfsmittel wie Screenreader, Lupensoftware und vieles mehr an Bord und sind somit zugänglich out of the box. Verbindet man diese Bemühung der Open-Source-Community mit der gerade veröffentlichten Roadmap for Accessible Rich Internet Applications des W3C, so ergeben sich ungeahnte Möglichkeiten.

Das Dokument beschreibt, wie die bisher als problematisch gehandelten Techniken wie Ajax in Zukunft barrierefrei angewendet werden können. Weitere Dokumente beschreiben die Verknüpfung von Standardelementen der Bedienung und Navigation in Webanwendungen mit den Funktionen, die von Accessibility APIs der Betriebssysteme bereitgestellt werden. Bis das aber so weit ist, hilft nur der alte Ratschlag: Testen, testen, testen. Vielen Dank an Tomas Caspers.

Thomas hat diesen Beitrag zum Webkongress in Erlangen 2006 gehalten. Die Musik aus der Kategorie Trance war von Alienation, Clear to Heaven. News.

Usability und Design. Es dreht sich um das Benutzbarmachen von Erfahrungen. Tom Guarillo vom UX Mag schreibt: "It's exciting to see so much energetic interest in understanding user experiences and designing environments that lead to desired user and customer experiences." Das UX Mag und A List Apart beschäftigen sich mit User Experience und der Erschaffung angemessener Designs, die diese Erfahrungen unterstützen und fördern.

Auf der einen Seite stehen Studien über das Verlangen und Verhalten der Nutzer und möglichen Kunden, auf der anderen der Designprozess und vor allem die Umsetzung. Dazu gehören ebenso die Einhaltung gewisser Standards, seines Designrichtlinien oder Regeln für barrierefreie, zugängliche Websites. Die beiden Artikel "Experiencing Experience" und "Working with Others Accessibility and User Research" fassen diese interessanten Felder hervorragend zusammen.

Web 2.0 Definitionen, Gewinner und Verlierer. Eine einheitliche Definition für den Begriff "Web 2.0" zu finden, ist schwer. Als Grundlage für eigene Erklärungen kann die Zusammenfassung von Ian Delaney dienen. In dem Artikel nennt Delaney Web 2.0 Eigenschaften wie die Weisheit der Masse, Nutzerbeteiligung und permanenter Beta-Status. Eine Auflistung der Web 2.0 Gewinner und Verlierer gab uns in der vergangenen Woche Paul Scrivens.

Linktips.

Gänzlich unkommentiert wollen wir die Links in dieser Ausgabe nicht lassen. Themen sind Web 2.0, Design und Zugänglichkeit. Markus Stephan nennt in "Was macht einen guten Designer aus?" acht Eigenschaften eines erfolgreichen Designers. Eine Liste nützlicher Webtools für Schule oder Studium, die aber auch Lehrern und Administratoren in ihrer Arbeit unterstützen, hat Brian Benzinger auf solutionwatch.com erstellt.

In den beiden bisher veröffentlichten Artikeln "Back to School with the Class of Web 2.0" nennt er uns zum einen Tools, die ein Studium oder die tägliche Arbeit erleichtern können und befasst sich zweitens mit webbasierten Anwendungen, die Desktop-Programme ergänzen oder ersetzen können. In einem dritten Teil will er sich mit realen Beispielen für die Verwendung von Web 2.0 im Unterricht beschäftigen.

Mit einem ähnlichen Ansatz, der Entwicklung der Office-Anwendung, prägnant Office 2.0 genannt, befasst sich auch Alan Graham im O'Reilly Macdevcenter Blog. Als zuhörende Teilnehmer der Office 2.0 Konferenz in San Francisco hat er sich Gedanken über das Konzept des Office 2.0 gemacht.

Jack Picard nimmt sich im Beitrag "Be Accessible, Don't Meet Guidelines" der WCAG-Richtlinien an und klärt auf, dass das Erfüllen dieser Richtlinien eine Seite nicht automatisch zugänglich machen, sondern lediglich ein Anzeichen dafür ist, dass die Website vermutlich zugänglich ist. Christian Montoya gibt in "The Minimalist Backlash" Tipps für ein einfaches, aber nicht langweiliges Design. In einem weiteren fünfteiligen Artikel teilt er seine Erfahrung als Lehrer für Webdesign.

Musik präsentiert von Podsave Music Network. In meinem Blog auf max.de habe ich euch erzählt, was ich so tolles Neues an Ajax entdeckt habe und dass Ajax ja ganz toll ist. Dabei hatte ich einen Leser namens Dietmar, der meinte, dass das alles ja ziemlich alter Käse sei, was im Prinzip ja stimmt. Und er meinte, dass es aber doch noch was viel Besseres gibt, nämlich Flash. Das funktioniert überall, ist das beste Entwicklerwerkzeug für alle und das ist so was von knuffelig toll.

Seine These, die er aufgestellt hatte, war natürlich ziemlich gewagt, weil er sich gleichzeitig auf das Glatteis begeben hat, dass die Barrierefreiheit oder die Zugänglichkeit von Webseiten eigentlich, hm, vielleicht gar nicht so toll ist, weil es gibt ja Flash und Flash ist ja eh viel besser.

Weil ich so langsam das Gefühl hatte, dass der Dietmar nicht der Dietmar ist oder dass sich jemand da einen kleinen Scherz erlaubt hatte, hatte ich Dietmar eingeladen, auf max.de für Technikwürze etwas aufzunehmen. Er sollte die Skype-In-Telefonrufnummer anwählen, dort was hinterlassen, sodass ich das in Technikwürze zur Diskussion stelle. Da sich Dietmar nicht gemeldet hat, Hallo Dietmar oder wie du auch immer heißt, denke ich mal, dass sich das Thema erledigt hat.

Also Flash ist bei Weitem nicht das Stück Software, was einem, erlauben könnte, dass wir sagen, wir verzichten jetzt auf die Zugänglichkeit von Webseiten. Natürlich, Zugänglichkeit von Webseiten ist ein Muss, auch für Dietmar. Ihr hört jetzt noch aus dem Podsave Music Network My Little Radio. So heißt die Band, nicht der Song. Der Song heißt nämlich Walk Away. Ich bedanke mich fürs Zuhören bei Technikwürze und sage, wir hören uns nächste Woche Montag wieder.

Obgleich mir fällt noch was ein: Wenn ihr auch so Thesen aufstellen wollt wie Dieter, ruft mich doch an. Ich habe einen Anrufbeantworter eingerichtet, unsere Skype-Inrufnummer in Hannover. Da könnt ihr so gesagt, wenn ihr nur vor Ort zum Ortstarif anrufen. Das ist die null fünf elf einundzwanzig siebenundzwanzig dreihundert. Die null fünf elf einundzwanzig siebenundzwanzig dreihundert und hinterlasst uns eure Meinung.

Hat euch etwas nicht gefallen, wie zum Beispiel die Hintergrundmusik während meines Beitrages von, Tomas Caspers oder andere Sachen? Oder ihr habt Themenvorschläge oder ihr seid zum Beispiel auch Webentwickler und seid der Meinung: "Mensch, ich hab so was Knuffiges gemacht. Ich hab so einen tollen Artikel geschrieben, der ist so was von Sahne, der muss unbedingt zu allen anderen Usern über Technikwürze." Dann ruft mich einfach an, null fünf elf einundzwanzig siebenundzwanzig dreihundert.

Gern auch auditive Kommentare oder schriftliche an echo at technikwürze de. Nadja Müller und ich sagen, wie gesagt, danke fürs Zuhören und wir würden uns freuen, wenn ihr nächste Woche Montag wieder einschaltet, wenn es heißt, "Hier ist Technikwürze, euer Design- und Webstandards-Podcast". Bis dahin.

You don't know what you do to me, so I forgive you. I say it doesn't bother me, but I'm a liar. I smile until I drive away, that's when I realize. I'm never getting what I want, I'm wasting time. And now you're gone. So this is what it's like to be alone. I know that I will somehow come out of this mess alive. Afraid of what you're gonna say, I keep it inside. I turn around, you walk away, I almost try. The truth is I do care for you, I try and be there.

I watch you watch somebody else, this isn't fair. And now you're gone. So this is what it's like to be alone. I know that I will somehow come out of this mess alive. There's nothing that I'd rather do than sit and wonder if you need me too. But what I'm scared of most of all is there's no one around you quite like you. Just walk away, I'll be fine. I know that I will get over this in my own time. Just walk away, I believe. There's a road that will lead us to whoever we need. And now you're gone.

So this is what it's like to be alone. I know that I will somehow come out of this mess alive.

Und nicht vergessen: Ruft uns an. Null fünf elf, einundzwanzig, siebenundzwanzig, dreihundert.