Scrollable <pre> elements should be focusable for WCAG 2.1 compliance

[kevinleedrum]

As mentioned in #220, scrollable <pre> elements should have tabindex="0" to allow them to be focusable. Right now, these elements will fail WCAG audits if/when they become scrollable. https://www.w3.org/WAI/standards-guidelines/act/rules/0ssw9k/proposed/

It seems ideal to me to make this the default rather than try to update consumers like remark-shiki, etc. to pass in a custom pre.

I wouldn't expect this to be a breaking change since anyone who is already providing a tabindex will already be passing in an entirely custom pre template literal that will override this default.

[OliverSpeir]

This results in tabindex applied to all code blocks which is in fact not WCAG compliant. It should only add tabindex when the codeblock is scrollable, but this of course would be difficult to know based on screen size etc. Maybe it's better to leave it up to the user to add tabindex themself

Edit: upon further research having tabindex on non interactive element does not create an explicit WCAG violation AFAIK

[aryanjha256]

maybe we can add overflow to all <pre /> elements if user opts not to wrap the code so that it won't create an accessibility issue.

[kevinleedrum]

The spec defines scrollable as having a scroll distance (e.g. the difference between the scrollWidth and clientWidth), so for elements that can be resized, you are pretty much forced to set up a ResizeObserver or at least a resize event listener to add or remove the tabindex.

I would argue that it's best to default to having the tabindex, so that if JavaScript is disabled or fails, all scrollable elements are still navigable by keyboard users. They just might have some extra unnecessary tab stops that JavaScript would have otherwise removed.

[kevinleedrum]

Chrome has announced that they are going to implement keyboard-focusable scrollers at the browser level. In the context of this issue, that would mean the tabindex would no longer be necessary in Chrome since the tab stop would be added automatically. Firefox already does this, and Chrome has tried to implement it before.

However, I have not heard anything about Safari adding this, so even if this lands in Chrome stable, having the occasionally unnecessary tabindex is still a good idea in my opinion.