13 issues found on Tarife

Ensure, a visible focus state exists for all interactive elements, including buttons. Ideally, focused buttons have a visible outline set.

Ensure, a visible focus state exists for all interactive elements, including the content cards. Ideally, focused buttons have a visible outline set that is not obscured and goes all around the focused element.

Ensure, link purpose is determinable. Ideally, a proper semantic structure on content card is used. As the base structure is already visually presented as such a card, consider the following structure:

<nav aria-labelledby="heading-tariff-list">
  <h2 id="heading-tariff-list">Alle Tarifgruppen im Überblick</h2>
  
  <ul>
    <!-- Content Card -->
    <li>
      <article class="card">
        <div>
          <h3 id="heading-TARIFF">TARIFF GROUP NAME</h3>
          <p>TARIFF DESCRIPTION</p>
          <a href="..." id="link-TARIFF">Zu den TARIFF GROUP-Tarifen</a>
        </div>
        <div style="order:-1;">
          <img src="..." alt="PROPER TEXT ALTERNATIVE" />
        </div>
      </article>
    </li>

    <!-- More Cards -->
  </ul>
</nav>

Setting up the link with a pseudo element like this:

.card a::before {
  content: '';
  position: absolute;
  inset: 0;
  z-index: 1;
}

And the card itself with:

.card { 
  position: relative; 
}

/* Add focus state to card when link WITHIN is focused */
.card:focus-within,
.card:hover {
  outline: 2px solid magenta;
  box-shadow: 8px 8px black;
}

/* Remove focus outline from link */
.card:focus-within :focus {
  outline: none;
}

Will make the card be focus visible, while the link in it still is the focused element with the correct accessible name.

Ensure, adding proper text alternative to the images.

Ensure, visual presentation matches the code markup and proper heading nesting is done.

Short: only what is an actual heading (using semantic HTML element) should be visually presented as such. And everything that is visually presented as a heading must be an actual heading.

Approach to better heading structure / outline, grouping the tariff group cards under a new <h2> heading.

p Telekom Tarife

1 Alles rund um die Telekom Tarife
  2 Alle Tarifgruppen im Überblick
    3 MagentaMobil
      p Mit den Telekom Tarifen ...

    3 MagentaZuhause
      p Bequem zu Hause im Festnetz ...

    3 MagentaTV
      p Erleben Sie Entertainment zu Hause und unterwegs ...

    3 MagentaEINS
      p Kombinieren Sie ganz einfach Ihre Telekom Tarife ...

    3 MagentaMobil Prepaid
      p Sie möchten unbeschwert telefonieren und surfen, ...

    3 Young Tarife
      p Mit den Telekom Tarifen für junge Leute ...

    3 Glasfaser-Tarife
      p Mit den Telekom Tarifen für Glasfaser ...

    3 MagentaMobil Data
      p Wenn Sie Tablet oder Laptop ...

    3 Zusatzkarten
      p Haben Sie bereits einen Telekom Tarif ...

  2 Häufig gestellte Fragen zu unseren Telekom Tarifen
    p Telekom Tarife

    3 Was ist der billigste Tarif der Telekom?
    3 Welche Telekom Tarife sind am beliebtesten?
    3 Welcher Telekom Vertrag ist der beste?
    3 Was ist das Besondere bei Telekom Tarifen?

Please (also) refer to observation 1.3.1 Info and Relationships – "Semantic HTML" for general remarks about the use of semantic HTML.

When remediating, please also refer to observation "Content card link purpose not determinable" (2.4.4 Link Purpose (In Context)), where remediation recommends the use of proper card structure, as those work in tandem.

Ensure, all text content meets required contrast minimum of 4.5:1 for all text content with font size <24px and 3:1 for all text content with font size ≥24px.

Side Note: this success criterion is not about identification of links. When a link would have no underline and its color is the only way to differentiate from surrounding text, it is considered a failure under 1.4.1 Use of Color. This is not the case here. This criterion is for all text content.

Ensure proper reflow of content on smaller viewports. Ideally, content reflows responsively based on available space. This can be achieved by a setup like this:

.grid {
  --min-item-width: 200px;
  --grid-gap: 1rem;

  display: grid;
  grid-gap: var(--grid-gap);
}

@supports (width: min(var(--min-item-width), 100%)) {
  .grid {
    grid-template-columns: repeat(auto-fit, minmax(min(var(--min-item-width), 100%), 1fr));
  }
}

Note: remediating this issue, please be aware of changes to the "content cards" in other observations as well. Please refer to observation "Content card link purpose not determinable" (2.4.4 Link Purpose (In Context)) for more information.

Ensure, using correct semantic HTML elements for all interactive elements. In case of accordions, these could be <detail> and <summary> constructs or ones with <button> as the accordion item "header".

Keyboard navigation is a must.

For custom building an accessible accordion component, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".

Possible methods to remediate and to ensure access to the links:

• Adding pagination (single pointer arrow buttons)

• Reflow to multiple lines (also see 1.4.10 Reflow)

Note, that the WCAG, and success criterion 2.5.7 Dragging Movements specifically, do not require presentation / layout parity of different devices, viewports, etc. This means, while functionality and information parity is a must, the layout and presentation can be different.

Ensure, all HTML image elements properly set the alt attribute. Depending on the purpose of the image, choose whether to declare an image decorative, informative, or functional. For more guidance in choosing, refer to the W3C Alt-decision tree.

If the image is

• purely decorative, set a null alt attribute as follows: <img alt="" />

• not purely decorative, the alt attribute must not be null

Ensure proper use of semantic HTML.

• Semantic elements must not solely be used for styling or layout purposes

• All styling and layout changes must use CSS

• Limit use of line breaks to intended purposes, e.g. in poetry or code snippets

• Only use <button> for buttons

• Use <a href=""> for links

Using non-native, non-semantic HTML elements to build functionality, native, semantic HTML elements already provide should be a rare occasion. As the first rule of ARIA use describes, if there is a semantic HTML with needed or wanted functionality this should always be used instead of ARIA.

Ensure, semantic HTML elements are used for all interactive elements and components. Refer to BFIT-Bund Handreichung "Accessible design of user interface elements" for technical requirements for building interactive user interface components.

Ensure, using semantic HTML elements to build accordion functionality.

Using non-native, non-semantic HTML elements to build functionality, native, semantic HTML elements already provide should be a rare occasion. As the first rule of ARIA use describes, if there is a semantic HTML with needed or wanted functionality this should always be used instead of ARIA.

Ensure, semantic HTML elements are used for all interactive elements and components. Refer to BFIT-Bund Handreichung "Accessible design of user interface elements" for technical requirements for building interactive user interface components.