Examples
Last modified on Wed 05 Apr 2023

Examples of non-accessible UI components

None of these examples are accessible and are uncompliant with the success criterion "Name, role, value". They are shown here to demonstrate bad practices. Links to ARIA Design Pattern Examples or other references on building accessible components will be provided where they exist.

Accordion

This accordion isn't compliant with Name, role, value, as its state can not be programmatically determined and set.

<div class="accordion-trigger">Open/close</div>
<div class="accordion">
  <p>Some content</p>
</div>
document.querySelector('.accordion-trigger').addEventListener('click', (event) => {
  event.target.classList.toggle('.is-open');
});
.accordion {
  display: none;

  &.is-open {
    display: block;
  }
}

Check out the accordion example in ARIA Design Patterns

WordPress The accordion component in Eightshift Frontend Libs follows ARIA Authoring Practices and is designed to be Level AA compliant.

Dialogs and modals

This modal isn't compliant with Name, role, value, as its state can not be programmatically determined and set. Note that this is a very common way to implement modals.

<button data-triggers="my-modal" class="modal-trigger">Open a modal</button>
<div class="modal-content" id="my-modal">
  <b>Hi, I'm a modal!</b>
  <a class="modal-close">Close</a>
</div>
document.querySelectorAll('.modal-trigger').forEach((trigger) => {
  trigger.addEventListener('click', (target) => {
    document.querySelector(`#{target.dataset.triggers}`).style.display = 'block';
  });
});
document.querySelectorAll('.modal-close').forEach((closeButton) => {
  closeButton.addEventListener('click', (target) => {
    target.parentNode.style.display = 'none';
  });
});
.modal-content {
  display: none;
  position: absolute;
  top: 100px;
  left: 100px;
  background-color: white;
  z-index: 999;
}

Find examples of accessible modal implementations and alert dialogs in ARIA Design Patterns.

Tabs

This tab component isn't compliant with Name, role, value, as its state can not be programmatically determined and set.

<div class="tabs">
  <ul class="tablist">
    <li class="tab is-active" data-triggers-tab="monkeys">Arctic Monkeys</li>
    <li class="tab" data-triggers-tab="jake">Jake Bugg</li>
    <li class="tab" data-triggers-tab="svemirko">Svemirko</li>
  </ul>
  <div class="tab-content is-open" id="monkeys">
    An English rock band formed in Sheffield in 2002. Best known for "Do I Wanna Know?".
  </div>
  <div class="tab-content" id="jake">An English singer-songwriter.</div>
  <div class="tab-content" id="svemirko">A Croatian indie band.</div>
</div>
document.querySelectorAll('.tabs').forEach((tabsBlock) => {
  tabsBlock.querySelectorAll('.tab').addEventListener('click', (target) => {
    target.closest('.tablist').querySelector('.is-active').classList.remove('is-active');
    target.closest('.tabs').querySelector('.is-open').classList.remove('is-open');
    target.classList.add('is-active');
    target
      .closest('.tabs')
      .querySelector(`.tab-content#{target.dataset.triggersTab}`)
      .classList.add('is-open');
  });
});
.tabs {
  display: inline-flex;
  list-style-type: none;

  & .tab {
    background: gray;

    &.is-active {
      font-weight: bold;
      background: white;
    }
  }

  & .tab-content {
    display: none;

    &.is-open {
      display: block;
    }
  }
}

Find an example of an accessible tabs component implementation in ARIA Design Patterns.

How to build accessible UI components?

We've discussed examples of non-compliant UI components here, but that's only going to help you avoid some common mistakes. Instead of providing examples of compliant UI components, we'll discuss how to build components with ARIA in mind.

The rationale behind this is simple: quality implementation examples already exist (and we'd reinvent the wheel if we were to code our own). As a reference, we suggest using ARIA Design Patterns and its parent document, WAI-ARIA Authoring Practices.

In implementing success criteria, you might find that the sufficient techniques described in WCAG suit you well, especially if you're using native HTML controls.

The rationale behind this is simple: quality implementation examples already exist (and we'd just reinvent the wheel if we were to code our own). As a reference, we suggest using ARIA Design Patterns and its parent document, WAI-ARIA Authoring Practices.

However, when you're building your own UI components (which is often the case), you should make sure they're accessible to users using assistive technologies by following the techniques laid out above.

This may prove to be confusing, so we'll go into detail on each of these techniques.