Я думаю, что это сработает, но может быть лучший общий HTML-подход, который дает лучший результат при меньших затратах. Для доступности (моя область специализации) я бы рассмотрел следующие требования для этого сценария:

1. Может ли кто-нибудь с помощью клавиатуры (но видит экран) зайти на изображения и выбрать их?
2. Может ли кто-нибудь с нарушениями зрения от легкой до умеренной степени увеличить масштаб с помощью элементов управления браузера и по-прежнему видеть содержимое (хотя это, вероятно, больше связано с CSS, чем семантикой, поэтому я не буду здесь это описывать).
3. Может ли пользователь программы чтения с экрана сказать, что можно получить дополнительную информацию, выбрав изображение, и найти информацию, когда она будет выбрана.

Я могу придумать два основных способа реализации того, что вы описали, и до сих пор вы использовали подход «вкладки», когда вверху есть набор элементов управления, а под ним содержимое, которое показывает выбранный вариант.

Другим способом было бы вложение, например:

<section class="fruits">
  <h1>Fruits</h1>
  <ul>
    <li>
       <a data-article-class="banana"> 
         <p>Learn about <strong>Bananas</strong></p>
       </a>
       <div id="content-banana">
         <h2>The Banana</h2>
         <p>A long yellow fruit...</p>
       </div>
    </li>
    ...
  </ul>
</section>

И тогда вам нужно будет расположить видимый контент там, где вы хотите. Я не могу точно сказать, сработает ли это по описанию (без диаграммы), но обычно это возможно.

Любой из подходов подходит для сценариев только с клавиатурой и масштабирования, но то, что вам нужно сделать для программ чтения с экрана, значительно различается.

Для вкладки вам потребуется использовать WAI-ARIA. установить связь между элементами управления и содержимым и потратить немало времени на манипулирование элементами управления с клавиатуры (см. Шаблон оформления вкладок). В противном случае, когда пользователь программы чтения с экрана выбирает изображение, он понятия не имеет, где появился контент.

Для вложенного подхода модель DOM устанавливает внутреннюю связь, поэтому все проще. Пользователь программы чтения с экрана будет просматривать (обычно «стрелка») вниз к изображению и выбирать его. Я бы рекомендовал переместить фокус клавиатуры на новый контент при выборе, поэтому в конце функции, которая показывает контент, вы должны добавить что-то вроде:

$('#content-banana').attr('tabindex', '-1').css('outline', 'none');
$('#content-banana').focus();

Это делает div фокусируемым, удаляет контур (который не нужен, так как вы все равно не можете перейти к нему) и устанавливает фокус там. Примечание: кажется, что вы можете объединить строки, но я обнаружил, что это не работает надежно в программах чтения с экрана.

Закончив чтение, пользователь программы чтения с экрана может просто перейти к следующему элементу и выбрать его (или нет), не зная, где находится контент.

Что касается того, какие теги использовать, <article> здесь не очень подходит, если только контента не много. Он может подойти для всего элемента (заменив section), но если он не предназначен для распространения/ синдицированный, тогда раздел в порядке.

Я бы склонялся к использованию списка в качестве контейнера, потому что он позволяет пользователям программ чтения с экрана пропускать остальные элементы, если они им не интересны. При вложенном подходе 'nav' вообще не подходит. Даже в подходе с вкладками W3C рекомендует список и ссылки для элементов управления вкладками.

Кроме того, я думаю (но это можно исправить), что сближение изображения и содержимого в источнике полезно для поисковой оптимизации, поскольку изображение с большей вероятностью будет ассоциироваться со словами рядом с ним.

NB: я также должен отметить, что если изображения имеют смысл, они должны быть изображениями переднего плана с подходящими атрибутами alt.

Следуя указаниям @AlastairC, я запустил это решение, которое включает в себя Виджет панели вкладок WAI-ARIA:

<!--( My Fruit Tabbing Widget )-->
<section class="fruits" role="application">
  <h1>Fruits</h1>

  <nav role="tablist"><ul> <!--( The Tabs )-->
    <li>
      <a id="fruit_tab_1" role="tab" 
       tabindex="1" aria-controls="fruit_content_1"> 
        <p>Learn about <strong>Bananas</strong></p> </a> </li>
    <li>
      <a id="fruit_tab_2" role="tab" 
       tabindex="2" aria-controls="fruit_content_2"> 
        <p>Learn about <strong>Apples</strong></p> </a> </li>
    <li>
      <a id="fruit_tab_3" role="tab" 
       tabindex="3" aria-controls="fruit_content_3">
        <p>Learn about <strong>Pears</strong></p> </a> </li>
  </ul></nav>

  <div role="tabpanel"> <!--( The Content )-->
    <section id="fruit_content_1" 
     role="tabpanel" aria-labelledby="fruit_tab_1">
      <h1>The Banana</h1>
        <p>A long yellow fruit...</p> </section>
    <section id="fruit_content_2"
     role="tabpanel" aria-labelledby="fruit_tab_2">
      <h1>The Apple</h1>
      <p>A round red fruit...</p> </section>
    <section id="fruit_content_3"
     role="tabpanel" aria-labelledby="fruit_tab_3">
      <h1>The Pear</h1>
      <p>A funny-shaped green fruit...</p> </section>
  </div>

</section>

<!--( JavaScript will apply and manipulate 
  aria-hidden attributes on the section tabpanels, 
  and aria-selected on the tabs, as well as provide 
  basic CSS changes for showing or hiding content )-->

Если кто-то может предоставить разъяснения или улучшения:

• Правильно ли я реализовал ARIA выше? Я новичок в этом. Я видел несколько официальных примеров, содержащих массу JavaScript для функциональности клавиатуры, которые я решил игнорировать.
• Я не могу не чувствовать, что <nav> может подходить для списка таблиц, поскольку мне кажется логичным, что вкладки являются навигационным блоком для раздела «фрукты». Является ли это приемлемым, допустимым, обескураживающим или неприемлемым?
• Являются ли теги <a> более подходящими, чем <button>, или нет?
• А как насчет tabindex? Это правильно настроено? Я не понимаю, что такое tabindex="-1".

Этот ответ установлен как вики сообщества в надежде, что кто-то вроде вас сможет его улучшить.