Remove explicit tabIndex values to comply with accessibility standards

[Copilot]

Lighthouse flagged explicit positive tabIndex values as non-compliant with WCAG accessibility guidelines. These create unpredictable tab order and confuse keyboard/screen reader users.

Changes

Removed all explicit tabIndex attributes from interactive elements:

• Logo: tabIndex='1' → implicit tab order
• Navigation: tabIndex='2' through '9' → implicit tab order
• Slideshow arrows: tabIndex='10' and '11' → implicit tab order
• Fullscreen button: tabIndex='12' → implicit tab order

The DOM structure already provides the correct tab flow (Logo → Navigation → Fullscreen → Slideshow). All elements remain keyboard-accessible via their native focusability as links and buttons.

Before:

<a href='/' tabIndex='1'>EYESBOUND</a>
<a href='/picture' tabIndex='2'>Overview</a>
<button tabIndex='12' onClick={toggleFullscreen}>...</button>

After:

<a href='/'>EYESBOUND</a>
<a href='/picture'>Overview</a>
<button onClick={toggleFullscreen}>...</button>

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• unpkg.com
  • Triggering command: /usr/local/bin/node node scripts/postinstall.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Improve Accessibility</issue_title>
<issue_description>This website already has a very high rating for accessibility according to the Lighthouse report.
One thing that is noted by the Lighthouse report is that tab-indexes should not be explicitly set to numbers.
The idea in the current implementation with setting those numbers was to give users a clear path to tab through the app.

See if this could be achieved differently while both maintaining the ability to tab through but also meeting the respective web standards for accessibility.
Also if you see other improvements for increasing accessibility feel free to suggest them. </issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Improve Accessibility #792

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[netlify]

✅ Deploy Preview for eyesbound ready!

Name	Link
🔨 Latest commit	044aab3
🔍 Latest deploy log	https://app.netlify.com/projects/eyesbound/deploys/6931cb7ffb47a70008bc4a0a
😎 Deploy Preview	https://deploy-preview-793--eyesbound.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 80 Accessibility: 100 Best Practices: 100 SEO: 100 PWA: 100 View the detailed breakdown and full score reports

---

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

[Primajin]

@copilot Should the tab-indexes be completely removed or rather set to 0 or -1 ?

[Copilot]

@copilot Should the tab-indexes be completely removed or rather set to 0 or -1 ?

Completely removed is correct. All the elements (<a> links and <button> elements) are naturally focusable and will be in the tab order based on DOM structure.

• tabIndex="0" is only needed to add non-interactive elements to the tab order
• tabIndex="-1" is for removing elements from tab order while allowing programmatic focus

Since these are native interactive elements, no tabIndex attribute is the proper accessibility standard.