Diskussion:SVG/ Barrierefreiheit

Noch zu tun:

Wie vorgeschlagen in mehrere Seiten aufteilen? (welcher browser hat Probleme mit mehr als 30kb?) – Doktorchen 14:30, 21. Okt. 2009 (CEST)

Also erst mal ein großes WOW für deine Arbeit. Was das <metadata>-Element betrifft habe ich eigentlich immer gedacht das es ausschließlich für automatisch verarbeitbare Metadaten im XML Format gedacht ist, vorzugsweise als RDF weißt du da mehr als ich? Was die Aufteilung betrifft sollten wir uns da erst Gedanken machen wenn wir halbwegs vollständig sind da ich glaube das wir dann das Buch am besten gleich neu strukturieren. --FischX 12:54, 22. Okt. 2009 (CEST)

Meiner Ansicht nach ist das, was ein Programm wie versteht, eine Frage der Abstraktionsstufe. Zudem hat sich da einiges entwickelt, seit SVG1.1 herausgekommen ist. Bei SVG tiny 1.2 (wo ich ja auch fleißig mitgebastelt und -genörgelt habe) ist das bereits etwas schöner formuliert, was man da alles machen kann.Dort wird natürlich auch wegen der beschränkten Möglichkeiten der DTD als Inhalt PCDATA vorgegeben. Wenn man es für notwendig hält, Metainfomationen zu geben und das Dokument auch noch den W3C-Validator überleben soll, ist das dann im Wesentlichen einfacher Text mit 'entities'. Nicht schön und unstrukturiert, aber nicht geradewegs verboten. Ohne triftigen Grund würde ich das auch selber nicht tun. Geht man jetzt davon aus, daß ein Programm eine Textalternative bereitstellen will, kann man nicht davon ausgehen, daß das alle beliebigen Formate versteht. Text kann es aber präsentieren, wenn auch nicht verstehen. Insofern ist es das Minimalmodell, da seine Metainformationen einfach reinzuschmieren, ist formal valide, aber nicht wie RDF weiter maschinengerecht aufschlüsselbar.

Technisch gesehen stört der Inhalt keinen XML/SVG-parser, solange er wohlgeformt ist - also eben PCDATA (interpretierter Text) oder XML-Elemente, die dann auch irgendwann PCDATA oder Attribute mit PCDATA drin enthalten. Und wenn ein Programm auf irgendeiner Stufe auf (P)CDATA stößt, welches keinen vordefinierten Wert hat, ist Ende der Fahnenstange der Weiterverarbeitung. Es bleibt nur noch die Präsentation des Textes. Zweifellos gelingt es mit RDF und Kollegen, diesen Punkt ziemlich weit rauszuschieben, was ein großer Vorteil ist, weil man da viel unabhängig von der für den Text selbst gewählten menschlichen Sprache verstehen kann.

Bei dieser nächsten Abstraktionsstufe ist der W3C-Validator außen vor, solange er die DTD von SVG1.1 benutzt. Man muß dann im Bedarfsfalle erstmal das SVG ohne Metainformationen testen und dann den ausgezeichneten Inhalt von metadata. Da pappt man also Elemente eines anderen Formates, am besten mit definiertem Namensraum rein. Formal reicht da auch XHTML, schließt die Spezifikation zumindest nicht aus. Immerhin könnte man dann maschinenlesbar eine Überschrift und Absätze basteln. Gut, da XHTML semantisch auch nicht besonders reichhaltig ist, kommt man damit auch nicht viel weiter. Man kann auch RDF nehmen, ist eine Sprache, die daraufhin spezialisiert ist, Metainformationen auszuzeichnen. Daß man darin dann zumeist auch gleich noch Dublin-Core, OWL etc verwendet, deutet schon an, daß da viele Köche die Suppe umrühren, insofern nicht so einfach für ein Programm, das wirklich zu verstehen. Kann ja auch jeder sein eigenes Vokabular spezifizieren, wenn ihm das der anderen nicht reicht. Insofern kann man als Autor wohl nicht davon ausgehen, daß ein Programm den Inhalt wirklich versteht. Das kennt bestenfalls einige der verwendete Formate, wenn man Glück hat. Auch ohne Kenntnis der Formate kann das Programm die Angaben aber zu Tripeln aufarbeiten und präsentieren, auf daß der interessierte Leser in endlicher Zeit sich alle Bedeutungen aus dem internet zusammensuchen kann. Generell sollte es auch einfach sein, selbst ohne Kenntnis der verwendeten Formate eine halbwegs brauchbare und strukturiete Textansicht (oder Präsentation) zu erzeugen, die einem Nutzer helfen kann, die Metadaten zu verstehen.

Wegen der Komplexität des Sachverhaltes kann man also nicht sagen: Papp da einfach RDF rein - Aus RDF folgt meist auch Dublin-Core oder OWL, XML-Schema, GRDDL und was die semantische Gemeinde gerade so hergibt - man ist da derzeit recht kreativ am arbeiten.

Automatisch verarbeiten kann ein Programm das natürlich alles, zum Beispiel in einer graphischen Darstellung mit eingerückten Absätzen oder als verschachtelte Definitionslisten oder eben mit einer korrespondierenden akustischen Ausgabe (Blinde sind ja leider viel Kummer gewohnt, da ist es schon prima, wenn eine vorlesbare Struktur vorhanden ist ;o)

Ob ein Progamm das 'versteht' oder inhaltlich sinnvoll weiterverarbeiten kann (zu was?), kommt natürlich darauf an, daß es das Format interpretieren kann, was man da gerade verwendet, das ist aber bei foreignObject auch so.

Es gibt da aber eigentlich kein ultimatives Format, was alle denkbaren Anwendungen von Metainformationen abdecken würde, weswegen SVG da eher wage ist und mehr oder weniger nur sagt, daß man da strukturierte Metainformationen reinschreiben sollte (das sollte und die DTD implizieren, daß man sie auch einfach unstrukturiert reinpappen darf, wenn man Gründe dafür hat).

Sicher sind Metainformationen in metadata eine großartige Hilfe, um einen (alternativen) Zugang zum Inhalt des Dokumentes zu bekommen, je strukturierter das ist, desto detaillierter die Information, die man da herausziehen kann. Man denke nur an ein abstraktes Gemälde und wie schwierig es sein kann, all das zu verstehen. Kann doch für jeden nützlich sein, wenn da im Dokument Metainformationen, eventuell mit Verweisen zu Artikeln des Autors oder zur Kunstrichtung sind, die erhellen können, wie das gedacht war. Und selbst wenn kein Programm das darstellt, kann man immer noch notfalls in den Quelltext gucken oder sich das mit einem XML-editor angucken, um die Metainformation zu extrahieren, um besser zu verstehen, was da abgebildet ist, ob man es nun sehen kann oder nicht. Doktorchen 16:48, 24. Okt. 2009 (CEST)