Yerf!
Das stimmt so nicht. Natürlich kann man »Alternativinhalt« unterbringen. Nämlich insofern:
»Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browser informing them of how to access the video contents.«
Ok, da muss ich zugeben, dass ich den Absatz bisher übersehen hab, vielleicht weil der nächste so extra hervorgehoben ist und einem erst einmal das Gegenteil nahelegt.
Sprich: Wenn das Video nicht abgespielt werden kann, wird der Alternativinhalt berücksichtigt.
Es ist allerdings nicht Sinn der Sache, dass darin ein zugängliches textuelles Äquivalent, Untertitel und dergleichen untergebracht werden, die z.B. für Blinde/Sehbehinderte oder Taube gedacht sind. Schließlich kann bei denen das Video durchaus in technischer Hinsicht abgespielt werden.
Mir geht es dabei mehr um technische Aspekte, aus denen das Video nicht dargestellt werden kann. Dann möchte ich dem Besucher einen Hinweis geben können, damit er evtl. später nochmals vorbeischaut, wenn das "Problem" beseitigt ist (er z.B. nicht mehr mit dem PDA sondern einem PC unterwegs ist)
Das sind einfach zwei Sachen, die in HTML 5 erstmals getrennt werden.
Wobei ich bisher aus den Richtlinien für Barrierefreiheit herausgelesen habe, dass man nur eine Ressource für alle bereitstellen sollte, eben mit entsprechenden Fallback-Mechanismen. Aber es gibt sicher auch gute Argumente für eine andere Herangehensweise.
Ich halte halt <object> für einen Leistungsfähigen Ansatz der auch zukünftige Anforderungen problemlos abdecken kann und frage mich, wieso man nicht darauf aufbaut (z.B. durch Standardisierung der <param>s)
Gruß,
Harlequin
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->