Barrierefreiheit in Sitecore Forms MVC
Lesezeit: 6 Min
Auf diesen Blogbeitrag haben Sie vielleicht schon lange gewartet. Und das aus gutem Grund: Barrierefreiheit ist ein sehr wichtiges und aktuelles Thema für uns alle – auch für Entwickler:innen. In einigen Ländern (insbesondere in Deutschland) ist die Barrierefreiheit öffentlicher Einrichtungen gesetzlich vorgeschrieben. Aber es gibt keinen Grund, warum digitale Räume nicht dem gleichen Ethos folgen sollten. Es sollte unsere Aufgabe als Entwickler:in sein, das Internet für alle zugänglicher und barrierefrei zu machen. Auf diese Weise ermöglichen wir Menschen mit Behinderungen eine aktivere Teilnahme an der Gesellschaft. Als jemand, der seit 30 Jahren mit behinderten Menschen im Sport arbeitet, liegt mir dieses Thema sehr am Herzen.
Manchmal scheint es, als ob die ganze Welt im Internet verschwunden ist und bis zu einem gewissen Grad stimmt das auch. Soziale Kontakte, Unterhaltung, Finanzen, Bildung, Arbeit und so vieles mehr: Bei der Schaffung eines für alle zugänglichen Internets geht es nicht nur um den gleichberechtigten Zugang zu Informationen. Es geht auch um Chancengleichheit. Ein zugängliches Web gibt Menschen mit Behinderungen die Möglichkeit, aktiver an der Gesellschaft teilzunehmen. Tim Berners-Lee, W3C-Direktor und Erfinder des World Wide Web, brachte es sehr schön auf den Punkt, als er sagte: „Die Stärke des Web liegt in seiner Universalität. Der Zugang für alle, unabhängig von einer Behinderung, ist ein wesentlicher Aspekt.“
Es wäre jedoch ein Fehler, Barrierefreiheit als Wohltätigkeit zu betrachten. Jeder profitiert von der Barrierefreiheit. Menschen mit oder ohne Behinderung, Senioren, Kinder, Eltern und Menschen, die nur vorübergehend in ihrer Mobilität eingeschränkt sind. Ein Aufzug hilft Eltern mit Kinderwagen, alten Menschen und Menschen mit Gehbehinderung gleichermaßen. Das Engagement für einen gleichberechtigten Zugang geht über bloße Solidarität hinaus, es schafft Vorteile für die Gemeinschaft und die gesamte Gesellschaft.
In diesem Artikel werfen wir einen Blick auf einige Tipps und Tools für Sitecore Forms, die die Zugänglichkeit verbessern. Es spielt keine Rolle, in welcher Sprache Sie Ihren Code schreiben oder welche Technologie Sie verwenden, am Ende müssen Sie sich nur um Ihre HTML-Ausgabe kümmern und Ihre Elemente mit Aria-Attributen kennzeichnen, um Screenreader-Unterstützung zu haben oder z.B. Eingaben und Beschriftungen zu verbinden, Live-Regionen zu verwenden, usw.
Tools – Software
Beginnen wir mit einer kurzen Übersicht über einige Tools. Es gibt mehrere Tools, um das Verhalten eines Screenreaders zu überprüfen und um festzustellen, ob Ihre Website barrierefrei ist oder nicht.
Nicht-visueller Desktop-Assistent
Das wichtigste Tool, das ich Ihnen vorstellen möchte, ist der Non-Visual Desktop Assistant (NVDA). Meiner Meinung nach ist er einer der besten Screen Reader und die von Menschen mit Sehbehinderungen am häufigsten verwendete Software. Es gibt zwar viele Browsererweiterungen für Screen Reader, aber NVDA funktioniert auf dem gesamten Windows-System. Es ist zu 100 % kostenlos, quelloffen, hat einen integrierten Braille-Viewer und einen Sprachviewer, um zu sehen, was der Screen Reader vorlesen würde.
Entwicklertools (Chrome)
Die meisten modernen Browser verfügen bereits über eine Registerkarte für Barrierefreiheit in ihren Entwicklertools, mit der Sie überprüfen können, ob Ihre Elemente zugänglich sind.
Kontrastprüfer
Vielleicht haben Sie bemerkt, dass die Entwicklertools bereits über eine Kontrastprüfung verfügen. Dies ist hilfreich, um die Bedürfnisse von Menschen zu erfüllen, die rot-grün farbenblind sind. Für sie werden Rot und Grün als Grautöne wahrgenommen, aber das bedeutet nicht, dass die Website schwarz-weiß sein muss. Allerdings sollten Sie mit den Kontrasten vorsichtig sein.
https://webaim.org/resources/contrastchecker/
https://github.com/ThePacielloGroup/CCAe
HTML-Validierer
Wir wollen immer eine gültige HTML-Ausgabe generieren, und dafür verwenden wir den HTML-Validierer.
Wie geht es weiter?
Das war jetzt eine ziemlich lange Einführung, aber es war notwendig, Sie für das Thema zu sensibilisieren. Jetzt werden wir all die Backend-Änderungen behandeln, um Upgrade-fähig zu sein. Diese Änderungen werden von zukünftigen Sitecore-Updates nicht betroffen sein und müssen nicht überschrieben werden. Werfen wir einen Blick darauf.
Backend-Anpassungen
Nach dem Symposium kann sich einiges geändert haben. Das bedeutet aber nicht, dass die Änderungen in der Kern-DB nicht eingeführt werden können! Wie ich bereits erwähnt habe, leben wir heutzutage in einer SaaS-Welt. All diese Änderungen könnten problemlos in XM Cloud ausgerollt werden, aber Sie müssen sich noch um das Frontend kümmern. Meine nächsten Aufgaben werden darin bestehen, dies auf Next.js oder einem anderen modernen Framework zu tun.
Die Hauptaufgabe bestand darin, das gesamte Sitecore Forms Backend zu überarbeiten. Das heißt, ich verstecke alle Standard-Sitecore
Expander, erstelle meine eigenen neuen Expander, kopiere alle Felder, die ich barrierefrei haben möchte, und füge schließlich all diese Felder zu meinen benutzerdefinierten Expandern hinzu.
Ich habe alle Felder in der Master-DB in einen separaten Ordner gelegt und alle Standardfelder kopiert, damit sie Upgrade-fähig sind. Die Standardexpander von Sitecore wurden ausgeblendet, um dem Kunden nur die Felder zu zeigen, die für die Barrierefreiheit bereit sind (nicht Teil des Pakets).
An den Ansichten wurden eine Menge Änderungen vorgenommen. Hier ist ein Vergleich zwischen der Sitecore-Standardansicht und meiner:
Standardansicht:
Benutzerdefinierte Ansicht:
Wie Sie vielleicht bemerkt haben, habe ich eine Menge Änderungen an den Ansichten vorgenommen. Das lässt sich aber auch leicht an Next.JS anpassen. Es geht nur darum, die Felder aus dem Backend einzuholen und sie zu rendern. Das Interessante ist, dass, was ich in Core DB geändert habe, Sitecore Rocks immer noch nicht tot ist!
Zuerst habe ich dem Sitecore Forms Backend neue Expander hinzugefügt. Sie sind alle als A11Y (Abkürzung für Barrierefreiheit) markiert:
Diese Expander enthalten mehrere Felder, die für die Zugänglichkeit vorbereitet sind:
Wie Sie sehen können, sind alle Felder mit (A11Y) markiert, um den Unterschied zwischen den Standard-Sitecore-Feldern und den überarbeiteten Feldern zu erkennen. Irgendwann möchten Sie vielleicht die Standarderweiterungen ausblenden, aber das bleibt Ihnen überlassen. So, das war ziemlich einfach, aber jetzt wollen wir uns die Felder selbst genauer ansehen. Hier geschieht die Magie.
Validierung
Viele Entwickler:innen wünschten benutzer:innendefinierte Validierungsmeldungen in MVC anstelle der standardmäßigen Sitecore-Validierungsmeldungen. Die Lösung war, ein zusätzliches Feld zum „Validation Expander“ hinzuzufügen. Prüfen Sie, ob es nicht leer ist, andernfalls verwenden Sie die Standard-Sitecore-Validierung als Fallback. Und das war’s! Von nun an werden diese Meldungen benutzer:innenfreundlich sein.
Stellen Sie sich vor, die Standard-Validierungsmeldung einer Telefonnummer lautet „Telefonnummer ist erforderlich“. Von nun an können Sie eine Validierungsmeldung wie „Bitte geben Sie eine Telefonnummer ein, das Format sollte +49 1111 1111111 sein“ haben. Das ist doch viel freundlicher, oder? Sie können diese Meldungen für jede Sprache einstellen, ansonsten wird die Standard-Sitecore-Meldung angezeigt.
Autovervollständigung
Dies ist eine der wichtigsten Funktionen, die hinzugefügt wurde. Sie wissen vielleicht alle, dass Ihr Browser weiß, was Sie eingegeben haben, wenn Sie verschiedene Formulare mehrmals ausfüllen. Aber wie oft kommt es vor, dass Sie eine Telefonnummer oder eine Handynummer eingegeben haben, und in einem anderen Formular wird Ihre Handynummer als Telefonnummer übernommen, und so weiter. Jetzt können Sie die entsprechenden Werte direkt in die Felder eingeben. Auch kombinierte Werte sind möglich, z.B. „Telefon Privat“, „Telefon Arbeit“ oder „Telefon Mobil“. Dies ist eine große Hilfe für Menschen mit Sehbehinderungen. Oder stellen Sie sich vor, dass Menschen mit nur einem Arm das Formular mit nur EINEM Klick ausfüllen können!
Alle diese Werte werden als Aria-Attribute zu den Feldern hinzugefügt und von den Screen Readern erkannt.
Sicherheit
Eine letzte Ergänzung der Felder ist ein neues Sicherheitsfeld namens „Honeypot„. Dies ist eine Spam-Falle. Sie alle wissen, wie man Captchas einsetzt, um zu verhindern, dass Formulare von einem Bot eingereicht werden, was leider zur Schließung von Websites führen kann.
Es gibt verschiedene Captchas, wie z. B. Audio Captchas oder Re-Captcha, bei denen Sie Ampeln in 3×3 Kacheln finden müssen. Aber bedenken Sie, dass wir hier über Menschen mit Sehbehinderungen oder Menschen, die nicht hören können, sprechen. All diese Captchas werden für sie nicht funktionieren.
Honeypot ist eine einfache Lösung zur Verhinderung von Spam-Eingaben in Formularen. Es ist eigentlich nur ein verstecktes Feld. Und so funktioniert es: Bots füllen jedes Feld eines Formulars aus, auch die versteckten. Was ich hinzugefügt habe, ist nur ein JavaScript, um das auf der Client-Seite zu verhindern, und auch eine benutzerdefinierte Submit-Aktion, um das auf der Server-Seite zu verhindern. Wenn Sie das Honeypot-Feld verwenden möchten, denken Sie daran, dass Sie auch die Submit-Aktion in Ihrem Formular verwenden müssen. Das wird in Zukunft alle Spam-Formular-Eingaben verhindern!
Lassen Sie uns gemeinsam das Internet ein wenig zugänglicher machen
Wenn Sie weitere Informationen suchen, finden Sie alle diese Themen in den offiziellen Richtlinien für die Zugänglichkeit von Web-Inhalten (WCAG). Dies ist die universelle Dokumentation für Barrierefreiheit im Internet. In Deutschland müssen alle öffentlichen Einrichtungen barrierefrei sein, dies wird durch die „Barrierefreie-Informationstechnik-Verordnung“ (BITV) und ihre Prüfschritte abgedeckt, die vor der Inbetriebnahme erforderlich sind. Eine gute Dokumentation für Entwickler:innen findet sich auch in der Mozilla Developer documentation for Accessibility.
Derzeit habe ich keine Möglichkeiten, die Funktionen des neuen XM-Cloud Forms-Produkts zu prüfen, aber ich stehe mit ihnen in Kontakt, um auch XM-Cloud Forms zugänglich zu machen.
Das Paket ist verfügbar unter https://github.com/monkey-dsc/A11Y.Feature.Forms/. Es ist kompatibel von 9.2.0-10.3.1, aber lesen Sie die Installationsanweisungen sorgfältig durch, da es in Ihrer aktuellen Umgebung zu Konflikten mit den Operatoren und Action Items kommen kann, aber das ist gut dokumentiert.
