HTML Auffälligkeiten, tote Links und Validierung am Beispiel netcup.de

  • Bei der Ostereiersuche ist mir aufgefallen, dass auch Seiten wie entcup.de nicht unbedingt eine Validierung ohne Fehler übersteht. Wie handhabt Ihr das bei Euren Webseiten so mit der Validierung?
    Wird da noch drauf geachtet oder verlässt man sich darauf, dass aktuelle Browser die meisten Stolpersteine sowieso meistern. Ich sehe nur noch wenige Webseiten, die auch sowas wie die strikte Validierung noch stolz angeben ... versuchen tun es die wenigsten Webmaster.


    Tote Links:
    Auf der Seite https://www.netcup.de/ueber-netcup/partner.php findet sich unter "ACS Teilnehmer" ein kaputter Deep-Link "Allianz für Cyber-Sicherheit (ACS)" bei dem sich mittlerweile die URL geändert hat. Besser wäre es statt so extremen Deeplinks hier direkt auf die Startseite zu verweisen (https://www.allianz-fuer-cybersicherheit.de/), die selbst dann hässlichen Redirect in die interne Struktur vornimmt.


    Auf der Seite mit den Domainrichtlinien ist der Link "User Terms" für die pro-Domains nicht mehr richtig. Welches die richtige URL bzw. überhaupt die Seite der pro-Registry konnte ich selber nicht herausfinden :S

    Auf der Über uns Seite steht im Header als alternativer link für die hreflang="x-default" eine Verweis auf die netcup.eu Seite, die ebenfalls einen 404 produziert. Welcher Browser oder welche Spracheinstellung das dann auswertet kann ich nicht genau sagen. Wäre aber auch einfach zu korrigieren.


    Der W3C Validator meckert mittlerweile ja vor allem den überflüssigen type bei JavaScript Quellen an ... :/


    aber viel interessanter sind hier vielleicht die Fehler: 8|
    Ich erwähne mal vorsichtig [netcup] Lars S. der vielleicht auch eine Osterschicht schiebt und das weitergeben kann.


    Pixelangabe im width / height img Tag:

    Bei den neuen Bildern von Ostereiern für die Suche sind das z.B. Breiten- und Höhenangaben im img Tag mit dem nicht als reine Zahl von Pixeln height="30px" width="30px". Diese Angabe wäre aber eher was für die Verwendung im style Tag während bei der Angabe hier ein "30" richtig wäre.


    Encoding:

    Das Encoding der Seite ist widersprüchlich: Content-Type iso-8859-15 Content-Type: text/html; charset=iso-8859-15 VS. utf-8 <meta charset="utf-8"/> im Meta.


    Slashes:
    Direkt auf der Startseite bei Jobs / Hiring werden die Slash / Backslashes gemischt:
    "/static/assets/images\jobs\Michaela-Tom_netcup_shirt_v03.png"


    IDs
    Es sind mehrere leere id Tags vorhanden.

    WH8000 SE 🥚 20 | WH1000 SE OST22 | WH1000 SE OST23 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️

    Einmal editiert, zuletzt von Copro () aus folgendem Grund: Frohe Ostern und Feiertage!

    Gefällt mir 1
  • Wie handhabt Ihr das bei Euren Webseiten so mit der Validierung?

    Früher(tm) mit HTML 4 und XHTML 1.1 war das sicher ein Thema.

    Heutzutage mit dem ganzen Nachgelade, oder Angular / Vue / React Frontends lässt sich das ganze schwer validieren - hier wird dann auf die JS Console zurückgegriffen.


    Teilweise werden ja auch HTML Tags verwendet, die nicht standardisiert sind. Die ganzen Rendering Engines (Webkit, Gecko) kommen mit Fehlern aber sehr gut klar und der HTML 5 Standard kommt einem hier sehr stark entgegen - wenn du früher nur an Doctypes etc. denken musstest.


    Was bei dem ganzen Nichtvalidieren aber zu kurz kommt: Accessibility für Menschen mit Einschränkungen - für Screenreader etc.

  • Was bei dem ganzen Nichtvalidieren aber zu kurz kommt: Accessibility für Menschen mit Einschränkungen - für Screenreader etc

    Das ist ein riesen Problem! JavaScript basierte Websiten *können* zugänglich gestaltet werden, sind es aber leider oft nicht.

  • Copro

    Hat den Titel des Themas von „HTML Auffälligkeiten, tote Links und Validierung am Beispiel netup“ zu „HTML Auffälligkeiten, tote Links und Validierung am Beispiel netcup.de“ geändert.
  • pasted-from-clipboard.png siehe hier: https://www.w3.org/WAI/WCAG1A-Conformance

    wobei eines sollte man hier schon sagen, dass direkten HTML kaum noch jemand direkt von Hand generiert;

    es handelt sich meist um das Ergebnis von Skriptkonvoluten - was nicht heißt dass es besser/schlechter ist;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Einmal editiert, zuletzt von mainziman ()

    Gefällt mir 1
  • Hay,

    Das ist ein riesen Problem! JavaScript basierte Websiten *können* zugänglich gestaltet werden, sind es aber leider oft nicht.

    es gibt ein schönes aria-validator plugin für den chrome, der sucht alle kritischen Stellen raus mit Lösungsvorschlängen, also darf das nicht die Ausrede sein :D


    Aber:

    Problematisch ist es bezüglich JavaScript schon ein bißchen. Für einen Kunden musste ich ein komplettes Tool auf accessability umstellen, dabei war das Problem, dass Module eingebunden wurden, die nicht von uns selbst stammen - z.B. jqgrid (das ist sowas wie dataTables, aber leider poorly maintained). Aber in diesen Modulen fummelt man nicht herum, weil nach einem möglichen Update ist ja alles wieder weg.


    Ich habe es natürlich gelöst ohne in fremden Code rumfummeln zu müssen, das traue ich aber (und hoffe nicht arrogant zu klingen, aber es ist ein Erfahrungswert) nicht jedem Webdev zu. Ich hatte es schon mit Leuten zu tun, die identische ids in die HTML-Elemente geschrieben hatten - und das auch noch in verschiedene Ebenen, also etwa wie <ul id="mist"><li id="mist></li><li id="mist"></li>....</ul>. Da kannste nur den Kopf schütteln. 30-50% meiner Arbeit ist Kopfschütteln und hinterherwischen von Devs in Marketingagenturen...


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

    Gefällt mir 1