molily: Barrierefreiheit vs. Design oder Barrierefreiheit und Design?

Beitrag lesen

Hallo, Cyx23,

Zur Frage der Textauszeichnung meine ich dass es Vorteile hat dicht am Text auszuzeichnen

Du meinst nicht die Textauszeichnung, sondern Formatierungen. Das Vermixen von Formatierungen und Markup entspricht nicht dem konzept von HTML, und CSS würde auch überflüssig, wenn es nicht vom Markup getrennt wurde, beispielsweise wurde aus diesem Grund das style-Attribut aus XHTML 2 entfernt beziehungsweise es wird darüber diskutiert (man kann darüber unterschiedlicher Auffassung sein).

und diese Auszeichnungen ggf. auch im Code zu erkennen, also ggf. höhere Notwendigkeit einen aufwändigeren Editor zu verwenden (als Autor).

Das Argument ist konstruiert, denn CSS lässt sich mit jedem x-beliebigen Texteditor schreiben, es ist zudem ein offenener Standard und kostenlose Autorenwerkzeuge existieren in Hülle un Fülle.

Wenn dann die Eindeutigkeit höher ist, beim Autor,

Das Verständnis des Codes ist IMHO viel einfacher, wenn semantische Elemente und bedeutungsvolle Klassennamen verwendet werden, beispielsweise:

<p><small>murks</small></p>
versus
<p class="anmerkung">murks</p>

Genauso sind del und ins darauf ausgerichtet, dass im title-Attribut der Grund und und im datetime-Attribut das Datum der Änderung abgelegt werden können, somit kann der Autor im Code ungleich mehr Informationen über die Änderung ablegen, als er es je mit einem strike-Element ohne Kommentare oder Ähnliches könnte. Text kann aus dutzenden Gründen durchgestrichen sein, weshalb ich dir widerspreche, dass strike semantisch mit del gleichwertig oder sogar aussagereicher ist - es sagt explizit nichts darüber aus, warum der Text durchgestrichen ist.

Natürlich sagen alle anderen Präsentatioselemente wie b, i und u auch etwas implizit über die Bedeutung aus, aber dies sollte im Markup festgehalten sein - deshalb rede ich ständig von der *Abstraktion*.

beim Leser, wenn der Code kompakter ist, macht es keinen Sinn viele tags durch <span class=xy> zu ersetzen.

Kompakter Code ist nicht das Ziel von XML-Applikationen, das Markup soll die Dokumentstruktur auf einer abstrakten Ebene detailliert beschreiben.

Und strike hat zudem eine andere Bedeutung als del.

IMHO sagt es nicht mehr aus, als dass der Text durchgestrichen dargestellt ewrden soll.
Opera stellt beispielsweise bei einem bestimmten Benutzerstylesheet besuchte Links durchgestrichen an - hat das etwas mit s oder del zu tun?

Wieso widersprechen sich Barrierefreiheit und W3C?

Ich unterstelle einfach dass eine Auflösung /Darstellung für
Hilfsmittel Behinderter mit Tags besser gelingt

Nein, wieso denn? Wie in diesem Thread sagte, ist die Trennung von Inhalt und Darstellung eine der Grundlagen, auf denen ein anpassungsfähiges und damit zugängliches Web aufbaut, die WCAG schreiben *explizit* vor, dass HTML-Elemente für Formatierungen nichts im Markup zu suchen haben, zumindest bis Browser CSS-Layout unterstützen.

dass dazu sowieso eine Darstellung ganz ohne CSS möglich sein muss

Ja, ist sie auch - HTML garantiert das. Es wäre aber der falsche Schluss, die gewonnenen Erkenntnisse der CSS-Benutzung dafür zu benutzen, um wieder mit HTML Formatierungen vorzunehmen, weil man schließlich jedem die Formatierungen aufzwängen will, selbst wenn der Browser CSS nicht versteht.

und auch ist ein Minimalbestand an Tags vorteilhaft.

IMHO stehen für die meisten Anwendungen die nötigen Elemente zur Verfügung, darüber hinaus lassen sich viele Bedeutungen durch kreative Nutzung der vorhandenen erreichen; an der Darstellung hapert es nicht, alleinig is die Frage, ob ein passendes Markup dafür existiert.

Es ist m.E. nötig eine Gegenstrategie zu CSS zu forcieren, wenn HTML noch irgendwie universell funktionieren soll.

HTML funktioniert zweifelsohne universell, CSS ist eine Sylesprache, welche als *optionaler Zusatz* zu HTML dient (wie oft habe ich es schon in diesem Thread gesagt?). Im Bezug auf die Zugänglichkeit ist CSS schlichtweg nicht zwingend notwendig.

Wobei ich allerdings zuwenig Informationen über die reale Bedeutung der Barrierefreiheit habe, da kann ich mich natürlich bei meinen Vorstellungen oder Vermutungen wie eine Website von einer Software vorgelesen oder anders dargestellt wird irren.

Diese Zusatzsoftware wird ein strike-Element womöglich schlichtweg ignorieren. Ein del-Element würde entsprechend gekennzeichnet werden.

Und auch hier die Frage ob jeder Behinderte gleiche und aktuelle Software hat.

Die aktuellen Browser verstehen tatsächlich keinesfalls alle Zugänglichkeitsfeatures von HTML, aber dafür sieht die WCAG Übergangslösungen vor...
Es geht auch darum, dass man die größtmögliche Benutzbarkeit und Zugänglichkeit anstrebt, das heißt sich am Möglichen orientiert - wenn ein WCAG-Zugänglichkeitsfeature bei den meisten Browsern nur Unheil anrichtet oder andere wichtige Seitenaspekte dadurch unverhätnismäßig negativ beeinflusst werden, ist es logisch, dass auf diese spezielle Richtlinie verzichtet werden sollte.

Aber, W3C, der Widerspruch i.d. Praxis wenn W3C-Empfehlungen nicht umgesetzt werden können, weil eine Website für möglichst viele Browser zugänglich sein soll.

Naja, das Problem ist ausreichend bekannt, deshalb ist es momentan auch nicht möglich, ultrakorrektes XHTML zu schreiben und sich ausschließlich auf die neusten CSS-Layouttechniken zu verlassen.
Im Vergleich zur rudimentären Zugänglichkeit einer Seite ist jedoch eher wenig relevant, ob das Layout interoperabel zu einer exakt pixelgleichen Ausgabe führt.

Da kann man strike auch als W3C gut beibehalten, aber vielleicht verselbstständigt sich da bei denen irgendetwas, oder man bildet sich als Browserhersteller ein Umsatz bzw. Updates generieren zu müssen (ob die Browser was kosten ist in dem Zusammenhang gar nicht so wichtig).

Den Satz verstehe ich nicht ganz. :)
Momentan sind die meisten W3C-Standards abwärtskompatibel, das heißt, es geht nichts Wesentliches verloren, wenn ein Browser benutzt wird, welcher nur die Vorgängerversion unterstützt. Wohingegen man eine gewisses Gestaltung durchaus als wesentlich ansehen kann, aber völlig ungestylt muss eine Seite auch in alten Browsern nicht sein.

die Verwebung von Markup und Präsentationsanweisungen zum Selbstzweck,

Nein, sondern da wo eindeutiger einfacher sicherer geschrieben, korrigiert und gelesen werden kann, möglichst ohne speziellen Editor.

Siehe oben.

Da, wo es so unmittelbar in der Struktur naheliegt wie das auch bei Tabellen vorkommt.

Tabellen sind IMHO eine völlig andere Strukturebene, das wäre, als würdest du ol, ul oder h1 mit strike vergleichen...

Grüße,
Mathias

0 58

Barrierefreiheit vs. Design oder Barrierefreiheit und Design?

Axel
  • design/layout
  1. 0
    Sven Rautenberg
    1. 0
      Axel
      1. 0
        Sven Rautenberg
        1. 0
          AnalphaBestie
          1. 0
            Sven Rautenberg
            1. 0
              Axel
      2. 0
        molily
        1. 0
          Axel
    2. 0
      Cyx23
      1. 0
        Kai Lahmann
        1. 0
          Cyx23
          1. 0
            Kai Lahmann
            1. 0
              Cyx23
              1. 0
                Kai Lahmann
                1. 0
                  Cyx23
                  1. 0
                    Christian Seiler
                    1. 0
                      Cxy23
                      1. 0
                        Christian Seiler
                      2. 0
                        Kai Lahmann
                        1. 0
                          Cyx23
                          1. 0
                            Kai Lahmann
                            1. 0
                              Cyx23
                              1. 0
                                Kai Lahmann
              2. 0
                molily
                1. 0
                  Cyx23
                  1. 0
                    Christian Seiler
                    1. 0
                      Cyx23
                      1. 0
                        Christian Seiler
                        1. 0
                          Cyx23
                          1. 0
                            Christian Seiler
                            1. 0
                              Cyx23
                              1. 0
                                Christian Seiler
                              2. 0
                                Kai Lahmann
                              3. 0
                                Sven Rautenberg
                                1. 0
                                  Cyx23
                                  1. 0
                                    Kai Lahmann
                                  2. 0
                                    Christian Seiler
                                    1. 0
                                      Cyx23
                                      1. 0
                                        Christian Seiler
                          2. 0
                            Kai Lahmann
                  2. 0
                    Sven Rautenberg
                    1. 0

                      Elemente für Navigationslisten

                      molily
                      • html
                      1. 0
                        Kai Lahmann
                      2. 0
                        Sven Rautenberg
                  3. 0
                    molily
          2. 0
            molily
    3. 0

      Design == Barrierefreiheit; Barrierefreiheit umfasst Ästhetik

      Robert Bamler
      • meinung
      1. 0
        Sven Rautenberg
        1. 0
          Robert Bamler
        2. 0
          molily
  2. 0
    Kai Lahmann
  3. 0
    Orlando
  4. 0
    Chräcker Heller
  5. 0
    Sebastian Burkhart
    1. 0
      Chräcker Heller
      1. 0
        Sebastian Burkhart
        1. 0
          Chräcker Heller