Am Montag, den 17.10. 2022, spreche ich über das Testen von Barrierefreiheit mit Hilfe von browsereigenen Tools auf der Online-Konferenz „Barrierefreie Webseiten“ des Rheinwerk-Verlags: „Barrierefreiheit testen? Nutzen Sie doch ihren Browser“. Mein Fokus liegt als auf dem Testen von Barrierefreiheit im Browser selbst.
Weiterlesen „Barrierefreiheit testen im Browser! (Vortrag)“Um die sprungmarker-Wiederaufnahme gut anlaufen zu lassen, beginne ich nun mit einer Vertiefung des Themas Barrierefreiheit optimieren mit der Web Developer Toolbar. Wir beschränken uns hierbei aber nicht auf die Web Developer Toolbar, sondern stellen zu Schwerpunktthemen wie Überschriften, Formulare oder Datentabellen unterschiedliche Ansätze und Plugins vor.
Im ersten Teil sehen wir uns die Darstellungs- und Kontrollmöglichkeiten für Überschriften an, denn eine konsistente Überschriftenhierarchie ist zum einen eine semantische Notwendigkeit und zum anderen für Screenreader-Nutzer ein wichtiges Werkzeug, um schnell und sinnvoll durch eine Webseite zu gelangen. Mit dem Screenreader JAWS reicht das Drücken der Taste H, um zur nächsten Überschrift zu navigieren. Wir führen hier keine H1-Diskussionen, es geht hier vorrangig um die Kontrolle von Hierarchie und Anordnung der Überschriften.
Weiterlesen „[Serie] Mit Barrierefreiheit arbeiten (1): Überschriften“
Als ich letzthin den Relaunch von zeldman.com ein wenig unter die barrierefreie Lupe genommen habe und dabei das fixe Pixel-Layout etwas überrascht zur Kenntnis genommen habe, gab es sofort Kritik. Sieht man sich die Diskussion in Sachen Pixel-Revival und Page Zoom in den aktuellen Browsern an, spürt man, wir bewegen uns offenbar auf wieder unsicherem Terrain.
Unsicheres Terrain wäre ja durchaus nichts ungewohntes – schon gar nicht in der barrierefreien Optimierung. Leider ist die Diskussion eher durch die übliche Abgrenzungsstrategie gekennzeichnet – was den Frontendbereich nur zu oft kennzeichnet: Ist es nicht Flash, gegen das man sich absetzt, dann sind es jetzt flexiblere Layoutformen – insbesondere elastisches Layout in em realisiert. Und wenn gar nichts mehr hilft, dann fängt man schlicht an zu mauern und gibt dem Pixel die Alleinherrschaft zurück, die er im übrigen nie verloren hat.
Weiterlesen „Die Barrierefreiheit heranzoomen: ein Ausblick“
Safari 4 Beta soll ja WAI ARIA unterstützen. Liest man sich den knappen Absatz durch, sind da wenig Details über die genaue Unterstützung zu erhalten.
Eclectic Dreams hat diese Unterstützung getestet: Quickfire ARIA Testing. Das Ergebnis sieht bis dato nicht sonderlich gut aus: So, basically ARIA support in Safari/Voiceover is not quite there yet.
Aber schliesslich ist es ja erst die Beta. :)
Sehr lustige Replik von WebAIM in Sachen Browser und deren Erkennung mit Hilfe des User-Agent-Strings: History of the browser user-agent-string.
Mit dem Erscheinen von Googles neuem Browser Chrome sei die Browsererkennung obsolet geworden, weil sich die quasi in den Schwanz beisst.
And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla
Quelle: History of the browser user-agent-string – WebAIM Blog
Weiterlesen „Wie der User-Agent-String zum Ringelspiel wird :)“