Bald 100.000 Besucher in meinem Inselfisch-Kochbuch

Wie einigen von ihnen vielleicht bekannt ist, betreibe ich seit einigen Jahren auf meiner privaten Webseite evileu.de ein barrierefreies Kochbuch, das Inselfisch-Kochbuch. Es ist ein WordPress-Blog mit mittlerweile über 300 Kochrezepten aus Bayern und aus aller Welt.

Das Inselfisch-Kochbuch

Das Kochbuch erfreut sich besonders seit der barrierefreien Umgestaltung Anfang letzten Jahres steigender Beliebtheit, und das ganz besonders bei Besuchern mit Handicap. Ich habe schon vielfache Rückmeldungen von sehgeschädigten oder anderweitig gehandicappeden Besuchern bekommen, dass das Inselfisch-Kochbuch auch mit einem Screenreader oder einer Braillezeile einwandfrei zu bedienen ist, und dass meine Rezepte leicht nachzukochen und gelingsicher sind.

Ich habe gerade meine Statistiken für diesen Monat ausgewertet: im Inselfisch-Kochbuch waren von Anfang 2017 bis heute mittlerweile 93.253 Besucher. Das ist für eine kleine, im ein-Frau-Betrieb geführte Webseite eine stolze Zahl, und ich freue mich sehr darüber. Die barrierefreie Umgestaltung das Inselfisch-Kochbuchs war eine Heidenarbeit, aber sie hat sich auf jeden Fall gelohnt!

Rian Rietvelds Rücktrittserklärung: autorisierte deutsche Übersetzung

Ich habe die soeben zurückgetretene ehemalige Chefin des WordPress Accessibility Teams gefragt, ob ich ihre Rücktrittserklärung ins Deutsche übersetzen und hier veröffentlichen darf, und sie hat mir ihr OK gegeben.

Hier zuerst der Link zu Rians Blogbeitrag vom 9.10.2018:

I have resigned as the WordPress accessibility team lead. Here is why.

 

Und hier folgt die deutsche Übersetzung:

Author Rian Rietveld Posted on 9 October 2018

Ich bin als Leiterin des WordPress Accessibility Teams zurückgetreten. Hier sage ich, warum.

Disclaimer: dieser Beitrag spiegelt ausschliesslich meine persönliche Meinung wieder

Nach mehreren Jahren der Arbeit an WordPress und Barrierefreiheit und der Beteiligung am Accessibility Team, habe ich die schwierige Entscheidung getroffen, das WordPress Accessibility Team zu verlassen. Ich bin es dem Team schuldig zu erklären warum ich diese Entscheidung getroffen habe und welche Hoffnung ich habe, dass sich die Dinge in Zukunft verbessern könnten.

Das letzte Jahr, insbesondre die letzten Wochen waren für mich zu sehr politisch kompliziert, da ist es besser wenn jetzt jemand anderer die Führung übernimmt.

In diesem Beitrag versuche ich eine Analyse dessen, was das WordPress Accessibility Team (wpa11y team) während der Entwicklung von Gutenberg getan hat und was die Probleme bei der Arbeit an seiner Barrierefreiheit waren.

Gutenberg

Als die Entwicklung von Gutenberg begann, verfolgte das wpa11y team den Fortschritt und testete, was da war. Und wir entdeckten, dass es viel zu verbessern gab. Also fing Andrea Fercia an, Tickets aufzumachen und Lösungen zu finden. Und das war eine gigantische Aufgabe.

Codebase

 

Wir hatten vier grosse Probleme:

 

Die Codebasis von Gutenberg ist für uns alle schwierig, weil niemand im wp11y team ein geschulter React Entwickler ist. Also war es sehr schwer, Änderungen zu implementieren und selbst PRs zu schreiben. Was wir tun konnten ist testen, sagen was falsch war und wie es sein sollte, und hoffen dass ein Entwickler das aufnehmen würde. Viel von der Arbeit des a11y teams ist vom Gutenberg Team getan worden, aber es gibt immer noch große Probleme.

 

Es gab keinen React Entwickler mit Barrierefreiheitskenntnissen in der Community, und keinen Barrierefreiheitsexperten mit React-Kenntnissen von ausserhalb der Community, der gewillt gewesen wäre, ohne Bezahlung an diesen Problemen zu arbeiten.

Funktionalität, die von Andrea getestet, verbessert und dann abgesegnet wurde änderte sich zu einem späteren Zeitpunkt, was die Barrierefreiheits- Verbesserungen zu nichte machte. Das hat Andrea schwer getroffen

Neue Funktionalitäten wurden vor der Implementierung nicht Tastatur-getestet. (z.B. der Date Picker)

Ich habe mein Netzwerk eingesetzt um Barrierefreiheitsexperten, Firmen und Entwickler mit sowohl React-Kenntnissen als auch Barrierefreiheitskenntnissen zu gewinnen. Wir machten im März dieses Jahres eine Testrunde, nachdem wir die Gutenberg Leitung gefragt hatten, wann sie gewillt waren einen vollständigen Test zu machen. Die Ergebnisse sind bei der Testprozedur und bei den Issues auf GitHub zu finden.

Die Ergebnisse zeigten so viele Barrierefreiheits-Probleme, dass die meisten Tester sich weigerten, Gutenberg nochmal anzuschauen.

Weiterbildung

Weil wir nicht alle Gutenberg Issues selbst lösen konnten, habe ich mich dafür entschieden, zu helfen und die Entwickler und Designer weiterzubilden.

 

Sami Keijonen und ich fingen damit an, das WordPress Accessibility Handbuch zu erweitern und zu reorganisieren, wir haben gute Vorgehensweisen und Methoden zum Testen von Code, Inhalt und Design hinzugefügt. Wir haben sehr viel geschrieben, so dass es jetzt beim Erstellen eines GitHub Issues so ist, dass der Autor auf eine Handbuch-URL verweisen und sagen kann „so wird das gemacht“.

 

An diesem Handbuch arbeiten immer noch Jaap Wiering und Daniel Koskinen, siehe auch der #accessibility-docs Channel auf Slack, hier kann man die Diskussion einsehen.

Wir haben über Testautomatisierung recherchiert. Dies ist immer noch eine nicht vollendete Arbeit, weil es schwierig aufzusetzen ist. Ich habe auf der Human Made Webseite einen Blogbeitrag über meine Erfahrungen mit automatisiertem Testen der Barrierefreiheit geschrieben, und ich habe meine Truppen versammelt, um dies auf eine höhere Ebene zu bringen.

Ausserdem haben wir eine Serie von Entwicklertalks über Barrierefreiheit bei Treffen und WordCamps gestartet.

Eine gute Sache, die man über alle diese Gutenberg-Vorbereitungen sagen kann ist, dass sie die Sichtbarkeit des a11y teams verstärkt haben, und es ist sehr gut zu sehen dass sie jetzt endlich Anerkennung für ihre Arbeit bekommen.

Handbuch für Assistive Technologien

Für Benutzer, die auf assistive Technologien  (AT) wie Screenreader oder Stimmerkennungssoftware angewiesen sind ist die Lernkurve von Gutenberg sehr hoch. Wenn man nicht den ganzen Bildschirm sehen kann, oder auf den Tastaturfokus angewiesen ist, dann ist Gutenberg sehr schwer zu erlernen.

 

Claire Brotherton hat angefangen dieses Handbuch zu schreiben und sie braucht die Hilfe von AT Experten. Siehe:  GitHub issue Manual for users of assistive technology #10373.

5.0 ist nah

Jetzt steht Gutenberg kurz vor der Veröffentlichung: wie barrierefrei ist Gutenberg?

In Andrea’s Worten (und ich stimme zu):

 

“Obwohl das Gutenberg Team hart daran gearbeitet hat, einige Grundlegende Features der Barrierefreiheit einzubauen (Fokus Management, Navigationshilfen) ist die generelle User Experience für Benutzer mit Handicap schrecklich kompliziert, das geht soweit dass der neue Editor für sie kaum benutzbar ist.

 

Der Hauptgrund für dieses generelle Fehlen von Barrierefreiheit steckt im generellen Design von Gutenberg, da Barrierefreiheit nicht in den Design Prozeß mit aufgenommen wurde.

 

Das Feedback von Barrierefreiheits-Benutzern wurde ständig bewertet, und Gutenberg ist tatsächlich ein Rückschritt im Grad der Barrierefreiheit im Vergleich mit dem vorigen Editor”

Andrea Fercia

Was ist schiefgelaufen

Ich habe diese Woche das Feedback bekommen, dass wir die GitHub Issues anders formulieren hätten sollen. Mir wurde gesagt, dass die Begründung, wieso das ein Issue war, ausführlicher hätte sein müssen, so dass die Entwickler besser motiviert gewesen wären, es zu lösen. Ich habe auch das Feedback bekommen dass manche Accessibility Issues zu groß waren, dass wir sie kleiner hätten machen sollen

Es wäre großartig gewesen, wenn dieses Feedback zeitnah in den Issues gekommen wäre, weil einige der Issues bereits über ein Jahr alt sind.

Im Nachhinein gesehen: was hätte ich anders hätte machen sollen:

 

Öfter und lauter kommunizieren, dass wir einen geschulten Gutenberg/React Entwickler viel früher im Prozess gebraucht hätten

Die Entwickler davon überzeugen, dass der Tastaturtest ein Muss ist

Andrea besser unterstützen, als er um eine zweite Meinung und um mehr Testen bat

Die AT-Tester davon überzeugen, es nochmal zu versuchen

Mehr Bemühungen darin investieren, Barrierefreiheitsexperten und Unternehmen zur Hilfe zu gewinnen

 

Vollzeit Entwickler

Ich bin sehr glücklich darüber, dass es jetzt einen dedizierten Entwickler von Automattic gibt, der 100 % an Barrierefreiheitsproblemen arbeitet. Ich wünsche Matthew MacPherson alles Gute, denn er wird es brauchen können. Ich hoffe, dass das a11y team ihn in allem unterstützen wird, was er braucht.

An Matt Mullenweg

Zu Matt Mullenweg möchte ich sagen: bitte passe besser auf deine Community auf. Schätze die Menschen, die ihre (eigene) Zeit investieren und die sehr hart daran arbeiten, WordPress so gut wie möglich zu machen. Ignoriere sie nicht und mach dich nicht über sie lustig, sondern sprich mit ihnen, führe sie, informiere sie. Sei nicht von der Community entkoppelt, sei ein Teil von ihr.

Danksagung

Es war ein Privileg, im Accessibility Team zu arbeiten. Ich kann ihnen allen hier nicht genug danken. Aber es gibt einige Leute, denen ich hier ein grosses Dankeschön aussprechen möchte:

 

Andrea Fercia, der hart und oft allein gegen den Strom arbeitet, was die GitHub Issues betrifft. Ich wünschte ich hätte dir mehr Unterstützung für das Testen geben können.

Claire Brotherton, die viel testet und angefangen hat, das Handbuch für assistive Technologien zu schreiben. Claire, du bist hier die unbesungene Heldin, du hast (in deiner eigenen Zeit) so viel hier getan. Mädchen, du rockst.

Adrian Roselli, der zweimal von den USA zum WordCamp nach Europa geflogen ist, um dem Accessibility Team zu helfen und Lösungen zu finden.

Eric Wright, der ein exzellentes Video darüber gemacht hat, wie schwierig es ist Gutenberg mit Dragon NaturallySpeaking zu benutzen.

Sami Keijonen, Jean-Baptiste Audras, Laken Hafner, Nic Bertino, Amanda Rush, @bemdesign, Chetan Prajapati und all die Leute im #accessibility channel, für ihre Beiträge und Diskussionen.

Morten Rand-Hendriksen, für seine Hilfe, Unterstützung, Netzwerken, Inspiration und Zeit, und dafür dass ich alle meine Zigaretten nach der Party in Belgrad in sein Gesicht rauchen durfte.

Was jetzt?

Ich verlasse weder WordPress noch die Barrierefreiheit, und Fakt ist, dass ich jetzt tatsächlich wieder an Barrierefreiheit arbeiten kann. Ich werde Reden halten und Workshops geben. Ich möchte außerdem Forschen und an Tickets arbeiten. Aber nach meinem eigenen Tempo.

Ich werde mich an Teilnehmertagen mit an den a11y-Tisch setzen, aber vielleicht gehe ich stattdessen lieber in ein Museum.

Für Level Level, die Firma für die ich jetzt arbeite, werde ich Workshops und Schulungen aufsetzen, in denen es um Web Accessibility und gute Code-Praktiken geht. Ich werde ausserdem den Designern, Content Managern und Entwicklern von Level Level helfen, die beste Agentur für barrierefreie WordPress-Seiten zu werden die es gibt. Lauter so Zeug das ich gern mache und das mir positive Energie gibt.

Ich wünsche euch alles Gute, und bitte meldet euch wenn ihr mein Wissen braucht oder wenn ihr einen Schwatz halten wollt oder ein Glas Wein mit mir trinken.

Liebe Grüße,

Rian

Author Rian Rietveld Posted on 9 October 2018

Chefin des WordPress Accessibility Teams zurückgetreten

Rian Rietveld, die Chefin des internationalen WordPress Accessibility Teams, ist zurückgetreten. Und das nicht im Guten!

Rian hat in ihrem Blog ausführlich begründet warum sie sich jetzt zurückzieht: weil der neue WordPress-Editor Gutenberg (Release für nächstes Jahr geplant) in Sachen Barrierefreiheit eine reine Katastrophe sein muss. Ich zitiere: “Unsere Barrierefreiheitstester weigerten sich nach einem ersten Blick, sich das Ding nochmal anzuschauen.”

Hier der Link zu Rians Artikel:

https://rianrietveld.com/2018/10/09/i-have-resigned-the-wordpress-accessibility-team/

WCAG 2.1 in Sicht

Die “Final Draft”, also der endgültige Entwurf der Web Content Accessibility Guidelines in der neuen Version 2.1 soll heute veröffentlicht werden. Die Version 2.1 ergänzt die seit 2008 gültige WCAG 2.0 besonders in drei Bereichen:

  • Nutzung mobiler Endgeräte, wie Smartphones, Tablets, Smartwatches etc. sowie mobile Endgeräte in KFZ.
  • Berücksichtigung von Benutzern mit eingeschränkter Sehfähigkeit. Es werden Sehbehinderungen einer anderen Art als Blindheit berücksichtigt, wie z.B. erhöhte Lichtempfindlichkeit, Farbenblindheit, eingeschränktes Sichtfeld oder Verzerrungen in der Sichtwahrnehmung.
  • Berücksichtigung von Benutzern mit kognitiven Behinderungen wie z.B. Lernstörungen, ADHS, Autismus und altersbedingte kognitive Einschränkungen.

Die WCAG 2.1 ersetzen nicht die Version 2.0, sondern ergänzen sie in wichtigen Bereichen.  Als vorab-Information sicher interessant ist das Dokument “Understanding WCAG 2.1” auf den Seiten des W3C.

BIK: BITV-Tests und WCAG 2.0 unter einem Dach

Quelle: http://www.bitvtest.de

Seit Ende letzten Jahres ist der überarbeitete BITV-Test verfügbar. Laut BIK wird jetzt auch die Konformität der Stufe AA nach den Richtlinien des WCAG 2.0 geprüft. Der Unterschied besteht lediglich in der Auswertung. Das BITV-Prüfverfahren vegibt nach wie vor eine graduelle Bewertung der Konformität in Prozent. Der Test nach WCAG wird nur nach “ist konform” oder “ist nicht konform” ausgewertet.

Besonders interessant für kleine und mittlere Unternehmen dürfte immer noch der kostenlos angebotene Selbstbewertungstest sein, der nach wie vor ein wertvolles Hilfsmittel zur Beurteilung des erreichten Grades der Barrierefreiheit der eigenen Webseite darstellt. Hier gehts zur Demoversion

Leider gilt aber nach wie vor: das Ergebnis des kostenlosen Selbsttests darf nicht veröffentlicht werden, es ist nur für den internen Gebrauch. Der abschließende kostenpflichtige BITV-Endtest kostet nach wie vor ab 1260 €, das wird für die meisten kleineren Betriebe dann doch nicht in Frage kommen. Hier wäre eine preiswertere Version nach wie vor sehr wünschenswert!

Barrierefreier Videoplayer der Aktion Mensch

Quelle: https://www.heise.de/ix/meldung/Aktion-Mensch-praesentiert-barrierefreien-Videoplayer-fuer-alles-und-alle-3921978.html

Die Aktion Mensch hat einen barrierefreien Videoplayer entwickelt, mit dem es möglich ist, auf der eigenen Internetseite unkompliziert barrierefreie Videos für alle einzustellen. Der Player ist auf dieser Seite der Aktion Mensch zum Download verfügbar.

Der Player ermöglicht es, zusätzlich zum eigentlichen Video eine Audiodeskription, Untertitel und Gebärdensprache anzubieten. Sehr interessant zu diesem Thema ist auch der hier verlinkte Artikel mit Tipps zur Erstellung barrierefreier Videos.

Inklusion am Arbeitsplatz: 100.000 zahlen lieber

Quelle: VDK-Zeitung Dezember 2017/Januar 2018

In Deutschland ist nach dem geltenden Arbeitsrecht eine 5%-Quote für die Beschäftigung schwerbehinderter Arbeitnehmer in Kraft, diese gilt für Unternehmen ab 20 Beschäftigten. Das heißt im Klartext: Betriebe mit 20- 39 Mitarbeitern müssen mindestens einen schwerbehinderten Arbeitnehmer beschäftigen, bis 59 Mitarbeiter zwei. Näheres hierzu in diesem sehr informativen Artikel bei internetratgeber-recht.de

Aber viele Arbeitgeber erfüllen diese Beschäftigungsquote nicht, sie zahlen stattdessen die Ausgleichsabgabe. Laut VDK-Zeitung sind dies immerhin fast 100.000 von den insgesamt ca. 156.000 deutschen Arbeitgebern, die zur Beschäftigung Behinderter verpflichtet wären. Das sind fast zwei Drittel! Eine traurige Mehrheit.  Es gibt noch viel zu tun in Deutschland, wenn es um die Inklusion am Arbeitsplatz geht!

Valides HTML – der gern vergessene erste Schritt

Spricht hier noch jemand HTML?

Heutzutage codiert niemand mehr seine Webseiten per Hand, so wie das in den Anfängen des Internet noch notwendig war. Damals schrieb man noch HTML im Texteditor, und sah erst im Browser, ob da auch etwas Vernünftiges dabei herauskam. Das ist lange, lange her, und seitdem sind unzählige Technologien und Hilfsmittel entstanden, die das Erstellen von Webseiten vereinfachen. Von ausgefeilten visuellen HTML-Editoren, Click&Build-Angeboten bei den Providern bis hin zu ausgewachsenen CMS (Content Management Systemen), die Helferschar für den Webdesigner ist heute Legion. Da ist es eigentlich gar nicht mehr notwendig, auch nur eine einzige Zeile HTML per Hand zu schreiben.  In den meisten Fällen kann man sich auch darauf verlassen, dass diese technologischen Helfer gültiges und fehlerfreies, also valides HTML produzieren.

Ist Validität wirklich Voraussetzung?

Es gibt viele sehr interessante Diskussionen darüber, ob valides HTML wirklich eine Grundvoraussetzung für barrierefreie Webseiten ist. Eine besonders aufschlussreiche Abhandlung gibt es hier bei der WAI (Web Accessibility initiative) zu lesen. Ich zitiere mal die Kernaussage des Artikels:

invalid sites may be accessible because of innovations for accessibility that have not yet been standardized

Auf Deutsch locker übersetzt: es mag Neuentwicklungen auf dem Gebiet der Barrierefreiheit geben, die in den geltenden W3C-Regelwerken noch nicht berücksichtigt sind. Das halte ich aber für die absolute Ausnahme! Im Normalfall der heutzutage veröffentlichten Durchschnittswebseite werden kaum Innovationen eingesetzt werden, die die barrierefreie Bedienbarkeit betreffen. Und es gilt auf jeden Fall, daß fehlerfreier HTML-Code eine gute Grundlage für die barrierefreie Gestaltung einer Webseite ist.

Best Practice: einfach mal checken

Wie oben angesprochen werden die meisten Webseiten heutzutage mit Hilfe von Technologien erstellt, die automatisiert validen HTML-Code erzeugen.  Trotzdem gibt es oft genug Ausnahmen von der automatisierten Codeerzeugung. Ich nenne mal nur als Beispiel das beliebte Einbinden von PHP-Snippets in WordPress-Seiten per Widget oder Plugin. Hier ist es meiner Ansicht nach unabdingbar, wenigstens einmal vor Veröffentlichung der Webseite abzuchecken, ob hierbei auch überall gültiger HTML-Code herauskommt.

Der W3C Validator

Den aktuellen W3C-Validator finden Sie unter:
https://validator.w3.org/unicorn/

Es ist absolut vertretbarer Aufwand, eine neue Webseite da vor der Veröffentlichung mal durchzuprüfen. Man gibt nur die betreffende URL online ein, und erhält umgehend einen aussagekräftigen Report mit Fehlerprotokoll.

Der Validator kann natürlich nur die technische Regelkonformität des eingegebenen HTML-Codes prüfen, das ist nur ein erster Schritt. Aber man tut sich deutlich leichter mit dem barrierefreien Ausbau einer Webseite, wenn der HTML-Unterbau stimmt. Diesen Gefallen sollten Sie sich und Ihren Kunden tun.

 

Die Liste 90+ – nur wer zahlt, ist drin

Was ist die Liste 90+?

Eine von der Initiative BIK veröffentlichte Liste barrierefreier Webangebote und Agenturen für barrierefreies Webdesign.

Was ist BIK?

Ich zitiere:

BIK – barrierefrei informieren und kommunizieren – ist eine vom Bundesministerium für Arbeit und Soziales geförderte Projektreihe, um Intranet- und Internetangebote besser zugänglich zu machen und damit die Arbeitsplatzchancen behinderter Menschen zu verbessern.

Mehr können sie hier nachlesen: Über BIK

Wie kommt man in die Liste 90+?

Das habe ich mich auch gefragt, und das BIK mal angeschrieben, wegen meines barrierefreien Online-Kochbuchs. Ich bekam die Auskunft, daß in die Liste nur Webseiten aufgenommen werden, die den vom BIK angebotenen kostenpflichtigen BITV-Test mit mehr als 90 Punkten bestanden haben. Ich zitiere über den BITV-Test:

Der BITV-Test ist ein Prüfverfahren für die umfassende und zuverlässige Prüfung der Barrierefreiheit von informationsorientierten Webangeboten.

Grundlage für den BITV-Test ist die Barrierefreie Informationstechnik-Verordnung (BITV). Der Test umfasst insgesamt 49 Prüfschritte. Zu jedem Prüfschritt gibt es ausführliche Erläuterungen, die sagen, was genau geprüft wird, warum das wichtig ist und wie in der Prüfung vorzugehen ist. Das Prüfverfahren ist im Detail offengelegt.

Die Bewertung erfolgt nach einem Punktesystem, insgesamt können maximal 100 Punkte erreicht werden. Ab 90 Punkten wird ein Webauftritt als “gut zugänglich” bewertet, ab 95 Punkten als “sehr gut zugänglich”.

Das ist alles recht und schön, aber was kostet mich der Test?

Schlappe 1134 € mindestens, hier gehts zur Preisliste. Das ist ganz schön happig, und für mich als Einzelkämpferin und Privatperson völlig indiskutabel.

Es gibt zwar noch die kostenfreie Version, den BITV-Selbsttest, aber es ist explizit nicht gestattet, die Ergebnisse diese Tests zu veröffentlichen, damit ist das Ganze reine Makulatur.

Ich kann mir die Liste 90+ nicht leisten – und sie?

Kein Einzelunternehmer, keine kleinere Firma hat locker das Budget, mal kurz über 1000 € abzudrücken, um in die Liste 90 + aufgenommen zu werden. Das ist in meinen Augen Geldschneiderei, schließlich werden sowohl die Liste 90+ als auch der kostenpflichtige Test von der selben Institution BIK angeboten, die wirtschaften sich da sauber in die eigene Tasche.

Nicht nur Geldschneiderei, sondern kontraproduktiv

Wer als Privatanwender oder kleine Firma wie ich nicht geringe Zeit und Mühe aufgewendet hat um seine Webseiten barrierefrei zu gestalten, wird hier “abgewatscht”, wie wir in Bayern sagen. Die hohen Kosten verhindern effektiv eine Aufnahme privater und kleinerer Webseiten in die Liste 90+, und das kann doch nicht im Sinne des Erfinders sein. Was nützt die schönste barrierefreie Webseite, wenn sie bei der Zielgruppe, den Internetnutzern mit Handicap, nicht bekannt wird?

Ich würde es ja einsehen, wenn das BIK für Privatanwender und kleine Firmen eine preiswertere Version des Tests anbieten würde, oder alternativ die Veröffentlichung der Selbsttest-Ergebnisse gestatten würde. So wie es jetzt ist nutzt die Liste 90+ nur dem BIK und bringt Geld in die Kasse.

Auch kleinere Agenturen bleiben aussen vor

Wenn man wie ich als Kleinunternehmer oder Freelancer in die Liste der empfohlenen Web-Agenturen für barrierefreies Design aufgenommen werden möchte, gilt Ähnliches: man muß wenigstens 1 Projekt vorweisen, das den kostenpflichtigen Test bestanden hat. Die überwiegende Mehrzahl meiner Kunden kann und will die über 1000 € für den BITV-Test nicht aufbringen, damit bleibe ich als Einzelunternehmerin auch aus der Liste 90+ der empfohlenen Webagenturen draussen. Das ist Wettbewerbsverzerrung und schlicht unfair, wer nicht zahlen kann bleibt hier ebenfalls ausgeschlossen.

Wie könnte man es besser machen?

Ich würde dem BIK dringend raten, hier noch einmal neu zu Denken und Nachzubessern. Wie wäre es, wenn man eine Abnahme des Selbsttests gegen eine faire Gebühr einführen würde? Den Test würden ja dann die Webseitenbetreiber selbst durchführen, das BIK müßte nur nochmal drüberschauen und seinen Segen dazu geben. So wäre allen geholfen, und in die Liste 90+ kämen auch Webangebote mit kleinem Budget.

Damit wäre die dringend notwendige Chancengleichheit hergestellt, und das Angebot von barrierefreien Webseiten für Benutzer mit Handicap würde um ein Vielfaches reicher. Das nützte allen etwas, und wäre eine saubere Lösung.

Denn so wie es jetzt ist, ist die Liste 90+ nur etwas für zahlungskräftige Webseitenbetreiber und Agenturen, und das ist in meinen Augen ein kapitaler Mißstand, der im Interesse der Betroffenen behoben werden sollte. Das nützte sowohl den kleineren Anbietern als auch den Benutzern mit Handicap, und darum sollte es bei diesem Thema ja eigentlich gehen, oder nicht?

BIK: Überarbeiteter BITV-Test ist online, WCAG-Test im Herbst

Am 17. Juli 2017 hat das BIK (Barrierefrei informieren und kommunizieren für Alle) eine überarbeitete Version des bekannten BITV-Tests online gestellt. Der BITV-Test prüft die Barrierefreiheit von Internetseiten auf Basis der deutschen Barrierefreie-Informationstechnik-Verordnung.

Ergänzend zum BITV-Test wurde für den Herbst 2017 ein neuer Test zur Überprüfung der WCAG-Konformität in Aussicht gestellt, ich zitiere direkt von der BIK-Webseite:

BIK für Alle entwickelt – in Ergänzung zum etablierten BITV-Test – ein Verfahren zur Prüfung und Zertifizierung der WCAG-Konformität von Webangeboten. Der WCAG-Test befindet sich noch bis Herbst 2017 in der Evaluationsphase.

Da es ein gemeinsames Prüfverfahren gibt – das heißt, beide Tests werden dieselben Prüfschritte umfassen – hat die Entwicklung des WCAG-Tests auch Auswirkungen auf den BITV-Test: Das Prüfkonzept bleibt zwar im Wesentlichen unverändert, die Prüfschrittstruktur wurde aber stärker an die Struktur der WCAG-Erfolgskriterien angepasst.

Da die Anforderungen der BITV 2.0 inhaltlich denen der WCAG 2.0 entsprechen, werden beide Tests auch dieselben Prüfschritte enthalten und die Konformität auf Stufe AA der WCAG prüfen.

Beim BITV-Test bleiben im Zuge der Auswertung die abgestuften Bewertungen erhalten und es wird ein Punkte-Ergebnis berechnet. Anders im WCAG-Test: Hier gibt es in der Ergebnisdarstellung nur noch erfüllt oder nicht erfüllt.

BIK hat angekündigt, daß es auch für den neuen  WCAG-Test eine Konformitätserklärung und ein Prüfsiegel geben soll. Man darf gespannt sein, wann die neue Version des Tests Online geht.