Non-interactive images are added to the page tab order

[aidanbruneel]

Observed behaviour

When the IMAGE browser extension is enabled, ordinary non-linked images on a webpage are modified to become keyboard-focusable. On https://image.a11y.mcgill.ca/tutorial/, the three content images on the page change from tabindexAttribute: null / tabIndex: -1 to tabindexAttribute: "0" / tabIndex: 0 after enabling the extension and reloading the page. This adds new tab stops to the host webpage and changes its normal sequential keyboard navigation even when the user is not actively trying to invoke IMAGE.

Expected behaviour

IMAGE should provide a keyboard-accessible way to invoke interpretations without unnecessarily changing the host page’s native tab order. Ordinary non-interactive images should remain outside the sequential keyboard focus order unless the page itself makes them focusable or interactive.

Reproduction

1. Disable the IMAGE browser extension.
2. Open https://image.a11y.mcgill.ca/tutorial/ in Chrome.
3. Open the developer console.
4. Run:

[...document.images]
  .filter(img => !img.closest("a"))
  .map(img => ({
    alt: img.alt,
    tabindexAttribute: img.getAttribute("tabindex"),
    tabIndex: img.tabIndex
  }));

5. Observe that the page’s three non-linked content images report tabindexAttribute: null and tabIndex: -1.
6. Enable the IMAGE browser extension.
7. Reload the page.
8. Run the same command again.
9. Observe that the same three images now report tabindexAttribute: "0" and tabIndex: 0.
10. Tab through the page and observe that these static images now participate in sequential keyboard navigation.

Runtime context

• Component: IMAGE-browser
• Page used for reproduction: https://image.a11y.mcgill.ca/tutorial/
• Browser: Chrome
• Extension state: reproducible when IMAGE is enabled and the page is reloaded
• Relevant implementation: src/content.ts adds tabindex="0" to non-linked images, and Ctrl+B processing depends on document.activeElement.tagName == "IMG".

Additional context

This behavior appears to be the implemented result of issue #22, which proposed adding tabindex="0" to images so they could be reached through keyboard navigation and stated that it should not affect site behavior. The new reproduction shows that it does affect site behavior by altering the host page’s tab order. A later issue, #387, also recognized that per-graphic keyboard navigation additions can slow user navigation, and the current Ctrl+B trigger seems to be coupled to this focusability approach.

[MansiDhanania]

@aidanbruneel From my understanding, switching tabIndex to -1 will remove it from the tab order (fixing this issue) but would require us to programmatically focus on the image in some other way to give users keyboard accessibility. Do you have any suggestions for this implementation?

[aidanbruneel]

I don't think we should switch the images to tabIndex=-1 and then find another way to focus them programmatically. We should probably just stop requiring the image itself to receive DOM focus.

We already inject an "Interpret graphic with IMAGE" button after each eligible graphic, so we have an interactive element, so that should be what keyboard users focus and activate. The image itself should keep whatever focus behaviour the page originally gives it, right?

My suggestion:

1. Remove the code that adds tabindex="0" to ordinary images rather than replacing it with tabindex="-1".
2. Keep the injected IMAGE button keyboard-accessible.
3. Update the .sr-only styling so the button becomes visible when it receives keyboard focus (e.g. :focus / :focus-visible override). Right now it stays clipped even when focused, which isn't great for keyboard users who aren't using a screen reader.
4. Remove the Ctrl+B requirement for document.activeElement needing to be an <img>.

For Ctrl+B, I don't think we should solve that by forcing focus onto images again. A better approach would be to have the shortcut open an accessible list of graphics/maps/charts on the current page and let the user choose one. We explored something pretty similar in #283 and there was already a proof of concept showing that a hotkey-triggered popup/list was feasible.

That selector could be separate follow-up work if it is too large for this bug... I am not sure. For this bug, I think the main requirement should just be that enabling IMAGE does not add otherwise non-interactive images to the host page's tab order. New paradigm would be that the graphic is content and our IMAGE button is the control. We shouldn't need to make the graphic itself interactive just so IMAGE can target it.

@MansiDhanania Let me know what you think too. This gets into the weeds of accessible web design but that's what we're here for!