Ich unterhielt mich neulich mit einigen Frontend-Entwicklern darüber, warum so viele Unternehmen Schwierigkeiten haben, barrierefreie Websites zu erstellen. Warum sind barrierefreie Websites so schwer zu erstellen? Wir lernen HTML, wir stellen sicher, dass die Dinge semantisch sind und – voilà! @– wir haben eine barrierefreie Website. Im Laufe des Gesprächs erwähnte jemand den Rechtsstreit um Domino's Pizza, der vielleicht das bekannteste Beispiel dafür ist, dass ein Unternehmen wegen mangelnder Barrierefreiheit verklagt wird.
Hier ist eine interessante Information aus diesem Link
Laut CNBC stieg die Zahl der Klagen wegen unzugänglicher Websites im letzten Jahr im Vergleich zu 2017 um 58 Prozent auf mehr als 2.200.
Unzugängliche Websites sind nicht nur eine Überlegung für Designer und Ingenieure, sondern auch ein ernstes Problem für das Rechtsteam eines Unternehmens. Glücklicherweise scheinen mehr dieser Fälle vor Gericht zu kommen und (meine persönliche Hoffnung ist) dies wird die Leute dazu bringen, sich mehr um Semantik und Best Practices in der Frontend-Entwicklung zu kümmern. Obwohl ich gerne glauben würde, dass Unternehmen das tun würden, was für das Web am besten ist, und Websites erstellen, die die Grundanforderungen ohne rechtliche Bedrohung erfüllen, müssen wir unzugängliche Websites absolut illegal machen, damit die Leute diesem Problem wirklich Aufmerksamkeit schenken.
Jedoch! Ich mache mir auch Sorgen, wenn ich vielleicht einfach nur mangelndes Wissen auf Bosheit zurückführe. Ich schätze, viele Websites haben schlechte Barrierefreiheit nicht, weil sich die Leute nicht darum kümmern, sondern weil sie überhaupt nicht wissen, dass es ein Problem gibt. Als sich mein Gespräch mit den Frontend-Entwicklern fortsetzte, erkannte ich, dass der Grund, warum Barrierefreiheit nicht ernsthaft angegangen wird, wahrscheinlich nichts mit Bandbreite, Erfahrung oder Geld zu tun hat.
Ich schätze, das Problem ist, dass die Barrierefreiheit einer Website unsichtbar und stillschweigend kaputtgehen kann.
Hier ist ein Beispiel: Bei der Entwicklung einer Website werden JavaScript-Fehler wahrscheinlich erkannt, weil alles kaputt geht, wenn etwas schief geht. Und CSS-Bugs werden erkannt, weil etwas seltsam aussieht. Aber die Barrierefreiheit oder Leistung einer Website kann sich über Nacht und ohne Vorwarnung von okay zu schrecklich entwickeln. Der einzige Weg, diese unsichtbar kaputten Dinge zu beheben, ist, sie zuerst sichtbar zu machen.
Also, hier ist eine Idee: Was wäre, wenn unsere Texteditoren Barrierefreiheitsprobleme erkennen und uns während der Entwicklung anzeigen würden? Es könnte so aussehen
Ich bin sicher, es gibt noch viele andere Möglichkeiten, Barrierefreiheitsprobleme öffentlicher und sichtbarer zu machen. Es gibt Werkzeuge wie Lighthouse und Browsererweiterungen, die bereits existieren, aber wenn wir Barrierefreiheit (und sogar Leistung, ein weiteres stilles Versagen) zu einem Teil unseres alltäglichen Workflows machen, stellen wir sicher, dass wir sie nicht ignorieren können. So etwas würde uns ermutigen, die Probleme kennenzulernen, uns Links zu potenziellen Lösungen bieten und uns alle ermutigen, uns um einen relativ missverstandenen Teil der Frontend-Entwicklung zu kümmern.
Es wäre auch großartig, native Unterstützung für ein hybrides Klick-/Tastendruckereignis speziell zur Reproduktion des Linkverhaltens zu haben.
Ich stimme dir zu, aber es sollte ausreichen, es zu polyfillen (vorausgesetzt, die relevanten Maus- und Tastaturereignisse dürfen bis zum DOM-Top blubbern). Hängen Sie einfach einen Handler für „click“- und „keydown“-Ereignisse an das Dokument (), und wenn der Klick oder Tastendruck (Enter-Taste für Links, Leertaste für Buttons, Checkboxen und Radio-Buttons) auf einen Link oder Button/Checkbox/Radio erfolgte, lösen Sie Ihr „hybrides“ Ereignis vom Ursprungselement aus. Dann könnten Sie Listener für das hybride Ereignis an jeden gewünschten Link oder Button anhängen.
Ich habe ziemlich unzugänglichen Code geschrieben, und das nicht, weil es mir egal war. Tatsächlich habe ich die Dinge noch schlimmer gemacht, als ich anfing, zugänglichen Code zu schreiben.
Was ich vorschlage, ist, dass Web-Barrierefreiheit von Anfang an in der Ausbildung von Web-Entwicklern (und Designern) gelehrt wird und Unternehmen eine Zertifizierung verlangen sollten, die sie bezahlen. Außerdem brauchen wir den Kongress, um WCAG tatsächlich zu einer gesetzlichen Anforderung zu machen. Obwohl Websites unter dem ADA abgedeckt sind, gibt es immer noch keine rechtlichen Standards für Web-Barrierefreiheit wie für physische Räume.
Ich weiß, was Sie meinen, die Dinge schlimmer machen :-D
Ich schätze, es ist ziemlich herausfordernd. Ich erinnere mich, an einem Stück gearbeitet zu haben und mit dem Ergebnis sehr zufrieden zu sein. Die Sache ist, da ich eine ziemlich klare Sicht und Kenntnis dessen hatte, was vor sich ging, verband mein Gehirn die Punkte. Als ein sehbehinderter Kollege mir zur Hand ging, war ich schnell desillusioniert :-D
Ich stimme zu! Neue Entwickler lernen kein korrektes/zugängliches semantisches HTML5 und nichts über ARIA. Ich bin seit über 20 Jahren Accessibility SME. a11y-Bildung ist ein Problem.
Ich denke, es gibt viele vielschichtige Antworten darauf, warum sie es nicht tun.
Für meine persönliche Erfahrung sind hier einige davon
Alte Websites – Wir haben Websites, die 2007 gebaut wurden und immer noch in Produktion sind. Sie haben niedrigere GeschäftsPrioritäten, daher werden sie oft ignoriert.
Inhaltsbeitragende – Wir verwenden ein Content-Management-System, das von vielen Menschen mit unterschiedlichen Kompetenzen genutzt wird. Und nicht alle leisten ihre gebührende Sorgfalt. Wir versuchen, es zu erkennen, aber das bedeutet nicht, dass wir es ständig sehen.
Bandbreite – Es gibt nur ein paar Entwickler mit über 60 Websites. Und wir tragen viele Hüte außer „Entwickler“.
Drittanbieter – Wir nutzen Drittanbieter für Dinge wie unser E-Commerce-System. Einige waren nicht sehr empfänglich für unser Feedback. Und es ist nicht einfach, sie einfach auszutauschen, wenn sie an alte Kassensysteme und dergleichen gebunden sind. In anderen Fällen wurden uns Dinge versprochen, die vollständig WCAG AA-konform waren, aber ich fand Probleme mit einigen der weniger bekannten Regeln.
Mangelnde rechtliche Klarheit – Es gibt keine ECHTEN Regeln, nur viel Gerede über die Verwendung von WCAG 2.0 AA. Aber selbst wenn Sie das erreichen, gibt es keine Garantie, dass wir nicht gegen die ADA-Konformität verstoßen. Das Beste, was wir tun können, ist, uns davor zu schützen, wie ein leichtes Ziel auszusehen.
Was ist mit Matterhorn und PDFs? E-Mails?
Anstatt sie den Texteditoren zu überlassen, brauchen wir vielleicht einen HTML5-Barrierefreiheits-Linter. Davon gibt es etwas für Reacts JSX, glaube ich, aber eine schnelle Suche ergab nichts für HTML im Allgemeinen.
Ein Linter kann in eine Vielzahl von Entwicklungsumgebungen und (wichtiger) in eine CI-Pipeline integriert werden, wodurch Commits abgelehnt werden, die die Grundregeln für Barrierefreiheit nicht erfüllen.
Ein Linter würde nur einige Dinge erfassen und die Leute wahrscheinlich dazu bringen, viel unnötigen Code zu schreiben (siehe Blogbeiträge über den Missbrauch von ARIA-Rollen, um zu sehen, wie dies bereits geschieht und Probleme verursacht). Eine Testsuite für Barrierefreiheit ist eine bessere Option, da sie Probleme bei Interaktionen erfassen könnte, was über einen Linter schwerer zu tun ist.
Ich würde es lieben, Optionen für Barrierefreiheits-Audits als Teil eines CI-Prozesses zu sehen. Ein Build, der aufgrund einer Barrierefreiheits-Regression fehlschlägt, wäre großartig, obwohl ich mir definitiv vorstellen kann, wie schwierig es sein könnte, so etwas zu implementieren, da a11y zu einer sehr komplexen Sache für die Überprüfung wird, wenn Schnittstellen immer komplexer werden.
Die meisten Barrierefreiheitsprobleme sind kontextabhängig. Ich bin blind. Wenn Sie keinen richtigen Kontext hinzufügen, ist die Auflistung von HTML nutzlos.
Tippfehler: meinte Linting.
Welche Browsererweiterungen/Tools könnten Frontend-Entwickler verwenden, um das Barrierefreiheitsproblem einfacher zu lösen? Es ist leicht zu sagen, dass es Tools gibt, aber Links dazu wären hilfreich!
WAS
WAVE
aXe
Die (Beta-) „Webhint-Erweiterung für Visual Studio Code“ könnte helfen…
https://webhint.io/docs/user-guide/extensions/vscode-webhint/
Sie verwendet die „Axe Accessibility Check“ (basierend auf axe-core)
https://webhint.io/docs/user-guide/hints/hint-axe/
Siehe auch: „Getting hints from Visual Studio Code“
https://medium.com/webhint/getting-hints-from-visual-studio-code-69118e48de1b
Ich verbringe viel Zeit damit, Farbenblindheit oder Hover- und Fokusstile Designern oder Kunden zu erklären. Oft stoßen diese Diskussionen auf „Das will der Kunde“ oder „Das können wir nach dem Start beheben“. Daher denke ich, dass Barrierefreiheit oft vor der Entwicklung schiefgeht, und ich kann absolut verstehen, warum einige Entwickler es nicht einmal in Erwägung ziehen, Barrierefreiheit zu einer Priorität zu machen (oder in einigen Fällen zu lernen, wie man sie macht).
MSFT-Fan, oder? Webhint ist ein schönes Werkzeug, wenn auch nicht sehr bekannt. Sehr anpassbar.
Guter Beitrag. Ich finde, mein Problem ist das eigentliche Design und nicht die Codierungspraktiken. Es ist etwas, womit ich persönlich kämpfe, die gleiche Website so zu gestalten, dass sie für Menschen mit und ohne Sehbehinderungen attraktiv aussieht. Die vielen Barrierefreiheitsregeln schränken die Verwendung von Farben und Schattierungen, viele Bilder, die Menge an Inhalten auf jeder Seite usw. ein.
Auf der Codierungsseite gibt es nicht nur das grundlegende HTML, das heute codiert wird, sondern auch WCAG, ARIA und strukturiertes Markup, das implementiert werden muss. Der Code wird sehr schnell sehr hässlich.
Was Code-Hinweise angeht, gibt es in VS Code einige Erweiterungen, die helfen.
Ist das ein tatsächlicher Atom-Plugin oder nur eine Mock-up?
Es ist VSCode, ich bin mir des Linter-Tools nicht sicher.
Das ist Visual Studio Code und ich glaube, es ist ein Mock-up.
Das macht ember-template-lint. Es lohnt sich, es sich anzusehen. Es gibt auch einige VS-Code-Erweiterungen, die ähnliche Dinge tun.
Axe bietet viele Tools, darunter Browsererweiterungen und eine Engine, die in Tests verwendet werden kann
https://www.deque.com/axe/
https://github.com/dequelabs/axe-core/blob/develop/README.md
Siteimprove Browsererweiterung
https://chrome.google.com/webstore/detail/siteimprove-accessibility/efcfolpjihicnikpmhnmphjhhpiclljc?hl=en-US
„…wir müssen unzugängliche Websites absolut illegal machen, damit die Leute diesem Problem wirklich Aufmerksamkeit schenken.“
Ja, lasst uns schlechte Designumsetzungen verbieten. Das wird das Interesse an der Frontend-Entwicklung ankurbeln und mehr Talente in die Branche bringen. Oh, hey, das wird auch das Problem der schlechten Barrierefreiheits Protokolle lösen!
Ich finde es schwierig, attraktive und barrierefreie Lösungen anzubieten. Man muss die a11y-Komponenten verstehen, und es ist so umfangreich. Als ich zum ersten Mal die a11y-Dokumentation durchsah, gab es Hunderte von Seiten zu behandeln, und es war unmöglich, irgendwann nicht gelangweilt zu sein...
Web-Barrierefreiheit ist seit mindestens fünf Jahren ein Schwerpunkt von mir. Ich habe Versionen fast aller benutzerdefinierten Komponenten implementiert, die WAI-ARIA in seinen Autorenpraktiken erwähnt, und trotz all meines Wissens ist die Erstellung barrierefreier Websites immer noch sehr schwierig. Eine der größten Herausforderungen für Entwickler ist der Mangel an Konsistenz und Compliance zwischen assistiven Technologien und Browsern (manchmal beeinflussen auch Betriebssysteme dies).
Es kommt häufig vor, dass ich etwas genau nach Spezifikation implementiere und dann feststelle, dass es in 25 % der assistiven Technologie-/Browser-Kombinationen funktioniert. Wenn ein Entwickler sich nicht auf den Screenreader und den Browser verlassen kann, dass sie gemäß den Spezifikationen funktionieren, und Tabellen mit Testergebnissen erstellen muss, um herauszufinden, ob er versuchen soll, Dinge auf eine hackeligere, aber potenziell besser unterstützte Weise zu machen, als WAI-ARIA empfiehlt, gibt es ein großes Problem. Ich glaube wirklich nicht, dass es fair gegenüber den Entwicklern ist, diese Belastung aufzuerlegen, wenn die Hersteller dieser Tools unvollständige Implementierungen liefern. Die meisten Entwickler werden neu darin sein, barrierefreie Komponenten zu schreiben, was das Problem noch verschärft. Wenn sie sich nicht sicher sein können, ob sie es richtig gemacht haben, auch wenn sie versuchen, es selbst zu testen, weil vielleicht ihre Werkzeuge einfach nicht funktionieren, macht das das Lernen viel schwieriger.
„Wir lernen HTML, wir sorgen dafür, dass die Dinge semantisch sind und – voilà!“
Leichter gesagt als getan.
Ich bin einer der wenigen a11y-Befürworter in meinem aktuellen Unternehmen und die Bewältigung semantischer Fehler/Probleme in unserem System ist eine ziemliche Herausforderung. Erstens ist es eine alte Codebasis, die keiner Styleguide folgte und sich nicht um User Flows kümmerte. Wir „modernisieren“ sie Stück für Stück, indem wir den FE-Code in wiederverwendbare Komponenten aufteilen. Komponenten sind cool, aber wenn wir anfangen, ein Layout zusammenzusetzen, wird die Kontrolle über semantische Aspekte wie Überschriftenreihenfolge und Landmarks schwierig.
Eine Lösung könnte die Verwendung von Wrapper-Komponenten sein, die das Übergeben optionaler Props wie Überschriftenebene ermöglichen.
Ich denke, a11y ist keine Frage des bloßen Lernens von HTML und Semantik, es ist eine gemeinsame Anstrengung des gesamten Teams und UX-Designer sind ein riesiger, riesiger Teil der Lösung (oder des Problems).
Vielleicht kann HTML5 einen Debug-Modus einführen. Zum Beispiel lässt ein Tool wie Dreamweaver Sie solche Dinge nicht vermissen (auf sehr einfacher Ebene) es sagt Ihnen, dass Sie z. B. Alt-Tags vermissen lol.
Soweit ich das sehe, gibt es verschiedene Arten von Bugs auf Websites, darunter……
Fehler, die die Funktion beeinträchtigen – Die Website funktioniert wegen ihnen nicht
Visuelle Fehler – Die Website funktioniert, aber die Ränder sind falsch, der Button ist falsch dimensioniert usw.
Barrierefreiheitsprobleme – Die Website tut alles, was sie soll, und sieht gut aus, es sei denn, Sie verwenden Barrierefreiheitstechnologie.
Das Problem ist, dass Sie, wenn Sie beim ersten Fehler scheitern, der Kunde Sie nicht bezahlt. Die Seite muss funktionieren. Wenn Sie ein paar visuelle Fehler haben, werden Sie wahrscheinlich trotzdem bezahlt, aber der Kunde beschwert sich vielleicht ein wenig und Sie möchten sie wahrscheinlich beim nächsten Mal beheben. Wenn Sie Barrierefreiheitsprobleme haben, müssen Sie zusätzliche Anstrengungen unternehmen, um überhaupt zu wissen, dass sie vorhanden sind, der Kunde bemerkt sie zu 90 % der Zeit nicht einmal.
Barrierefreiheit ist also wahrscheinlich nicht so schwer, ich glaube nicht, dass das das Problem ist. Wenn Websites nicht richtig funktionieren würden (d. h. nicht laufen würden), bis Barrierefreiheitsprobleme behoben sind, wären wir alle am Ende der Woche Experten für Barrierefreiheit.
Ich bin seit fast zwei Jahrzehnten Webdesignerin und weiß mit Sicherheit, dass eine Website, die nicht konform ist, fast zu 100 % auf mangelndes Wissen und nicht auf Bosheit zurückzuführen ist. Keiner der Webdesigner in meinem Team – einige sind frisch von der Universität, andere machen das schon so lange wie ich – weiß, welche Gesetze und Anforderungen eine ADA-konforme Website hat. Das wird nicht an Universitäten gelehrt, wird nicht wirklich auf Online-Blogs wie diesem behandelt und man hört es nirgendwo sonst wirklich diskutiert.
Ehrlich gesagt und beschämenderweise wusste ich bis vor einer Woche, als ich vom Domino's-Fall hörte, nicht einmal, dass es tatsächliche Gesetze und Anforderungen gab, an die ich mich als Designer halten musste. Natürlich kannte ich Alt-Tags und so, aber ich hatte das immer als Bequemlichkeit für Benutzer mit Screenreadern oder so angesehen. Mir war nicht bewusst, dass es gesetzlich vorgeschrieben war.
Das Traurige ist, dass ich in der letzten Woche mehrmals gesucht habe, was die tatsächlichen Gesetze und Vorschriften sind, und alles, was ich finden kann, ist ein Haufen juristisches Kauderwelsch oder Websites, die scheinbar von Anwälten geschrieben wurden. Es gibt nichts da draußen, was ich finden konnte – selbst von traditionell einfach zu bedienenden Unternehmen wie Mozilla oder Google –, das prägnant, leicht lesbar, verständlich oder benutzerfreundlich war. Ich verlange keine Stichpunktliste von Regeln, die ich einfach abhaken könnte, aber es ist unmöglich, etwas zu finden, das nicht frustrierend unmöglich zu verstehen ist.
Ich weiß, dass Sie nicht nach einer Checkliste gefragt haben, aber ich denke, Vox Media hat eine gute: https://accessibility.voxmedia.com/ Ich mag es besonders, dass es die Barrierefreiheit über das Produkt hinweg abdeckt – es ist nicht nur die Verantwortung eines Entwicklers. Universitäten und Regierungsbehörden haben oft auch gute Dokumente zu barrierefreien Webpraktiken, da sie schon seit einiger Zeit an vorderster Front dieser Überlegungen stehen.
Außerdem nimmt Google Barrierefreiheit in seine Web-Grundlagen-Materialien auf (sowohl als Dokumente als auch als kostenloser Kurs auf Udacity): https://developers.google.com/web/fundamentals/accessibility
Schließlich, wenn Sie Ihre Kenntnisse über Barrierefreiheit verbessern möchten, empfehle ich diesen wöchentlichen Newsletter: https://a11yweekly.com/ Er enthält immer einen Abschnitt für Neulinge in Sachen Barrierefreiheit und ist eine gute Möglichkeit, Barrierefreiheit für Entwickler im Vordergrund zu halten.
In der Tat. WCAG wird nicht an Universitäten gelehrt. Als Accessibility Developer habe ich WCAG durch mehrere Kurse und die Arbeit mit Vision Australia viele Jahre nach meinem Abschluss gelernt. Ich bin froh, dass ich das getan habe, da Online-Barrierefreiheit die Zukunft der Webentwicklung ist, sie spielt eine zentrale Rolle in meinem Geschäft und die Zukunft sieht jeden Tag hell aus.
Ich habe mich also damit beschäftigt, die Dinge, die ich baue, zugänglicher zu machen, und das Problem, auf das ich stoße, ist Zeit. Ich habe einfach keine Zeit, es zu testen, und ehrlich gesagt habe ich auch nicht das Wissen über all die verschiedenen Arten, Barrierefreiheit zu testen. Also kann ich ein Projekt mit der Absicht beginnen, es ein Barrierefreiheits-Meisterwerk zu sein, aber wenn die Fristen näher rücken, bin ich gezwungen, mich nur auf semantische Markups zu konzentrieren.
Der zweite Teil der Barrierefreiheit ist, dass es nicht nur um Screenreader und Farbkontrast geht. Es gibt eine breite Palette von Behinderungen, die mehr sind als nur Benutzer mit Screenreadern. Wenn also nicht das gesamte Team darüber nachdenkt und darauf hinarbeitet, wird Ihre Code, egal wie barrierefrei er ist, immer noch nicht konform sein.
Was wir brauchen, sind mehr Werkzeuge und Ressourcen, die uns allen, Entwicklern, Designern und Content-Erstellern gleichermaßen helfen können. Wir brauchen Möglichkeiten, wie oben erwähnt, die uns bei der Qualitätssicherung helfen. Gibt es ein Browserstack für assistierende Technologien? Wir brauchen auch unsere Produktmanager und Stakeholder, die verstehen, dass all dies etwas mehr Zeit in Anspruch nimmt, aber ihr Produkt für ein neues Publikum öffnet.
Barrierefreiheit ist auch schwer, weil Barrierefreiheit sich auf die „Zugänglichkeit“ eines Einzelnen bezieht – und diese hat eine riesige Variationsbreite, die noch keine Regelwerk (bisher) vollständig abdecken kann. Deshalb verwendet WCAG den Begriff „Richtlinien“, nicht Regeln. Es ist nicht möglich, jedes mögliche Szenario der Web-Barrierefreiheit abzudecken, da es so individuell wie jeder Mensch ist, über die Zeit variiert und sich letztendlich mit der Verbesserung von Technologie und Werkzeugen ändert.
Dieser Vortrag von Heydon Pickering hat die meisten meiner Bedenken hinsichtlich Barrierefreiheit gelöst. (Warnung, einige Schimpfwörter)
Der wichtigste Punkt, den ich daraus mitgenommen habe (bezüglich Barrierefreiheit), ist, dass einfaches HTML standardmäßig barrierefrei ist. Je weniger Code Sie schreiben, desto einfacher ist es, ihn barrierefrei zu machen.
In einigen Aspekten bricht Barrierefreiheit nicht leise, solange Sie Ihre Website kontinuierlich mit AT nutzen. Ich versuche immer, meine Websites regelmäßig nur mit der Tastatur, mit geschlossenen Augen und mit einem Screenreader usw. zu nutzen. Wenn also etwas kaputt geht, kommt es nicht sehr weit, bevor ich es bemerke (im Idealfall).
Ich denke also, ein Teil der Lösung hier ist, Anfängern der Webentwicklung beizubringen, mindestens 1/3 so oft ohne Maus und Augen zu testen wie mit; als Gewohnheit und Routine, nicht als „fortgeschrittene“ Best Practice. Wenn man sich daran gewöhnt, auf diese Weise zu surfen, wird es einem auch helfen, sich in Benutzer mit Behinderungen hineinzuversetzen und sie besser zu verstehen, und zu wissen, was zu tun ist, wenn man auf Barrierefreiheitsprobleme stößt.
Barrierefreie Websites sind überhaupt nicht schwer zu erstellen. Es braucht nur ein wenig Bewusstsein und Bildung. Ich mag Ihre Idee, dass Barrierefreiheitsprobleme in einem Code-Editor markiert werden, obwohl es bereits Tools wie pa11y gibt, die problemlos in den Workflow eines Entwicklers integriert werden können https://pa11y.org/
Was ich liebe, sind die Gründe, es nicht zu tun – Zeit und Ressourcen waren 2 genutzte Ausreden, die mich zu der Zeit praktisch gefesselt haben. Und erst jetzt, da Kunden darauf bestehen (obwohl sie es nicht müssten), wird Zeit dafür eingeräumt. Auch die höchsten Standards erfordern, dass Ihre Website/Anwendung auch mit ausgeschaltetem JS funktioniert :)
Auch was ist barrierefrei? Tastaturzugänglich? Ist der Farbkontrast für farbenblinde Personen ausreichend? Wie funktioniert es mit einem Screenreader? Wie funktioniert es für einen Benutzer, der keine Tastatur oder sogar eine Maus zum Navigieren verwendet? Wenn Sie Barrierefreiheit implementieren wollen, ist das Erste, was Sie tun müssen – eine Überprüfung der Barrierefreiheit durchführen zu lassen – es gibt Unternehmen, die sich auf diesen Bereich spezialisiert haben. Dann schauen Sie sich an, was Sie liefern müssen, welches Mindestniveau Sie anstreben. Und wenn Sie entwickelt haben – lassen Sie es erneut überprüfen. Weiter entwickeln, weiter überprüfen usw. Es ist ein fortlaufender Prozess, besonders wenn Sie neue Funktionen/Funktionalitäten hinzufügen.
Und eine Konformitätserklärung ist so ziemlich der Schlüssel, diese wird Ihren Endbenutzer genau darüber informieren, was Sie unterstützen (z. B. https://www.bbc.co.uk/guidelines/futuremedia/accessibility/)
Ich bin eine Frontend-Entwicklerin, die zur Barrierefreiheitsberaterin geworden ist, und ich stimme voll und ganz zu, dass es mangelndes Wissen, nicht Bosheit, ist, das das Problem verursacht. Ich kann an einer Hand abzählen, wie viele Leute voreingenommen oder feindselig gegenüber meinen Eingaben waren, während alle anderen, die ich in meiner achtjährigen Karriere bisher getroffen habe, einfach nur herausfinden wollten, was das Richtige ist. Ich würde gerne Barrierefreiheit auf Anfängerniveau unterrichtet sehen, ich denke, das würde einen großen Unterschied machen. Ein weiterer Ort, an dem Leute helfen können, ist sicherzustellen, dass ihre Tutorials und Werkzeuge auch zugängliche Ergebnisse liefern. CSS Tricks ist da immer so gut!
Nicht jeder kann sich einen Berater leisten, also habe ich einen kleinen Lernplan für Barrierefreiheit geschrieben – er ist noch ein Entwurf, also wenn Sie Verbesserungsvorschläge haben, würde ich mich freuen, sie zu hören. https://github.com/stringyland/a11y-learning-plan Die Version in einfacher Sprache von WCAG von WebAIM ist auch großartig: https://webaim.org/standards/wcag/checklist
Das Argument „Es ist zu schwer“ kaufe ich jedoch nicht. Leute lernen ständig neue Frameworks, neue Funktionen. Sie schreiben ganze Codebasen neu, um Hooks oder was auch immer die neueste Modeerscheinung dieser Woche ist, einzubeziehen. Webentwickler sind schlau und mehr als fähig, die nötige Anstrengung zu unternehmen, um Barrierefreiheit zu lernen.
Gesetzgebung hat auch außerhalb der USA viel zur Förderung des digitalen Zugangs beigetragen. Sie schafft einen gemeinsamen Standard oder eine Basis, auf die jeder hinarbeiten und Ressourcen teilen kann. Ich hoffe, dass die
„Was wäre, wenn unsere Texteditoren Barrierefreiheitsprobleme erkennen und uns während der Entwicklung anzeigen würden?“ Webhint.io tut genau das. :)
Für VS Code sollte ich sagen, unter Verwendung der aXe-Barrierefreiheitsregeln.
Gibt es etwas mehr zu tun, als bei den Barrierefreiheitstests von Chrome Lighthouse gut abzuschneiden?
Es gibt KEINE Apps, die mehr als 15-20 % der Barrierefreiheitsprobleme identifizieren oder beheben. Das weiß ich. Ich bin blind und habe mit Microsoft und vielen Bundesbehörden bei der Abwehr von Klagen zusammengearbeitet. Man kennt sich aus oder man kennt sich nicht aus… Und die meisten UI/UX-Leute haben immer noch keine Ahnung.
Ich schätze, das bedeutet, ich habe Jobsicherheit.
Die meisten Barrierefreiheitstests betrachten die statische Seite – sie stellen also sicher, dass Sie semantisches HTML verwenden, Ihre Bilder über Alt-Texte verfügen und der Kontrast angemessen ist. Dies sind alles wichtige Überlegungen, aber sie testen keine Interaktionen – kann ein Screenreader-Benutzer erkennen, ob Ihr Hamburger-Menü geöffnet oder geschlossen ist? Werden Formularfehlermeldungen von Screenreadern vorgelesen? Usw. usw.
Diese erfordern entweder maßgeschneiderte Tests oder praktische Barrierefreiheitsprüfungen.
Ja, denn so gut Lighthouse auch ist, es kann nur auf Probleme prüfen, die durch fehlerhaften Code verursacht werden. Es gibt Probleme mit Inhalt und Interaktion, die manuelle Tests erfordern. Sie müssen alle Punkte auf der WCAG 2.1-Kriterienliste überprüfen – es gibt eine Kurzversion von WebAIM: https://webaim.org/standards/wcag/checklist und The A11y Project hat ebenfalls eine gute Einführung in grundlegende manuelle Tests: https://a11yproject.com/
Nun, ich kann durchaus anerkennen, dass mehr dazugehört und wir mehr tun müssen. Manuelle Listen werden uns jedoch nicht dorthin bringen – die Leute werden sie einfach nicht verwenden. Wir haben auch WAVE und Axe (Chrome-Erweiterung) verwendet. Je mehr wir diese nutzen, desto mehr lernen wir und integrieren die Techniken in unseren Standard-Website-Entwicklungsprozess. Wie schätzen Sie die Fähigkeit dieser Tools ein, reale Probleme zu lösen?
Hallo Sean, die Antwort wäre ja – es muss mehr getan werden. Das a11y-Audit von Lighthouse soll Sie mehr oder weniger in die richtige Richtung lenken und Ihnen eine Vorstellung davon geben, wie gut Sie abschneiden. Nicht um den Topf aufzuwirbeln und die Arbeit des Lighthouse-a11y-Teams zu diskreditieren, aber dieser eine Blogbeitrag machte die Runde, als jemand das Audit-Tool *manipulierte* und auf einer nicht zugänglichen Website eine Punktzahl von 100 erhielt. Lesen Sie ihn hier.
https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/
Natürlich gab es dazu einige Twitter-Threads, aber eine Sache, die erwähnt – und ignoriert – wird, ist, dass Google hinzufügt, dass es „das Lighthouse-Audit nicht alles testen kann“ und „wir auch eine ganze Reihe von manuellen Audits mit Dokumentation hinzufügen, die erklärt, wie sie durchgeführt werden.“ (via Rob Dodson).
Die meisten a11y-Profis werden Ihnen sagen, dass Sie sich nicht zu sehr auf automatisierte Tools verlassen sollten. Sie sind nützlich, aber einige Fälle werden immer durchrutschen. Ich hatte ein Gespräch mit Rob darüber, und ein Teil dieses Problems – so empfand ich – war die Punktzahl. Leute hängen daran wie an einer Goldmedaille. Eine 100 bedeutet also, dass Sie fertig sind – aber das sind Sie eigentlich nicht.
bezüglich Ihres zweiten Kommentars, wie nützlich die vorhandenen Tools sind… Ich würde sagen, Chrome's Lighthouse ist mein Favorit, weil es so einfach zu bedienen ist, aber aXe und WAVE sind auch gut (ich habe gehört, dass bald ein neues WAVE-Update kommt!). Sie sind sehr gut in dem, was sie tun, und geben auch gute Empfehlungen für Korrekturen. Aber ein automatisiertes Tool kann nur 20 bis 25 % der potenziellen Probleme abdecken. Immerhin sind das 20 %, mit denen Sie sich nicht manuell auseinandersetzen müssen, wie wir es noch vor wenigen Jahren tun mussten. Der Widerspruch besteht darin, dass Barrierefreiheit ein Problem ist, das auf menschlicher Vielfalt und Flexibilität beruht, und Automatisierung auf Replikation und Mustererkennung ausgerichtet ist. Es bedarf wirklich menschlicher Aufmerksamkeit, sowohl vor der Entwicklung (im Design und Inhalt) als auch bei den Tests durch Entwickler, wie die Dinge in der realen Welt tatsächlich funktionieren, wenn wir unsere schöne, aufgeräumte Entwicklungsumgebung verlassen. Nutzen Sie Lighthouse auf jeden Fall weiter! Aber vertiefen Sie sich auch in seine Empfehlungen für manuelle Tests oder schauen Sie sich Microsoft Insights für weitere manuelle Testprozesse an, denen Sie folgen können.
Ich kann bestätigen, dass Entwickler Barrierefreiheit nicht praktizieren, weil die Leute einfach nicht davon wissen. Bevor ich mich selbst mit der Prüfung von Barrierefreiheit beschäftigte, arbeitete ich 4 Jahre lang als freiberuflicher Webentwickler, beginnend im Jahr 2012. Ich wechselte von einem kurzfristigen Vertrag von 3 oder 6 Monaten zum nächsten, einschließlich der Arbeit mit einigen sehr bekannten großen Unternehmen mit sehr großen Websites. Während dieser Zeit hörte ich nie jemanden sagen: „Wir haben keine Zeit dafür“ oder „Wir können es uns nicht leisten“ oder etwas Ähnliches. Tatsächlich hörte ich in all diesen vier Jahren nie das Wort „Barrierefreiheit“ einmal erwähnt! Auch nicht das Akronym „WCAG“. Nicht einmal, weder von Kollegen, noch von Designern, noch vom Management.
Barrierefreiheit war einfach nichts, was irgendjemand kannte. Erst gegen Ende dieser Zeit entdeckte ich sie selbst, als ich zufällig im Internet darauf stieß und erforschte, worum es ging. Also nahm ich eine Stelle bei einer der größten Beratungsfirmen für Barrierefreiheit an und machte mich später selbstständig.
Ich betrachte diesen Wissensmangel als ein Versäumnis meines neuen Berufsstandes, den Rest der Welt zu unterrichten. Wir verbringen viel Zeit damit, uns gegenseitig zu unterrichten, und etwas Zeit damit, Material für Entwickler zu veröffentlichen, falls sie es finden sollten. Aber wir widmen fast keine Zeit der Öffentlichkeitsarbeit für die Entscheidungsträger in Industrie und Handel, für das Management und die Vorstände. Manchmal hören sie erst davon, wenn eine Klage auf ihrem Tisch landet.
Seien Sie vorsichtig mit automatisierten Tools. 100 % bei Lighthouse, Axe oder was auch immer Sie verwenden, bedeuten *keinen* Barrierefreiheits-Pass. Es ist nur ein Hinweis darauf, dass Sie in die richtige Richtung gehen.
Versuchen Sie, echte Menschen einzubeziehen. Benutzen Sie selbst Bildschirmlesegeräte, testen Sie ohne Maus, wenden Sie Farbfilter an, um die 8 Hauptarten von Farbenblindheit zu testen, prüfen Sie das Lesefähigkeitsalter/den Textgrad, betrachten Sie die Größe der Elemente und überlegen Sie, wie Menschen, die Schwierigkeiten haben, ihre Hände zu benutzen, navigieren könnten.
Ich stimme vollkommen zu, aber ich denke, wenn Entwickler häufige Erinnerungen in ihren Editoren zu diesem Thema bekämen, würde das allgemeine Bewusstsein stark zunehmen. Sie würden vielleicht anfangen, es zumindest als eine weitere Code-Qualitätsproblem zu betrachten.
Wenn Sie die Webhint.io-Erweiterung für Visual Studio Code verwenden, können Sie genau das bekommen. Sie unterstreicht Elemente mit Barrierefreiheitsproblemen mit geschwungenen Linien.
Hallo Robin und Besucher,
Applaus für Ihre Idee: *Was wäre, wenn unsere Texteditoren Barrierefreiheitsprobleme erkennen und uns während der Entwicklung anzeigen würden?* Mit der eindringlichen Warnung, dass nicht *alle* Probleme automatisch gefunden werden können und weitere Tests unvermeidlich sind.
– Auch Lob für die Bildungsvorschläge in den Kommentaren!
Werkzeuge
Nicht in einen Texteditor eingebettet, aber mit einem Klick erreichbar, gibt es einige nützliche Werkzeuge. So wie Sie ab und zu den HTML-Validator und CSS-Validator während der Entwicklung auf Tippfehler und schwerwiegendere Probleme prüfen, können Sie die Barrierefreiheit (bis zu einem gewissen Grad) auf die gleiche Weise überprüfen; und wie die Anmerkungen des HTML- und CSS-Validators nicht immer ausreichend sind.
Wenn dies während des Prozesses zur Gewohnheit wird, müssen Sie die Hauptstruktur der Seite nicht neu aufbauen, wenn alles andere fertig ist!
Seit über 10 Jahren gibt es zum Beispiel
Die University of Illinois hat einen „FAE: Functional Accessibility Evaluator“, der einen detaillierten Barrierefreiheitsbericht für eine Website erstellen kann (registrieren Sie ein kostenloses Benutzerkonto) mit Anweisungen zur Lösung von Problemen. Siehe: https://fae.disability.illinois.edu/
Für Single-Page-Anwendungen gibt es eine Version des FAE als Firefox-Plugin (ohne Registrierung): https://addons.mozilla.org/en-US/firefox/addon/ainspector-wcag/
Ein weiteres Tool ist von WebAIM (WebAccessibilityInMind, https://webaim.org/): das Web Accessibility Evaluation Tool WAVE, https://wave.webaim.org/, das online verwendet werden kann.
Es gibt auch WAVE-Browsererweiterungen für Firefox und Chrome: https://wave.webaim.org/extension/
Hinweis: Ich stimme Ashley Sheridan und anderen zu: *„Seien Sie vorsichtig mit automatisierten Tools“*.
Bildung
Beide Validatoren können auch exzellente Dienste in der Praxis der Barrierefreiheitsbildung leisten.
Mehr Infos: Die Web Accessibility Initiative (WAI) des W3C, https://www.w3.org/WAI/, hat eine Beschreibung wesentlicher Ressourcen für die verschiedenen Rollen der beteiligten Personen in Bezug auf Barrierefreiheit: von Politikern über Designer, Entwickler, Tester, Pädagogen usw. bis hin zu Webnutzern. Siehe: https://www.w3.org/WAI/roles/.
Siehe auch: Teach and Advocate Overview, https://www.w3.org/WAI/teach-advocate/
Standards
Die WCAG (Web Content Accessibility Guidelines, https://www.w3.org/WAI/standards-guidelines/wcag) bieten viele nützliche Barrierefreiheits-Techniken. Die WCAG-2.1 ist die neueste Version: Empfehlung vom 5. Juni 2018.
In der Zwischenzeit hat das W3C das „Accessibility Conformance Testing (ACT) Rules Format 1.0“ (https://www.w3.org/TR/act-rules-format/) entwickelt, eine vorgeschlagene W3C-Empfehlung vom 30. Juli 2019. Aus ihrer Einleitung:
„Es gibt derzeit viele Testverfahren und Werkzeuge, die ihre Benutzer bei der Prüfung von Webinhalten auf Konformität mit Barrierefreiheitsstandards wie den Web Content Accessibility Guidelines [WCAG] unterstützen. Da das Web in Größe und Komplexität wächst, sind diese Verfahren und Werkzeuge unerlässlich für die Verwaltung der Barrierefreiheit von im Web verfügbaren Ressourcen.
Dieses Format soll eine konsistente Interpretation ermöglichen, wie die Konformität mit WCAG und anderen Barrierefreiheitsanforderungen getestet wird, und konsistente Ergebnisse bei Barrierefreiheitstests fördern. Das Regelnformat wurde entwickelt, um sowohl manuelle Barrierefreiheitstests als auch automatisierte Tests durch Barrierefreiheitstestwerkzeuge zu beschreiben.“
Der Fokus auf universelle Barrierefreiheit wächst also!
Viele Leute wissen nicht einmal, dass die Web Accessibility Initiative Authoring Tool Accessibility Guidelines veröffentlicht (https://www.w3.org/WAI/standards-guidelines/atag/), die Barrierefreiheitsstandards für Software und Dienste festlegen, die zur Erstellung von Webinhalten verwendet werden.
Die Richtlinien umfassen nicht nur die Barrierefreiheit des Tools selbst, sondern verlangen auch, dass das Tool genau das tut, was in diesem Artikel vorgeschlagen wurde: Autoren (seien es Entwickler, Designer, Schreiber oder was auch immer) beim Erstellen barrierefreier Inhalte zu helfen. Diese Richtlinien werden übersehen, und ich denke, viele unserer Code-Editoren sowie beliebte Content-Management-Systeme könnten viel besser werden, wenn wir uns mit diesen Richtlinien vertraut machen und sie gut einsetzen.
Es gibt eine Web Accessibility-Erweiterung für VS Code (https://marketplace.visualstudio.com/items?itemName=MaxvanderSchee.web-accessibility), die problematische Elemente in HTML-Vorlagen identifiziert, aber sie funktioniert nicht in JavaScript-Framework-Vorlagen wie Vue.
Das nehme ich zurück – sie funktioniert in Vue, aber nicht in Pug-Vorlagen.
Anscheinend wissen Sie nicht, dass selbst DIESE Seite für mich UNZUGÄNGLICH ist. Die ersten ZWEI Sichten sind ein Menü, wobei der Inhalt OBEN beginnen, bei der DRITTEN Ansicht. Weiterhin beginnt der Inhalt mit „dem öffentlichsten Beispiel für ein Unternehmen, das wegen mangelnder Barrierefreiheit verklagt wurde“, was mir sagt, dass sich VERSTECKTER Inhalt UNTER dem Menü auf den ersten beiden Ansichten befindet.
Wenn Sie auf etwas beharren, das behoben werden muss, sollten Sie vielleicht MIT IHRER EIGENEN Website BEGINNEN, BEVOR Sie die schmutzigen Fenster anderer Leute kritisieren. Oder um es mit den Worten meiner Mutter zu sagen: WASCHEN SIE IHRE EIGENEN FENSTER, BEVOR Sie sich über die schmutzigen Fenster Ihres Nachbarn beschweren.
Wow, du bist aber aufgeregt, Kumpel. Atmen Sie tief durch und lesen Sie den Beitrag noch einmal. Hier gibt es keine Verurteilung – lediglich die Feststellung, dass der Aufbau barrierefreier Websites schwierig ist und die Frage, warum das so ist. Kein Grund, Granaten zu einer Teeparty mitzubringen.
Hallo. Ich bin ein Anwalt, der sich auf ADA-Barrierefreiheitsklagen, einschließlich Website-Klagen, spezialisiert hat. Sie sind zu Recht verwirrt, denn das Gesetz ist unklar. Für bestimmte Regierungs-Websites gibt es eine Verordnung, die WCAG 2.0 AA verfolgt, und für Fluggesellschaften gilt dasselbe, aber für die meisten Unternehmens-Websites gibt es keinen regulatorischen Standard, dem man folgen kann. Die Regel, die niemanden zufriedenstellen wird, ist, dass eine Website „sinnvollen Zugang zu den Gütern und Dienstleistungen der Website“ für Personen mit Behinderungen bieten muss. Aus Bequemlichkeitsgründen haben Anwälte und einige Gerichte zu WCAG 2.0 AA gegriffen, und das ist der beste Ausgangspunkt für den Aufbau einer barrierefreien Website. Sie müssen nur wissen, dass die perfekte Einhaltung nicht garantiert, dass die Website dem ADA-Standard entspricht, da niemand genau weiß, was dieser Standard ist.
Ich stimme der Beobachtung zu, dass Websites mit automatisierten Tools getestet werden. Software-Tools können einige Arten von Barrierefreiheitsproblemen nicht erkennen und erzeugen auch Fehlalarme, da sie nicht unterscheiden können, ob Bilder dekorativ sind oder Bedeutung haben. Die einzige Möglichkeit, eine Website zu testen, besteht darin, dass behinderte Benutzer systematisch jede mögliche Benutzerinteraktion testen, um zu sehen, ob sie funktioniert.
Tatsächlich ist es ein weit verbreiteter Irrtum, dass das Testen einer Website durch Benutzer mit Behinderungen der einzige Weg ist. Es ist nicht der einzige Weg, nicht einmal der beste Weg, um die Barrierefreiheit zu testen. Obwohl es sicherlich sehr hilfreich ist, Benutzertests als Teil der gesamten Teststrategie einzubeziehen, benötigen Sie einen geschulten und erfahrenen Barrierefreiheits-Tester, um eine Website vollständig zu testen – aber es muss jemand sein, der sehen kann, was auf dem Bildschirm ist.
Ein Teilnehmer an dieser Konversation hat sich gerade bitterlich beschwert – und das zu Recht –, dass der obere Teil dieser CSS-Tricks-Seite, auf der wir uns gerade befinden, für ihn nicht verfügbar ist, alles bis zur zweiten Ansicht! Das ist ein riesiger Inhaltsteil, der für Screenreader unmöglich zu testen ist.
Nehmen Sie einige andere sehr häufige Fälle – Hauptmenü-Links können manchmal von Screenreadern nicht befolgt werden, wodurch ganze Seiten für Benutzer unerreichbar werden. Einkaufswagen sind oft nicht nutzbar oder manchmal sogar nicht erreichbar, weder per Tastatur noch per Screenreader. Oder ein weiteres sehr häufiges Muster auf Websites, der „Button“, der nur ein SVG-Symbol oder ein Hintergrundbild in einem Div ist, sodass Screenreader nichts anzukündigen haben und der Leser-Benutzer keine Ahnung hat, dass er existiert. Es bedarf eines professionellen Barrierefreiheits-Testers, um visuell zu sehen, dass er existiert, ihn zu überprüfen und dem Entwickler mitzuteilen, was zu tun ist.
Und gehörlose Menschen, die ein Video prüfen, können leider nicht sagen, wann Geräusche oder Ereignisse außerhalb des Bildschirms in die Untertitel aufgenommen werden sollten, aber nicht enthalten sind. Holen Sie sich also auf jeden Fall Benutzertester mit allen erforderlichen Behinderungen. Aber Sie benötigen einen geschulten WCAG-Tester oder Berater, um die primäre Barrierefreiheitsprüfung einer Website durchzuführen.
Tatsächlich ist es ein weit verbreiteter Irrtum, dass das Testen einer Website durch Benutzer mit Behinderungen der einzige Weg ist. Es ist nicht der einzige Weg, nicht einmal der beste Weg, um die Barrierefreiheit zu testen. Obwohl es sicherlich sehr hilfreich ist, Benutzertests als Teil der gesamten Teststrategie einzubeziehen, benötigen Sie einen geschulten und erfahrenen Barrierefreiheits-Tester, um eine Website vollständig zu testen – aber es muss jemand sein, der sehen kann, was auf dem Bildschirm ist.
Ein Teilnehmer an dieser Konversation hat sich gerade bitterlich beschwert – und das zu Recht –, dass der obere Teil dieser CSS-Tricks-Seite, auf der wir uns gerade befinden, für ihn nicht verfügbar ist, alles bis zur zweiten Ansicht! Das ist ein riesiger Inhaltsteil, der für Screenreader unmöglich zu testen ist.
Nehmen Sie einige andere sehr häufige Fälle – Hauptmenü-Links können manchmal von Screenreadern nicht befolgt werden, wodurch ganze Seiten für Benutzer unerreichbar werden. Einkaufswagen sind oft nicht nutzbar oder manchmal sogar nicht erreichbar, weder per Tastatur noch per Screenreader. Oder ein weiteres sehr häufiges Muster auf Websites, der „Button“, der nur ein SVG-Symbol oder ein Hintergrundbild in einem Div ist, sodass Screenreader nichts anzukündigen haben und der Leser-Benutzer keine Ahnung hat, dass er existiert. Es bedarf eines professionellen Barrierefreiheits-Testers, um visuell zu sehen, dass er existiert, ihn zu überprüfen und dem Entwickler mitzuteilen, was zu tun ist.
Und gehörlose Menschen, die ein Video prüfen, können leider nicht sagen, wann Geräusche oder Ereignisse außerhalb des Bildschirms in die Untertitel aufgenommen werden sollten, aber nicht enthalten sind. Holen Sie sich also auf jeden Fall Benutzertester mit allen erforderlichen Behinderungen. Aber Sie benötigen einen geschulten WCAG-Tester oder Berater, um die primäre Barrierefreiheitsprüfung einer Website durchzuführen.
Warum ist Barrierefreiheit so schwer? Wer hier hat es geschafft, die Zahnpasta wieder in die Tube zu bekommen?? Meist niemand.
Wenn man sich mit etwas wie Barrierefreiheit *nach der Tatsache* beschäftigt, ist die Implementierung noch schwieriger als bei einer gut optimierten Website. Echte a11y-Experten werden Ihnen sagen, dass der beste Test mit echten Benutzern ist. Und das erfordert Zeit *und* eine angemessene Planung – beides wird nie zugewiesen.
Davon abgesehen, kann es auch *ohne* echte Benutzer geschehen, aber es muss immer noch als Teil der gesamten einfachsten Planung (und idealerweise Tests) berücksichtigt werden. Und egal wie man es dreht, die Herausforderungen der Barrierefreiheit werden wahrscheinlich mit der Komplexität der Website zunehmen. Sie schreiben einfacheren Code und werden wahrscheinlich leichter zugängliche Dinge machen. Karl Groves von Tenon.io hat einen großartigen Vortrag über einige der Hauptprobleme in a11y. Web AIM hatte auch einen großartigen Beitrag, der die Ergebnisse der Überprüfung von 1 Million Websites detailliert beschreibt – ein Muss. https://webaim.org/projects/million/
Schließlich haben wir in Toronto das Glück, ein unglaubliches Meetup zu haben, das auch jedes Jahr ein a11y Camp (kostenlos, 1 Tag, mehrere Tracks) organisiert, und wir hatten letzte Woche eine vollwertige a11y Conf – 2 Tage mit internationalen Präsentationen. Lesezeichen setzen Sie diese Seite, wenn Sie sich für a11y-Pädagogik interessieren. https://conf.a11yto.com
Die BBC hat einen Barrierefreiheits-Standardprüfer, der auf npm verfügbar ist und Node.JS verwendet: https://github.com/bbc/bbc-a11y. Er kann in Projekten für die Entwicklung verwendet und gegen URLs eingesetzt werden. Er folgt den Barrierefreiheitsstandards der BBC, die sehr detailliert sind: http://www.bbc.co.uk/guidelines/futuremedia/accessibility/
Hallo liebe Web-Geeks und Front-End-Nerds!
Ich wollte nur etwas erwähnen. Ich würde argumentieren, dass wir vorsichtig sein müssen, wie wir dieses Thema behandeln und nutzen… als Gemeinschaft.
Aus meiner Sicht liegt die Antwort auf die Frage des OP bei den Budgets. Das bedeutet, dass Unternehmen all die Zeit (in meinem Fall als reiner Webentwickler) die Webentwicklung und das Webdesign grob unterbudgetiert haben. Wenn auch weniger für Webdesign.
Ich erwähne, vorsichtig zu sein, weil eine legitime rechtliche Bedrohung wie der Domino's-Fall genau der Anstoß ist, den die meisten Firmen brauchen, um ihre Produktionsabläufe neu zu bewerten. Hier ist also mein Hack/Patch für diesen Moment:
Implementieren Sie ein Webdesignsystem, das erfordert, dass alle aktuellen und neuen Ergänzungen des Systems (in der UI-Kategorie) vollständig in die Barrierefreiheitsstandards integriert sind, bevor sie zum System hinzugefügt werden. So sind in der Praxis und bei der Verwendung des Designsystems durch Mitarbeiter zur Erstellung von Dingen, jede einzelne Code-Snippet bereits mit Barrierefreiheitsattributen sowie den Beziehungen ihrer Werte markiert.
Nehmen Sie das Nachdenken heraus und behandeln Sie es wie einen Basissstandard. Behandeln Sie sie wie HTML-, HEAD- und BODY-Tags. 24/7/365,25
Diese einfache Umstellung verändert die Dynamik dieses Problems vollständig. Denn jetzt müssen Designer und Entwickler physisch Barrierefreiheitsattribute löschen, um diese Komponente oder dieses Element unzugänglich zu machen. Ansonsten ist alles da und benötigt nur den richtigen Kopiertext oder Selektor!
Aber der Schlüssel dazu ist in der Realität, das Webdesignsystem zur einzigen Quelle der Wahrheit für alle Unternehmens-Builds zu machen (wo Variationen desselben Systems in verschiedenen Projekten verwendet werden). Keine Ausnahmen. Daher ist es bei weitem am einfachsten, Ihr Webdesignsystem zu reparieren und dem Unternehmen beizubringen, es von dort zu beziehen und zu installieren. Boom. Jetzt „verstehen“ die Designer auch wirklich Agile. Woot.
An diesem Punkt wird Barrierefreiheit zu einem normalen Bestandteil jeder Bewegung auf einer Seite. Und jetzt müssen wir uns keine Sorgen mehr machen, auf automatisierte Lösungen zu warten… denn wir können dieses Problem besser als einfach ein Team von fleißigen Leuten durch progressive Verbesserungen des Designsystems lösen. KISS.
Viel Spaß beim Codieren! :)
Ich fand WUHCAG (nicht zu verwechseln mit WCAG) als eine sehr nützliche Website, um Barrierefreiheitskriterien klar und sinnvoll zu erklären. Es half mir, die einzelnen Kriterien zu verstehen, als ich versuchte, mehr über Barrierefreiheit zu lernen.
Die Situation mit Domino's Pizza war ein spezifischer Fall, der außerhalb der Norm liegt. Sie haben höchstwahrscheinlich eine bewusste Entscheidung getroffen, nicht extra für Barrierefreiheit zu bezahlen, und dachten, dass mehrere Kommunikationskanäle ausreichen würden.
Die zusätzlichen Vorabkosten wären deutlich geringer gewesen, als für die Nachrüstung von über 3 Millionen Dollar und die Prozesskosten und Vergleichszahlungen aufzuwenden. Das ist jedoch typisches Unternehmensverhalten und es ist keine Überraschung, dass es so kam. Wir sahen dasselbe bei der BP-Ölpest, wo sie sich entschieden, Kosten zu sparen und 10 Millionen Dollar zu sparen, nur um dann Gerichtskosten und 20-25 Milliarden Dollar an Zahlungen leisten zu müssen. Die kalifornischen Brände vor 2 Jahren, bei denen das Stromversorgungsunternehmen in der Gegend defekte Geräte hatte, die im Trockenwetter die Brände auslösten, entschieden sich, die Ausrüstung nicht zu erneuern, und verursachten dann das Feuer, weshalb sie sich mit einer Menge von Zivilklagen, Regierungsstrafen auseinandersetzen mussten und ihre Ausrüstung immer noch aufrüsten mussten.
Denkweise der Unternehmenskultur – „Dieses Gesetz gilt nicht für uns“
Ich kann der Meinung über die Unternehmenskultur von Domino's nicht widersprechen, aber ihr Fall basierte auch auf einer mobilen App. Ich denke auch, es ist wichtig zu verstehen, dass die Barrierefreiheitsklagen nicht von echten Barrierefreiheitsproblemen angetrieben werden; sie werden von Anwälten angetrieben, die damit Geld verdienen. Eine typische Klage beginnt damit, dass ein Rechtsassistent ein Software-Tool gegen eine Website laufen lässt, um WCAG 2.0 AA-Fehler zu finden. Wenn etwas auftaucht, geht ein blinder Kläger, der wahrscheinlich Dutzende oder Hunderte von Fällen hat, auf die Website und stöbert herum. Er oder sie hat möglicherweise Schwierigkeiten mit der Website oder auch nicht, aber das spielt keine Rolle, denn der Softwarebericht ist die Grundlage der Klage und den Anwälten ist es egal, ob der Bericht Fehlalarme enthält. Sie brauchen nur etwas Deckung, falls der Vorwurf erhoben wird, sie hätten die Klage bösgläubig eingereicht. Die Klage wird eingereicht und die Kanzlei fordert zwischen 10.000 und 50.000 US-Dollar plus die Zusage, die Website über einen Zeitraum von 18 bis 24 Monaten zu reparieren, um sie abzuweisen. Die geringstmöglichen Kosten einer erfolgreichen Verteidigung übersteigen 10.000 US-Dollar, daher zahlen fast alle Unternehmen, außer den hartnäckigsten, und stimmen der Reparatur der Website zu und machen weiter. Sie zahlen möglicherweise sogar, wenn die Website perfekt zugänglich ist, nur weil der Nachweis der Zugänglichkeit teurer ist als die Bezahlung der Anwälte des Klägers. Barrierefreie Websites zu machen ist gutes Geschäft, aber es hat nichts mit Klagen oder der Vermeidung von Klagen zu tun, denn Klagen in diesem Bereich werden von Gier angetrieben, nicht von Fürsorge für Barrierefreiheit.
Barrierefreiheit als Entwicklungsproblem zu betrachten, ist einer der Gründe, warum sie als schwierig gilt. (Ich halte sie nicht mehr für schwierig)
Wenn wir die WCAG-Prüfpunkte und Barrierefreiheits-Testberichte von echten Nutzern mit assistiven Bedürfnissen durchlesen, wird klar, dass Barrierefreiheit eine ziemlich ausgeglichene Dreiteilung zwischen Inhalt, Design und Implementierung ist.
Automatisierte Tests sind nicht fortgeschritten genug, um Barrierefreiheitsprobleme im Inhalt zu erkennen, zum Beispiel, wenn eine Website mehrere Sprachen hat, könnte sie in einer Sprache gut getestet werden, in einer anderen aber nicht.
Auch wenn Entwickler wissen, was eine Lösung zugänglich macht, müssen die Designer und Content-Schreiber ebenfalls an Bord sein.
Was wäre, wenn die Leute wirklich lernen würden, was Semantik bedeutet, und was progressive enhancement bedeutet. Wenn sie diese Dinge wüssten, dann könnten sie Barrierefehler verstehen und beheben, bevor sie zum Problem werden.
All diese Frameworks und UI-Builder generieren Mist-Markup: Haufen von div und span, oh und wir werfen ein bisschen ARIA hinein, das wir nicht verstehen und dessen Einfluss wir nicht einmal sehen können, weil wir keine Screenreader benutzen, oh, aber jemand später wird es aufgreifen und wir werden iterieren.
Ugh!