Auch wenn man alles richtig gemacht hat kann es beim praktischen Einsatz noch einige Probleme geben, so auch bei der Barrierefreiheit. Deswegen ist es immer sinnvoll, die fertige Anwendung zu testen.
\nDabei sollte man nach M\u00f6glichkeit externe Tester zu Rate ziehen. Die eigenen Mitarbeiter und die Web-Agentur sind fast immer betriebsblind, das gilt im \u00dcbrigen auch f\u00fcr die Mitarbeiter mit einer Behinderung. Nur weil jemand behindert ist muss er nicht unbedingt etwas von Barrierefreiheit verstehen. Eine minimale Voraussetzung muss sein, dass er die Probleme anderer Behinderter antizipieren kann und das kann er nicht, wenn er sich nur mit der eigenen Technik besch\u00e4ftigt hat.
\nEs gibt verschiedene Testm\u00f6glichkeiten. Es gibt automatische Testtools, die die Barrierefreiheit pr\u00fcfen sollen. Das ist ganz n\u00fctzlich, damit Fehler auf der Webseite wie schlechte Kontraste, fehlende Alternativtexte und so weiter entdeckt werden k\u00f6nnen. F\u00fcr die erste Phase vor allem f\u00fcr die Pr\u00fcfung von Prototypen ist das ausreichend. Echte Probleme kann man damit nicht aufdecken. Man kann zum Beispiel das Redaktionssystem so einstellen, dass es automatisch einen Text wie \u201eLorem ipsum dolor\u201c f\u00fcr Grafikbeschreibungen vergibt. Das Testtool kann nicht zwischen echten und belanglosen Alternativtexten unterscheiden. Es kann auch nicht bestimmen, ob eine Auszeichnung semantisch korrekt ist, ob ich zum Beispiel eine Zwischen\u00fcberschrift korrekt formatiert habe oder ob sie nur als fetter Absatz markiert wurde.
\nNach wie vor verwechseln viele Menschen Barrierefreiheit mit Validit\u00e4t. Das W3C stellt Anwendungen zur Verf\u00fcgung, mit denen sich HTML und CSS auf Korrektheit pr\u00fcfen lassen. Das ist nicht unwichtig, aber valide Webseiten sind nicht unbedingt barrierefrei und nichtvalider Code wirkt sich nicht unbedingt negativ auf die Barrierefreiheit aus. Es reicht schon, wenn ein einziges Zeichen im Head der Datei falsch codiert wurde und schon wirft der Validator f\u00fcr jede Seite mit diesem Head Unmengen an Fehlern aus, ohne dass das den Screenreader-Nutzer oder jemand anderen interessieren muss. <\/p>\n