Focus outline applied on click/touch of [tabindex="-1"] (Safari 14.1.1)

[dotherightthing]

From https://github.com/dotherightthing/wpdtrt-dbth/issues/228

Elements with tabindex="-1" should only be programmatically focusable.

This outline is suppressed in the SCSS:

wpdtrt-scss/scss/_frontend.scss

Lines 14 to 32 in c3e5c66

	a,
	button,
	input,
	textarea,
	[tabindex='0'] {
	&:focus {
	@extend %wpdtrt-scss-focus-show;
	&:not(:focus-visible) {
	@extend %wpdtrt-scss-focus-hide;
	}
	}
	}
	[tabindex='-1'] {
	&:focus {
	@extend %wpdtrt-scss-focus-hide;
	}
	}

But Safari overrides the compiled CSS by applying a new internal style:

:-webkit-direct-focus {
    outline-color: -webkit-focus-ring-color;
    outline-style: auto;
    outline-width: 5px;
}

This style was added in Changeset 250788 in webkit via Bug 202432 - focus pseudo class should match a shadow host whose shadow tree contains the focused element, via :focus-visible in WebKit - January 2021.

In order to preserve the behavior of focus ring, which should be only drawn on the currently focused
element and not any shadow host which contains such an element, this patch introduces a new pseudo class,
-webkit-direct-focus, which is only available in the user agent stylesheet.

From: Changeset 250788 in webkit

Safari appears to deem user focus of elements with tabindex="-1" to match the :focus, and my :focus rules are being overridden by Safari's :focus replacement, :-webkit-direct-focus:

:focus-visible is expected to replace :focus (now :-webkit-direct-focus in WebKit) in the default UA style sheet.

Whatever the reason, this issue is resolved in the latest Safari Technology Preview (Release 125) which adds support for :focus-visible(Develop > Experimental Features > :focus-visible pseudo-class).

For background and more information, see https://blogs.igalia.com/mrego/2021/06/07/focus-visible-in-webkit-may-2021/

[dotherightthing]

Actually, my assumption that [tabindex="-1"] should not be mouse/touch focusable is wrong:

A negative value (usually tabindex="-1") means that the element is not reachable via sequential keyboard navigation, but could be focused with JavaScript or visually by clicking with the mouse. It's mostly useful to create accessible widgets with JavaScript.
...
The user won't be able to focus any element with a negative tabindex using the keyboard, but a script can do so by calling the focus() method.

From: MDN: tabindex

Therefore [tabindex="-1"] should be focusable when clicked or tapped.

So the stylistic solution would be to use :focus-visible instead, to suppress the outline when the element is clicked with the mouse, and to wait for Safari's patches to be released to the public.

But the semantic solution would be to treat [tabindex='-1']:focus the same as [tabindex='0']:focus, move the tabindex from the container to the first child element (e.g. the heading), then apply custom styling of the :focus as desired. This would improve the UX as it would yield more useful content when activating an anchor link.

[dotherightthing]

wpdtrt-anchorlinks requires the ID on the section container, as this determines which anchor link is bolded during scrolling.

The tabindex is presumably there so that activating the anchor link moves the tab focus to the target so that subsequent tab presses are relative to the selected section.

<div id="main"> is also navigable and also uses tabindex. This isn't in the latest WP template, but the dev history is in Bitbucket.

However this doesn't mean that the anchor needs to link to (and move focus to) the same ID - this could be refactored so it links to a child element.

Note that wpdtrt-gallery rebuilds the section elements when adding it's own markup

[dotherightthing]

Pages that use self-referencing heading links - possibly AKA 'bookmark links':

https://css-tricks.com/hash-tag-links-padding/

Uses aria-hidden on the anchor, but leaves it in the tab order. When the icon is tabbed to in Safari 14.1.1, the tab focus is lost because :focus-visible isn't supported by this version of Safari.

<h3>
    <a href="#target" aria-hidden="true" class="aal_anchor" id="target">
        <svg aria-hidden="true">
            <path ... ></path>
        </svg>
    </a>
    Heading text
</h3>

I've emailed them about the tab order issue.

---

https://github.com/dotherightthing/wpdtrt-plugin-boilerplate

Github Markdown uses a similar system, except the anchor icons only appear on hover. However they are still in the tab order - and the icon does not appear on tab focus.

<h2>
    <a id="target" class="anchor" aria-hidden="true" href="#target">
        <svg aria-hidden="true">
            <path></path>
        </svg>
    </a>
    Installation
</h2>

I logged an issue on the GFM repo.

---

https://www.bryanbraun.com/anchorjs/

Generates anchor icons with duplicate aria-label of 'Anchor'. Icon appears on hover and focus:

<h2 id="target">
    Installation
    <a class="anchorjs-link " aria-label="Anchor" data-anchorjs-icon="" href="#target" style="font: 1em / 1 anchorjs-icons; padding-left: 0.375em;"></a>
</h2>

I logged an issue on the anchorjs repo.

---

https://amberwilson.co.uk/blog/are-your-anchor-links-accessible/

Amber Wilson has put together a deep dive on appropriate solutions (December 14th, 2020).

She suggested two options:

(A)

Amber Wilson's approach:

<h2 id="introduction">Introduction</h2>
<a href="#introduction">
    <span aria-hidden="true">#</span>
    <span class="hidden">Section titled introduction</span>
</a>

This approach adds verbosity to the screen reader's links list, as there will be multiple links beginning with "Section titled".

(B)

Barry Pollard's approach:

<h2 id="ease-of-reading">
    <a href="#ease-of-reading" class="anchor-link">
        ::before
        Ease of reading
    </a>
</h2>

This approach has zero fluff. So long as the link is not display:block the text will remain easy to select.

(C)

Lee Reamsnyder then tweaked this to support Safari Reader, which otherwise removes the linked headings:

<h2 id="introduction">
    <a href="#introduction">
        <span>
            Introduction
        </span>
    </a>
</h2>

[dotherightthing]

Once this is tested, opening an issue / submitting a PR on https://github.com/vyskoczilova/add-anchor-links will address CSS Tricks' implementation.

[dotherightthing]

There's also feature detection for :focus-visible:

twbs/bootstrap#30872