@marctrix
(Ich erwähne das auch noch mal, weil es vielleicht in meinen anderen Posts etwas untergeht/anders wirkt. Ich bin absolut für die Nutzung von Accessibility-Features.)
Klingt vielleicht pingelig, weil du sicher das richtige meinst, aber Accessibility ist kein Feature - es bedeutet dass die gewünschten Features welche sind. Es füllt die eigentlichen Features erst mit Bedienbarkeit, mit Funktion. Sie steckt also in allen anderen Features drin.
Ich schrieb „Nutzung von Accessibility-Features“, nicht „Nutzung des Accessibility-Features“. ;)
„Accessibility“ ist ein Konzept. Das ist so ähnlich wie etwa „Sicherheit“ in einem Auto. Um zur bestmöglichen Erfüllung des Konzepts „Sicherheit“ in einem Auto beizusteuern, dienen konkrete Features wie Knautschzonen, Airbags oder das ABS. Im Webbereich wären das in Bezug auf Accessibility eben beispielsweise eine möglichst umfangreiche und exakte semantische Auszeichnung[1] und das Bereitstellen von alternativen Inhalten (Bildbeschreibungen, Transkripte, …) und möglicherweise/nach meiner Auslegung auch so was wie eine Mobile-Version einer Seite, bei der nur eine geringere Datenmenge übertragen werden muss.
Andersrum gesagt: ohne Accessibility keine Features. Nicht ein einziges!
Das bedeutet im Umkehrschluss aber nicht, dass in einem Auto eine Knautschzone (die gleichzeitig auch noch grundlegende autobautechnische Funktionen erfüllt) nicht als Sicherheitsfeature bezeichnet werden kann oder dass im Webbereich eine möglichst gute semantische Auszeichnung nicht Accessibility-Feature genannten werden kann.
Keine Tabellenlayouts, keine zu Überschriften umgestylten
p
-Elemente, Nutzung von Elementen wielabel
oder gegebenenfalls ARIA-Attributen. ↩︎