Often tabbed interfaces are just called tabs and they are an interface design pattern that we will all be familiar with, as some websites use this pattern, but all desktop operating systems do and some mobile apps.

Called tabs or a tabbed interface because of its resemblance to the little tabs you put on the files that would typically be in a file cabinet or binder. Each tab's position is usually slightly offset for quicker visual identification of a specific file.

On a computer, they are usually represented by a series of "tabs" (either horizontal or vertical) and each has a corresponding panel. There would always be one panel visible and the others would remain hidden until their corresponding tab is clicked. There are implementations where multiple can be open, but let's pretend there isn't.

These UI elements are probably usable to the majority of users when built correctly and styled with strong visual affordances, in that they're commonplace on your Mac or PC for many of the system settings and file directories. They're even present on the operating systems of your phone or tablet. That's not me saying they are a good pattern to use, that's for your users with disabilities to inform you of that, it's their opinion what counts, not mine.

The problem with tabs

Tabs seem to make more sense on larger viewports, typically desktops, laptops and some tablets (each at regular zoom levels). But just because something works well on larger viewports at regular zoom levels that doesn't guarantee it will work as well on a smaller viewport or when the viewport is zoomed enough to trigger the "mobile view". What we tend to find across the web is something that doesn't really work at smaller viewports. I guess this is a classic case of "Desktop first, mobile worst", in that the experience can differ quite dramatically between the viewport sizes.

The most obvious issue is always going to be the lack of screen real estate, on a smaller viewport you simply cannot fit your horizontal tabs across the screen width if you have more than a few single-word tabs, but even then, the layout will likely break if a user sets their default text size to "Large" or "Largest" etc. What you then end up with is 2 or more rows of "tabs", so activating a tab on the top row will display the tabpanel immediately after the bottom row, which maybe looks a little odd.

Vertical tabs to the rescue?

Errm, possibly not. Again you end up in that situation where the only time the visible tabpanel immediately follows the active tab is if you activated the last tab, which some users may find a little confusing and cause them to have to think about what is going on and how these somewhat distant elements are related.

Don't make me think

I am of course making some assumptions here that users find the pattern a little confusing and thus far I am just referring to users who can see the interface, as it's the visuals we are focusing on right now.

Just a quick run through what is needed:

• A wrapping element with role="tablist", this will hold the individual tabs, obviously there should be more than one tab present in a tablist
• The current tab will need aria-selected="true" to indicate it is the currently active tab, for screen reader users
• Each tab having aria-controls="[IDRef of the associated tabpanel]", to create a programmatic relationship between each tab and its corresponding tabpanel
• The panel should have a role of tabpanel and an accessible name, using aria-labelledby=[IDRef of the controlling button]", is a common approach
• An interaction model which uses arrow navigation between tabs, only allowing one tab to be focusable with the tab key and then using arrows to focus on adjacent tabs, if using a button or link, then tabindex="-1" would be required for removing the non-active tabs out of the tab sequence
• For each of the tabpanels that are not visible, hide the tabpanel and its contents from both the accessibility tree and the focus order, so they can only be accessed when the tabpanel is visible

Just a few alternatives for you to look at, Don't worry, I'm not just going to copy anybody's work or paraphrase what has already been said, this is just going to be an alternative, nothing more.

• If you are unaware of the excellent Inclusive Components book by Heydon Pickering, you should definitely give that a read, the chapter for Tabbed Interfaces is obviously related to what we are doing here. Heydon's approach is obviously solid, a progressively enhanced table of contents that becomes tabs when JavaScript is available
• There is also the Deque tabby-accordion things, which make so much sense visually, the tabpanel always displays directly below its corresponding tab, but unfortunately, that tabpanel is inside the tablist, which isn't valid ARIA
• Finally, Andy Bell has an interesting solution, one I had not seen before until recently, where the tablist itself is scrollable, horizontally, so they still appear as tabs on smaller viewports. Just one little niggle on this one, I could not get the last tab to be fully in view using a keyboard alone, but other than that, these are are really neat solution

OK, so what is our approach?

Well, we're just going to go with tabs on larger viewports and accordions on smaller viewports, but we will of course do this properly, in that there will be no incorrect roles present on either widget, all properties will be correct and each widget will have the correct interaction model. We'll also start from a nice progressively enhanced version and only do the magic where JS is available.

If this isn't the solution for you, I recommend exploring those linked above.

I'm going to explain this step-by-step, which if you're already comfortable with JS will likely be far too much waffling from me, but maybe some folks are just starting out with it, so you can skip past those bits.

An MVP for when there is no JS

Let's start with the good stuff, the HTML, we want this to be our minimum viable product (MVP), this should be accessible if or when JS doesn't load or the user chooses not to allow it. Given that tabs usually show the the first panel on page load, we could do something similar, we could use the <details><summary> element and force the first one to be open on page load. There are still some browser inconsistencies, as Scott O'Hara points out here and Adrian Roselli points out here.

Is it appropriate for us to use this element? Hmm, well it has some quirks across browsers, but no show-stopping issues, so we'll do so tentatively. Ultimately let your users' needs guide your decisions, not some random guy on the internet.

<div class="widget__wrapper">
  <details open>
    <summary>Widget 1</summary>
    <div>
      <p>
        Widget 1 contents: Lorem ipsum dolor sit amet consectetur adipisicing
        elit. Porro quasi ab, error fugiat at, maiores enim impedit cumque
        quidem similique et laborum aliquam modi assumenda officiis est!
        Sapiente, non neque! <a href="">Test 1</a>
      </p>
    </div>
  </details>
  <details>
    <summary>Widget 2</summary>
    <div>
      <p>
        Widget 2 contents: Lorem ipsum dolor sit amet consectetur, adipisicing
        elit. Numquam molestias nostrum repudiandae, quaerat alias iste placeat
        at a, sequi deserunt iure praesentium velit repellendus ipsum culpa
        ratione soluta eius magni quasi fugiat repellat necessitatibus fugit.
        <a href="">Test 2</a>
      </p>
    </div>
  </details>
  <details>
    <summary>Widget 3</summary>
    <div>
      <p>
        Widget 3 contents: Lorem ipsum dolor sit amet consectetur, adipisicing
        elit. Est illo hic vitae tenetur omnis laborum itaque vero adipisci
        doloremque optio ullam, vel similique aliquam quo! <a href="">Test 3</a>
      </p>
    </div>
  </details>
</div>

So, we have three <details> & <summary> elements and the first has the open attribute, to have some visual similarity with the tabbed interface. Notice I have a wrapping <div> inside each <details> which is a sibling of the <summary> element? As you may have multiple paragraphs or even other stuff inside your <details> it makes sense to wrap it all in something, making it easier to grab those contents with JS, assuming we mark it up correctly the <summary> is the first child, we the know that <div> will be the last child and it will hold the entirety of the collapsible content.

Also, I have wrapped them all in a <div class="widget__wrapper"> because we'll need that for DOM manipulation and also I called it that because it's neither tabs or accordions all of the time, so due to my lack of creativity, we'll just call this element a widget.

Cool, JS is available, let's do the magic

What I am going to do is just show each step's code on its own as opposed to making the code block longer and longer at each step, thus making the page overly long. I will of course provide completed files at the end.

Setting up our main variables

First we'll initialise our global variables and then we'll build a string from the contents of the <details> and <summary elements, so we can use this as our base HTML. Once that is all sorted, we'll remove everything from our wrapper and insert our new string as HTML and then reference the global variables we need from that new HTML.

Explainer 1

const widgetWrapper = document.querySelector('.widget__wrapper');
let baseHTML = '',
  open = 0;
const mq = window.matchMedia('(max-width: 767px)');
const navKeys = [
  'ArrowUp',
  'ArrowRight',
  'ArrowDown',
  'ArrowLeft',
  'Home',
  'End',
];

widgetWrapper.querySelectorAll('details').forEach((el, idx) => {
  baseHTML += `<h3 class="widget__heading">
    <button class="widget__btn" id="btn-${
      idx + 1
    }" data-btn-idx="${idx}" aria-controls="panel-${idx + 1}">${
    el.firstElementChild.textContent
  }</button></h3>
    <div class="widget__panel" id="panel-${
      idx + 1
    }" data-panel-idx="${idx}" aria-labelledby="btn-${idx + 1}">${
    el.lastElementChild.innerHTML
  }</div>`;
});
baseHTML = `<div class="widget__controls-wrapper">${baseHTML}</div>`;

widgetWrapper.innerHTML = '';
widgetWrapper.insertAdjacentHTML('afterbegin', baseHTML);
const widgetControlsWrapper = widgetWrapper.querySelector(
  '.widget__controls-wrapper'
);
const widgetBtns = Array.from(widgetWrapper.querySelectorAll('.widget__btn'));
const widgetPanels = Array.from(
  widgetWrapper.querySelectorAll('.widget__panel')
);

Adding a function to create accordions

We'll create our accordions first as they are what will display on smaller viewports and mobile first tends to be the best way of building sites, so we create a createAccordions() function.

Explainer 2

const createAccordions = () => {
  widgetControlsWrapper.removeAttribute('role');
  widgetBtns.forEach((btn, idx) => {
    idx === open
      ? btn.setAttribute('aria-expanded', 'true')
      : btn.setAttribute('aria-expanded', 'false');
    idx === open
      ? btn.parentElement.setAttribute('data-expanded', 'true')
      : btn.parentElement.setAttribute('data-expanded', 'false');
    btn.parentElement.removeAttribute('role');
    btn.removeAttribute('tabindex');
    btn.removeAttribute('role');
    btn.removeAttribute('aria-setsize');
    btn.removeAttribute('aria-posinset');
    btn.removeAttribute('aria-selected');
    btn.parentElement.after(
      widgetWrapper.querySelector(`[aria-labelledby="${btn.id}"]`)
    );
  });

  widgetPanels.forEach(panel => {
    panel.setAttribute('role', 'region');
    panel.removeAttribute('tabindex');
    panel.removeAttribute('hidden');
  });
};

Adding a function to create tabs

We'll now create a createTabs() function which will add all of the necessary roles and properties to our tabbed interface, as well as removing any artefacts of the accordions pattern.

Explainer 3

const createTabs = () => {
  widgetControlsWrapper.setAttribute('role', 'tablist');
  widgetBtns.forEach((btn, idx) => {
    btn.parentElement.setAttribute('role', 'presentation');
    btn.setAttribute('role', 'tab');
    btn.setAttribute('aria-setsize', widgetBtns.length);
    btn.setAttribute('aria-posinset', idx + 1);
    idx === open
      ? btn.setAttribute('aria-selected', 'true')
      : btn.setAttribute('aria-selected', 'false');
    if (idx !== open) btn.setAttribute('tabindex', '-1');
    btn.removeAttribute('aria-expanded');
    btn.parentElement.removeAttribute('data-expanded');
  });

  widgetPanels.forEach((panel, idx) => {
    panel.setAttribute('role', 'tabpanel');
    idx === open
      ? panel.setAttribute('tabindex', '0')
      : panel.setAttribute('hidden', '');
  });
  widgetPanels.reverse().forEach(el => widgetControlsWrapper.after(el));
};

Just a tiny bit of CSS, for now

Just so we can actually see these working, we'll hide the accordion panels when data-expanded="false" is present on the button's parent heading with display: none; and we'll also belt and brace the hidden attribute for tabpanels with the same CSS.

Just so our tabs are displayed horizontally, we'll set display: flex; and gap: 2px; to the tablist container.

[role='tablist'] {
  display: flex;
  gap: 2px;
}

[hidden],
[data-expanded='false'] + .widget__panel {
  display: none;
}

Adding events to display the correct widget

Now we need to determine which widget to display, initially we need to do this on page load so we are providing the user with the widget that best fits their viewport.

Explainer 4

window.addEventListener('DOMContentLoaded', evt => {
  mq.matches ? createAccordions() : createTabs();
});

mq.addEventListener('change', evt => {
  mq.matches ? createAccordions() : createTabs();
});

Adding click functionality to the widgets

Accordions are naturally easier to manage as we just need a click event, which will handle both mouse clicks and keyboard presses to expand or collapse their corresponding panel. We need to tackle the tabs in a slightly different way, we're going for tabs with automatic activation, which means as a user cycles through the tabs with arrow keys, each time they focus on a new tab it becomes the selected tab and its corresponding tabpanel is displayed. Tabs also need to add a click event, as we need this to work for mouse and touchscreen input too.

Now we will create a function handleClickOnBtns() which will listen for clicks on our <button> elements, the first thing we need to do is make sure that the 'click' event was on an item that has the class which is present on our buttons, as we only want this code to run if it was our buttons that were clicked, otherwise it will run if somebody adds elements with certain roles to any of the panels, best to be safe, right?

Explainer 5

function handleClickOnBtns(evt) {
  if (evt.target.classList.contains('widget__btn')) {
    if (evt.target.getAttribute('aria-expanded') === 'false') {
      evt.target.setAttribute('aria-expanded', 'true');
      evt.target.parentElement.setAttribute('data-expanded', 'true');
    } else if (evt.target.getAttribute('aria-expanded') === 'true') {
      evt.target.setAttribute('aria-expanded', 'false');
      evt.target.parentElement.setAttribute('data-expanded', 'false');
    }
    if (evt.target.hasAttribute('role')) {
      setActiveTab(evt.target);
    }
  }
}

widgetWrapper.addEventListener('click', handleClickOnBtns);

Setting active and non-active tabs

So we need a function to handle setting the active tab and displaying its corresponding panel, whilst setting all other tabs to be non-active and their corresponding panels to hidden, we will do this in a setActiveTab() function, which will accept the current tab a user has clicked or selected.

Explainer 6

setActiveTab = (activeTab) => {
  widgetBtns.forEach(tab => {
    if (tab === activeTab) {
      tab.setAttribute('aria-selected', 'true');
      tab.removeAttribute('tabindex');
      widgetWrapper.querySelector(`[aria-labelledby="${tab.id}"]`).setAttribute('tabindex', '0');
      widgetWrapper.querySelector(`[aria-labelledby="${tab.id}"]`).removeAttribute('hidden');
    } else {
      tab.setAttribute('aria-selected', 'false');
      tab.setAttribute('tabindex', '-1');
      document.getElementById(tab.getAttribute('aria-controls')).removeAttribute('tabindex');
      document.getElementById(tab.getAttribute('aria-controls')).setAttribute('hidden', '');
    }
 }

Adding the interaction model to our widgets

The interaction model for horizontal tabs is as follows:

• Only one tab is in the page's focus order at any given time, pressing Tab whilst focus is on a tab will move focus out of the tablist, in our example focus will move to the tabpanel
• Pressing Shift and Tab will also move focus out of the tablist, in reverse
• Pressing Shift and Tab whilst focus is on a tabpanel will move focus back up to the active tab
• A keyboard user should be able to focus on adjacent tabs using the horizontal arrow keys, in our automatic activation implementation, focusing on any tab will make it the active tab and automatically display its panel
• Should a user reach the last tab and press the right arrow key or they press the left arrow key whilst focus is on the first tab, we can either cycle back through, infinitely or just do nothing, we're going to do nothing, reaching either end of the tablist will be a hard stop
• If a user presses Home whilst focus is within the tablist, then focus moves to the first tab
• If a user presses End whilst focus is within the tablist, then focus moves to the last tab

The interaction model for accordions is as follows:

• Pressing tab whilst focusing on an accordion button

  • If that accordion is collapsed and there is an accordion below, then focus advances to that accordion, as any interactive elements inside the closed panel must be ignored
  • If that accordion is expanded and there are no interactive elements inside its panel. then focus moves to the accordion below (if present) or continues through the page, as normal

• Pressing Shift and Tab whilst focusing on an accordion button

  • If there is an accordion above and it is collapsed, focus will move to that accordion, ignoring any interactive elements it may contain
  • if the above accordion is open and has no interactive elements, then focus will move to the above accordion (if present) or continue up the page

• Pressing Tab or pressing Shift and Tab whilst focus is inside an accordion panel

  • If focus is on the last interactive element inside the panel and a user presses Tab, focus will move to the below accordion (if present), else continue down the page
  • If focus is on the first interactive element inside the panel and a user presses Shift and Tab, focus will move to the above accordion (if present), else continue up the page
  • All interactive elements within the panels should of course be focusable in a logical order, which is usually the source order of the HTML

• Optional interaction for accordions

  • If a user is focused on an accordion and presses Home their focus moves to the first accordion in that group
  • If a user is focused on an accordion and presses End their focus moves to the last accordion in that group
  • If a user is focused on an accordion and presses the down arrow key, focus will move to the accordion below (if present) else we are choosing to do nothing
  • If a user is focused on an accordion and presses the up arrow key, focus will move to the accordion above (if present) else we are choosing to do nothing

Quite a bit to consider there, but it's not as involved as it sounds, as the browser already handles a good chunk of that, we have hidden our panels properly, so focus cannot enter them if they are not displayed. We already manage the focus by setting the appropriate tabindex values, where required, so we only need to add the functionality for the keys we stored in our navKeys array. We're going to also add the optional interaction for accordions.

Explainer 7

function handleKeyboardInteraction(evt) {
  if (
    navKeys.includes(evt.key) &&
    evt.target.classList.contains('widget__btn')
  ) {
    evt.preventDefault();
    const currentIdx = Number(evt.target.getAttribute('data-btn-idx'));
    evt.target.hasAttribute('role')
      ? (next = 'ArrowRight')
      : (next = 'ArrowDown');
    evt.target.hasAttribute('role') ? (prev = 'ArrowLeft') : (prev = 'ArrowUp');

    if (evt.key === next && currentIdx < widgetBtns.length - 1) {
      evt.target.hasAttribute('role')
        ? setActiveTab(widgetBtns[currentIdx + 1])
        : widgetBtns[currentIdx + 1].focus();
      if (evt.target.hasAttribute('role')) widgetBtns[currentIdx + 1].focus();
    } else if (evt.key === prev && currentIdx > 0) {
      evt.target.hasAttribute('role')
        ? setActiveTab(widgetBtns[currentIdx - 1])
        : widgetBtns[currentIdx - 1].focus();
      if (evt.target.hasAttribute('role')) widgetBtns[currentIdx - 1].focus();
    }

    if (evt.key === 'Home' && evt.target.hasAttribute('role'))
      setActiveTab(widgetBtns[0]);
    if (evt.key === 'Home') widgetBtns[0].focus();
    if (evt.key === 'End' && evt.target.hasAttribute('role'))
      setActiveTab(widgetBtns[widgetBtns.length - 1]);
    if (evt.key === 'End') widgetBtns[widgetBtns.length - 1].focus();
  }
}

widgetControlsWrapper.addEventListener('keydown', handleKeyboardInteraction);

Handling focus when the viewport changes

Some users may be unable to read text that others find comfortable, we all have different needs and preferences, so we need to consider those circumstances where our current implementation has one issue that may be less than obvious. Let's assume we have a user that has low-vision, they open up our page and see the widget and one of the buttons contains the topic they are interested in. This user also uses a keyboard to navigate websites, as that is what works best for them. They decide they want to zoom in, to read the contents, currently in our implementation, their focus could be lost, which would be hugely frustrating for keyboard users.

This happens because we never update our open variable, it is just set to 0 at the top of our JS. That's OK though, as obviously we have that for a reason and now we are going to use it properly. Let's look at the three situations where we don't want the switching of patterns to become jarring, confusing or steal a user's focus:

• If a user's focus was on one of the buttons, irrespective of whether they were in the accordions layout or the tabs layout, the browser doesn't lose focus here, as the buttons are only modified with attributes. We want to try to make sure users don't lose their place so we will force the panel they were focused on to be the open panel. If the layout was accordions, we have to open one panel when it changes to tabs and by focusing on this tab, it automatically becomes the selected tab, so it has be this one and if a user was viewing the tabs layout, that tab was selected so we'll just expand that accordion for them
• If a user was focused on a tabpanel (as they're focusable), we cannot send focus to the relevant accordion panel as accordion panels are not focusable. So the sensible solution is to send focus back one step, to its controlling <button> and we'll expand that accordion as it was open in the tabs layout (if we didn't do this, focus would be lost to the <body> as that element is no longer focusable)
• Finally, the only other place focus could have been was inside a panel, in which case that panel was open and a user's focus position needs to be maintained, so we just detect which panel was open and force that to be open in whichever layout the user triggered. We then return focus to the initial position (currently focus is lost to the <body> as we hoist the panels around and I guess for a fraction of a nanosecond, they don't exist so focus is lost?)

It is of course possible that a user had multiple accordions open, but we can't do anything about that, as our tabs can only have one panel open. We do all of the above simply by detecting where focus was and getting a reference to that element or its closest ancestor that matches a given query. We can use the data attributes data-btn-idx and data-panel-idx, we added earlier. We then update the value of our open variable to force whichever panel that meets one of our three conditions to be open. We also store a reference to a user's current focus position and we only do anything about that if their focus was inside our widgetWrapper, as this is where we kinda broke the way a browser manages that.

We'll update our mq.addEventListener() method as this is the only time we need to concern ourselves with this change.

Explainer 8

mq.addEventListener('change', evt => {
  // New code below
  let currentFocus = document.activeElement;

  if (currentFocus.closest('.widget__wrapper')) {
    if (currentFocus.classList.contains('widget__btn')) {
      open = Number(currentFocus.getAttribute('data-btn-idx'));
    } else if (currentFocus.classList.contains('widget__panel')) {
      open = Number(currentFocus.getAttribute('data-panel-idx'));
      currentFocus = widgetWrapper.querySelector(`[data-btn-idx="${open}"]`);
    } else if (currentFocus.closest('.widget__panel')) {
      open = Number(
        currentFocus.closest('.widget__panel').getAttribute('data-panel-idx')
      );
    }
  }
  // New code above
  mq.matches ? createAccordions() : createTabs();
  // New code below
  currentFocus.focus();
});

Now, let's style um

I'm not going to explain the CSS, as this has guide has already taken forever to write, I will of course provide the completed code at the end and I'll just summarise what we need in the bullets below: I'm also not going to great lengths to make them look good, they'll just look OK and I'm not animating their expanding or collapsing.

• We either need a media query in CSS that matches our media query in JS or we just use the attributes as styling hooks, I'm just going to use the attributes, but a media query would be safer on a real site
• We need to style the <details> & <summary> elements so they look decent where JS isn't available, we also need to ensure they have a focus indicator
• We need to make our accordions look like accordions and they will need a focus indicator
• Our tabs need to look like something a user can operate and we need a focus indicator, along with a selected indicator
• Our tabpanels need a focus indicator too, as the active panel has tabindex="0" set, so we need to show keyboard users where they are
• We need to consider Windows High Contrast Mode, which will ignore a couple of background colours I had set

I genuinely haven't taken much time to style these, I would of course do better for an actual site. The High Contrast Mode focus indicators could definitely be improved and the CSS would be better if I used classes and media queries, as I'm currently using attributes, which may be present elsewhere on a page. This wasn't a styling exercise, just a proof of concept, please feel free to style your version much nicer.

See the Pen Responsive Accessible Tabs by LDAWG-a11y (@LDAWG-a11y) on CodePen.

Is it worth the effort to wrangle the DOM to provide a user with either tabs or accordions depending on their viewport size? Well, it took us just over 130 lines of JS to do that and I have no doubt that could be further reduced by a JS ninja. In this example though we have taken a <details> & <summary> element and progressively enhanced it, providing ARIA accordions for the smaller viewport breakpoint and ARIA tabs for the larger viewport breakpoint. We did so with all of the correct ARIA and interaction patterns and we even considered managing focus when a user triggers the 'change' event for the media query, so we have pretty much covered everything here.

I'm not personally a fan of tabs, not because I find them difficult to use, but because they typically only appear suited to larger viewports, they just don't seem suited to smaller viewports, but that's just my view. Accordions, however, work on all screen sizes, so my preference would be to just use accordions, which would be much simpler in those cases where we want to hide some content until a user exposes it. We don't always get the choice though, sometimes we have to work with what we have. So, maybe when we find ourselves in a situation where tabs are staying put, then this approach could be an alternative to Heydon's or Andy's solutions? I'm not saying my solution is as good as either of theirs, I just wanted to provide a different solution, because the tabs problem actually comes up quite often, usually when we encounter them though, they don't have the correct interaction model and often the ARIA is wrong or not present at all.

If you have a site that hardly has any JS and loads fast anyway, then this solution should only have a minimal impact, performance wise.

Whether you choose to use or improve this pattern yourself, always test, I have tested my own work, but disclaimer, I've only done so with the latest browsers and assistive tech pairings.

The no JS solution, using <details> & <summary>

The smaller viewport solution: accordions

The larger viewport, showing the tabs

Windows High Contrast Mode

No JS <details> and <summary> solution

Accordions solution

Tabs solution

HTML full code

<div class="widget__wrapper">
  <details open>
    <summary>Widget 1</summary>
    <div>
      <p>
        Widget 1 contents: Lorem ipsum dolor sit amet consectetur adipisicing
        elit. Porro quasi ab, error fugiat at, maiores enim impedit cumque
        quidem similique et laborum aliquam modi assumenda officiis est!
        Sapiente, non neque! <a href="">Test 1</a>
      </p>
    </div>
  </details>
  <details>
    <summary>Widget 2</summary>
    <div>
      <p>
        Widget 2 contents: Lorem ipsum dolor sit amet consectetur, adipisicing
        elit. Numquam molestias nostrum repudiandae, quaerat alias iste placeat
        at a, sequi deserunt iure praesentium velit repellendus ipsum culpa
        ratione soluta eius magni quasi fugiat repellat necessitatibus fugit.
        <a href="">Test 2</a>
      </p>
    </div>
  </details>
  <details>
    <summary>Widget 3</summary>
    <div>
      <p>
        Widget 3 contents: Lorem ipsum dolor sit amet consectetur, adipisicing
        elit. Est illo hic vitae tenetur omnis laborum itaque vero adipisci
        doloremque optio ullam, vel similique aliquam quo! <a href="">Test 3</a>
      </p>
    </div>
  </details>
</div>

JavaScript full code

const widgetWrapper = document.querySelector('.widget__wrapper');
let baseHTML = '',
  open = 0;
const mq = window.matchMedia('(max-width: 767px)');
const navKeys = [
  'ArrowUp',
  'ArrowRight',
  'ArrowDown',
  'ArrowLeft',
  'Home',
  'End',
];

widgetWrapper.querySelectorAll('details').forEach((el, idx) => {
  baseHTML += `<h3 class="widget__heading">
    <button class="widget__btn" id="btn-${
      idx + 1
    }" data-btn-idx="${idx}" aria-controls="panel-${idx + 1}">${
    el.firstElementChild.textContent
  }</button></h3>
    <div class="widget__panel" id="panel-${
      idx + 1
    }" data-panel-idx="${idx}" aria-labelledby="btn-${idx + 1}">${
    el.lastElementChild.innerHTML
  }</div>`;
});
baseHTML = `<div class="widget__controls-wrapper">${baseHTML}</div>`;

widgetWrapper.innerHTML = '';
widgetWrapper.insertAdjacentHTML('afterbegin', baseHTML);
const widgetControlsWrapper = widgetWrapper.querySelector(
  '.widget__controls-wrapper'
);
const widgetBtns = Array.from(widgetWrapper.querySelectorAll('.widget__btn'));
const widgetPanels = Array.from(
  widgetWrapper.querySelectorAll('.widget__panel')
);

const createAccordions = () => {
  widgetControlsWrapper.removeAttribute('role');
  widgetBtns.forEach((btn, idx) => {
    idx === open
      ? btn.setAttribute('aria-expanded', 'true')
      : btn.setAttribute('aria-expanded', 'false');
    idx === open
      ? btn.parentElement.setAttribute('data-expanded', 'true')
      : btn.parentElement.setAttribute('data-expanded', 'false');
    btn.parentElement.removeAttribute('role');
    btn.removeAttribute('tabindex');
    btn.removeAttribute('role');
    btn.removeAttribute('aria-setsize');
    btn.removeAttribute('aria-posinset');
    btn.removeAttribute('aria-selected');
    btn.parentElement.after(
      widgetWrapper.querySelector(`[aria-labelledby="${btn.id}"]`)
    );
  });

  widgetPanels.forEach(panel => {
    panel.setAttribute('role', 'region');
    panel.removeAttribute('tabindex');
    panel.removeAttribute('hidden');
  });
};

const createTabs = () => {
  widgetControlsWrapper.setAttribute('role', 'tablist');
  widgetBtns.forEach((btn, idx) => {
    btn.parentElement.setAttribute('role', 'presentation');
    btn.setAttribute('role', 'tab');
    btn.setAttribute('aria-setsize', widgetBtns.length);
    btn.setAttribute('aria-posinset', idx + 1);
    idx === open
      ? btn.setAttribute('aria-selected', 'true')
      : btn.setAttribute('aria-selected', 'false');
    if (idx !== open) btn.setAttribute('tabindex', '-1');
    btn.removeAttribute('aria-expanded');
    btn.parentElement.removeAttribute('data-expanded');
  });

  widgetPanels.forEach((panel, idx) => {
    panel.setAttribute('role', 'tabpanel');
    idx === open
      ? panel.setAttribute('tabindex', '0')
      : panel.setAttribute('hidden', '');
  });
  widgetPanels.reverse().forEach(el => widgetControlsWrapper.after(el));
};

function handleClickOnBtns(evt) {
  if (evt.target.classList.contains('widget__btn')) {
    if (evt.target.getAttribute('aria-expanded') === 'false') {
      evt.target.setAttribute('aria-expanded', 'true');
      evt.target.parentElement.setAttribute('data-expanded', 'true');
    } else if (evt.target.getAttribute('aria-expanded') === 'true') {
      evt.target.setAttribute('aria-expanded', 'false');
      evt.target.parentElement.setAttribute('data-expanded', 'false');
    }
    if (evt.target.hasAttribute('role')) setActiveTab(evt.target);
  }
}

setActiveTab = activeTab => {
  widgetBtns.forEach(tab => {
    if (tab === activeTab) {
      tab.setAttribute('aria-selected', 'true');
      tab.removeAttribute('tabindex');
      widgetWrapper
        .querySelector(`[aria-labelledby="${tab.id}"]`)
        .setAttribute('tabindex', '0');
      widgetWrapper
        .querySelector(`[aria-labelledby="${tab.id}"]`)
        .removeAttribute('hidden');
    } else {
      tab.setAttribute('aria-selected', 'false');
      tab.setAttribute('tabindex', '-1');
      document
        .getElementById(tab.getAttribute('aria-controls'))
        .removeAttribute('tabindex');
      document
        .getElementById(tab.getAttribute('aria-controls'))
        .setAttribute('hidden', '');
    }
  });
};

function handleKeyboardInteraction(evt) {
  if (
    navKeys.includes(evt.key) &&
    evt.target.classList.contains('widget__btn')
  ) {
    evt.preventDefault();
    const currentIdx = Number(evt.target.getAttribute('data-btn-idx'));
    evt.target.hasAttribute('role')
      ? (next = 'ArrowRight')
      : (next = 'ArrowDown');
    evt.target.hasAttribute('role') ? (prev = 'ArrowLeft') : (prev = 'ArrowUp');

    if (evt.key === next && currentIdx < widgetBtns.length - 1) {
      evt.target.hasAttribute('role')
        ? setActiveTab(widgetBtns[currentIdx + 1])
        : widgetBtns[currentIdx + 1].focus();
      if (evt.target.hasAttribute('role')) widgetBtns[currentIdx + 1].focus();
    } else if (evt.key === prev && currentIdx > 0) {
      evt.target.hasAttribute('role')
        ? setActiveTab(widgetBtns[currentIdx - 1])
        : widgetBtns[currentIdx - 1].focus();
      if (evt.target.hasAttribute('role')) widgetBtns[currentIdx - 1].focus();
    }

    if (evt.key === 'Home' && evt.target.hasAttribute('role'))
      setActiveTab(widgetBtns[0]);
    if (evt.key === 'Home') widgetBtns[0].focus();
    if (evt.key === 'End' && evt.target.hasAttribute('role'))
      setActiveTab(widgetBtns[widgetBtns.length - 1]);
    if (evt.key === 'End') widgetBtns[widgetBtns.length - 1].focus();
  }
}

window.addEventListener('DOMContentLoaded', evt => {
  mq.matches ? createAccordions() : createTabs();
});

mq.addEventListener('change', evt => {
  let currentFocus = document.activeElement;

  if (currentFocus.closest('.widget__wrapper')) {
    if (currentFocus.classList.contains('widget__btn')) {
      open = Number(currentFocus.getAttribute('data-btn-idx'));
    } else if (currentFocus.classList.contains('widget__panel')) {
      open = Number(currentFocus.getAttribute('data-panel-idx'));
      currentFocus = widgetWrapper.querySelector(`[data-btn-idx="${open}"]`);
    } else if (currentFocus.closest('.widget__panel')) {
      open = Number(
        currentFocus.closest('.widget__panel').getAttribute('data-panel-idx')
      );
    }
  }
  mq.matches ? createAccordions() : createTabs();
  currentFocus.focus();
});

widgetWrapper.addEventListener('click', handleClickOnBtns);
widgetWrapper.addEventListener('keydown', handleKeyboardInteraction);

CSS full code (Basic styling)

:root {
  --colour-interactive: rebeccapurple;
  --colour-bg: #f1f1f1;
}

*,
*::before,
*::after {
  box-sizing: border-box;
  margin: 0;
}

body {
  padding: 0.5rem;
  max-width: 50rem;
  font-size: 1.25rem;
  line-height: 1.5;
  font-family: Arial, Helvetica, sans-serif;
  color: #202020;
  background-color: var(--colour-bg);
}

details {
  margin-bottom: 2px;
  border: 2px solid var(--colour-interactive);
}

details div {
  border-top: 2px solid var(--colour-interactive);
  padding: 8px;
}

summary {
  padding: 8px 10px;
  color: var(--colour-interactive);
  font-weight: bold;
}

summary:focus-visible {
  color: var(--colour-bg);
  background-color: var(--colour-interactive);
  outline: 2px solid transparent;
}

.widget__btn {
  position: relative;
  padding: 8px 10px;
  font-size: 1.5rem;
  font-weight: bold;
  color: var(--colour-interactive);
  background-color: var(--colour-bg);
  cursor: pointer;
}

.widget__btn[aria-expanded] {
  display: flex;
  align-items: center;
  margin-bottom: 2px;
  border: 2px solid var(--colour-interactive);
  width: 100%;
  text-align: left;
}

.widget__btn[aria-expanded]::before,
.widget__btn[aria-expanded]::after {
  content: '';
  position: absolute;
  background-color: var(--colour-interactive);
}

.widget__btn[aria-expanded]::before {
  right: 20px;
  height: 20px;
  width: 6px;
  transition: transform ease-in 200ms;
}

.widget__btn[aria-expanded]::after {
  right: 13px;
  height: 6px;
  width: 20px;
}

.widget__btn[aria-expanded='true']::before {
  transform: scaleY(0);
}

.widget__btn[aria-expanded]:focus-visible {
  color: var(--colour-bg);
  background-color: var(--colour-interactive);
  outline: 2px solid transparent;
}

.widget__btn[aria-expanded]:focus-visible::before,
.widget__btn[aria-expanded]:focus-visible::after {
  background-color: var(--colour-bg);
}

.widget__panel[role='region'] {
  position: relative;
  top: -2px;
  border: 2px solid var(--colour-interactive);
  border-top: none;
  padding: 8px;
}

[role='tablist'] {
  display: flex;
  gap: 2px;
}

[role='tab'] {
  border: 1px solid var(--colour-interactive);
  border-bottom: none;
  border-radius: 3px 3px 0 0;
}

[role='tab'][aria-selected='true']::before,
[role='tab'][aria-selected='true']::after {
  content: '';
  position: absolute;
  left: 0;
  width: 100%;
}

[role='tab'][aria-selected='true']::before {
  top: 0;
  height: 0;
  border-top: 3px solid var(--colour-interactive);
}

[role='tab'][aria-selected='true']::after {
  bottom: -1px;
  width: 100%;
  height: 3px;
  background-color: var(--colour-bg);
}

[role='tabpanel'] {
  padding: 8px;
  border: 1px solid var(--colour-interactive);
}

[role='tab']:focus-visible {
  outline: 2px solid var(--colour-interactive);
  outline-offset: -8px;
}

[role='tabpanel']:focus-visible {
  position: relative;
  outline: 2px solid var(--colour-interactive);
  z-index: 1;
}

[hidden],
[data-expanded='false'] + .widget__panel {
  display: none;
}

@media screen and (forced-colors: active) {
  .widget__btn[aria-expanded]::before,
  .widget__btn[aria-expanded]::after {
    background-color: ButtonText;
  }

  [role='tab'][aria-selected='true']::after {
    background-color: Window;
  }
}