Add overflow checks to code blocks to dynamically remove tabindex

[querkmachine]

The recent audit noted a usability issue for users who navigated using the Tab key, wherein they would be made to stop at every code block as they all have the tabindex attribute set. #4007

We set tabindex intentionally so that long lines of code can overflow the container and be scrolled by using the keyboard's arrow keys. We want to maintain this ability (removing it entirely would be a likely violation of Success Criterion 2.1: Keyboard Accessible) but would like to limit it only to blocks that need to scroll.

Changes

• Adds a data-module attribute to code blocks processed by Markdown.
• Adds JavaScript to attach a ResizeObserver to each code block.
  • When the page is initially loaded, or the elements are resized, checks if the content of the code block overflows the container.
  • If so, it adds the tabindex attribute. Otherwise, it removes it.

Thoughts

This is only one possible solution to this issue, if we opt to implement a 'fix' at all.

Personally, I'm a little iffy on how necessary it is. Having some code blocks focusable and some not, contextual depending upon things like font size and screen width, feels inconsistent and confusing to a keyboard navigation user—potentially being more detrimental to their experience than having each code block just be focusable.

[netlify]

✅ You can preview this change here:

Name	Link
🔨 Latest commit	c9c2da0
🔍 Latest deploy log	https://app.netlify.com/sites/govuk-design-system-preview/deploys/66ea9afdf00004000886da88
😎 Deploy Preview	https://deploy-preview-4034--govuk-design-system-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[owenatgov]

One pithy comment. This is looking great and working great 💪🏻

[owenatgov]

😎

Dismissing due to some chat happening outside this PR.

[owenatgov]

Just adding some thoughts on if this is worth doing or not, which I didn't address in my original review.

Here are 2 quotes from @selfthinker on this issue. Firstly on if this is a failure or not:

disagree that this is a WCAG fail, definitely not 2.4.3 as the order is fine, although agree it is confusing when there is nothing to interact with;
suspect it's there due to long lines being cut off (e.g. when zooming in) to make it possible for keyboard only users to scroll through and read the text

specialists agree it's not a WCAG fail, but is a usability issue and a minor accessibility issue

...and if we should accet DAC's proposed solution to completely remove tabindex="0":

no, as removing this would fail 1.4.4, 1.4.10 and 2.1.1

it's worth noting that Firefox make overflowing elements focusable by default for years and Chrome will start doing that soon, probably in version 128

Based on these quotes, I personally think this is fine as an enhancement. The specific points that stand out to me from what Anika's said:

1. The accessibilty specialists at GDS agee it's a 'minor accessibilty issue', so there's value in providing something to bypass it as a potential problem
2. Firefox already provides this as a enhancement out of the box

I take your point on this potentially being confusing for keyboard users but I wonder if there's enough info in a given context for users to figure it out ie: they're reading page content and tabbing as they go, they notice an overflowing code block, tab and reach it, realising it's scrollable. I can't corroberate that, it's just a feeling. Maybe we could explore making the scroll controls more prominent or adding something to pompt users that overflowing code blocks are interactable?

[selfthinker]

I like that this solution is basically implementing what some browser vendors have already implemented.

We've decided to ask DAC about this solution when we have the followup meeting with them.
They might be able to share with us how their keyboard-only testers would find using this solution.

[selfthinker]

We've had a meeting with DAC today. They like this solution.
They said when something receives focus it should be actionable. And the scrollbar makes it clear that it's actionable as scrolling itself is an action. When it doesn't have a scrollbar (like it is without this change when on a code block that doesn't need it) it's confusing.

I suggest to merge this (after the conflicts are resolved).

[owenatgov]

One more thing I forgot to add: Once this is merged, I think we're good to write up a final explainer on #4007 and close it. To summarise: this solution doesn't follow DAC's recommendation to the letter but both us and DAC are happy with it so we feel this is done.