Only make scrollable code blocks into tab stops #1777
Conversation
| function setupLiteralBlockTabStops() { | ||
| const updateTabStops = () => { | ||
| document.querySelectorAll('[data-tabindex="0"]').forEach((el) => { | ||
| el.tabIndex = el.scrollWidth > el.clientWidth ? 0 : -1; |
There was a problem hiding this comment.
Right now, I'm only checking for scrollable content in the x, or horizontal, direction because that's all I've ever seen. But do we know if we ever have code blocks that scroll in the y direction?
There was a problem hiding this comment.
I don't think we do, or I don't see any reason to have some. The only thing I ce see that would be vertically scrollable would be inclusions like widgets/iframe from things like jupyter-lite-sphinx.
There was a problem hiding this comment.
I decided to extend this line to check for y-overflow too. My reasoning is that the theme should work robustly—it would be fairly easy for some documentation site to create a class like .height-10em that they apply to code blocks.
| function setupLiteralBlockTabStops() { | ||
| const updateTabStops = () => { | ||
| document.querySelectorAll('[data-tabindex="0"]').forEach((el) => { | ||
| el.tabIndex = el.scrollWidth > el.clientWidth ? 0 : -1; |
There was a problem hiding this comment.
I don't think we do, or I don't see any reason to have some. The only thing I ce see that would be vertically scrollable would be inclusions like widgets/iframe from things like jupyter-lite-sphinx.
|
Side question for general reviewing of the theme/debugging. Would it be good to have a mode/css where all items that can be keyboard focused have a border ? I tried |
Yeah, that won't work because, depending on your browser and OS configuration, some elements are automatically treated as tab stops—buttons, for example. And I don't know of any CSS pseudo-selectors for tab stops. You'd have to create some kind of long heuristic selector, like: button, a, [tabindex]:not([tabindex="-1"]), input, textarea...(Which wouldn't be truly accurate because some browsers—Safari—don't treat links as tab stops by default.) You'd probably have to develop a browser extension, where you simulate pressing the tab key after the page is loaded, record all of the elements that were visited, then apply the border to those elements. That might be what the Wave browser extension does under the hood. You can use it to show you the tab navigation order of the page. (It doesn't outline the elements, though; it overlays a number.) |
There was a problem hiding this comment.
confirmed to behave as expected on https://pydata-sphinx-theme--1777.org.readthedocs.build/en/1777/examples/kitchen-sink/blocks.html
| function debounce(callback, wait) { | ||
| let timeoutId = null; | ||
| return (...args) => { | ||
| clearTimeout(timeoutId); | ||
| timeoutId = setTimeout(() => { | ||
| callback(...args); | ||
| }, wait); | ||
| }; | ||
| } |
There was a problem hiding this comment.
this is so general-purpose I'm surprised there isn't a JS built-in for doing it
There was a problem hiding this comment.
Heh, I had the same thought!
gabalafou
added
the
tag: accessibility
* Only make scrollable code blocks into tab stops * Check for y-overflow too
#1787) One of many fixes for the failing accessibility tests (see #1428). The accessibility tests were still reporting some violations of: - Scrollable region must have keyboard access (https://dequeuniversity.com/rules/axe/4.8/scrollable-region-focusable) even after merging #1636 and #1777. These were due to Jupyter notebook outputs that have scrollable content. This PR extends the functionality of PRs #1636 and #1777 to such outputs. - Adds a test for tabindex = 0 on notebook outputs after page load This also addresses one of the issues in #1740: missing horizontal scrollbar by: - Adding CSS rule to allow scrolling - Add ipywidgets example to the examples/pydata page
* Only make scrollable code blocks into tab stops * Check for y-overflow too
pydata#1787) One of many fixes for the failing accessibility tests (see pydata#1428). The accessibility tests were still reporting some violations of: - Scrollable region must have keyboard access (https://dequeuniversity.com/rules/axe/4.8/scrollable-region-focusable) even after merging pydata#1636 and pydata#1777. These were due to Jupyter notebook outputs that have scrollable content. This PR extends the functionality of PRs pydata#1636 and pydata#1777 to such outputs. - Adds a test for tabindex = 0 on notebook outputs after page load This also addresses one of the issues in pydata#1740: missing horizontal scrollbar by: - Adding CSS rule to allow scrolling - Add ipywidgets example to the examples/pydata page
Context:
PR #1636 puts
tabindex="0"on all code blocks. This PR limits it to code blocks that actually have overflowing, scrollable content.How to test
This PR includes an automated test, which should run and pass with
pytest -m "not a11y".To manually test this PR, go to the preview build of the Kitchen Sink blocks page. With your browser wide (> 1440px), check that you can use the
tabkey on your keyboard to focus on the code blocks that have content that overflows (scrollable). It should be easy to tell that you are focused on the code block because it should have a purple focus ring and you should be able to use the left and right arrows to scroll the content. Now, make your browser window narrow so that some code blocks which previously did not have overflow now do. Double check that before you resized the window, you could not use thetabkey to focus on the block, but now you can.