@@Matthias Apsel > Ich habe einen [Wiki-Artikel](https://wiki.selfhtml.org/wiki/CSS/Anwendung_und_Praxis/Validierungs-Stylesheet) gebastelt. > > Was gibts zu kritisieren? Ja. Schon den Anfang: _„… können sich leicht Fehler einschleichen, die zu einem invaliden Markup führen. Ein **Validierungs-Stylesheet** hilft, diese Fehler sichtbar zu machen._“ Das ist nicht das alleinige Ziel, schon gar nicht das Hauptziel. > _„Ein solches Validierungs-Stylesheet erspart in der Entwicklungszeit die ständige Konsultation eines Validators“_ **Formale** Fehler aufzudecken kann ein Validator besser. So ein Test-Stylesheet ist vor allem dazu da, Fehler aufzudecken, die ein Validator **nicht** findet. Eine Tabelle mit einer Zeile und einer Spalte bspw. ist kein formaler Fehler, aber unsinniges Markup. Das kann man [sichtbar machen](https://forum.selfhtml.org/self/2017/feb/26/einzeilige-einspaltige-tabelle-element-in-rechte-untere-ecke-plazieren/1688121#m1688121). Das Hauptaugenmerk liegt eher auf **Accessibility**{: @en}-Sünden. Wie bspw. [Click-Events für nicht fokussierbare Elemente](https://forum.selfhtml.org/self/2017/feb/22/rahmen-nur-um-ausgefuellte-zellen-einer-dynamisch-erstellten-tabelle/1687719#m1687719). `img:not([alt])` ist da ein Anfang, aber ausbaufähig. Jemand könnte auf die Idee kommen, im Markup `alt=""` zu ergänzen, womit der Fehler natürlich nicht behoben ist. Also auch `img[alt=""]` kennzeichnen? Nö, das liefert _false positives_{: @en}. Es gibt ja durchaus Fälle wie [diesen](http://codepen.io/gunnarbittersmann/pen/YpJdRm?editors=1000), wo `alt=""` angebracht ist. In dem Fall sollte das `aria-labelledby`-Attribut angeben, wo die Beschriftung des Bildes zu finden ist. Ein anderer Fall wäre ein Schmuckbild (das aus irgendeinem Grund nicht als Hintergrundbild realisiert ist), als solches markiert mit `role="none"` oder/und `"presentation"`. Eine passende Gruppe von Selektoren wäre also `img:not([alt]), img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby])`. --- Es ist auch problematisch, die Farbe der Umrandung hartcodiert auf rot zu setzen. Was, wenn man das Farbschema ändert und nun Rot als Akzentfarbe auf den Seiten auftritt? Dann muss man die Fehlerfarbe schnell ändern können, z.B. auf orange. Dateiweites Suchen und Ersetzen kann das zwar, es geht aber besser, wenn man sich die Fehlerfarbe in eine Variable packt. Die Rahmendicke dann auch gleich: ~~~css :root { --error-color: red; --error-outline: 0.5rem solid var(--error-color); } img:not([alt]), img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby]) { ERROR: 'Alternativtext fürs Bild fehlt'; outline: var(--error-outline) !important; } ~~~ Das funktioniert noch nicht im Edge; aber benutzt den wer als Browser zum Entwickeln? LLAP 🖖 PS: Kaputte Syntax-Highlighter sind kaputt. -- “When UX doesn’t consider *all* users, shouldn’t it be known as ‘*Some* User Experience’ or... SUX? #a11y” —[Billy Gregory](https://twitter.com/thebillygregory/status/552466012713783297)

@@Matthias Apsel > Ich habe einen [Wiki-Artikel](https://wiki.selfhtml.org/wiki/CSS/Anwendung_und_Praxis/Validierungs-Stylesheet) gebastelt. > > Was gibts zu kritisieren? Ja. Schon den Anfang: _„… können sich leicht Fehler einschleichen, die zu einem invaliden Markup führen. Ein **Validierungs-Stylesheet** hilft, diese Fehler sichtbar zu machen._“ Das ist nicht das alleinige Ziel, schon gar nicht das Hauptziel. > _„Ein solches Validierungs-Stylesheet erspart in der Entwicklungszeit die ständige Konsultation eines Validators“_ **Formale** Fehler aufzudecken kann ein Validator besser. So ein Test-Stylesheet ist vor allem dazu da, Fehler aufzudecken, die ein Validator **nicht** findet. Eine Tabelle mit einer Zeile und einer Spalte bspw. ist kein formaler Fehler, aber unsinniges Markup. Das kann man [sichtbar machen](https://forum.selfhtml.org/self/2017/feb/26/einzeilige-einspaltige-tabelle-element-in-rechte-untere-ecke-plazieren/1688121#m1688121). Das Hauptaugenmerk liegt eher auf **Accessibility**{: @en}-Sünden. Wie bspw. [Click-Events für nicht fokussierbare Elemente](https://forum.selfhtml.org/self/2017/feb/22/rahmen-nur-um-ausgefuellte-zellen-einer-dynamisch-erstellten-tabelle/1687719#m1687719). `img:not([alt])` ist da ein Anfang, aber ausbaufähig. Jemand könnte auf die Idee kommen, im Markup `alt=""` zu ergänzen, womit der Fehler natürlich nicht behoben ist. Also auch `img[alt=""]` kennzeichnen? Nö, das liefert _false positives_{: @en}. Es gibt ja durchaus Fälle wie [diesen](http://codepen.io/gunnarbittersmann/pen/YpJdRm?editors=1000), wo `alt=""` angebracht ist. In dem Fall sollte das `aria-labelledby`-Attribut angeben, wo die Beschriftung des Bildes zu finden ist. Ein anderer Fall wäre ein Schmuckbild (das aus irgendeinem Grund nicht als Hintergrundbild realisiert ist), als solches markiert mit `role="none` oder/und `"presentation"`. Eine passende Gruppe von Selektoren wäre also `img:not([alt]), img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby])`. --- Es ist auch problematisch, die Farbe der Umrandung hartcodiert auf rot zu setzen. Was, wenn man das Farbschema ändert und nun Rot als Akzentfarbe auf den Seiten auftritt? Dann muss man die Fehlerfarbe schnell ändern können, z.B. auf orange. Dateiweites Suchen und Ersetzen kann das zwar, es geht aber besser, wenn man sich die Fehlerfarbe in eine Variable packt. Die Rahmendicke dann auch gleich: ~~~css :root { --error-color: red; --error-outline: 0.5rem solid var(--error-color); } img:not([alt]), img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby]) { ERROR: 'Alternativtext fürs Bild fehlt'; outline: var(--error-outline) !important; } ~~~ Das funktioniert noch nicht im Edge; aber benutzt den wer als Browser zum Entwickeln? LLAP 🖖 PS: Kaputte Syntax-Highlighter sind kaputt. -- “When UX doesn’t consider *all* users, shouldn’t it be known as ‘*Some* User Experience’ or... SUX? #a11y” —[Billy Gregory](https://twitter.com/thebillygregory/status/552466012713783297)

@@Matthias Apsel > Ich habe einen [Wiki-Artikel](https://wiki.selfhtml.org/wiki/CSS/Anwendung_und_Praxis/Validierungs-Stylesheet) gebastelt. > > Was gibts zu kritisieren? Ja. Schon den Anfang: _„… können sich leicht Fehler einschleichen, die zu einem invaliden Markup führen. Ein **Validierungs-Stylesheet** hilft, diese Fehler sichtbar zu machen._“ Das ist nicht das alleinige Ziel, schon gar nicht das Hauptziel. > _„Ein solches Validierungs-Stylesheet erspart in der Entwicklungszeit die ständige Konsultation eines Validators“_ **Formale** Fehler aufzudecken kann ein Validator besser. So ein Test-Stylesheet ist vor allem dazu da, Fehler aufzudecken, die ein Validator **nicht** findet. Eine Tabelle mit einer Zeile und einer Spalte bspw. ist kein formaler Fehler, aber unsinniges Markup. Das kann man [sichtbar machen](https://forum.selfhtml.org/self/2017/feb/26/einzeilige-einspaltige-tabelle-element-in-rechte-untere-ecke-plazieren/1688121#m1688121). Das Hauptaugenmerk liegt eher auf **Accessibility**{: @en}-Sünden. Wie bspw. [Click-Events für nicht fokussierbare Elemente](https://forum.selfhtml.org/self/2017/feb/22/rahmen-nur-um-ausgefuellte-zellen-einer-dynamisch-erstellten-tabelle/1687719#m1687719). `img:not([alt])` ist da ein Anfang, aber ausbaufähig. Jemand könnte auf die Idee kommen, im Markup `alt=""` zu ergänzen, womit der Fehler natürlich nicht behoben ist. Also auch `img[alt=""]` kennzeichnen? Nö, das liefert _false positives_{: @en}. Es gibt ja durchaus Fälle wie [diesen](http://codepen.io/gunnarbittersmann/pen/YpJdRm?editors=1000), wo `alt=""` angebracht ist. In dem Fall sollte das `aria-labelledby`-Attribut angeben, wo die Beschriftung des Bildes zu finden ist. Ein anderer Fall wäre ein Schmuckbild (das aus irgendeinem Grund nicht als Hintergrundbild realisiert ist), als solches markiert mit `role="none` oder/und `"presentation"`. Eine passende Gruppe von Selektoren wäre also `img:not([alt]), img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby])`. --- Es ist auch problematisch, die Farbe der Umrandung hartcodiert auf rot zu setzen. Was, wenn man das Farbschema ändert und nun Rot als Akzentfarbe auf den Seiten auftritt? Dann muss man die Fehlerfarbe schnell ändern können, z.B. auf orange. Dateiweites Suchen und Ersetzen kann das zwar, es geht aber besser, wenn man sich die Fehlerfarbe in eine Variable packt. Die Rahmendicke dann auch gleich: ~~~css :root { --error-color: red; --error-outline: 0.5rem solid var(--error-color); } img:not([alt]), img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby]) { ERROR: 'Alterntivtext fürs Bild fehlt'; outline: var(--error-outline) !important; } ~~~ Das funktioniert noch nicht im Edge; aber benutzt den wer als Browser zum Entwickeln? LLAP 🖖 PS: Kaputte Syntax-Highlighter sind kaputt. -- “When UX doesn’t consider *all* users, shouldn’t it be known as ‘*Some* User Experience’ or... SUX? #a11y” —[Billy Gregory](https://twitter.com/thebillygregory/status/552466012713783297)

@@Matthias Apsel > Ich habe einen [Wiki-Artikel](https://wiki.selfhtml.org/wiki/CSS/Anwendung_und_Praxis/Validierungs-Stylesheet) gebastelt. > > Was gibts zu kritisieren? Ja. Schon den Anfang: _„… können sich leicht Fehler einschleichen, die zu einem invaliden Markup führen. Ein **Validierungs-Stylesheet** hilft, diese Fehler sichtbar zu machen._“ Das ist nicht das alleinige Ziel, schon gar nicht das Hauptziel. > _„Ein solches Validierungs-Stylesheet erspart in der Entwicklungszeit die ständige Konsultation eines Validators“_ **Formale** Fehler aufzudecken kann ein Validator besser. So ein Test-Stylesheet ist vor allem dazu da, Fehler aufzudecken, die ein Validator **nicht** findet. Eine Tabelle mit einer Zeile und einer Spalte bspw. ist kein formaler Fehler, aber unsinniges Markup. Das kann man [sichtbar machen](https://forum.selfhtml.org/self/2017/feb/26/einzeilige-einspaltige-tabelle-element-in-rechte-untere-ecke-plazieren/1688121#m1688121). Das Hauptaugenmerk liegt eher auf **Accessibility**{: @en}-Sünden. Wie bspw. [Click-Events für nicht fokussierbare Elemente](https://forum.selfhtml.org/self/2017/feb/22/rahmen-nur-um-ausgefuellte-zellen-einer-dynamisch-erstellten-tabelle/1687719#m1687719). `img:not([alt])` ist da ein Anfang, aber ausbaufähig. Jemand könnte auf die Idee kommen, im Markup `alt=""` zu ergänzen, womit der Fehler natürlich nicht behoben ist. Also auch `img[alt=""]` kennzeichnen? Nö, das liefert _false positives_{: @en}. Es gibt ja durchaus Fälle wie [diesen](http://codepen.io/gunnarbittersmann/pen/YpJdRm?editors=1000), wo `alt=""` angebracht ist. In dem Fall sollte das `aria-labelledby`-Attribut angeben, wo die Beschriftung des Bildes zu finden ist. Ein anderer Fall wäre ein Schmuckbild (das aus irgendeinem Grund nicht als Hintergrundbild realisiert ist), als solches markiert mit `role="none` oder/und `"presentation"`. Ein passender Selektor wäre also `img[alt=""], img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby])`. --- Es ist auch problematisch, die Farbe der Umrandung hartcodiert auf rot zu setzen. Was, wenn man das Farbschema ändert und nun Rot als Akzentfarbe auf den Seiten auftritt? Dann muss man die Fehlerfarbe schnell ändern können, z.B. auf orange. Dateiweites Suchen und Ersetzen kann das zwar, es geht aber besser, wenn man sich die Fehlerfarbe in eine Variable packt. Die Rahmendicke dann auch gleich: ~~~css :root { --error-color: red; --error-outline: 0.5rem solid var(--error-color); } img[alt=""], img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby]) { ERROR: 'Alterntivtext fürs Bild fehlt'; outline: var(--error-outline) !important; } ~~~ Das funktioniert noch nicht im Edge; aber benutzt den wer als Browser zum Entwickeln? LLAP 🖖 PS: Kaputte Syntax-Highlighter sind kaputt. -- “When UX doesn’t consider *all* users, shouldn’t it be known as ‘*Some* User Experience’ or... SUX? #a11y” —[Billy Gregory](https://twitter.com/thebillygregory/status/552466012713783297)