Gutenberg: Verbesserungen der Inline-Grenzen

Erstellt am 8. März 2017  ·  3Kommentare  ·  Quelle: WordPress/gutenberg

Es gibt verschiedene kleine Probleme mit der neuen Verknüpfungs-/Codegrenzenlogik, die korrigiert werden müssen.

  1. Der Dialog „Link reparieren“ enthält zwsp in „Anzuzeigender Text“
  2. Enter bei zwsp erzeugt einen leeren Link, den man kürzen muss.
  3. Das Aufheben der Verknüpfung ist möglicherweise fehlerhaft und erfordert weitere Tests.
  4. Entfernen Sie zwsp, wenn sich das Caret im selben Textknoten befindet, aber nicht mehr neben dem zwsp-Zeichen.
  5. Fügen Sie weitere Tests für rtl und bidi hinzu.
  6. Probieren Sie line-height aus: -moz-block-height; als Problemumgehung für Firefox-Windows-Rendering-Störungen.
  7. Fügen Sie eine Option hinzu, um dieses Ding zu deaktivieren, falls die Leute denken, dass es nervig ist.
  8. Versuchen Sie, die Navigation unter iOS mit externen Tastaturen zu reparieren.
[Type] Task

Hilfreichster Kommentar

Wir haben die in diesem Ticket aufgeführten Punkte behoben. Also schließe ich dieses hier.

Alle 3 Kommentare

Ich liebe die Funktion und ich denke, sie hilft sehr dabei, zu verstehen, wo Sie tippen.

Beim schnellen Testen mit Safari 10 + VoiceOver wird die Linkgrenze jedoch wie folgt ausgelesen:
link zero width no break space
oder so ähnlich, sorry, kein englischer Muttersprachler hier 🙂

Eine Option könnte die von @spocke auf Slack erwähnte sein:

Möglicherweise müssen Sie es dann mit Arien-Tags in eine Spanne einwickeln

Beim Navigieren nach Zeichen oder Wörtern kündigen Screenreader bereits link an, wenn sie einen Link eingeben, obwohl sie nichts ankündigen, wenn sie den Link verlassen, also könnte es vielleicht einfach das Zeichen zwnbsp vor Hilfstechnologien verbergen gut arbeiten.

@afercia Habe einige Nachforschungen angestellt.

Um zu verhindern, dass sich das Caretzeichen in den Anker normalisiert, wenn es sich innerhalb / außerhalb befindet, müssen wir etwas einfügen, das den Browser daran hindert, seine Standardeinstellung zu tun. Wir verwenden geschützte Leerzeichen mit der Breite null, da es sich im Grunde um ein unsichtbares Zeichen handelt, das für nichts mehr verwendet wird, außer für BOM-Signaturen in Dokumenten. Diese Zeichen scheinen von Jaws ignoriert, aber von VoiceOver und NVDA gesprochen zu werden.

Ich habe versucht, dies auf verschiedene Weise zu umgehen:

  1. Das Ändern des Charakters in Spans mit Arienrollen und -attributen funktionierte nicht, da die Attribute von den meisten Screenreadern selbstgefällig ignoriert wurden. Ich vermute, da es im Editor-Kontext ist, hat es keine Relevanz. Versuchte role="presentation" aria-hidden="true" und aria-label="abc" nichts passiert außer auf Jaws.
  2. Versuchte den reservierten Unicode-Bereich \ue000, dieser ist für Dinge wie Symbole usw. reserviert und sollte nicht vom Bildschirmleser gesprochen werden. Es spricht diese nicht, wird jedoch auch von der Normalisierungslogik der Browserauswahl ignoriert, sodass es nicht verwendet werden kann.
  3. Ein role="status"-Element mit aria-live="assertive" hinzugefügt und Text zu dem gepusht, was im Grunde wp.a11y.speak tut und das die Warteschlange auf VoiceOver, aber nicht auf NVDA aufhebt, und es scheint auf Jaws etwas seltsam zu sein. Die Spezifikation sagt, dass es die Warteschlange aufheben könnte, also denke ich, dass es zufällig ist, was passiert. Dies ist jedoch wahrscheinlich am sinnvollsten, um dem Benutzer mitzuteilen, wo sich das Caretzeichen befindet, ob es sich am Anfang des Links, am Ende, davor oder danach befindet, da dies die Orte sind, die wir behandeln. Einige Screenreader sprechen jedoch immer noch diesen seltsamen Zeichencode, nicht sicher, ob wir viel dagegen tun können.

Zusammenfassend ist es also kompliziert. :)

Wir haben die in diesem Ticket aufgeführten Punkte behoben. Also schließe ich dieses hier.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen