marctrix: Inclusives Design: Das „current page“-Problem

2 52

Inclusives Design: Das „current page“-Problem

marctrix
  • barrierefreiheit
  1. 2
    Christian Kruse
    1. 0
      marctrix
      1. 0
        Matthias Apsel
        • barrierefreiheit
        • selfhtml
  2. 1
    MrMurphy1
    1. 0
      marctrix
  3. 0
    Auge
    1. 0
      marctrix
      1. 0
        Auge
        1. 1
          Tabellenkalk
          • hardware
          1. 0
            marctrix
    2. 0
      mermshaus
      1. 0
        marctrix
        1. 1
          mermshaus
          1. 0
            marctrix
  4. 0
    pl
    1. 0
      marctrix
      1. 0
        pl
        1. 0
          marctrix
      2. 0
        Gunnar Bittersmann
        1. 0
          marctrix
          1. 0
            Gunnar Bittersmann
            1. 0
              Julius
              • kontextwechsel
              • zu diesem forum
              1. 0
                mermshaus
                1. 0
                  Julius
                  1. 0
                    mermshaus
                  2. 0
                    Gunnar Bittersmann
      3. 0
        encoder
        1. 0
          marctrix
          1. 0
            encoder
            1. 0
              marctrix
              1. 0
                Auge
                1. 0
                  marctrix
                  1. 0
                    Auge
                    1. 0
                      marctrix
            2. 0
              Auge
          2. 0
            mermshaus
            1. 0
              marctrix
              1. 0
                mermshaus
  5. 0
    Julius
    1. 0
      Matthias Apsel
      1. 0
        Julius
      2. 0
        marctrix
        1. 0
          Matthias Apsel
          1. 0
            marctrix
            1. 0
              JürgenB
              1. 1
                marctrix
                1. 1
                  JürgenB
                  1. 0
                    marctrix
            2. 0
              marctrix
            3. 0
              Gunnar Bittersmann
    2. 0
      marctrix

problematische Seite

Hej alle,

nachdem mein letzter Artikel hier so freundlich aufgenommen wurde, möchte ich meinen neuesten Blog-Artikel hier bereit und zur Diskussion bereit stellen. So weit ich weiß, ist hier im Forum für externe links nofollow voreingestellt. Ich habe also nicht vor, SEO-Spam zu betreiben. Wenn sich allerdings Leute an solchen Postings hier stören, werde ich diese in Zukunft unterlassen. Sie werden aber auch so ein natürliches Ende finden, da ich eher dazu neige alle paar Monate einen Beitrag zu verfassen.

Aber hier erst mal der Link zu "Inclusives Design: Das „current page“-Problem"

Marc

  1. problematische Seite

    Hallo marctrix,

    nachdem mein letzter Artikel hier so freundlich aufgenommen wurde, möchte ich meinen neuesten Blog-Artikel hier bereit und zur Diskussion bereit stellen. So weit ich weiß, ist hier im Forum für externe links nofollow voreingestellt.

    Es gibt eine Whitelist. Du stehst drauf. ;-)

    Ich habe also nicht vor, SEO-Spam zu betreiben.

    Ich denke nicht, dass dir das einer unterstellen möchte.

    Wenn sich allerdings Leute an solchen Postings hier stören, werde ich diese in Zukunft unterlassen.

    Ich würde mich wundern, wenn sich hier jemand dadurch gestört fühlt.

    LG,
    CK

    1. problematische Seite

      Hej Christian,

      Es gibt eine Whitelist. Du stehst drauf. ;-)

      Gut zu wissen ;-)

      Marc

      1. problematische Seite

        Hallo marctrix,

        Es gibt eine Whitelist. Du stehst drauf. ;-)

        Gut zu wissen ;-)

        Wolltest du nich auch noch was für selfhtml machen? Ein Bilderkarussell?

        Bis demnächst
        Matthias

        --
        Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
  2. problematische Seite

    Hallo

    Da wird leider nur ein Problem geschaffen das es überhaupt nicht gibt. Wie die verlinkte Webseite interessanterweise selbst zeigt und damit ihren eigenen Aussagen widerspricht.

    Ein Problem ist eher das Anfänger und unsichere Webseitenersteller solche Aussagen glauben.

    Gruss

    MrMurphy

    1. problematische Seite

      Hej MrMurphy1,

      Da wird leider nur ein Problem geschaffen das es überhaupt nicht gibt.

      Probleme schafft man nicht, Probleme löst man ;-)

      Wie die verlinkte Webseite interessanterweise selbst zeigt und damit ihren eigenen Aussagen widerspricht.

      Was ich da schreibe sind ganz frische Gedanken. Leider kann ich in eine bestehende Seite nicht immer alles reinquetschen, was mir in den Sinn kommt. Zudem musste meine Webseite immer wieder als Spielwiese und für Experimente herhalten.

      Derzeit überarbeite ich Sie und versuche viele meiner Tipps auch selbst zu beherzigen.

      Ist aber nicht so einfach, weil ich z. B. mit den Beschränkungen meines aktuellen WordPress-Themes leben möchte, zu dem ich mich jetzt entschieden habe wegen dem was es kann, obwohl es anderes nicht kann.

      Wer mal in letzter Zeit auf der Seite war, hat vielleicht gesehen, dass sich gerade etwas tut.

      Insbesondere am Menü habe ich noch nichts getan, das kommt aber noch.

      Ein Problem ist eher das Anfänger und unsichere Webseitenersteller solche Aussagen glauben.

      Schön wär es!

      Marc

  3. problematische Seite

    Hallo

    Aber hier erst mal der Link zu "Inclusives Design: Das „current page“-Problem"

    Da sind Rechtschreibfehler, der vierte Absatz beginnt mit „Aandererseits“ und „Komvention“ ist immer noch eine „Konvention“. Dem Satz „Leider ist das in Aufklappmenüs bei allen Seiten, die sich nicht in der ersten Navigationsebene befinden schlicht unmöglich.“ fehlt zwischen „befinden“ und „schlicht“ ein den Nebensatz schließendes Komma.

    Ansonsten bietet dein Artikel für mich einen neuen Blickwinkel. Und das praktischerweise jetzt, wo ich gerade die Navigation unserer Website überarbeite.

    Tschö, Auge

    --
    Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
    Wolfgang Schneidewind *prust*
    1. problematische Seite

      Hej Auge,

      Aber hier erst mal der Link zu "Inclusives Design: Das „current page“-Problem"

      Da sind Rechtschreibfehler,

      Vielen Dank für die Rückmeldung! Habe jetzt keine Zeit mehr, werde das aber korrigieren!

      Ansonsten bietet dein Artikel für mich einen neuen Blickwinkel. Und das praktischerweise jetzt, wo ich gerade die Navigation unserer Website überarbeite.

      Das ist schön - man muss ja nicht immer alles machen, was man so liest, zumal ich ja zwei miteinander unvereinbare Lösungen anbiete (entweder Link zum Inhalt oder keine Verlinkung).

      Aber mal auf neue Gedanken gebracht zu werden, kann ja auch dazu führen, seine eigene Lösung zu verbessern.

      Marc

      1. problematische Seite

        Hallo

        … man muss ja nicht immer alles machen, was man so liest, zumal ich ja zwei miteinander unvereinbare Lösungen anbiete (entweder Link zum Inhalt oder keine Verlinkung).

        Aber mal auf neue Gedanken gebracht zu werden, kann ja auch dazu führen, seine eigene Lösung zu verbessern.

        Eben eben. Einfach mal von einer anderen Seite draufschauen.

        Tschö, Auge

        --
        Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
        Wolfgang Schneidewind *prust*
        1. Hallo,

          Einfach mal von einer anderen Seite draufschauen.

          Da sehe ich bloß das Acer-Logo...

          Gruß
          Kalk

          1. Hej Tabellenkalk,

            Einfach mal von einer anderen Seite draufschauen.

            Da sehe ich bloß das Acer-Logo...

            hahaha - hat eine Weile gedauert, aber wie ich schon sagte: hahaha!

            ;-)

            Übrigens habe ich den Artikel eben aktualisiert. Es gab noch Input von anderer Seite und eine Facebook-Diskussion dazu. Interessant auch hier für das Forum.

            Neben @mermshaus hat auch Kerstin Probiesch (ist eine der hier registrierten Kerstins Kerstin Probiesch?) darauf hingewiesen, dass der "Deppenlink" durchaus nützlich sein kann und in der Mehrzahl der Seiten eben nicht entfernt wird. Konventionen sind ein Freund der Zugänglichkeit und ihren Vorschlag habe ich nun als Empfehlung ins Fazit übernommen:

            Auf die Aktuelle Seite verlinken, wie auf jede andere. Diese aber optisch für sehende und mit einem Text für Blinde markieren. Das ist verständlich und robust.

            Für das Entfernen des Links sehe ich nur einen Grund: unerfahrene Nutzer können verwirrt werden, wenn sie einen Link anklicken, der auf die aktuelle Seite führt - vor allem wenn sich augenscheinlich nichts tut. Für Blinde kann es dann lästig sein, dass sie wieder am Beginn der Seite sind.

            Das durch das Missachten einer Konvention zu vermeiden, scheint mir aber nicht sinnvoll. Der Nutzen (Robustheit, Bekanntheit bei erfahrenen Nutzern, die den Hauptanteil ausmachen) überwiegt hier die Vorteile für die Neuländer meiner Meinung nach - habe mich überzeugen lassen.

            Ich weiß, dass das hier im Forum anders gesehen wird ( @gunnar bittersmann empfiehlt beispielsweise das a-Element beizubehalten aber das href-Attribut zu entfernen) . Gerade darum hier dieser Beitrag. Denkt mal drüber nach - auch wenn ihr nicht meine Meinung übernehmen könnt/wollt/sollt: diese Lösung ist robust, verständlich und am weitesten verbreitet, was dafür spricht, dass es der Nutzererwartung am nächsten kommt...

            Marc PS: wer die aktuelle Version lesen möchte: http://haunschild.de/2016/inclusives-design-current-page/

    2. problematische Seite

      @marctrix @Auge

      Ich habe auch noch mal drübergeschaut: http://tmp.ermshaus.org/621549186b9752630f70fb03d8679a3f.png (absichtlich temporär bei mir abgelegt, damit ich es in einigen Tagen wieder löschen kann)

      Ich bin mir nicht bei allen Anmerkungen völlig sicher, aber na ja. :)

      1. problematische Seite

        Hej mermshaus,

        @marctrix @Auge

        Ich habe auch noch mal drübergeschaut: http://tmp.ermshaus.org/621549186b9752630f70fb03d8679a3f.png (absichtlich temporär bei mir abgelegt, damit ich es in einigen Tagen wieder löschen kann)

        Ich bin mir nicht bei allen Anmerkungen völlig sicher, aber na ja. :)

        Vielen Dank, ist abgearbeitet! - Kannst du wieder löschen (wobei es sinnvoller wäre mir eine PN zu schicken, wenn Du Infos nur mir für eine Zeit bereit stellen würdest)... ;-)

        Bin dir für Deine Arbeit sehr dankbar!

        Marc

        1. problematische Seite

          Vielen Dank, ist abgearbeitet! - Kannst du wieder löschen (wobei es sinnvoller wäre mir eine PN zu schicken, wenn Du Infos nur mir für eine Zeit bereit stellen würdest)... ;-)

          Gern. :) Ist gelöscht.

          Der Vorteil, es öffentlich zu haben, liegt darin, dass andere Leser, die auf die gleiche Idee wie ich kommen könnten, sich dadurch potenziell doppelte Arbeit sparen, wenn sie zumindest die Chance haben, den bereits existierenden Beitrag zu sehen.

          1. problematische Seite

            Hej mermshaus,

            Vielen Dank, ist abgearbeitet! - Kannst du wieder löschen (wobei es sinnvoller wäre mir eine PN zu schicken, wenn Du Infos nur mir für eine Zeit bereit stellen würdest)... ;-)

            Der Vorteil, es öffentlich zu haben, liegt darin, dass andere Leser, die auf die gleiche Idee wie ich kommen könnten, sich dadurch potenziell doppelte Arbeit sparen,

            Stimmt! - Hatte ich nicht bedacht...

            Marc

  4. problematische Seite

    @@

    Aber hier erst mal der Link zu "Inclusives Design: Das „current page“-Problem"

    Dieses Thema wurde hier vor gefühlten 10 Jahren schon einmal diskutiert. Das damalige Ergebnis bestand darin, das href-Attribute im <a>-Element wegzulassen.

    1. problematische Seite

      Hej pl,

      Aber hier erst mal der Link zu "Inclusives Design: Das „current page“-Problem"

      Dieses Thema wurde hier vor gefühlten 10 Jahren schon einmal diskutiert. Das damalige Ergebnis bestand darin, das href-Attribute im <a>-Element wegzulassen.

      Ich weiß, dass das hier Konsens ist. Eben drum mal ein frischer Input. Selbst gefühlte 10 Jahre sind eine Ewigkeit.

      Ich fand den Verzicht auf das href nie als Optimum. Die Ersetzung mittels strong um die aktuelle Seite zu betonen, finde ich deutlich besser. Allerdings kann ich verstehen, warum man das anders sieht. Egal ob a oder strong: Screenreader müssen auch bedacht werden.

      wobei das Ergebnis des Denkprozesses offen sein muss. Ich kann das Argument zum Beispiel gut nachvollziehen, dass eine Seite, auf der man bereits ist, im Menü nicht unbedingt noch einmal auftauchen muss. Insbesondere, wenn dieser Menüeintrag ohnehin nicht anklickbar ist. Insofern könnte ich durchaus verstehen, wenn einer der Meinung ist, der Menüeintrag muss entweder auf den Hauptinhalt verweisen, oder er soll gar nicht erst vorgelesen werden.

      Marc

      1. problematische Seite

        @@

        wobei das Ergebnis des Denkprozesses offen sein muss. Ich kann das Argument zum Beispiel gut nachvollziehen, dass eine Seite, auf der man bereits ist, im Menü nicht unbedingt noch einmal auftauchen muss. Insbesondere, wenn dieser Menüeintrag ohnehin nicht anklickbar ist.

        Bedenke, dass sich dann die anderen <li>-'s verschieben, auf deutsch gesagt: Das Menu zappelt dann unnötig rum wenn Einträge rausfliegen. Einem Blinden kann das zwar egal sein aber es gibt ja auch Besucher die gucken selber. Und warum sollte der letzte BreadCrumb verschwinden wenn man draufklickt... in meinem Fall muss er sogar bleiben weil es der Link zum virtuellen Ordner/Index ist in dem die Dokumente angesiedelt sind -- in dem Moment wo eine dieser Seiten aufgerufen wird, ist der BreadCrumb wieder klickbar.

        Meine Log-Auswertungen/Trackings zeigen mir auch, dass die Navigation genutzt wird. MfG

        1. problematische Seite

          Hej pl,

          @@

          wobei das Ergebnis des Denkprozesses offen sein muss. Ich kann das Argument zum Beispiel gut nachvollziehen, dass eine Seite, auf der man bereits ist, im Menü nicht unbedingt noch einmal auftauchen muss. Insbesondere, wenn dieser Menüeintrag ohnehin nicht anklickbar ist.

          Bedenke, dass sich dann die anderen <li>-'s verschieben, auf deutsch gesagt: Das Menu zappelt dann unnötig rum wenn Einträge rausfliegen

          Nein, da der Link "nur" für Blinde verschwindet, ist aber auch Schwachsinn, ihr habt recht. Der Exkurs fliegt raus!

          Marc

      2. problematische Seite

        @@marctrix

        Ich fand den Verzicht auf das href nie als Optimum.

        Die Spec sieht das explizit vor: “If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element’s contents.”

        Und liefert auch ein Beispiel.

        Die Ersetzung mittels strong um die aktuelle Seite zu betonen, finde ich deutlich besser.

        Warum sollte der Menüpunkt der aktuellen Seite auf der semantischen Ebene hervorgehoben werden? Er ist doch im Menü nicht bedeutsamer als die anderen. Im Gegenteil.

        Der Menüpunkt der aktuellen Seite wird in der Betonung zurückgenommen. Nur weil es der einzige derart zurückgenommene ist, erscheint er hervorgehoben.

        Kein Grund für strong, IMHO. a ohne href ist semantisch genau das Richtige.

        LLAP 🖖

        --
        „Wenn du eine weise Antwort verlangst, musst du vernünftig fragen.“ —Johann Wolfgang von Goethe
        1. problematische Seite

          Hej Gunnar,

          @@marctrix

          Ich fand den Verzicht auf das href nie als Optimum.

          Die Spec sieht das explizit vor: “If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element’s contents.”

          Und liefert auch ein Beispiel.

          Manchmal führt die Spec auch in die Irre, HTML5 ist ja einerseits gerade bemüht, Trampelpfade zu asphaltieren, also gängige Praxis und Konventionen zu standardisieren.

          Dann wiederum (wie in diesem Fall) möchte sie Konventionen bilden. Dieser Widerspruch allein macht sie schon ungeeignet um nachzuweisen, welches Element aus Nutzersicht das erwartete und damit verständlichste ist.

          Wenn die Spec immer recht hätte, wäre das entrümpeln in der Version 5.1 ja unnötig gewesen. menu beispielsweise einzusetzen, hätte wohl nie einen Gewinn an Benutzerfreundlichkeit bedeutet - egal ob Teil des Standards oder nicht.

          Die Ersetzung mittels strong um die aktuelle Seite zu betonen, finde ich deutlich besser.

          Warum sollte der Menüpunkt der aktuellen Seite auf der semantischen Ebene hervorgehoben werden? Er ist doch im Menü nicht bedeutsamer als die anderen. Im Gegenteil.

          Sehe ich anders. Wieso sollte die aktuelle Seite denn nicht etwas besonderes unter allen ansonsten gleichrangigen Seiten sein? - Für mich ist sie das eindeutig! Und damit ein Paradebeispiel für den sinnvollen Einsatz von strong. Mir ist natürlich klar, dass ich dich nicht werde überzeugen können ;-)

          Der Menüpunkt der aktuellen Seite wird in der Betonung zurückgenommen. Nur weil es der einzige derart zurückgenommene ist, erscheint er hervorgehoben.

          Eben, jedem erscheint er hervorgehoben - und trotzdem soll ich ihn semantisch zurücknehmen? Entgegen dem Empfinden und der Erwartung der Nutzer? Warum? - Mir fällt nur ein Grund ein: Standardkonformität über Nutzerwünsche zu stellen!

          Kein Grund für strong, IMHO. a ohne href ist semantisch genau das Richtige.

          Wie kann es richtig sein, das, was jeder™ als hervorgehoben wahrnimmt, semantisch zurückzunehmen?

          Benutzerfreundliche Lösungen erfüllen die Erwartungen von Nutzern, nicht die der Spec. Die Spec hat sich den Realitäten anzupassen und diese zu standardisieren, nicht umgekehrt.

          Deswegen brauchen wir ja auch ein di...

          Marc

          1. problematische Seite

            @@marctrix

            Warum sollte der Menüpunkt der aktuellen Seite auf der semantischen Ebene hervorgehoben werden? Er ist doch im Menü nicht bedeutsamer als die anderen. Im Gegenteil.

            Sehe ich anders. Wieso sollte die aktuelle Seite denn nicht etwas besonderes unter allen ansonsten gleichrangigen Seiten sein?

            Etwas besonderes, ja. Aber um besonders zu sein, muss der Menüpunkt nicht hervorgehoben werden. Die Besonderheit ergibt sich bereits daraus, dass der Menüpunkt nicht verlinkt ist, d.h. dass das Element (welchen Typs auch immer) kein href-Attribut hat.

            Man muss hier zwei Ebenen unterscheiden: die technische (HTML) und die Nutzersicht.

            Aus Markup-Sicht besteht ein Menü aus gleichrangigen Menüpunkten. Die Nichtverlinkung der aktuellen Seite ändert nichts an der Gleichrangigkeit.

            (Es könnten auch einzelne Menüpunkte wichtiger sein als andere und deshalb hervorgehoben – dann aber auf allen Seiten.)

            Aus Nutzersicht sollte die aktuelle Seite im Menü anders erscheinen.

            Der Menüpunkt der aktuellen Seite wird in der Betonung zurückgenommen. Nur weil es der einzige derart zurückgenommene ist, erscheint er hervorgehoben.

            Eben, jedem erscheint er hervorgehoben - und trotzdem soll ich ihn semantisch zurücknehmen?

            Alle Menüpunkte buhlen um die Beachtung durch den Nutzer: „Ruf. Mich. Auf!“ ;-) Außer dem einen Mauerblümchen, das sich still verhält, sich also zurücknimmt.

            Dass dieser eine vom Nutzer hervorgehoben erscheint, liegt an der Figur-Grund-Wahrnehmung: Das, wovon mehr da ist, wird als Grund wahrgenommen; das, wovon weniger da ist, hebt sich als Figur vom Grund ab.

            Nur wenn beides gleich stark ist, kann man wahlweise das eine oder das andere als Figur wahrnehmen:

            Kippfigur: (a) zwei schwarze Gesichter vor weißem Hintergrund und (b) eine weiße Vase vor schwarzem Hintergrund (Quelle: Wikimedia Commons; Autoren: Guam, Bryan Derksen, Fibonacci; CC BY-SA 3.0)

            Eben, jedem erscheint er hervorgehoben - und trotzdem soll ich ihn semantisch zurücknehmen?

            Vor mir aus soll dem Nutzer die aktuelle Seite im Menü auch hervorgehoben erscheinen. Das Menü erfüllt ja zwei Funktionen: (1) Sammlung von Wegweisen zu anderen Seiten und (2) Orientierungshinweis: Du bist hier.

            Das heißt aber nicht, dass sich die wahrgenommene Hervorhebung auf der technischen Ebene, d.h. im Markup widerspiegeln müsste.

            Für mich ist sie das eindeutig! Und damit ein Paradebeispiel für den sinnvollen Einsatz von strong. Mir ist natürlich klar, dass ich dich nicht werde überzeugen können ;-)

            Vielleicht kann ich dich aber davon überzeugen, dass der Einsatz von strong auf der technischen Ebene alles andere als sinnvoll ist. Er verkompliziert den Code unnötig.

            Für ein a ohne href brauchst du nur eine einfache If-Anweisung:[1]

              <a 
            <?php if ($Menüpunkt != $aktuelleSeite): ?>
                href="http://example.net/stairway/to/heaven"
            <?php endif; ?>
              >
                Stairway to heaven
              </a>
            

            Um das a gegen einen anderen Elementtypen auszutauschen, brauchst du zwei If-Anweisungen, jede davon mit Then- und Else-Zweig:

            <?php if ($Menüpunkt != $aktuelleSeite): ?>
              <a href="http://example.net/road/to/hell">
            <?php else: ?>
              <strong>
            <?php endif; ?>
                Road to hell
            <?php if ($Menüpunkt != $aktuelleSeite): ?>
              </a>
            <?php else: ?>
              </strong>
            <?php endif; ?>
            

            Mir fällt jetzt wirklich kein Grund ein, der gegen a und für strong spräche.

            Vom Markup ganz abgesehen ist es sicherlich nicht sinnvoll, im Menü die aktuelle Seite durch Fettschrift zu kennzeichnen. Durch die veränderte Laufweite würde die Schrift womöglich nicht mehr in den für den Menüpunkt vorgesehenen Platz passen; oder wenn sich der Platz vergrößert, würde das Menü rumzappeln, womöglich sogar eine Zeile mehr beanspruchen und das Layout zerschießen.

            Andere Vordergrund-/Hintergrundfarbe, ja. Andere Schriftstärke – nein, besser nicht.

            Für strong müsstest man die Schriftstärke explizit mit CSS auf inherit setzen; das entfällt bei a.

            LLAP 🖖

            PS: Nun gibt’s bei der einfachen If-Anweisung doch einen Else-Zweig:

              <a 
            <?php if ($Menüpunkt != $aktuelleSeite): ?>
                href="http://example.net/stairway/to/heaven"
            <?php else: ?>
                tabindex="0"
            <?php endif; ?>
              >
                Stairway to heaven
              </a>
            

            Man könnte zwar tabindex="0" für jeden Link im Menü angeben, aber man muss das Markup ja nicht vollmüllen.

            Der Else-Zweig wäre auch der Platz fürs aria-describedby-Attribut, das dem Screenreader-Nutzer mitteilt, das dies die aktuelle Seite ist (als Hinweis, warum der Menüpunkt nicht verlinkt ist).

            --
            „Wenn du eine weise Antwort verlangst, musst du vernünftig fragen.“ —Johann Wolfgang von Goethe

            1. Man erhält weder mit php noch mit html hier eine brauchbare Darstellung des Codes. Kaputte Syntax-Highlighter sind kaputt. ↩︎

            1. problematische Seite

              Hallo Gunnar,

              ¹: Man erhält weder mit php noch mit html hier eine brauchbare Darstellung des Codes. Kaputte Syntax-Highlighter sind kaputt.

              Das liegt wohl daran, dass der php-Modus kein HTML kann und der html-Modus kein PHP versteht (bzw. es nicht ignoriert).

              gedit schaltet beispielsweise den „Modus“ um:
              Alternativ-Text

              Die Quelltextansicht von Firefox dagegen ignoriert CSS und JavaScript (immerhin sinnvoller als blind irgendetwas hervorzuheben):
              Alternativ-Text

              @Christian Kruse: Ist dir dieses Verhalten bekannt?

              Gruß
              Julius

              1. problematische Seite

                @Gunnar Bittersmann @Julius @Christian Kruse

                Der Syntax-Highlighter für PHP (~~~ php) startet im PHP-Modus, während eine komplette PHP-Datei auf der Festplatte sozusagen immer im HTML-Modus startet (und mit <?php am Dateibeginn in den PHP-Modus umgeschaltet wird).

                Das kann der Syntax-Highlighter aber nicht wirklich anders handhaben, weil sonst bei jedem kurzen Codeausschnitt…

                for ($i = 1; $i <= 24; $i++) {
                    echo $i, "<br>\n";
                }
                

                …ein einleitendes <?php hinzugefügt werden müsste. Das ist nicht praktikabel.

                Das Beispiel aus Gunnars Post könnte also um ein einleitendes ?> ergänzt werden, um in den HTML-Modus zu schalten.

                ?>
                  <a 
                <?php if ($Menüpunkt != $aktuelleSeite): ?>
                    href="http://example.net/stairway/to/heaven"
                <?php else: ?>
                    tabindex="0"
                <?php endif; ?>
                  >
                    Stairway to heaven
                  </a>
                

                Das ergibt inhaltlich aber natürlich wenig Sinn.

                Alternativ könnte man höchstens im Syntax-Highlighter so eine Logik haben: „Wenn die Eingabe irgendwo nicht direkt am Anfang noch <?php … ?>-Sequenzen enthält, dann gehe davon aus, dass die Eingabe im HTML-Modus beginnt.“ Das scheint beispielsweise der Highlighter von vBulletin zu machen. Das ist oft „richtig genug“:

                Es kann aber genauso danebenliegen:

                (Beziehungsweise ist es letztlich nicht entscheidbar. Das $x= usw. könnte ja auch tatsächlich als HTML-Ausgabe gemeint sein.)

                Mir ist der Ansatz des Highlighters hier im Forum, den Start-Modus nicht erraten zu wollen, deshalb grundsätzlich lieber.

                Die sauberste Lösung wäre es wohl, einen zweiten Code-Tag für PHP-Highlighting hinzuzufügen, der im HTML-Modus beginnt, oder der ~~~ php-Syntax einen Parameter hinzuzufügen. So im Sinne von: ~~~ php startinline=false (was aber so nicht funktioniert).

                Kann auch gut sein, dass es so was auch hier im Forum bereits gibt.

                1. problematische Seite

                  Hallo mermshaus,

                  Das kann der Syntax-Highlighter aber nicht wirklich anders handhaben, weil sonst bei jedem kurzen Codeausschnitt […] ein einleitendes <?php hinzugefügt werden müsste. Das ist nicht praktikabel.

                  Ich wusste, dass ich etwa übersehen habe :-)

                  Das ergibt inhaltlich aber natürlich wenig Sinn.

                  Alternativ könnte man höchstens im Syntax-Highlighter so eine Logik haben: „Wenn die Eingabe irgendwo nicht direkt am Anfang noch <?php … ?>-Sequenzen enthält, dann gehe davon aus, dass die Eingabe im HTML-Modus beginnt.“ Das scheint beispielsweise der Highlighter von vBulletin zu machen. Das ist oft „richtig genug“:

                  Problem: Was passiert bei dem PHP-Codeschnipselchen ohne einleitendes <?php?

                  (Beziehungsweise ist es letztlich nicht entscheidbar. Das $x= usw. könnte ja auch tatsächlich als HTML-Ausgabe gemeint sein.)

                  Mir ist der Ansatz des Highlighters hier im Forum, den Start-Modus nicht erraten zu wollen, deshalb grundsätzlich lieber.

                  Mir erscheint es aber dann sinnvoll, beispielsweise im Modus html auf <?php oder <?= zu reagieren, da diese in HTML sonst nicht vorkommen dürfen. Alternativ könnte man dieses Verhalten html-php nennen.

                  Gruß
                  Julius

                  1. problematische Seite

                    Mir erscheint es aber dann sinnvoll, beispielsweise im Modus html auf <?php oder <?= zu reagieren, da diese in HTML sonst nicht vorkommen dürfen.

                    Die Tags können mindestens in script-Elementen und in HTML-Kommentaren (<!-- … -->) auftauchen. Das wäre also auch nicht zweifelsfrei exakt.

                    Ich meine, klar, in den allermeisten Fällen wird schon eingebetteter PHP-Code gemeint sein, wenn ein <?php oder <?= im HTML-Codebeispiel steht.

                  2. problematische Seite

                    @@Julius

                    Hach, früher™ war alles besser™. Da hätte ich hier im Forum geschrieben:

                    [code=html]  <a 
                    <?php [code=php]if ($Menüpunkt != $aktuelleSeite):[/code] ?>
                        href="http://example.net/stairway/to/heaven"
                    <?php [code=php]endif;[/code] ?>
                      >
                        Stairway to heaven
                      </a>[/code]
                    

                    Das heißt, ich habe das so geschrieben. Was jetzt dazu führt, dass, weil der Syntax-Highlighter keine verschachtelten Sprachen kennt, etliche meiner Postings im Archiv zerschossen sind. Einige wurden berichtigt (was @Christian Kruse immer wieder in den Wahsinn treibt), unzählige andere sind wohl immer noch zerschossen und werden es wohl auch für immer bleiben. Staub drauf!

                    Jetzt muss man sich für eine Sprachangabe entscheiden; vermutlich für die äußere.

                    Aber ja, ein vernünftiger™ Syntax-Highlighter sollte mit häufig auftretenden Verschachtelungen (wie es PHP in HTML eine ist) umgehen können.

                    Mir erscheint es aber dann sinnvoll, beispielsweise im Modus html auf <?php oder <?= zu reagieren, da diese in HTML sonst nicht vorkommen dürfen. Alternativ könnte man dieses Verhalten html-php nennen.

                    Genau das. Wobei ich mir nicht sicher bin, ob es dazu einer Kennzeichnung wie html-php bedürfen sollte.

                    LLAP 🖖

                    --
                    „Wenn du eine weise Antwort verlangst, musst du vernünftig fragen.“ —Johann Wolfgang von Goethe
      3. problematische Seite

        Ich kann das Argument zum Beispiel gut nachvollziehen, dass eine Seite, auf der man bereits ist, im Menü nicht unbedingt noch einmal auftauchen muss.

        Ich nicht. Es verwirrt wenn ein Eintrag plötzlich fehlt, der Grund warum er fehlt ist keinem sofort ersichtlich. Außerdem ist es zur Orientierung sehr nützlich wenn ich sehe wo ich gerade bin und wo es weitergeht, wenn ich eine Seite systematisch durchsehen möchte.
        Was mit dem kleinen Pfeilchen in diesem Forum übrigens nicht so wirklich gegeben ist, hatte schon mal angeregt den aktuellen Beitrag schön knallig hervorzuheben.

        Insofern könnte ich durchaus verstehen, wenn einer der Meinung ist, der Menüeintrag muss entweder auf den Hauptinhalt verweisen

        Sehr gute Idee. Guten Seiten gibts genug, nicht mit uns! Diese verdammten Benutzer die sich immer zurechtfinden wollen, können uns mal! Deswegen ordne ich Links auf jeder Seite zufällig an. Man könnte auch in jedem zweiten auf eine Pornoseite verweisen.

        Bleiben wir ernsthaft. 3 Monate Internetsperre für den Erfinder dieser Lösungen. Minimum!
        Dann lass ich den Link doch lieber so wie er ist, wer zum zehnten Mal draufklickt merkt schon dass er immer das selbe wählt.
        Da verstehe ich MrMurphy1 durchaus wenn er sagt wo bitte ist da eigentlich ein Problem, vor allem wenn sowas die Lösung dazu sein soll.

        1. problematische Seite

          Hej encoder,

          Ich kann das Argument zum Beispiel gut nachvollziehen, dass eine Seite, auf der man bereits ist, im Menü nicht unbedingt noch einmal auftauchen muss.

          Ich nicht. Es verwirrt wenn ein Eintrag plötzlich fehlt,

          Wie merkst du das denn? Das ist ja gerade einer der Schwierigkeiten bei Aufklappmenüs.

          Trotzdem hast du vermutlich recht, dass er besser bleibt, wo er ist. Ich gebe im Artikel ja auch eine andere Empfehlung (markieren der geöffneten Seite mittels strong)

          Den Satz werde ich im Artikel streichen.

          der Grund warum er fehlt ist keinem sofort ersichtlich. Außerdem ist es zur Orientierung sehr nützlich wenn ich sehe wo ich gerade bin und wo es weitergeht, wenn ich eine Seite systematisch durchsehen möchte.

          Auch das ist mit einem Aufklappen fast unmöglich - insbesondere wenn besuchte Links nicht markiert werden.

          Das ist aber auch nicht sinnvoll, wenn jemand öfters ein Angebot kommt oder eine Seite unter verschiedenen URLs erreichbar ist - was immer mehr zur Regel wird. Hier würde meiner Meinung nach eine zeitlich sortierte Liste aller Artikel mehr helfen.

          Insofern könnte ich durchaus verstehen, wenn einer der Meinung ist, der Menüeintrag muss entweder auf den Hauptinhalt verweisen Sehr gute Idee. Guten Seiten gibts genug, nicht mit uns! Diese verdammten Benutzer die sich immer zurechtfinden wollen, können uns mal!

          Es ist dir aber schon klar, dass es mir bei den Überlegungen darum geht, gerade das Zurechtfinden zu erleichtern?

          Da verstehe ich MrMurphy1 durchaus wenn er sagt wo bitte ist da eigentlich ein Problem, vor allem wenn sowas die Lösung dazu sein soll.

          Das Problem ist: wie unterstütze ich Nutzer optimal bei in ihrem Bedürfnis, sich auf einer Webseite zurechtzufinden.

          Die Lösung finde ich interessant. Das Problem ist ja nicht wirklich, dass es nicht sinnvoll wäre, wenn der Link statt zur aktuellen Seite zum Inhalt der Seite führt. Das Problem ist, dass Nutzer es anders gewohnt sind. Würde es zu einer Konvention (Quasi-Standard), dass ein Menüeintrag mit dem Namen der aktuell geöffneten Seite zum Hauptinhalt genau dieser Seite führt, dann wäre es ein Gewinn. Die Verwirrung entsteht ja nur dadurch, dass wir heute etwas anderes erwarten. Genau das ist ja auch mein Argument dagegen. Zwar habe ich mit Vorschlägen (die nicht von Pickering, sondern mir stammen) zur Verdeutlichung der neuen Funktionalität versucht, den Nutzer über das Linkziel vor dem Klick zu informieren - mir erscheint das aber sehr aufwändig und vor allem für wiederkehrende Nutzer nervig, die das Verhalten schon kennen - zumal solche Hinweise andere Inhalte überlagern würden - jedenfalls die Mouse-Over-Geschichten...

          Daher rate ich persönlich (wie seit zehn Jahren oder länger schon) zu strong statt a...

          Marc

          1. problematische Seite

            Oh!
            Ich las heraus als sollte der Link der aktuellen Seite plötzlich zur STARTseite (Hauptseite) führen, also wo ganz anders hin als sonst, nur weil ein Link auf die bereits angezeigte Seite nicht hilfreich ist. Diese Vorstellung war so absurd dass mein Satz mit "gute Idee usw." reinste Ironie war. Ich dachte mir ach du liebe Güte, auf was die Leute alles kommen nur um was anders zu machen als bisher.

            Wie ist das denn sonst gemeint? Mir scheint da hab ich zu wenig Zeit zum überlegen investiert. Was ist der Hauptinhalt einer Seite?
            Richtig verstanden hab ich das immer noch nicht. Aber ich weiß jetzt wenigstens dass ich es falsch verstanden habe :-)

            Ich kann das Argument zum Beispiel gut nachvollziehen, dass eine Seite, auf der man bereits ist, im Menü nicht unbedingt noch einmal auftauchen muss.

            Ich nicht. Es verwirrt wenn ein Eintrag plötzlich fehlt,

            Wie merkst du das denn? Das ist ja gerade einer der Schwierigkeiten bei Aufklappmenüs.

            Auch in einem Aufklappmenü kann der Link ja drinstehen, dann seh ich ah da bin ich grad, die nächste Seite wäre also eins weiter unten.

            1. problematische Seite

              Hej encoder,

              Was ist der Hauptinhalt einer Seite?

              Das, was in das Element maingehört. - Haben das noch andere nicht so verstanden? Dann müsste ich das besser formulieren!?!

              Ich kann das Argument zum Beispiel gut nachvollziehen, dass eine Seite, auf der man bereits ist, im Menü nicht unbedingt noch einmal auftauchen muss.

              Ich nicht. Es verwirrt wenn ein Eintrag plötzlich fehlt,

              Wie merkst du das denn? Das ist ja gerade einer der Schwierigkeiten bei Aufklappmenüs. Auch in einem Aufklappmenü kann der Link ja drinstehen, dann seh ich ah da bin ich grad, die nächste Seite wäre also eins weiter unten.

              Ja, ist schon klar. Das Problem: Du musst noch wissen, unter welchem Hauptmenü-Punkt das war oder suchen. Aber das Problem lässt sich nicht lösen - man kann aber die aktuelle Rubrik in der Hauptnavigation hervorheben.

              Ein Problem dabei, einen Beitrag in eine bestimmte Rubrik einzuordnen ist allerdings, dass ein Artikel eben in seinem zeitlichen Kontext, seinem thematischen Kontext oder in einem quantitativen (mesitgelesene Artikel) und qualitativen (von irgendeinem Schlaumeier gut bewertet) Kontext erscheinen kann - deswegen baue ich haunschild.de gerade um. Ich tüftle noch an einem Navigationskonzept, in dem die Hauptnavi auf eine Ebene eingedampft wird - alles andere findet dann über Navigationslisten listen statt, die Artikel in solche Kontexte einsortiert und andere Artikel in denselben Kontexten zugänglich macht. Das hinzukriegen ohne Nutzer zu überfordern oder mit unzähligen Navigationsleisten zu nerven, ist die Herausforderung, die ich gerade zu lösen zu versuche - für so eine simple Seite, wie es meine nun mal ist...

              Marc

              1. problematische Seite

                Hallo

                Auch in einem Aufklappmenü kann der Link ja drinstehen, dann seh ich ah da bin ich grad, die nächste Seite wäre also eins weiter unten.

                Ja, ist schon klar. Das Problem: Du musst noch wissen, unter welchem Hauptmenü-Punkt das war oder suchen. Aber das Problem lässt sich nicht lösen - man kann aber die aktuelle Rubrik in der Hauptnavigation hervorheben.

                Man kann auch den Baum des Hauptpunkts der aktuellen Seite als Voreinstellung aufgeklappt darstellen. Bedienelemente zum auf- und zuklappen des aktuellen wie der anderen Bäume sollten natürlich vorhanden sein und bei langen Listen wird das bestimmt schnell unübersichtlich. Für Seiten mit jeweils wenigen Unterpunkten zu den Hauptpunkten wäre das mMn aber eine Möglichkeit, die aktuelle Seite in jedem Fall im Menü hervorzuheben.

                Tschö, Auge

                --
                Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
                Wolfgang Schneidewind *prust*
                1. problematische Seite

                  Hej Auge,

                  Ja, ist schon klar. Das Problem: Du musst noch wissen, unter welchem Hauptmenü-Punkt das war oder suchen. Aber das Problem lässt sich nicht lösen - man kann aber die aktuelle Rubrik in der Hauptnavigation hervorheben.

                  Man kann auch den Baum des Hauptpunkts der aktuellen Seite als Voreinstellung aufgeklappt darstellen.

                  So was in der Art?

                  |Link 1. Ebene|Link 1. Ebene|Link 1. Ebene|Aktueller Pfad|Link 1. Ebene| |Link 2. Ebene|Aktuelle Seite|Link 2. Ebene|Link 2. Ebene|Link 2. Ebene|

                  Klingt nach einem Ansatz - vielleicht kombiniert mit einem Farbleitsystem...

                  Marc

                  1. problematische Seite

                    Hallo

                    Ja, ist schon klar. Das Problem: Du musst noch wissen, unter welchem Hauptmenü-Punkt das war oder suchen. Aber das Problem lässt sich nicht lösen - man kann aber die aktuelle Rubrik in der Hauptnavigation hervorheben.

                    Man kann auch den Baum des Hauptpunkts der aktuellen Seite als Voreinstellung aufgeklappt darstellen.

                    So was in der Art?

                    |Link 1. Ebene|Link 1. Ebene|Link 1. Ebene|Aktueller Pfad|Link 1. Ebene| |Link 2. Ebene|Aktuelle Seite|Link 2. Ebene|Link 2. Ebene|Link 2. Ebene|

                    Hmm … ich dachte eher an soetwas:

                    • Start
                    • Eine Geschichte ▲
                      • Prolog
                      • Kapitel 1
                      • Kapitel 2
                      • Kapitel 3
                      • Epilog
                    • Eine zweite Geschichte
                    • Eine dritte Geschichte
                    • Impressum

                    Klingt nach einem Ansatz - vielleicht kombiniert mit einem Farbleitsystem...

                    Oh, Farben. Noch 'ne interessante Herausforderung. :-)

                    Tschö, Auge

                    --
                    Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
                    Wolfgang Schneidewind *prust*
                    1. problematische Seite

                      Hej Auge,

                      Hmm … ich dachte eher an soetwas:

                      • Start
                      • Eine Geschichte ▲
                        • Prolog
                        • Kapitel 1
                        • Kapitel 2
                        • Kapitel 3
                        • Epilog
                      • Eine zweite Geschichte
                      • Eine dritte Geschichte
                      • Impressum

                      Bei einer horizontalen Navigation im Kopfbereich würde diese Darstellung aber zwangsläufig Inhalte verdecken (ich rede hier von der Darstellung auf Desktops - auf dem Smartphone würden die Inhalte aus dem sichtbaren Bereich gedrückt)...

                      Klingt nach einem Ansatz - vielleicht kombiniert mit einem Farbleitsystem...

                      Oh, Farben. Noch 'ne interessante Herausforderung. :-)

                      Daran soll man ja bekanntlich wachsen ;-)

                      Marc

            2. problematische Seite

              Hallo

              Wie ist das denn sonst gemeint? Mir scheint da hab ich zu wenig Zeit zum überlegen investiert. Was ist der Hauptinhalt einer Seite?

              Es ist der Inhalt der aktuellen Seite, wenn ich das richtig verstanden habe. Hier mal mit ID, damit es ein Sprungziel gibt.

              <main id="content"></main>
              

              Tschö, Auge

              --
              Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
              Wolfgang Schneidewind *prust*
          2. problematische Seite

            @pl @marctrix @encoder

            Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“ anbietet (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen. Ich nutze das jetzt nicht unbedingt häufig, aber ich denke, dass mir das Fehlen dieses Features öfter mal negativ auffallen würde (zum Beispiel in Foren, siehe unten). Konkret verändert man mit einem Entfernen des Selbstlinks die Funktionalität der entsprechenden Schaltfläche. Sie tut dann nicht mehr das, was sie auf anderen Seiten des Angebots tut und was erwartbar ist.[1]

            Wenn ich bei HOME | BLOG | CONTACT (nur Wörter in Großbuchstaben sollen Links sein) auf BLOG klicke und dann HOME | Blog | CONTACT im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf Blog zu klicken – auf HOME oder CONTACT klicken, um dann dort direkt wieder auf BLOG klicken zu können.

            Alternativ müsste ich zur Tastatur greifen und F5 drücken (umständlich und nicht funktional identisch (!)[2]) oder den Refresh-Button in der Toolbar des Browsers betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).

            Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

            Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.

            Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler. Die Alternative wäre es wieder, aus dem Thread zu klicken, um auf eine Übersichtsseite zu gelangen, auf der der Thread sauber verlinkt ist. Wie oben mit der Blog-Seite.


            Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein aria-current wie im verlinkten Artikel erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.


            Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.


            1. Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt. ↩︎

            2. Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“. ↩︎

            1. problematische Seite

              Hej mermshaus,

              Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“ anbietet (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen.

              Herzlichen Dank für Deinen Einwand - würde den gerne im Artikel verwursten!

              Darf ich und möchtest du genannt werden? Wenn ja, wie?

              Macht wohl auch Sinn auf diese Diskussion hier zu verlinken...

              Marc

              1. problematische Seite

                Hi Marc.

                Herzlichen Dank für Deinen Einwand - würde den gerne im Artikel verwursten!

                Darf ich und möchtest du genannt werden? Wenn ja, wie?

                Macht wohl auch Sinn auf diese Diskussion hier zu verlinken...

                Mach es von mir aus sehr gern so, wie es für dich am besten passt. Ich habe nichts dagegen, aber ich bestehe in keiner Weise darauf.

                Viele Grüße

                Marc :)

  5. problematische Seite

    Hallo Marc,

    vielen Dank für den Überblick! Die Argumentation zum Springen mit der Tab-Taste war mir noch gar nicht bekannt – strong mit tabindex="0" klingt gut (hatte bisher nur ein span verwendet...).

    Mir sind zwei Dinge bei der Formatierung aufgefallen:

    1. Im Abschnitt zur Lösung mit Verlinkung des Hauptinhalts ist im Absatz über dem Beispiel-HTML ein Code-Element nicht geschlossen.
    2. Irgendwie werden die Quotes " in deinem Beispiel-HTML durch Anführungszeichen ersetzt, sodass das HTML bei Copy & Paste nicht funktioniert. Das könnte Leute irritieren...

    Gruß
    Julius

    --
    Die neuste Digital-Neuland-Bildungsoffensive der Bundesregierung:
    Netzjargon als Fremdsprache!
    1. problematische Seite

      Hallo Julius,

      vielen Dank für den Überblick! Die Argumentation zum Springen mit der Tab-Taste war mir noch gar nicht bekannt – strong mit tabindex="0" klingt gut (hatte bisher nur ein span verwendet...).

      Warum sollte man ein Element in die Tabulatorreihenfolge aufnehmen, wenn man mit ihm nicht interagieren kann?

      Bis demnächst
      Matthias

      --
      Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
      1. problematische Seite

        Hallo Matthias,

        Warum sollte man ein Element in die Tabulatorreihenfolge aufnehmen, wenn man mit ihm nicht interagieren kann?

        Marcs Erlärung ergibt für mich Sinn – ich habe mich aber noch nie mit einem Screenreader beschäftigt...

        Der simple Verzicht auf href bietet keine zusätzliche Information und span, bzw. strong sind nicht einmal mit der Tastatur erreichbar. Deshalb werden sie vor einem Screenreader-Nutzer versteckt, der per Tab von Link zu Link springt.

        Die Fokussierbarkeit des strong-Elementes lässt sich allerdings leicht erreichen, durch Hinzufügen von tabindex=“0“.

        Gruß
        Julius

        --
        Die neuste Digital-Neuland-Bildungsoffensive der Bundesregierung:
        Netzjargon als Fremdsprache!
      2. problematische Seite

        Hej Matthias,

        vielen Dank für den Überblick! Die Argumentation zum Springen mit der Tab-Taste war mir noch gar nicht bekannt – strong mit tabindex="0" klingt gut (hatte bisher nur ein span verwendet...).

        Warum sollte man ein Element in die Tabulatorreihenfolge aufnehmen, wenn man mit ihm nicht interagieren kann?

        Weil es sonst für Blinde aus der Navigation verschwindet - das sehe ich inzwischen als problematischer an, als ein anderes Problem: dass man den Menü-Eintrag zwar antaten kann, dass ein "abschicken" mittels Return aber nichts bewirkt.

        Das brachte mich ja auch auf den Gedanken, vielleicht ist es gar nicht so schlimm, den Menüeintrag nicht wahrzunehmen.

        Ist aber Quatsch. Wenn etwas fehlt, ohne dass man diese Begründung kennt, verwirrt das mehr, als alles andere... - wobei ich dazu wie immer gerne Belege hätte ;-)

        Wir entscheiden (leider viel zu) oft für andere aufgrund der Dinge, die wir annehmen...

        Ich habe dafür einfach keine Statistiken und wüsste auch nicht, wie ich an sie kommen sollte...

        Marc

        1. problematische Seite

          Hallo marctrix,

          Warum sollte man ein Element in die Tabulatorreihenfolge aufnehmen, wenn man mit ihm nicht interagieren kann?

          Weil es sonst für Blinde aus der Navigation verschwindet - das sehe ich inzwischen als problematischer an, als ein anderes Problem: dass man den Menü-Eintrag zwar antaten kann, dass ein "abschicken" mittels Return aber nichts bewirkt.

          Ok. Was hältst du dann von einem a-Element ohne href aber mit tabindex=0?

          Bis demnächst
          Matthias

          --
          Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
          1. problematische Seite

            Hej Matthias,

            Hallo marctrix,

            Warum sollte man ein Element in die Tabulatorreihenfolge aufnehmen, wenn man mit ihm nicht interagieren kann?

            Weil es sonst für Blinde aus der Navigation verschwindet - das sehe ich inzwischen als problematischer an, als ein anderes Problem: dass man den Menü-Eintrag zwar antaten kann, dass ein "abschicken" mittels Return aber nichts bewirkt.

            Ok. Was hältst du dann von einem a-Element ohne href aber mit tabindex=0?

            Das hier und das hier ;-)

            Zusammengefasst: tabindex=0 ist wohl nötig, die Entscheidung für span, strong oder a spielt für die Zugänglichkeit nur noch eine geringe Rolle. Es hängt davon ab, was man als Benutzererwartung annimmt - es sei denn, man kann belegen, dass Nutzer eines dieser Elemente bevorzugen.

            Zu guter letzt bleibt noch zu überlegen, ob die Konvention, Links auf die aktuelle Seite zu entfernen, weit verbreitet genug ist, um davon ausgehen zu können, dass dadurch jedem klar ist, warum der Link entfernt wurde.

            Wenn man diese Frage mit "nein" beantwortet, müsste man noch mit aria-describedby eine Beschriftung für Screenreader-Nutzer oder mittels für alle zugänglicher Beschriftung dieses Verhalten erklären.

            Ich habe das bisher nicht für nötig gehalten, allerdings hat mietshaus darauf hingewiesen, dass Seiten mit durchaus sehr viel Traffic sich an solche Praktiken nicht halten, was natürlich dazu führen kann, dass diese Konvention nicht so intuitiv erfassbar ist oder sein wird, wie ich das annehme.

            In der Webentwicklung läuft ja leider sehr viel schief (siehe Blue Beine-Day-Post von Gunnar). Es gibt viel zu viele Entwickler, die von Konzepten, best practices, WCAG-Prinzipien nicht die geringste Ahnung haben und sogar noch stolz drauf sind, dass ihr Kram irgendwie mehr recht als schlecht läuft, aber töfte aussieht und für billig Geld zusammengekloppt wurde aus Komponenten, die man passend gemacht hat, damit das Ergebnis schick aussieht und man dem Kunden einen irrsinnigen Betrag in Rechnung stellen kann.

            Auch in Bezug auf Barrierefreiheit sehe ich ein abnehmendes Interesse. Insofern sehe ich auch schwarz für Konventionen aller Art. Hoffentlich bringt die EU-Initiative zur Förderung der Barrierefreiheit hier wieder etwas Schwung in das Thema...

            Leider finde ich die Dokumente nicht mehr - die Webseite der EU ist im Rahmen eines Relaunches extrem auf das eingedampft worden, was "die Leute" wollen - so gewinnt man natürlich keine Interessenten für Themen, die noch nicht im Fokus der Öffentlichkeit stehen. :-(

            Marc

            1. problematische Seite

              Hallo Marc,

              Zusammengefasst: tabindex=0 ist wohl nötig, …

              das verstehe ich jetzt nicht. Warum ist es für einen Blinden hilfreich, wenn ein Element, mit dem er nicht interagieren kann, trotzdem per Tabulator erreicht werden kann? Es ist ja nicht weg, es wird ohne tabindex ja nur nicht angesprungen.

              Un warum muss der Linktext auf die aktuelle Seite in ein extra Element? Reich da nicht

              <ul>
               <li><a href="/">Startseite</a></li>
               <li>Text zur aktuellen Seite</li>
               <li><a href="xyz.html">Weitere Seite</a></li>

              Gruß
              Jürgen

              1. problematische Seite

                Hej JürgenB,

                Zusammengefasst: tabindex="0" ist wohl nötig, …

                das verstehe ich jetzt nicht. Warum ist es für einen Blinden hilfreich, wenn ein Element, mit dem er nicht interagieren kann, trotzdem per Tabulator erreicht werden kann?

                Das hängt mit der Art zusammen, wie ein blinder eine Webseite nutzt. Wenn er das Menü nicht benötigt, wird er direkt zum Hauptinhalt springen wollen. Eine gut gemachte Webseite bietet dafür zwei Möglichkeiten:

                1.) gibt es einen Sprunglink, der direkt zum Hauptbereich der Seite führt, wo also die eigentliche Anwendung oder ein Artikel zu finden ist 2.) Er springt das main-Element an 3.) Er überspringt die Navigationsliste(n) am Seitenanfang (ein Grund warum es empfehlenswert ist, das verlinkte Logo zur Startseite mit in die Hauptnavi zu packen, dann ist das gleich mit "abgefrühstückt")

                Wenn er also die Navigation durchliest, ist er da ganz bewusst und sucht dort nach etwas. Die Erfahrung lehrt ihn, dass er sich da durchhaben kann, weil idR alle Inhalte der Hauptnavigation verlinkt sind. Das erspart es ihm, sich alle Links komplett vorlesen lassen zu müssen - wenn er nach "Impressum" sucht, kann er das vorlesen aller Links, die nicht mit "Im" beginne, durch drücken der Tab-Taste abbrechen und so zum nächsten Link kommen. Blinde "fliegen" mit entsprechender Übung tatsächlich so schnell durch Menüs!

                Dabei kann ein Blinder Nutzer natürlich schon darüber stolpern, dass ein zuvor erreichbarer Menü-Eintrag nun nicht mehr bereit steht.

                Es ist ja nicht weg, es wird ohne tabindex ja nur nicht angesprungen.

                Tatsächlich könnte er sich den vorlesen lassen, wenn er sich die Navigation komplett von vorn bis hinten ausgeben lässt - aber machst du das immer? - Das kostet unendlich Zeit und Nerven!

                Un warum muss der Linktext auf die aktuelle Seite in ein extra Element? Reich da nicht

                <ul>
                 <li><a href="/">Startseite</a></li>
                 <li tabindex="0">Text zur aktuellen Seite</li>
                 <li><a href="xyz.html">Weitere Seite</a></li>

                Mit meiner Ergänzung tabindex="0" sollte auch das tatsächlich reichen!

                Gefällt mir spontan sehr gut, habe ich wohl auch schon mal so gemacht. Muss noch in den Artikel. Danke für den Hinweis!

                Marc

                1. problematische Seite

                  Hallo Marc,

                  danke für deine erhellenden Worte. Wenn es darum geht, sich vorzustellen, wie ein Blinder "sieht", bin ich meistens recht "blind".

                  Gruß
                  Jürgen

                  PS Meine Navigation steht im Quelltext immer noch am Seitenende.

                  1. problematische Seite

                    Hej JürgenB,

                    danke für deine erhellenden Worte. Wenn es darum geht, sich vorzustellen, wie ein Blinder "sieht", bin ich meistens recht "blind".

                    Sehr nett formuliert!

                    PS Meine Navigation steht im Quelltext immer noch am Seitenende.

                    Einem Blinden mit aktuellem Screenreader kann das theoretisch Wurscht sein - er hat einen Shortcut um das nav-Element anzuspringen - so wie main. Allerdings weiß ich nicht, wie viele Blinde sich so gut mit ihrem Screenreader auskennen - welcher Firefox-Nutzer kennt schon sämtliche Tastaturkürzel seines Browsers?

                    Marc

            2. problematische Seite

              Hej marctrix,

              Auch in Bezug auf Barrierefreiheit sehe ich ein abnehmendes Interesse. Insofern sehe ich auch schwarz für Konventionen aller Art. Hoffentlich bringt die EU-Initiative zur Förderung der Barrierefreiheit hier wieder etwas Schwung in das Thema...

              Leider finde ich die Dokumente nicht mehr - die Webseite der EU ist im Rahmen eines Relaunches extrem auf das eingedampft worden, was "die Leute" wollen - so gewinnt man natürlich keine Interessenten für Themen, die noch nicht im Fokus der Öffentlichkeit stehen. :-(

              Update: Unter "Kontakt" gibt es auf der EU-Seite eine sehr kompetente und hilfsbereite Hotline. Mir wurde versprochen, in einer persönlichen Antwort die benötigten Informationen bereit zu stellen.

              so nett das auch ist: es löst weder das Problem, dass man diese Infos weder mit Google, noch mit der Suche auf der Eu-Seite findet, noch dass durch diese Art der Informationsvermittlung ein Anliegen (Barrierefreiheit zu fördern) konterkariert wird. Solche Infos sollten schließlich leicht zu finden sein, sonst kann man sich die Initiative auch sparen.

              Im übrigen sind Medienwechsel (vom Web zum Telefon) nicht die Idee hinter einer Webseite und die Arbeit der Kollegen, die mir meine Anfrage jetzt händische beantworten hätte die Webseite ebendiesen Kollegen ersparen können (meiner Meinung nach sollen).

              Marc

            3. problematische Seite

              @@marctrix

              Zusammengefasst: tabindex=0 ist wohl nötig, die Entscheidung für span, strong oder a spielt für die Zugänglichkeit nur noch eine geringe Rolle. Es hängt davon ab, was man als Benutzererwartung annimmt - es sei denn, man kann belegen, dass Nutzer eines dieser Elemente bevorzugen.

              Kann man vermutlich nicht; dem Nutzer dürfte das schnurzpiepegal sein, welcher Elementtyp da verwendet wird.

              Es sei denn, eine assistive Technologie käme auf die Idee, auch andere Elementtypen als li, h# etc. als solche bekanntzugeben, also a ohne href tatsächlich als potentiellen Link.

              Dann ist man mit a ohne href klar im Vorteil. Weil es tatsächlich das passende Markup ist.

              Und natürlich, weil’s technisch am einfachsten umzusetzen ist, wenn man nicht das Menü auf jeder Seite einzeln händisch bearbeitet.

              LLAP 🖖

              --
              „Wenn du eine weise Antwort verlangst, musst du vernünftig fragen.“ —Johann Wolfgang von Goethe
    2. problematische Seite

      Hej Julius,

      vielen Dank für den Überblick! Die Argumentation zum Springen mit der Tab-Taste war mir noch gar nicht bekannt – strong mit tabindex="0" klingt gut (hatte bisher nur ein span verwendet...).

      Mir leuchtet es auch ein, bin auch nicht der einzige, der das so sieht, aber an @Gunnars Kommentar siehst du, es gibt auch andere Meinungen. ;-)

      Letztendlich macht weder die Verwendung eines a noch die Verwendung eines ´span´ oder eines strong eine Seite unzugänglich. Mein Artikel und die anderen Beiträge in dieser Diskussion finden ja auf einem recht hohen level statt: was ist aus diesen allesamt um Zugänglichkeit bemühten Ansätzen der allerallerbeste...

      1. Im Abschnitt zur Lösung mit Verlinkung des Hauptinhalts ist im Absatz über dem Beispiel-HTML ein Code-Element nicht geschlossen.
      2. Irgendwie werden die Quotes " in deinem Beispiel-HTML durch Anführungszeichen ersetzt, sodass das HTML bei Copy & Paste nicht funktioniert. Das könnte Leute irritieren...

      Auch dir herzlichen Dank für die Fehlermeldung - ist bereinigt!

      Marc