Micro Blogging im eigenen Blog

In seinem aktuellen Artikel ›Untitled‹ schreibt Matthias Pfefferle darüber wie die Nutzung des eigenen Blogs für mehr als klassische Blogartikel™ sowohl die Blogs als auch die Feedreader verändert.

Im Sinne von micro Blogging, das der Nutzung von Twitter entspricht, werden immer öfter kurze Posts in Blogs veröffentlicht, die ein Bild, ein Zitat oder eben ein paar Sätze beinhalten. Diese kurzen Updates erscheinen ohne Titel, da der Inhalt für sich steht.

Alle Formen des Bloggens auf eine Plattform zu vereinen, und die Inhalte von dort aus in die unterschiedlichen Netzwerke zu verteilen, kann ich sehr gut verstehen. Die Möglichkeit nach Gedanken, Links und Zitaten in meinem Blog zu suchen ist mir sehr viel Wert. Für Fotos und Zitate habe ich das Vorgehen in meinem Blog getestet, es aktuell aber pausiert, da diese Art der Nutzung des eigenen Blogs meiner Ansicht nach einiger Einstellungen bedarf:

  • Die unterschiedlichen Veröffentlichungsarten würde ich durch Kategorien oder Post-Typen ordnen.
  • Längere Artikel und kurze Veröffentlichungen würde ich strukturell und visuell voneinander abheben.
  • Die kurzen Veröffentlichungen würde ich aus dem Feed nehmen, oder zumindest explizit einen Artikel-Feed anbieten.

Solche Grundentscheidungen helfen meiner Ansicht nach dabei das eigene Blog weiterhin attraktiv zu halten. Die Nutzer*innen bekommen dadurch die Möglichkeit sich gezielt darauf zu bewegen und finden sich in den unterschiedlichen Sparten gut zurecht.

Homebrew Website Club

Gestern fand der zweite Homebrew Website Club in Karlsruhe statt. Der Homebrew Website Club ist ein regelmäßiges Treffen von Personen, die leidenschaftlich dabei oder interessiert sind, ihre eigene Website zu konzipieren, designen, entwickeln und zu verbessern.

In diesem Sinne tauschten wir uns über die eigenen Webseiten, Arbeitsweisen und aktuelle Projekte aus. Wir sahen uns das ActivityPub-Plugin von Matthias an. Das Plugin erweitert WordPress durch das ActivityPub-Protokoll, wodurch das Blog beispielsweise mit Mastodon kommunizieren kann – neue Artikel werden dort publiziert und Reaktionen fließen zurück ins Blog.

Die Teilnehmer des Homebrew Website Club am 20.02.2019 in Karlsruhe

Falls Du vorhast bei einem der nächsten Treffen dabei zu sein, kannst Du Dir schon Mal die kommenden Termine eintragen:

  • 20.03.
  • 17.04.
  • 15.05.
  • 12.06.
  • 10.07.
  • 07.08.

Der Karlsruher Homebrew Website Club trifft sich jeweils um 18:30 Uhr im NUN Kulturraum, Gottesauer Straße 35, 76131 Karlsruhe.

Wie werden heute Webseiten entwickelt

Was die Entwicklung der Benutzeroberfläche von Webseiten angeht, ist eine Kontroverse sichtbar, die sich an der Schwerpunktsetzung von Kompetenzen und verwendeten Sprachen und Techniken entzündet. Wer auf Twitter ein paar Entwickler*innen folgt, sich Projektausschreibung oder Jobangebote durchliest, stößt sehr schnell auf die gewachsene Bedeutung von JavaScript und den darauf basierenden Bibliotheken. Anhand der Fragestellung zu vorausgesetzten Arbeitsweisen und damit einhergehenden Bewertungen entspannt sich ein Konflikt.

Chris Coyier von CSS-Tricks spricht in diesem Zusammenhang von »The Great Divide« und erkennt zwei unterschiedliche Schwerpunktsetzungen:

  • Auf der einen Seite sind Entwickler*innen deren Interessen, Verantwortlichkeiten und Können sich hauptsächlich auf JavaScript konzentriert.
  • Und auf der Anderen finden sich Entwickler*innen deren Interessen, Verantwortlichkeiten und Können sich auf andere Bereiche der Benutzeroberfläche wie HTML, CSS, Design, Interaktionen, Strukturen, Accessibility fokussiert.

Der Artikel »The Great Divide« auf CSS-Tricks lohnt sich auch deshalb zu lesen, da Chris Coyier einige wichtige Stimmen aufgreift, wodurch Breite und Bedeutung des Konflikts deutlich wird, und zur Schärfung des Begriffs ›Front-End Development‹ anregt.

Als ich vor ungefähr fünfzehn Jahren begann mich intensiver mit Design und Entwicklung von Benutzeroberflächen zu beschäftigen, fand ich bei Entwickler*innen um Jeffrey Zeldman mit dem Schwerpunkt auf Webstandards meine Inspiration. Aus diesem Grund widmete ich mich in erster Linie semantischem Markup (HTML) und validen Stylesheets, so dass alle Inhalte für Mensch und Maschine lesbar sind. Die Bedeutung von JavaScript war dem nachgeordnet und diente der Interaktivität und Anreicherung von Inhalt und Erlebnis auf der Webseite.

In diesem Sinne verstehe ich den Artikel »HTML, CSS and our vanishing industry entry points« von Rachel Andrew. Rachel Andrew führt aus, dass am Ende HTML und CSS vom Browser interpretiert werden, und dass es daher wichtig ist diese beiden Sprachen flüssig zu sprechen. Des Weiteren weist sie auf die Abstraktion hin, die durch die Betonung von JavaScript und die entsprechenden Bibliotheken, dem Entwickeln von Benutzeroberflächen hinzugefügt wird, wodurch der Einstieg in die Entwicklung von Webseiten erschwert wird.

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

That’s the real entry point here and yes, in 2019 they are going to have to move on quickly to the tools and techniques that will make them employable, if that is their aim. However those tools output HTML and CSS in the end. It is the bedrock of everything that we do, which makes the devaluing of those with real deep skills in those areas so much more baffling.

[…]

I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged. I have plenty of fight left in me to stand up against that.

Rachel Andrew: HTML, CSS and our vanishing industry entry points

Entwickler*innen wie Rachel Andrew sprechen sich daher auch für die Notwendigkeit aus, HTML, CSS und JavaScript in der Tiefe zu kennen und die Bibliotheken wie früher jQuery, Angular und heute React oder Vue bei bedarf zusätzlich zu lernen, dabei aber im Blick zu behalten, dass sich im Web ständig einiges ändert, und vielleicht schon morgen eine andere Bibliothek heiß gehandelt wird.

Ende letzten Jahres veröffentlichte Mandy Michael ein lesenswertes Plädoyer für die Bedeutung von HTML und CSS, in dem sie auch auf die Abwertung gegenüber Entwickler*innen, die ›nur HMTL und CSS schreiben‹, reagierte:

What I don’t understand is why it’s okay if you can “just write JS”, but somehow you’re not good enough if you “just write HTML and CSS”.

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

Mandy Michael, Is there any value in people who cannot write JavaScript?

Diesen Artikel habe ich vor Allem deswegen geschrieben, um darüber nachzudenken wie ich auf den Konflikt reagiere und um zu verstehen woraus sich meine Reaktionen speisen. Mir ist nun wieder bewusster, weshalb mich einige Aspekte automatisch erzeugten Markups stören und was mir an der Einfachheit gefällt Webseiten und Prototypen zu erstellen, und dabei die Benutzbarkeit derselben immer im Hinterkopf zu haben. Gleichzeitig möchte ich mich nicht auf meinem aktuellen Standpunkt ausruhen und mich darüber wundern wie schnell „die Jungen“ neue Techniken und Arbeitsweisen lernen, sondern mich weiterhin mit den Entwicklungen des Webs beschäftigen und neues lernen.

Da es in diesem Konflikt auch immer wieder um den Begriff Programmiersprache geht und die Frage auftaucht, ob Entwickler*innen, die HTML und CSS schreiben auch programmieren, möchte ich abschließend noch den Artikel »CSS is a Declarative, Domain-Specific Programming Language« von Lara Schenck empfehlen.

Homebrew Website Club in Karlsruhe

Am 23.01.2019 findet der erste Homebrew Website Club in Karlsruhe statt.

Matthias fragte Anfang Oktober auf Twitter ob es Interesse an einem solchen Treffen in Karlsruhe gebe. Da ich Mitte September endlich Webmentions integriert hatte, war mein Interesse groß, und so reagierte ich kurz nach Marc direkt, ein paar Weitere bekundeten im Laufe der Zeit Interesse. Nach einige Absprachen findet der erste HWC nun am Mittwoch 23. Januar um 18:30 Uhr im NUN Kaffeehaus statt.

Homebrew Website Club

Der Homebrew Website Club ist ein regelmäßiges Treffen von Personen, die leidenschaftlich dabei oder interessiert sind, ihre eigene Website zu konzipieren, designen, entwickeln und zu verbessern.

Matthias schreibt zu unserem Treffen:

Wir versuchen den HWC eher ungezwungen und frei zu gestalten und wollen den ersten Termin dazu nutzen, uns kennen zu lernen und den weiteren Ablauf zu besprechen.

Bisher war ich noch bei keinem IndieWeb-Treffen, und freue mich, dass sich das nun ändern wird.

Falls Du auch Interesse hast, komm vorbei oder gib Bescheid, wenn Du über weitere Termine informiert werden möchtest.

Homebrew Website Club am im NUN Kaffeehaus, Gottesauer Straße 35, 76131 Karlsruhe, DE.

Das dunkle Erscheinungsbild von macOS im Webdesign nutzen

Seit macOS 10.14 ist es möglich statt des klassisch hellen ein dunkles Erscheinungsbild zu wählen. Die Auswahl des Erscheinungsbilds hat systemweite Auswirkung, und verwandelt die Benutzeroberfläche des Mac in ein angenehm dunkles Farbspektrum. Nach einer kurzen Testphase gefiel mir die dunkle Ästhetik wesentlich besser und ich wechselte auch im Editor zu einem dunklen Theme.

macOS Systemeinstellungen, Allgemein

Während viele Programme die dunkle Ästhetik sehr gut umgesetzt haben, wirkten helle Webseiten, wie diese hier, sehr schnell wie ein Störkörper in der sonst dunkel gehaltenen Ästhetik. Aus diesem Grund nahm ich mir eben einen Moment Zeit um den kommenden Ausdruck für eine Media Query zu testen, um auch eine Webseite auf die Auswahl der Nutzerin reagieren zu lassen. Die Media Query, die dafür verantwortlich ist, liest sich folgendermaßen:

@media (prefers-color-scheme: dark) {
  /* dark mode styles */ 
}

Wird diese verwendet, lässt sich eine Webseite so designen, dass sie sowohl das helle wie das dunkle Erscheinungsbild unterstützt.

In diesem Codepen habe die Anwendung des dunklen Erscheinungsbildes auf eine Webseite schnell getestet. Bisher unterstützt nur Safari Technology Preview (ab Version 68) den Ausdruck prefers-color-scheme, der für ein solches Webdesign benötigt wird. Falls Du diesen Browser nicht installiert hast, siehst Du unter obigem Link die helle Version der Webseite, die dunkle sieht folgendermaßen aus:

Webdesign: Dunkles Erscheinungsbild (Dark Mode)

Zum direkten Vergleich, hier noch ein Bildschirmfoto der hellen Version:

Webdesign: Helles Erscheinungsbild (Light Mode)

Bis der Ausdruck in allen gängigen Browsern unterstützt wird, kommen nur weniger Nutzerinnen in den Genuss des dunklen Webdesigns. Im Sinne von Progressive Enhancement kann diese Technologie schon jetzt eingesetzt werden, so dass das Erlebnis einiger weniger Nutzerinnen schon jetzt verbessert wird, und andere zu einem späteren Zeitpunkt in den Genuss kommen werden.

Vor einigen Wochen las ich den Artikel Redesigning your product and website for dark mode von Andy Clarke, der noch auf einige weitere wichtige Aspekte eingeht. Die Entwickler-Dokumentation von Apple gibt ebenfalls nützliche Hinweise zum Design für das dunkle Erscheinungsbild.

Bürogemeinschaft in Karlsruhe

Bist Du auf der Suche nach einem Büroplatz in Karlsruhe? Ab Dezember ist bei uns im Büro 5&30 wieder ein Platz frei.

Büro 5&30

Das Büro 5&30 liegt in der Karlsruher Oststadt zwischen KIT und Altem Schlachthof. In den hellen Räumen im Erdgeschoss arbeiten Illustrator_innen, Grafiker_innen, Konzepter_innen und ein Webdesigner.

Seit 2011 ist das Büro 5&30 ein Ort an dem Selbstständige gut arbeiten können. Neben Phasen von Konzentration, lebt das Büro vom Austausch über und Anregung für die Arbeit und das Leben. Gerne auch bei einer Tasse Kaffee auf unserem Vorplatz.

Vorplatz des Büro 5&30

Wenn sich das für Dich interessant anhört, freue ich mich von Dir zu lesen.

Am Besten schreibst Du eine kurze Mail an mich über buero@5und30.de oder die Kontaktseite hier. Nachdem Du ein bisschen davon erzählt hast wer Du bist und was Du machst, erzähle ich Dir ein paar wissenswerte Dinge, und wir sehen ob Du und das Büro zusammenpassen.

Platz im Büro 5&30

Bist Du auf der Suche nach einem Büroplatz in Karlsruhe? Ab Juli ist bei uns im Büro 5&30 ein Platz frei.

Büro 5&30

Das Büro 5&30 liegt in der Karlsruher Oststadt zwischen KIT und Altem Schlachthof. In den hellen Räumen im Erdgeschoss arbeiten Illustratoren, Grafiker, Konzepter, Marketingfachleute und Webdesigner.

Seit 2011 ist das Büro 5&30 ein Ort an dem Selbstständige gut arbeiten können. Neben Phasen von Konzentration, lebt das Büro vom Austausch über und Anregung für die Arbeit und das Leben. Gerne auch bei einer Tasse Kaffee auf unserem Vorplatz.

Vorplatz des Büro 5&30

Wenn sich das für Dich interessant anhört, freue ich mich von Dir zu lesen.

Der freie Platz ist mittlerweile vergeben. Falls Du denkst es wäre dennoch gut wir würden uns mal kennenlernen, schreibe mir gern über die Infos auf der Kontaktseite.

ServiceWorker von Apple unterstützt

Webseiten werden ab jetzt auch auf Apple-Geräten zwischengespeichert, und stehen dann zur Verfügung wenn keine Verbindung zum Server hergestellt werden kann. Apple unterstützt ab iOS 11.3 und macOS 10.13.4 ServiceWorker!

Ab jetzt ist es auch im Apple-Umfeld möglich Progressive Web Apps (PWA) einzusetzen. Der Einsatz von PWA wird dadurch ermöglicht, dass zusätzlich zu ServiceWorker das Web App Manifest ab dieser Version von Safari (11.1) unterstützt wird.

Als Nutzer unterschiedlicher Apple-Geräte, und Angesichts deren Verbreitung, freue ich mich sehr darüber.

Beispiel eines ServiceWorker unter iOS 11.3

Wie ich auf meiner Seite ServiceWorker einsetze, habe ich in diesem ServiceWorker-Artikel vom 5. März beschrieben. Falls Du auf Deiner Seite ebenfalls von den Vorteilen – schnelleren Ladezeiten und offline-Verfügbarkeit – eines ServiceWorker profitieren möchtest, melde Dich gerne über das Kontaktformular oder per Mail bei mir.

Wenn ich es richtig sehe, fehlt nun noch die Implementierung in Edge, dann können wir, bezogen auf aktuelle Betriebssysteme und Browser, von einer guten Abdeckung ausgehen und plattformübergreifend PWA weitaus prominenter einsetzen.

Auf der Seite Is service worker ready? von Jake Archibald findest Du eine gute Übersicht zum aktuellen Stand der Implementierung von ServiceWorker in den unterschiedlichen Browsern.

Webseiten benutzbar machen

Laura Kalbag legt mit Accessibility for Everyone ein wunderbares Buch zu Barrierefreiheit vor, in dem sie sowohl grundlegende Überlegungen ausführt als auch konkrete Beispiele zur Verbesserung von Webseiten gibt.

In den sieben Kapiteln des kurzen Buches beleuchtet sie die Frage was Barrierefreiheit bedeutet. Welche konkreten Auswirkungen einige Beeinträchtigungen auf die Nutzung von Webseiten haben. Wie sich Barrierefreiheit im gesamten Entwicklungsprozess planen lässt. Darüber hinaus thematisiert sie den Zusammenhang von Inhalt und Design und die Verbindung von Barrierefreiheit und HTML. In den letzten beiden Kapiteln spricht sie über Tests und deren Auswertung und gibt einen kurzen Einblick in Gesetze und Richtlinien zur Barrierefreiheit.

In ihrem Buch folgt sie dem Konzept des Universal Design und spricht davon wie wichtig es ist davon auszugehen, dass Menschen auf unterschiedlichste Weise im Netz unterwegs sind. Der Zweite Schwerpunkt des Buches ist die Betonung auf den Beitrag aller Beteiligten am Entstehungsprozess einer Webseite zur Barrierefreiheit derselben.

»Making our sites accessible starts with the understanding that people access the web differently, and continues with every member of the team ensuring their output is inclusive«

Universal Design

Der Wikipedia-Artikel zu Universal Design beginnt mit dem Hinweis, dass es sich bei Universal Design um ein internationales Design-Konzept handelt, nach dem »Produkte, Geräte, Umgebungen und Systeme derart gestaltet« sind, »dass sie für so viele Menschen wie möglich ohne weitere Anpassung oder Spezialisierung nutzbar sind.«

Kalbach folgt in Ihrem Buch Ronald L. Mace, der Universal Design in der Architektur etabliert hat. Sie überträgt das Konzept auf Webseiten und formuliert es folgendermaßen:

»Web accessibility is the degree to which a website is usable by as many people as possible.«

Daraus folgt die Notwendigkeit Barrierefreiheit von Anfang zu bedenken, und nicht zu einem späteren Zeitpunkt im Entwicklungsprozess einer Webseite darauf zurück zu kommen. Wie bereits erwähnt ist es daher auch die Aufgabe von allen Beteiligten die Webseite auf eine Art zu designen, die von so vielen Menschen wie möglich ohne weitere Anpassung oder Spezialisierung nutzbar ist.

Aufmerksamkeit auf vier Aspekte helfen nach Kalbag dabei eine Webseite gemäß Universal Design zugänglich zu designen:

  • visuell: achte auf gute Sichtbarkeit.
  • auditiv: achte auf gute Hörbarkeit.
  • motorisch: achte auf die Bedienbarkeit der Interaktionen.
  • kognitiv: achte auf Verständlichkeit.

Bei der Ausführung dieser vier Aspekte wird deutlich wie eng Barrierefreiheit mit guter Bedienbarkeit zusammenhängen: »Good accessibility is good usability.« Eine Webseite, die dem Universal Design Konzept folgt, ist demnach für alle besser zu bedienen, und somit insgesamt ein besseres Produkt.

Konkrete Beispiele

Browser verwenden die vorhandene Struktur des HTML um die Inhalte entsprechend darzustellen und zugänglich zu machen. Webseiten deren HTML semantisch und gut strukturiert ist, sind demnach automatisch barrierearm und auf unterschiedliche Weise auslesbar. Kalbag empfiehlt daher die HTML-Spezifikation gut zu kennen, und die Elemente in ihrer vorgesehenen Funktion zu verwenden. Ein guter Seitenaufbau lässt sich einfach verbessern, während es beinahe unmöglich ist eine schlechte Struktur barrierefrei zu bekommen.

Im folgenden fasse ich ein paar ihrer konkreten Beispiele zusammen, die dazu beitragen im Entstehungsprozess einer Webseite darauf zu achten, dass am Ende ein barrierefreies Produkt steht.

Die Navigation bietet den User_innen Orientierung und hilft bei der Einschätzung welche Inhalte auf der Webseite angeboten werden. Daher sollte sie eine knappe Zusammenfassung der Inhalte darstellen um ihre Funktion gut zu erfüllen.

Links mit Texten wie ›weiter‹ und ›hier klicken‹ sind unbedingt zu vermeiden, da diese bei der Sprachausgabe keinen Zusammenhang zum Ziel des Links bieten. Das Ziel sind sprechende Links, die eine Verbindung zum verlinkten Inhalt herstellen, und bei der Erstellung dabei helfen den eigenen Schreibstil zu verbessern.

Alternative Attribute von Bildern, und Beschreibungen für Infografiken und Diagramme sind wichtig und sollen eine verständliche Erklärung des Dargestellten enthalten. Ihre Anregung beim Schreiben der alternativen Texte daran zu denken den Inhalt am Telefon oder in einer E-Mail zu erklären finde ich hilfreich:

»It might help to think about how you would explain the contents of the media to someone over the phone, or via email.«

Bezüglich der Strukturierung des Inhalts gab es mit dem Aufkommen von HTML5 eine Diskussion über die mehrfache Verwendung von Überschriften erster Ordnung (h1) in einem Dokument. Auch wenn das laut Spezifikation möglich ist, rät Kalbag diese nur für den Titel der Seite zu verwenden und damit die Hauptfunktion der Seite zu bezeichnen.

Für Formulare ist die Verknüpfung von label und input und erforderliche Felder mit einem entsprechenden Texthinweis im label zu versehen – und eben nicht mit dem zur Gewohnheit gewordenen Sternchen*. Dadurch bleibt die Benutzbarkeit offensichtlich und erfordert keine Vorerfahrung.

Um eine Webseite auch gut mit der Tastatur bedienen zu können helfen die tabindex Attribute. tabindex="0" weist die Tastatur-Navigation darauf hin das Element in der standardisierten Reihenfolge zu beachten. tabindex="-1" entfernt das Element aus der standardiesierten Reihenfolge. Daher ist die Verwendung von tabindex="-1" in Elementen die per Sprungmarken angesteuert werden hilfreich. Springt ein_e User_in zu einem Bereich mit tabindex="-1" wird diesem Bereich der programmatische Fokus zugewiesen, ein weiterer Tab findet dann zum entsprechend nächsten Element statt. Der Fokus bleibt nicht – wie ohne tabindex – an der ursprünglichen Stelle.

Im weiteren Verlauf des fünften Kapitels bespricht sie WAI-ARIA, was Web Accessibility Initiative—Accessible Rich Internet Applications bedeutet und als zusätzliche Ebene auf dem gut strukturierten HTML die Sprachausgabe der Inhalte unterstützt. Damit lassen sich Rollen, Bereiche, Status, Attribute und Live Regions definieren, die dann jeweils entsprechend besser zugänglich sind. Es bietet sich meiner Ansicht nach an über WAI-ARIA zu einem späteren Zeitpunkt nochmals zu schreiben.

Testen

Die aufmerksame Integration des Universal Design Konzepts in die Entwicklung einer Webseite sollte von regelmäßigen Tests begleitet werden.

»Regular testing will reassure you that you’re heading in the right direction, or give you new targets if the accessibility falls short.«

Neben den Tests durch eine breite Gruppe von User_innen empfiehlt sie das WebAIM’s WAVE web accessibility evaluation tool. Dabei handelt es sich um ein Webtool, mit dem die Barrierefreiheit einer Webseite überprüft werden kann. WAVE stellt die Webseite im Browser dar, und versieht sie an den entsprechenden Stellen mit Hinweisen auf Aspekte der Barrierefreiheit. Features, Warnungen und Fehler werden hervorgehoben, wodurch der testenden Person direkt weitere Einsichten bezüglich der Barrierefreiheit vermittelt werden.

Richtlinien

Im siebten Kapitel schriebt Kalbag über Gesetze und Richtlinien. Dabei erwähnt sie den Europäischer Rechtsakt zur Barrierefreiheit und die Web Content Accessibility Guidelines (WCAG) 2.0.

Die Web Content Accessibility Guidelines (WCAG) 2.0 enthalten drei Konformitätsstufen (A, AA und AAA), die darüber Aufschluss geben wie gründlich die Richtlinien umgesetzt werden. Die Richtlinien selbst sind durch vier Prinzipien strukturiert, welche mit den oben erwähnten Aspekten von Kalbag verwandt sind:

  • Prinzip 1: Wahrnehmbar – Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzern so präsentiert werden, dass diese sie wahrnehmen können.
  • Prinzip 2: Bedienbar – Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.
  • Prinzip 3: Verständlich – Informationen und Bedienung der Benutzerschnittstelle müssen verständlich sein.
  • Prinzip 4: Robust – Inhalte müssen robust genug sein, damit sie zuverlässig von einer großen Auswahl an Benutzeragenten einschließlich assistierender Techniken interpretiert werden können.

Zusammenfassung

Am Ende des siebten Kapitels fasst sie ihr Anliegen der Integration von Barrierefreiheit in den gesamten Entstehungsprozess einer Website in drei Haltungen zusammen:

  • Aufmerksam sein.
  • Flexibel bleiben.
  • Auf die Bedürfnisse der User_innen achten.

Wenn alle Beteiligten auf Barrierefreiheit achten und ihre Aufgaben aufmerksam erledigen, sind wir auf einem guten Weg. In Anbetracht der stetigen Veränderung und der jeweiligen Anforderungen ist es wichtig flexibel zu bleiben und unterschiedliche Schwerpunkte zu setzten und schließlich empfiehlt sie Richtlinien als solche zu verstehen, und die Bedürfnisse der User_innen zu beachten.

Bevor sie eine Fülle von Ressourcen und weiterführende Links anführt, schließt sie ihre Ausführungen mit dieser ansteckenden Vision:

»We need to work together to make and keep the web open, affordable, and available to all. Accessibility is our way to ensure that nobody gets shut out.«

Wie bereits deutlich wurde halte ich Accessibility for Everyone von Laura Kalbag für ein sehr gelungenes Buch und empfehle es gerne weiter. Kalbag gelingt es sehr gut die Auswirkungen von Universal Design deutlich zu machen, darüber hinaus kombiniert sie gekonnt grundsätzliche Überlegungen mit konkreten Beispielen.

Optimieren der Webfonts

Webfonts sind, wie alle anderen Schriften auch, für den Einsatz in unterschiedlichen Sprachen ausgelegt. Daher enthalten sie eine Fülle von Schriftzeichen. Wird ein Font in einer Webseite verwendet, die vor Allem einen Sprachraum bedient, werden viele dieser Schriftzeichen nie aufgerufen. Mit der Fülle der Schriftzeichen wächst die Dateigröße der Schrift, weshalb es sich lohnt zu überprüfen welche Schriftzeichen tatsächlich verwendet werden, und dementsprechend den Webfont anzupassen.

Dienste wie Typekit oder Google-Fonts bieten die Möglichkeit eine Teilmenge von verwendeten Schriftzeichen festzulegen, und auf diese Weise die Dateigröße des ausgelieferten Webfonts anzupassen. Sollen die Webfonts selbst gehostet werden, ist dies zwar über Font Squirrel möglich, allerdings muss dazu der Webfont hochgeladen werden.

Für mich erschien das bisher als eine nicht zufriedenstellende Lösung, weshalb ich in der letzten Woche die Artikel Three Techniques for Performant Custom Font Usage von Ollie Williams und It’s Dangerous to Go Stallone. Take Glyphhanger von Zach Leatherman mit großem Interesse gelesen habe. Am Wochenende installierte ich dann fonttools und glyphhanger um Webfonts gut über das Terminal optimieren zu können.

Das Tool glyphhanger der Filament Group verwendet die fonttools und bietet darüber hinaus noch die Möglichkeit Dateien oder URLs zu Parsen um dadurch herauszufinden welche Teilmenge an Schriftzeichen darin verwendet werden. Entsprechend dessen kann schließlich ein Webfont optimiert werden, und in unterschiedlichen Formaten abgespeichert werden.

glyphhanger https://depone.net/ --formats=woff2,woff --subset=SourceSansPro-Regular.ttf --css

Wird eben erwähnter Befehl ausgeführt wird der Webfont entsprechend der verwendeten Schriftzeichen in meiner Webseite optimiert. Die Dateigröße minimiert sich dadurch signifikant:

Subsetting SourceSansPro-Regular.ttf to SourceSansPro-Regular-subset.woff (was 287.07 KB, now 27.27 KB)
Subsetting SourceSansPro-Regular.ttf to SourceSansPro-Regular-subset.woff2 (was 287.07 KB, now 21.04 KB)

Mit Hilfe der Option --css gibt glyphhanger die Anweisung aus mit deren Hilfe der Webfont im Stylesheet verwendet werden kann. Um TOFU – hässlichen Kästchen die das fehlende Schriftzeichen ersetzen – in der Typographie zu verhindern wird die unterstützte unicode-range direkt mit angegebenen. Befinden sich im Text nicht unterstützte Schriftzeichen, greifen die Browser auf Systemschriften zurück.

@font-face {
 src: url(SourceSansPro-Regular-subset.woff2) format("woff2"), url(SourceSansPro-Regular-subset.woff) format("woff");
 unicode-range: U+A,U+20-5B,U+5D,U+5F,U+61-7E,U+A0,U+A9,U+AB,U+AD,U+B7,U+BB,U+C4,U+C7,U+D6,U+D7,U+DC,U+DF,U+E4,U+E9,U+F6,U+FC,U+2013,U+2014,U+2019,U+201C-201E,U+2026,U+2033,U+2039,U+203A,U+2192,U+21E7,U+2318,U+F8FF;
}

Der eben erwähnte Rückgriff auf Systemschriften verhindert zwar TOFU und stellt die Lesbarkeit des Textes sicher, die Typographie wird jedoch empfindlich gestört. Daher muss die Optimierung der Webfonts mit Bedacht vorgenommen werden. Die Übersicht der Unicode-Schriftzeichen in der Wikipedia hilft bei der Einschätzung der notwendigen Teilmenge.

Abschließend ist es auch noch wichtig zu erwähnen, dass die Ersparnis in der Dateigröße nicht 90%, wie oben zitierter Ausschnitt andeutet, da es sich beim Ausgangsfont um ein TrueType Format handelt, der entsprechende Webfont (woff) war dennoch dreimal so groß wie die optimierte Teilmenge.

Der Vollständigkeit halber ist noch zu erwähnen, dass für die Komprimierung der Webfonts als woff und woff2 die Installation von Brotli und Zopfli notwendig ist.