DE EN

Accessibility web design for more sales in e-commerce

YouTube Thumbnail mit Roland neben einer Webseite mit vorher nachher Vergleich für bessere Kontraste

Deutsch

English

Español

Français

Nederlands

Suomi

Sweden

Norway

Accessible web design: Inclusion and performance for your digital project

Increase the accessibility and performance of your website with our specialized service for accessible web design. We implement inclusive solutions in all common CMS and e-commerce systems while optimizing the performance of your digital presence.

Request a free initial consultation
Ruhr Refactoring Hero

Our accessibility web design services at a glance

Comprehensive analysis:

  • Detailed review of your existing websites with AXE and Silktide
  • Identification of accessibility barriers and performance issues

 

Customized implementation:

  • Conversion of your current design into accessible markup
  • Modernization and facelift with Tailwind CSS and Flowbite
  • Optimization for maximum performance and user-friendliness

Continuous quality assurance:

  • Regular automated audits
  • Detailed feedback for continuous improvement

Sustainable know-how transfer:

  • Close cooperation with your team
  • Training and workshops to promote internal expertise

Your benefits

Increased conversion rates:

  • Improved accessibility allows you to reach more potential customers.

Positive corporate image:

  • Show your commitment to inclusion and human values.

Optimized SEO:

  • Benefit from significantly better indexing in search engines.

Legal compliance:

  • Meet legal requirements for digital accessibility.

Extended target group:

  • Reach people with different abilities and needs.

Improved user experience:

  • Create an intuitive and pleasant interaction for all visitors to your website.

Roland Golla - Your accessibility partner

Roland Golla is a driving force in the world of barrier-free web design and digital accessibility. With over three years of intensive specialization in front-end web development and accessibility, he has established himself as a recognized expert in the industry. His passion for innovative technologies is reflected in his expertise in AI tools and fully automated solutions, which he skillfully uses to break down digital barriers and create inclusive online experiences.

As a well-known YouTuber and sought-after speaker, Roland shares his extensive knowledge with a wide audience and thus contributes significantly to raising awareness of the importance of accessibility on the web. His practical insights and in-depth understanding of the latest developments in web development make him a valuable point of contact for companies looking to make their digital presence more inclusive and powerful. Thanks to his excellent networking in the industry, Roland always keeps his finger on the pulse and brings fresh, innovative ideas to every project.

Roland Golla NCA Inhaber Roland Code Talks 2023

Free initial analysis with Silktide

Get started today and let us find out how we can optimize your PHP project.

 

Email-contact
Telephone

Accessible web design with Never Code Alone on YouTube

Our German tutorials on accessible webdesign

Barrierefreies Webdesign: Braucht dein Logo diesen Alt Text?

Barrierefreies Webdesign ist meiner Meinung nach oft eine Frage der Details, die aber eine massive Auswirkung auf die User Experience haben. Ich behaupte, dass ein redundanter `alt text` bei einem verlinkten Logo nicht nur überflüssig, sondern schädlich ist. Das Problem liegt darin, dass Screenreader den gleichen Inhalt doppelt vorlesen: einmal durch einen sichtbaren oder unsichtbaren Text im Link und ein zweites Mal durch den `alt text` des Bildes selbst. Viele Entwickler übersehen diese Feinheit, weil sie sich auf die reine Existenz eines `alt text` konzentrieren, anstatt auf dessen Kontext innerhalb der DOM-Struktur. In diesem Fall führt die Kombination aus einem `span`-Element mit einer `sr-only`-Klasse und dem `alt text` des Logo-Bildes zu einer störenden Wiederholung, die die Navigation für Nutzer assistiver Technologien unnötig verlangsamt. Die Lösung ist oft radikal einfach: Code entfernen, nicht hinzufügen. Bei der Analyse habe ich auf ein externes Tool gesetzt, das mir genau diesen Fehler auf mehreren Seiten gemeldet hat: "gleicher Altext wie der umschließende Link". Das zeigt, wie wichtig automatisierte Tests für Barrierefreiheit sind. Besonders interessant wurde es, als ich den Fehler lokal nicht reproduzieren konnte, obwohl er auf der Live-Umgebung klar ersichtlich war. Habt ihr auch schon solche Erfahrungen gemacht, wo sich eure Dev- und Live-Umgebungen beim Testing unterschiedlich verhalten? Das ist eine der frustrierenden, aber alltäglichen Herausforderungen im Entwickleralltag. Der Fix selbst war dann simpel: Ich habe das überflüssige `span`-Element mit dem Screenreader-Text komplett entfernt und mich darauf verlassen, dass der `alt text` des `img`-Tags innerhalb des `a`-Tags völlig ausreichend ist. Das Commit "Accessibility Fix vor Logo Alttext" wurde direkt in die CI/CD-Pipeline gepusht, um den Fix schnell auszurollen. Jetzt seid ihr gefragt: Was ist eure Meinung zu diesem konkreten Fix? Seht ihr das genauso, dass der alleinige `alt text` im Image-Tag hier die saubere und richtige Lösung ist, oder hättet ihr einen anderen Ansatz gewählt? Wie handhabt ihr das Thema `alt text` bei Logos, die als Hauptnavigation-Link zur Startseite dienen? Ich finde, die Diskussion um barrierefreies Webdesign muss viel tiefer gehen als nur das Abhaken von Checklisten. Es geht um das Schaffen einer nahtlosen Erfahrung für alle. Teilt eure Sichtweise und eure Best Practices in den Kommentaren! Ich bin gespannt auf eure Perspektiven. Wenn ihr bei eurem Projekt Code-Probleme habt, die ihr nicht gelöst bekommt, schreibt mir direkt an roland@nevercodealone.de. Ich schaue mir das an und helfe euch, euren Code zu reparieren. 0:00 Intro zum Problem: Doppelter Logo Alt-Text 1:33 Fehleranalyse mit Accessibility-Tools 3:06 Der Code-Fix: Screenreader-Only-Text entfernen 4:39 Live vs Lokal: Unerwartete Debugging-Probleme 6:13 Fazit und Diskussion: Eure Meinung zählt

Accessibility Webdesign: Zeilenabstand in Tailwind richtig fixen

Barrierefreies Webdesign wird oft als selbstverständlich angesehen, besonders bei der Nutzung von CSS-Frameworks. Ich behaupte jedoch, dass gerade hier die größten Fallstricke lauern. Viele Entwickler verlassen sich blind auf die Standardeinstellungen von Tools wie Tailwind und übersehen dabei kritische Accessibility-Anforderungen. Wie ich hier zeige, ist der korrekte Zeilenabstand ein perfektes Beispiel: Die WCAG fordert eine `line-height` von mindestens 1.5, aber viele Utility-Klassen wie `text-sm` unterschreiten diesen Wert standardmäßig. Meiner Meinung nach ist das ein strukturelles Problem in der Denkweise vieler Frameworks, das aktive Gegenmaßnahmen erfordert. Es reicht nicht, ein Framework zu nutzen, man muss seine Konfiguration gezielt auf Barrierefreiheit prüfen und anpassen. Das ist kein optionaler Schritt, sondern eine Kernaufgabe im modernen Webdevelopment. Die Analyse solcher Probleme ist oft ein tiefer Einblick in die CSS-Kaskade. Habt ihr auch schon mal erlebt, dass eine simple `line-height` von einer unerwarteten Stelle überschrieben wird? In meinem Fall war es eine Kombination aus alten, migrierten CSS-Klassen und der Spezifität von Tailwind selbst. Der Debugging-Prozess über die Browser-Entwicklertools ist dabei entscheidend, um den wahren Verursacher zu finden. Manchmal ist die Lösung dann ein globaler Fix, der vielleicht sogar ein `!important` erfordert – ein Mittel, das viele als "Holzhammer" sehen, das aber in manchen Fällen pragmatisch und notwendig ist, um eine konsistente User Experience zu garantieren. Wie geht ihr mit solchen hartnäckigen CSS-Overrides um? Greift ihr auch mal zum `!important` oder habt ihr elegantere Lösungen parat, um die Barrierefreiheit sicherzustellen? Teilt eure Sichtweise dazu gerne in den Kommentaren. Am Ende zeigt sich, dass die Arbeit an der Barrierefreiheit oft weit mehr bewirkt als nur die Behebung des ursprünglichen Fehlers. Sobald man anfängt, den Code unter dem Aspekt der Zugänglichkeit zu betrachten, fallen einem auch andere strukturelle und semantische Probleme auf. In diesem Fall waren es falsch genutzte Überschriften-Tags (`H5` statt `div`), die keine inhaltliche Relevanz hatten und die Dokumentenstruktur störten. Welche unerwarteten Bugs habt ihr schon entdeckt, während ihr eigentlich an einem Accessibility-Thema gearbeitet habt? Diese "Nebeneffekte" sind für mich der beste Beweis, dass barrierefreies Webdesign die Code-Qualität insgesamt verbessert. Wenn ihr bei eurem Projekt ähnliche Herausforderungen mit dem Zeilenabstand oder anderen Accessibility-Hürden habt, schreibt mir direkt an roland@nevercodealone.de. Ich schaue mir euren Code an und helfe euch, diese Probleme zu lösen. 0:00 Analyse: Zu geringer Zeilenabstand im Accessibility-Check 4:08 CSS-Debugging: Die Ursache für den falschen Zeilenabstand finden 8:16 Die Lösung: Tailwind CSS mit !important korrigieren 12:24 Bonus-Fix: Semantische HTML-Fehler in Überschriften beheben 16:34 Fazit und Ausblick: Kontinuierliche Code-Verbesserung

Accessibility Webdesign: Leere Überschriften im Live Coding beheben

Ich behaupte, dass Webdesign Accessibility oft an einer unerwarteten, nicht-technischen Stelle scheitert: der redaktionellen Inhaltspflege. Während wir als Entwickler sauberen Code schreiben, können durch einfache Copy-Paste-Fehler oder falsche Formatierungen im Backend leere Überschriften entstehen, die für Screenreader-Nutzer eine Katastrophe sind. Diese Fehler sind unsichtbar und nur mit spezialisierten Tools wie Iable auffindbar. Selbst KI ist keine Lösung; wie ich im Video erwähne, hat sie mir letzte Woche sogar neue Fehler eingebaut. Meiner Meinung nach wird der menschliche, redaktionelle Faktor bei der Erstellung für ein barrierefreies Webdesign massiv unterschätzt. Ein technisch perfektes System ist wertlos, wenn der Inhalt Barrieren schafft. In diesem Live Coding zeige ich euch meinen exakten Workflow, um diese unsichtbaren Probleme zu jagen und zu beheben. Ihr seht, wie ich mich durch verschiedene Seiten der NCA-Website arbeite und manuell leere H3- und H4-Tags entferne, die sich eingeschlichen haben. Das ist mühsame Detailarbeit, die aber entscheidend für einen hohen Accessibility-Score ist. Was ist eure Erfahrung damit? Habt ihr in euren Projekten auch schon festgestellt, dass die größten Probleme für ein barrierefreies Webdesign nicht im Code, sondern im Content-Management-System durch Redakteure verursacht werden? Wie stellt ihr sicher, dass euer Content-Team für solche Themen wie leere Überschriften sensibilisiert ist und semantisch korrekten Inhalt einpflegt? Lasst uns über eure Strategien diskutieren. Ein barrierefreies Webdesign ist ein fortlaufender Prozess, keine einmalige Aufgabe. Mich interessiert brennend, welche Tools und Workflows ihr für eure regelmäßigen Checks nutzt. Verlasst ihr euch auf manuelle Audits mit Browser-Plugins oder habt ihr automatisierte Tests, vielleicht sogar mit CypressIO oder Vitest, in eure CI/CD-Pipeline integriert? Gibt es vielleicht sogar CMS-Features, die leere Überschriften von vornherein verhindern können? Teilt eure Best Practices und auch eure größten Herausforderungen in den Kommentaren. Ich bin auch auf andere Perspektiven gespannt und freue mich auf einen regen Austausch über die pragmatische Umsetzung von Webdesign Accessibility. 0:00 Leere Überschriften: Das Problem und die Analyse 4:11 Live Debugging: Redaktionelle Fehler manuell beheben 8:22 Weitere Seiten prüfen: Barrierefreie PDFs und mehr 12:33 Letzte Korrekturen und der finale Accessibility-Scan 16:43 Fazit und eure Tools für Webdesign Accessibility

Accessibility Webdesign: Empty Headlines in Symfony Twig Templates beheben

Accessibility Webdesign ist mehr als nur ein Buzzword, es ist eine technische Notwendigkeit, die oft an Kleinigkeiten scheitert. Ich behaupte, dass Fehler wie Empty Headlines oft fälschlicherweise Redakteuren zugeschrieben werden, obwohl die Ursache tief im Code liegt, beispielsweise nach Layout-Anpassungen in einem Symfony-Projekt. Es reicht nicht, nur oberflächlich Tests durchlaufen zu lassen. Ein echter Sprung im Accessibility Score, wie bei mir von 84 auf 87,1, kommt erst, wenn ein Problem zu 100 % gelöst ist. Eine einzelne, nicht barrierefreie Stufe macht das ganze Gebäude unzugänglich. Meiner Meinung nach wird dieser Aspekt der vollständigen Problemlösung in der Entwicklung oft unterschätzt, was zu stagnierenden Scores und echter Frustration führt. Im Video zeige ich genau, wie ich solche Empty Headlines aufspüre. Der Fehler trat auf mehreren Glossar-Seiten auf, was auf eine zentrale Ursache im Template hindeutete. Mit einer einfachen Suche im Code fand ich schnell die leeren H2- und H3-Tags, die durch eine Schleife generiert wurden, wenn kein Inhalt vorhanden war. Die Lösung war denkbar einfach: eine simple `if`-Bedingung im Twig-Template, die das Rendering der Headline verhindert, wenn der Inhalt fehlt. Oft sind es genau diese kleinen, logischen Checks, die den Unterschied machen. Interessanterweise deckt so eine Analyse oft weitere Probleme auf, wie einen Sprung in der Überschriftenreihenfolge oder Kontrastprobleme in der Symfony Debug Toolbar. Habt ihr auch schon erlebt, dass ein kleiner Fix eine Kaskade anderer, kleinerer Baustellen offenbart? Ich finde es wichtig, solche Fixes pragmatisch anzugehen. Man könnte komplexe Validierungen im Backend einbauen, aber manchmal ist eine einfache `if`-Abfrage im Frontend-Template die effizienteste Lösung, ohne es zu overengineeren. Was ist eure Erfahrung damit? Setzt ihr auf strikte Backend-Validierung oder bevorzugt ihr auch schnelle, gezielte Template-Fixes? Solche Fehler sind eine gute Erinnerung, sich die eigenen Projekte regelmäßig mit Tools wie dem Iable Dashboard anzuschauen. Der gesamte Quelltext des Projekts ist übrigens auf GitHub verfügbar, falls ihr den Fortschritt verfolgen oder selbst beitragen wollt. Widersprecht mir gerne in den Kommentaren: Wann ist ein einfacher Template-Fix zu wenig und wann ist es genau die richtige Dosis Pragmatismus? 0:00 Einführung: Das Problem der Empty Headlines 2:30 Fehlersuche: Leere H2 und H3 Tags im Code finden 5:00 Live-Coding: Der Twig-Fix für leere Überschriften 7:30 Weitere Findings: Von Kontrastfehlern bis zur Heading-Order 10:03 Fazit und Ausblick: Open Source auf GitHub

Accessibility Webdesign: Vibe Coding vs Manuelles Fixing in Twig

Ich behaupte, dass Accessibility Webdesign in einem best practice Twig Template oft mehr Fingerspitzengefühl erfordert, als KI-Tools wie Vibe Coding aktuell liefern können. In diesem Fall war das Problem ein klassisches: Die sichtbare Bezeichnung eines Elements, hier die Sprachflaggen, war nicht Teil des zugänglichen Namens im `aria-label`. Während der sichtbare Text "Englisch" war, lautete das `aria-label` "englische Version", was zu einer inkonsistenten User Experience für sehende und nicht-sehende Nutzer führt. Der Versuch, dies mit Claude zu beheben, führte zu "Wildwuchs". Das Tool hat zwar die richtigen Dateien identifiziert, aber dann viel zu viele Änderungen vorgeschlagen, die teilweise nichts mit dem eigentlichen Problem zu tun hatten. Das zeigt, dass Vibe Coding zwar schnell ist, aber die Präzision für solche nuancierten Accessibility-Anpassungen noch fehlt. Der Lösungsansatz von Vibe Coding war, das `aria-label` zu entfernen, was prinzipiell korrekt ist, aber im Prozess wurden auch andere, unerwünschte Änderungen am Code vorgenommen. Diese Gefahr des "Wildwuchses" ist meiner Meinung nach eine der größten Herausforderungen beim Einsatz von KI-Assistenten im Development. Der manuelle Fix war im Gegensatz dazu trivial: Einfach das differenzierende `aria-label` im Twig Template entfernen, da der sichtbare Text bereits ausreichend Information liefert. Das hat den Fehler sofort behoben und den Accessibility Score um über 3% verbessert. Was denkt ihr zu diesem Thema? Habt ihr ähnliche Erfahrungen gemacht, wo KI-Tools mehr Chaos als Ordnung in euren Code gebracht haben, besonders bei spezifischen Themen wie Accessibility oder einem best practice Twig Template? Teilt eure Sichtweise! Wie geht ihr mit dem Code um, den KI-Tools generieren? Macht ihr immer einen gründlichen Review oder vertraut ihr den Vorschlägen? Eine weitere Frage, die sich hier stellt, betrifft den Workflow: Ich habe für den Fix den Dateinamen direkt in die Git Commit Message geschrieben, um bei kleinen Änderungen sofort den Kontext zu haben, obwohl die Info natürlich in Git selbst steckt. Ist das für euch Best Practice oder unnötige Redundanz? Lasst uns darüber diskutieren, wie wir unsere Workflows optimieren können, um solche Fehler effizient zu beheben, ohne uns auf unzuverlässige Automatisierung zu verlassen. Wenn ihr bei euren Projekten Hilfe bei der Implementierung von automatisierten Tests mit CypressIO oder einer CI/CD-Pipeline braucht, meldet euch direkt bei mir unter roland@nevercodealone.de, und ich helfe euch, euren Code auf das nächste Level zu bringen. 0:00 Analyse eines Accessibility Fehlers im Iable Report 4:36 Vibe Coding: KI-gestützter Fix mit Claude schlägt fehl 9:13 Der manuelle Fix: Das Twig Template korrekt anpassen 13:50 Git Workflow und Best Practice für Commit Messages 18:26 Fazit: Die Gefahr von Vibe Coding und Wildwuchs im Code

Claude Code Tutorial Optimiere deine Website in 17 Minuten: AI Coding Accessibility und Screenreader

Clode Code Tutorial, Accessibility Optimierung mit AI, Step-by-Step Screenreader Anpassung – Optimiere deine Website in nur 17 Minuten mit revolutionärer KI-Technologie für perfekte Barrierefreiheit! Detaillierte Schritte: - Silk Tight Screenreader-Plugin für präzise Zugänglichkeitsanalyse - Clode Code AI für automatische Code-Verbesserungen - Heygen Übersetzungstool für mehrsprachige Videoinhalte - PHP Storm Integration zur Echtzeitoptimierung 00:00 Einführung Clode Code 02:30 Screenreader Analyse 06:45 AI-basierte Accessibility Optimierung 11:00 Implementierung der Änderungen 15:45 Live-Test und Ergebnisse In diesem Tutorial zeige ich, wie moderne KI-Technologien Webseiten barrierefrei machen. Wir optimieren Screenreader-Kompatibilität, verbessern Sprachunterstützung und erhöhen die Nutzererfahrung für Menschen mit Einschränkungen. Schritt für Schritt demonstriere ich, wie Entwickler mit minimaler manueller Arbeit maximale Zugänglichkeit erreichen können. Diskutiere mit: 1. Welche Accessibility-Herausforderungen hast du bereits erlebt? 2. Wie wichtig sind KI-Tools für barrierefreie Webentwicklung? #AccessibilityAI #ClodeCode #WebsiteOptimierung #2024

Fixe H1 Tags in 6 Minuten: SEO und Accessibility Optimierung – Step-by-Step Guide

H1 Tags fixen, SEO Best Practices, Accessibility optimieren – Entdecke jetzt die perfekte Lösung für deine Webseite in nur 6 Minuten! In diesem Tutorial zeige ich dir Schritt für Schritt, wie du multiple H1 Tags professionell eliminierst und deine Webseite sowohl SEO- als auch accessibility-optimiert gestaltest. Wir arbeiten live mit PHP Storm, analysieren die HTML-Struktur und demonstrieren konkrete Verbesserungsstrategien. Lerne, wie du semantische Überschriften korrekt verwendest, Suchmaschinen-Rankings verbesserst und gleichzeitig die Benutzerfreundlichkeit deiner Website maximierst. Praxisnahe Tipps und Tricks aus der Entwickler-Perspektive inklusive! Timestamps: 00:00 H1 Tag Grundlagen 01:00 Accessibility Check 02:00 SEO Optimierung 03:00 Praktische Umsetzung 04:06 Fazit & Tipps Details: - W3C Validator für semantische HTML-Struktur prüfen - PHP Storm Search Funktion für H1 Elemente identifizieren - Tailwind CSS zur Layout-Beibehaltung nutzen - Git Workflow für Änderungsdokumentation implementieren Diskussionsfragen: - Welche H1 Tag Fehler habt ihr bereits entdeckt? - Wie optimiert ihr eure Webseiten-Struktur? Hashtags: #seo #headlines #accessibility

Optimiere Farbkontraste in 9 Minuten: Barrierefreies Webdesign mit Eye-Able und Tailwind

Barrierefreies Webdesign, Farbkontraste optimieren, Accessibility-Tools nutzen – Entdecke in 9 Minuten deine Web-Optimierungsstrategie! 00:00 Barrierefreiheit Grundlagen 01:30 Contrast Checker Analyse 03:00 Tailwind Farbkontrast-Anpassung 05:15 Live Refactoring Praxis 08:00 Accessibility Performance Technische Schritte zur Weboptimierung: - Eye-Able Contrast Checker für präzise Farbwerte - Tailwind Color Scale von 500 auf 800 umstellen - Github Accessibility Score verbessern - Kontinuierliche Accessibility-Überwachung implementieren Professionelle Webentwickler optimieren permanent ihre Projekte durch systematische Accessibility-Checks. Farbkontraste sind dabei ein Schlüsselelement für bessere Lesbarkeit und Nutzerfreundlichkeit. Mit Tools wie WebAIM können Entwickler schnell kritische Kontrastbereiche identifizieren und gezielt verbessern. Der Fokus liegt auf praktischen Lösungen, die sowohl die visuelle Qualität als auch die technische Zugänglichkeit steigern. Diskutiere: Welche Accessibility-Herausforderungen hast du bereits gemeistert? Welche Tools sind für dich unersetzlich? #WebAccessibility #TailwindCSS #FrontendOptimierung #2024

Barrierefreies Webdesign Tutorial: WCAG Standards und Alt-Text Fehler in 8 Minuten beheben

Barrierefreies Webdesign Tutorial, WCAG Standards, Accessibility Optimierung, Website Fehler beheben – Komplexe Alt-Text Probleme in 8 Minuten lösen! Barrierefreies Webdesign erfordert präzise technische Umsetzung. Dieser Walkthrough demonstriert praktische Lösungsstrategien für häufige Accessibility-Herausforderungen. Lernen Sie, wie automatisierte Tests Ihre Websitequalität verbessern und Screenreader-Kompatibilität sicherstellen. Detaillierte Einblicke in Image-Tagging, semantische Strukturierung und Performance-Optimierung. 00:00 Accessibility Dashboard Analyse 01:30 Image Alt-Text Fehler identifizieren 03:45 Dekorative Bilder korrekt markieren 05:20 Best Practices für Screenreader 07:50 Live Debugging und Fehlerkorrektur Tools und Schritte: - Lighthouse Accessibility Scoring - ImageAlt Plugin für Fehleranalyse - PHP Storm Template Optimierung - WCAG 2.1 Alt-Text Richtlinien prüfen Diskutieren Sie: - Welche Alt-Text Strategien nutzen Sie aktuell? - Wie optimieren Sie Ihre Accessibility-Workflows? Neue Videos: Zweimal wöchentlich veröffentliche ich hier Live-Coding-Tutorials und alles als Open Source. Falls du den Kanal noch nicht kennst, folge gerne und schalte die Glocke ein, um keine neuen Videos zu verpassen! ChatGPT Playlist: https://www.youtube.com/watch?v=Rfh8DSpRYIM&list=PLKrKzhBjw2Y9WAmajKpaE8mzQ2UpY1UYu Cypress.IO Live Coding Tutorial Playlist: https://www.youtube.com/watch?v=mb_PTxDeJKI&list=PLKrKzhBjw2Y9ceCxO3ollOc4eIVPAjiHs Vim Playlist: https://www.youtube.com/playlist?list=PLKrKzhBjw2Y-9sCNpvbg3BY9v4JRc6fgn Tailwind Playlist: https://www.youtube.com/playlist?list=PLKrKzhBjw2Y92eHOPEfwwZmAkxxcGr-yi ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Hier geht es zu unseren Social-Media-Kanälen: ► Patreon: https://patreon.com/nevercodealone ► Twitter: https://twitter.com/nevercodealone ► Instagram: https://www.instagram.com/nevercodealone/ ► LinkedIn: https://www.linkedin.com/company/never-code-alone/ ► Facebook: https://www.facebook.com/nevercodealone ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Das sind unsere Webseiten: ► Never Code Alone bietet kostenlose und kommerzielle live Coding Events und PHP Kurse für Fortgeschrittene an und unterstützt soziale Projekte https://nevercodealone.de ► TESTIFY - Agentur für Website Testing mit Cypress.IO und dem Codeception Testing Framework https://testify.team/ ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Du möchtest Never Code Alone unterstützen? Dann lass uns gerne ein Abo da und schreibe deine Fragen und/oder Anregungen in die Kommentare. Danke fürs zuschauen! Ich hoffe das Video hat dir gefallen. #WebAccessibility #WCAG #AltTextFix #2024