Code blocks: Unnecessary tab stops

[selfthinker]

This issue is from the accessibility audit of the Design System website by DAC in July 2024.

DAC's description

• Page: Type scale – GOV.UK Design System
• WCAG reference: 2.4.3 Focus Order (Level A) none (Usability)
• Issue ID: DAC_Unnecessary_Tab_Stops_01

Non-actionable elements have been included in tab sequence using the tabindex attribute.
This may be disorientating for users navigating via the use of the keyboard alone as it can be difficult to track focus if it lands on unexpected objects within the page. This also causes the need for additional key-presses when navigating the page, which can become strenuous for users with mobility impairments. Users may assume that because these are in the tab sequence, they must be interactive but become confused as to why they cannot action the content.

Current code

<pre><code tabindex="0" class="language-scss"><span class="hljs-
keyword">@include</span> govuk-font(<span class="hljs-variable">$size</span>:
<span class="hljs-number">19</span>);</code></pre>
[…]
<pre><code tabindex="0" class="language-scss"><span class="hljs-
keyword">@include</span> govuk-font(<span class="hljs-variable">$size</span> <span
class="hljs-number">19</span>, <span class="hljs-variable">$weight</span>: bold,
<span class="hljs-variable">$tabular</span>: true);</code></pre>
[…]
<pre><code tabindex="0" class="language-scss"><span class="hljs-
keyword">@include</span> govuk-font-size(<span class="hljs-variable">$size</span>:
<span class="hljs-number">19</span>);</code></pre>
[…]

Keyboard only user comments

“Tabbing through the page, focus lands on multiple elements that cannot be interacted with in any way. This is confusing for keyboard users to encounter, since there is no clear indication of if this element should be actionable or if it receives focus by mistake. This would cause various issues for anybody trying to navigate, and may need to call on a mouse dependent user to confirm if it can or cannot be interacted with. I would only expect my focus to land on interactive elements.”

DAC's proposed solution

Remove all instances tabindex="0" on non-interactive elements.

Disagreement

At the moment we disagree that this fails 2.4.3 Focus Order or any WCAG success criteria.
We haven't had a followup meeting with DAC yet but aim to discuss this with them soon.
Update: We had the followup meeting now and agree that it's not a WCAG fail.

The order of the focus is logical and expected.
The fact that it does get focus at all will be unexpected to anyone who doesn't understand why it's there, including keyboard-only users but also any other user who happens to focus on a code block. Keyboard-only users will be slightly more disadvantaged because it means they have to tab more for seemingly no reason.

Therefore we think it is a usability issue and a minor accessibility issue but not a WCAG fail.

If we implemented DAC's proposed solution, we would fail WCAG 1.4.4 Resize text, 1.4.10 Reflow and 2.1.1 Keyboard. That's because there would be no way to read the whole text of a code block for keyboard-only users when it overflows. It overflows when the text is overly long, which happens quite often with code, like on the HTML tabs for component (for example the checkbox component). And it also happens for anyone who needs to zoom into the page. Code that was previously not overflowing would start to overflow at some point, including the example from the type scale page.

We definitely shouldn't implement DAC's solution, as it would make the accessibility worse and cause other WCAG fails. But there might be other things we could do.

Other potential solutions

We should research what others are doing.
(For example, the W3C design system also adds tabindex. But the WCAG techniques wrap the code text.)

Maybe we could add content to explain the behaviour.

Maybe we could let the code wrap.

Maybe we could add tabindex only when the code is overflowing. (Like in this solution, except do it the other way around for progressive enhancement: always add tabindex and remove it when it is not overflowing.)

Background information

It's worth noting that Firefox has been make overflowing elements focusable by default for years.
Chrome will start doing that soon, probably in version 128.
That means tabindex would only be needed for older browsers and less mainstream browser.

Additional instances

Code blocks appear on multiple pages throughout the website.
But as they are using the same component, it will only need to be fixed once.

Needed roles

Frontend developer, content designer

[selfthinker]

We've discussed this with DAC today and have agreed that it's not a WCAG fail. They will list it under 'Usability' instead.
I will amend some of the description accordingly.

[owenatgov]

Given this comment from @selfthinker and the fact that #4034 has been merged, I believe we can call this issue resolved.