Make scrollable area keyboard (and voice) focusable

[colinbm]

⚠️ Don't forget to update the gem version in the CHANGELOG before merging! When you're ready to release bump version file and generate a tag. ⚠️

What

Add the main content area to the tabindex.

Why

Using keyboard (or voice) control, the only way to scroll this area is to tab to a focusable item (i.e. a link) within the area. This is a workaround and relies on there being a focusable item within the area, which is not guaranteed. Making the area itself focusable means this will always be scrollable with the keyboard.

[36degrees]

Closing and re-opening to try and trigger Travis CI.

[m-green]

@36degrees Did this look ok to you when you closed and re-opened it? Just wondered if it's a quick review, or if it needs more input from you (or another frontend person if you're busy).

[m-green]

Hi @36degrees You re-opened this PR last July. Just wondered if it looks like a quick review and approve that you could do? Or whether it needs more work?

[lfdebrux]

Hi @colinbm, thank you so much for raising this PR, sorry it's taken us so long to progress it.

I've taken a look at this, after talking to @36degrees, as he hasn't had the time to.

He suggested testing this with screenreaders, which I did, I found that the announcement when using Chrome and VoiceOver on macOS was not useful by default, so I have added another commit to add an accessible name to improve the announcement slightly. See 0817f47 (Add accessible name to content pane div).

We also discussed some of the history behind the 'two-pane' layout of the tech docs template. @36degrees noted that the Design System website used to have a similar layout, but dropped it because of the issues with independently scrollable regions [1], instead using a fixed table of contents and a back-to-top link. We did think though that for tech docs where the table of contents can be very long the design we're using currently does make sense, but wonder if it needs to be refreshed to properly solve this issue. That is probably not possible in the immediate though, so for now adding tabindex="0" seems like a reasonable fix.

I also talked to some people in the accessibility community about this change, we discussed whether adding an ARIA role/landmark to the <div> would be appropriate, but there are some issues there around having the main and footer regions within other landmarks according to Deque, and using the focus outline from the GOV.UK Design System. I'll leave these as ideas for another person another day.