42 issues found on Smartphones

Ensure, purely decorative images have a null alt attribute set. SVGs must have an empty <title> element instead and ideally be hidden manually via aria-hidden="true".

For more information about accessible icon buttons, refer to Sara Soueidan's "Accessible Icon Buttons" article.

If an image is declared to be informative rather than decorative, a purpose equivalent text alternative must be programmatically determinable. Duplicating already existing text content never is purpose equivalent of an image. See the W3C Alt-decision tree for more information about types of non-text content.

Use proper semantic HTML headings to indicate the structure of the sidebar content. How the heading is worded, potentially the most fitting element structure would be a a heading level 2 and an unordered list.

<h2>Ich möchte...</h2>
<ul><li>...

Ideally, creation of empty paragraph elements will technically be prohibited.

Content management however must ensure, not creating empty paragraph elements, not in rich text nor source code editor.

Side note: while this issue is about the found empty paragraph element, there are rare occasions, any element should be empty.

Use proper semantic HTML structure to create navigation landmark. Ensure, labelling the <nav> element to differentiate from main, breadcrumb and other menu(s).

The use of semantic HTML is adamant to a good user experience and web accessibility. Ideally, native HTML is used. In case of an accordion, this could be realized by using the <detail> and <summary> elements.

If there is a valid reason to not use those, ensure the use of interactive elements (<button>) for the interactive parts of the accordion.

The technical requirements for building an accessible accordion component can be found in the BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".

The accordion, while not strictly defined as such, can be defined as an opposite to a tab group. They both have the purpose of hiding content from the user to be revealed on user interaction. Defining accordion and tab group as opposites allows for an easy rule of usage. Tab groups are used, if and only if there must always be exactly one content panel visible. The accordion is then used, whenever the possibility of showing more than one content panel at the same time is needed or wanted. This distinction can e.g. be found in the documentation of the GOV.UK Design System at Accordion – "Decide between using accordions, tabs and details".

Use anchor elements for links instead of trying to build custom interactive components. All <a> elements MUST have an href attribute. To demonstrate, this is one of the links:

<div class="style__StyledNavigationChips-sc-h2fd9x-0 IhoCS dt_navigationChips clickable selected"
     data-qa="LST_DeviceCategory_smartphones">
  <article class="style__StyledIconWrapper-sc-h2fd9x-1 jAhAws">
    <div class="iconWrapper" role="image" aria-label="Handys">
      <div class="sc-imWYAI iYZqNY es_preloadImage">
        <img class="sc-kpDqfm bxTqZb dt_mainImage customStyle imgLoaded"
          alt="Handys"
          src="..."
          data-img="isSafari_false isSsr_undefined">
        <div class="sc-jXbUNg jYexhV dt_placeholderImage">
          <svg width="100%" height="100%" viewBox="0 0 121 242"
            fill="none" xmlns="http://www.w3.org/2000/svg">
            <path d="..."
              fill="#F3F3F3"></path>
          </svg>
        </div>
      </div>
    </div>
  </article>
  <div class="sc-YysOf esSDcz dt_typography variant_smallBold">
    Handys
  </div>
</div>

When it easily could be:

<nav aria-labelledby="heading-device-categories" id="menu-device-categories">
  <h2 id="heading-device-categories">Geräte-Kategorien</h2>
  <ul>
    <li><img alt="" src="..."><a href="">Handys</a>
    <li><img alt="" src="..."><a href="">Smartwatches</a>
    <li><img alt="" src="..."><a href="">Tablets</a>
    <li><img alt="" src="..."><a href="">Mobile Router</a>
    <li><img alt="" src="..."><a href="">Tastenhandys</a>
  </ul>
</nav>

for the whole navigation to be perfectly accessible. The clean semantic structure with the id on the navigation element allows for all necessary CSS selectors to be created from the id alone without the need of countless CSS classes.

Simple structured HTML outperforms in many ways.

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

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.

• Ankaufsbonus

  • Change the text alternative to communicate the icon's purpose, e.g. by setting alt="Ankaufspreis Ihres Altgerätes".

• Vorbestellung

  • Add <title> element to SVG or embed SVG from file and treat like <img>

  • If declaring icon as decorative, ensure <title> element is empty and SVG is hidden from screen readers by setting aria-hidden="true"

There are multiple ways to remediate this issue.

Image description

The ideal way would be to use the actual image description. Possible text alternatives for the example devices in the screenshot could be in the following style:

• "Apple iPad Air 13" (2025) M3 in Space Grau. Vorderseite mit generischem Wallpaper, Hinterseite mit Kamera"

• "Samsung Galaxy S25 Edge in Titanium Icyblue (hellblau). Vorderseite mit Gerätenamen als Schriftzug, Seitenansicht, Promotion für 2× Speicher-Upgrade inklusive"

• "Samsung Galaxy S25 Ultra in Schwarz. Vorderseite mit Gerätenamen als Schriftzug, Rückseite mit 5 Kameras"

Declare decorative

A less ideal way would be to declare the device image as decorative by using a null alt attribute, removing it from the accessibility tree. There are a few caveats to this "tactic", though and if using it, there are multiple other steps to be done, to ensure conformance with this success criterion.

• While this would improve the current use of the images' text alternatives, removing the content duplication, it does not really solve the issue of the images' purpose not being communicated.

• A decorative image only is purely decorative, if not adding any information that is not communicated otherwise. While device name and device color might be information which is available elsewhere, the actual description of the device is not.

• Declaring the images decorative, you additionally MUST ensure, all other information (color, promotions, add-ons, extra devices like styluses, etc.) is available as text in the product card.

Change the text alternative to communicate the icon's purpose, e.g. by setting alt="Geräte von Apple anzeigen". Ensure to deliver accessible, purpose equivalent text alternatives for all filter states.

• No manufacturer filter selected: "Nur Geräte von MANUFACTURER anzeigen"

• One manufacturer filter selected

  • selected filter: "Alle Geräte anzeigen"

  • non-selected filter: "Geräte von MANUFACTURER anzeigen"

• Multiple manufacturer filters selected

  • selected filter: "Geräte von MANUFACTURER nicht mehr anzeigen" (or ideally even announcing the still selected filters, see notes below)

  • non-selected filter: "Geräte von MANUFACTURER anzeigen"

One possible solution would be to use native checkbox inputs for the manufacturer filters. But the structural idea down below can be used with other methods as well.

<fieldset>
  <legend>Filter nach Endgeräte-Hersteller</legend>

  <input type="checkbox" 
         id="manufacturer-apple" 
         name="manufacturer" 
         value="Apple" 
         checked />
  <label for="manufacturer-apple">
    <svg><title>Apple</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-google" 
         name="manufacturer" 
         value="Google" />
  <label for="manufacturer-google">
    <svg><title>Google</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-samsung" 
         name="manufacturer" 
         value="Samsung" 
         checked />
  <label for="manufacturer-samsung">
    <svg><title>Samsung</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-telekom" 
         name="manufacturer" 
         value="Telekom" />
  <label for="manufacturer-telekom">
    <svg><title>Telekom</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-xiaomi" 
         name="manufacturer" 
         value="Xiaomi" />
  <label for="manufacturer-xiaomi">
    <svg><title>Xiaomi</title>...</svg>
  </label>
</fieldset>

From there work with the ids of checked/unchecked to create the accessible names by dynamically adding IDs of checked inputs. This way, you could create something like "Geräte von MANUFACTURER nicht mehr anzeigen. Es werden Geräte gezeigt von: CHECKED_MANUFACTURERS"

Change the text alternative to communicate the icon's purpose, e.g. by setting alt="Tarifdetails anzeigen/ausblenden".

Ensure, code markup matches the visual presentation. One possible solution could be a structure as follows:

<h2></h2> <!-- Heading to introduce device list -->
<!-- Device list -->
<ul>
  <li>
    <!-- Device card -->
    <article>
      <h3></h3> <!-- Device name -->
      <span></span> <!-- Badge with promotion/info -->

      <dl>
        <div>
          <dt class="visually-hidden">Verfügbar in den Farben</dt>
          <dd>
            <ul></ul> <!-- Available colors -->
          </dd>
        </div>

        <div>
          <dt class="visually-hidden">Speicherplatz</dt>
          <dd>
            Verfügbar in
            <ul></ul> <!-- Storage options -->
          </dd>
        </div>

        <div>
          <dt>Preis, einmalig</dt>
          <dd></dd> <!-- Price -->
        </div>
      </dl>

      <img /><!-- Device image -->
    </article>
  </li>

  <!-- More device cards -->
</ul>

Improvements made and notes to implement:

• Clear structure without unnecessary nesting, without sections/articles nested, etc.

• Use actual semantic list (<ul>) for the list

• Each product is an <article> so it can be navigated to easily via screen reader

• Product is defined by semantic heading <h3> as first child of product card

• <span> with badge positioned right after heading, so it will be announced after the device name; badge can be positioned absolute or visually be moved up by using CSS order: -1

• Product description is moved into description list to make each description detail easily navigable

• Lists within the description (color list, storage option list) are using semantic list elements

• Some <dt> can use a class="visually-hidden" to be accessible to screen readers while not being visible; check example class below

.visually-hidden:not(:focus):not(:active) {
  clip: rect(0 0 0 0); 
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap; 
  width: 1px;
}

Added side-effect of a semantic structure like this is the improved simplicity to build a responsive layout for the list, using CSS grid and Flexbox.

Ensure the site is responsive. A viewport of 320px width must keep all content visible and all functionality intact. For the product cards, use a responsive layout method like the following to ensure correct reflow:

.product-list {
  --min-card-width: 200px;
  --product-list-gap: 1rem;

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

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

Containers of any type (e.g. badges, teasers, stages) must not use fixed dimensions, if they contain text content.

Ensure use of proper structure of of the page and easy identification of repeated content blocks by using a combination of landmarks, and HTML headings. An example structure for the shop pages containing product lists, could be as followed:

1. HTML header

   1. The current header element is not part of this audit, thus its current contents are not listed in here.

   2. Breadcrumb navigation as HTML <nav> element, labeled to differentiate from main menu, and including an ordered list <ol>

   3. Option product highlights identified by <h2> heading

   4. Device group navigation, using <nav> navigation element, labeled to differentiate from other menus

2. <main> landmark

   1. <h1> main heading and description text content

   2. <section> for filtering and sorting

      1. evaluate use of ARIA role search

      2. add <h2> heading with id attribute and

      3. label the section by using aria-labelledby="" with the heading ID

   3. <section> for product list as your main content

      1. add <h2> heading with id attribute and

      2. label the section by using aria-labelledby="" with the heading ID

      3. The actual device list should use <ul>

      4. Each product card should be <article> including <h3> with product name

      5. No further nesting of landmarks should be needed inside this section as the structure is well defined by the article elements and their nested heading

   4. <section> for sidebar content; ideally labeled by a visible heading <h2> that describes all sidebar content; sections inside sidebar should not use <section> but only <h3> for structure

   5. <section> for landing page, SEO content and FAQ; sections inside should not use <section> but only <h2> and <h3> for structure

3. HTML footer

Additionally, the use of skip links should be evaluated. Skip links are not only meant to be the first links on a page, but can also be used before certain repeated content blocks. For example, at the start of the main landmark, there could be a skip link that skips the product list and brings the user to the sidebar content or the FAQ section. Skip links can also be used at the end of a section or landmark to go back to its beginning. For example, at the end of the product list, which can be quite long, there could be a skip link to reach the start of the product list again.

Using proper structure of HTML headings usually makes "custom landmarks" (by sections) a redundant mechanism to navigate on a page, so they should not be used on everything. Only use landmarks for broad page structure.

The same goes for skip links. If a proper heading structure and optional landmarks already exist, there usually is no need for additional skip links.

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

Ensure, contents of the filtering dialog window are in correct focus order (after filter button)

Ensure, link purpose is determinable. This can be done by adding "GERÄT XYZ in den Warenkorb legen" as text alternative. Ideally, a proper semantic structure on product card is used.

<article>
  <h3 id="heading-PRODUCT">PRODUCT NAME</h3>
  ...
  <a href="..." id="link-PRODUCT" aria-labelledby="heading-PRODUCT link-PRODUCT">
    Produktdetails
  </a>
</article>

A focus state must be defined for all interactive, focusable elements. Ideally, a visual distinct focus state uses an outline or other larger area changes to the product card.

If using color change for focus state, ensure to meet minimum color contrast between different states (1.4.3 Contrast (Minimum)) and to not only rely on color change (1.4.1 Use of Color).

A focus state must be defined for all interactive, focusable elements. Ideally, a visual distinct focus state uses an outline or other larger area changes to the focused element.

If using color change for focus state, ensure to meet minimum color contrast between different states (1.4.3 Contrast (Minimum)) and to not only rely on color change (1.4.1 Use of Color).

Footnotes must be made accessible. They must trap the keyboard focus when opened and must not allow scrolling of the page and focusing of underlying interactive elements. This will remediate the obscuring of focused elements.

Treat scrollable area as carousel or make scrollbar visible.

Ideally, the filter buttons should reflow correctly into multiple rows.

Opening a dialog window with the keyboard must set the focus into the dialog window. Preferably onto the close button as the first interactive element in the dialog window. The focus must also be trapped inside the dialog window so the underlying page cannot be reached by keyboard while the dialog window is opened.

A better approach would be to use a <dialog> element for dialog windows.

Ensure complete navigation and operation by keyboard is possible. All interactive elements MUST be reachable by keyboard.

Only use semantic HTML elements to create interactive elements to ensure the base accessibility. If building custom interactive elements instead, you MUST refer to something like BFIT-Bund Handreichung "Accessible design of user interface elements" to ensure all necessary functionality is available. This MUST be done for all interactive elements that are custom built. Every button, every input, every link, ... Thus, using proper semantic HTML will decrease time and necessary effort to complete dramatically.

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

For example, filtering dialog window should use buttons, radio button groups, checkmark groups, etc. instead of relying on dozens/hundreds of nested <div> to "rebuild" functionality, native HTML elements already deliver.

The "Filter" button to open the filter dialog window looks as follows:

<div class="... clickable" data-qa="LST_FilterButton">
  <i class="..." id="svg_wrapper_undefined">
    <svg width="1em" height="1em" viewBox="0 0 20 20" color="currentColor">
      <path>...</path>
    </svg>
  </i>
  <p class="...">Filter</p>
</div>

When it could just be:

<button><svg aria-hidden="true">...</svg>Filter</button>

Dialog windows must be made accessible. They must trap the keyboard focus when opened and must not allow scrolling of the page and focusing of underlying interactive elements. They must be closable via ESC and the close button must be operable by keyboard as well. This will remediate the obscuring of focused elements.

Ensure, making all interactive elements at least 24×24px in size. This does not necessarily mean to make the icon itself 24×24px, if you can ensure a surrounding area of said size to be the clickable area of the icon.

A better approach would however be to not use interactive elements below this minimum size. Also consider mobile users when designing these elements. An increased target size of 44×44px (see success criterion 2.5.5 Target Size (Enhanced) [AAA]) will immensely help mobile users as well.

Ensure, making all interactive elements at least 24×24px in size. This does not necessarily mean to make the icon itself 24×24px, if you can ensure a surrounding area of said size to be the clickable area of the icon.

A better approach would however be to not use interactive elements below this minimum size. Also consider mobile users when designing these elements. An increased target size of 44×44px (see success criterion 2.5.5 Target Size (Enhanced) [AAA]) will immensely help mobile users as well.

As used in the filter dialog window already, a "Filter anwenden" button could fix this issue, although for the given structure, this might not be the best option.

The buttons should have appropriate accessible names to describe their purpose. See ___ for an example solution. The success criterion says, the change of content or context can be announced prior to making the change. Having the accessible name set properly, would meet this for screen reader users. For other users it would be best to visually indicate by text. E.g., introducing the filter section by a short text:

<section>
  <h2>Geräteliste filtern und sortieren</h2>
  <h3>Filter</h3>
  <p> <!-- Add description -->
  <button> <!-- Filter dialog window -->
  <fieldset> <!-- Checkbox Group for direct filters -->

That description could be:

"Öffnen Sie die gesamten Filteroptionen über einen Klick auf den 'Filter' Button oder klicken sie auf einen der darauffolgenden Hersteller-Buttons, um die Geräteliste entsprechend zu filtern."

Or you could even set a <legend> inside the checkbox group to properly describe their purpose.

Ensure, links do not rely on color alone to be differentiated from (surrounding) body text. Preferably use underline to indicate text links as it is the default –thus user friendly– method.

While not a failure for the given success criterion, the limited vertical space in the dialog window makes navigating the dialog's contents extremely difficult. Evaluation of the need for the fixed top bar and the large fixed bottom bar should be done.

Consistency with other dialog windows could remove the (empty) top bar and/or add the close button to a fixed position of the scrollable dialog window.

The fixed bottom bar could e.g. be shrunken by

• decreasing margins and/or paddings,

• decreasing the size of the primary button,

• changing the layout to display price information and primary button side-by-side.

Ideally, the colors would be described as text.

If this is not possible, ensure a minimum contrast ratio of 3:1. The easiest way to achieve this is by using a simple outline on the color variant circle:

.variantCircle {
  outline: .1px solid;
}

This way, the contrast ratio is not calculated to the background color but to the outline color.

No remediation necessary, as the contrast ratio does exceed the required ratio slightly.

Ensure, all text content meets required contrast minimum.

Ensure all text content meets minimum color contrast requirements.

The contents of the tooltip must stay accessible on smaller viewports. Ensure to display the contents within the boundaries of the viewport.

As the site is already working with dialog windows and collapsible elements, the easiest way to achieve this is to eliminate the tooltip functionality, as they (tooltip, dialog window, collapsible) serve the same purpose of hiding information. For this, the other used method must meet all success criteria, but this would eliminate the need of meeting them with yet another mechanism.

Hiding information from the user never is good user experience but the use of dialog windows or collapsible elements is widespread. While the use is no clear failure of accessibility criteria, concerning WCAG, one could argue it being at least a grey area for 3.2.4 Consistent Identification: "Components that have the same functionality within a set of Web pages are identified consistently." – this audit will not add this as a failure but asks to evaluate the use of multiple components that have the same purpose. Ideally, the functionality "hide from user" has a single way to be done. Splitting into a trigger being "block level" (FAQ) and "inline level" (Footnotes) seems reasonable, but adding another mechanism does not seem necessary.

While not a failure for the given success criterion, I also attached a screenshot showing the limited vertical space in the dialog window, which makes navigating the dialog's contents extremely difficult. Evaluation of the need for the top bar and the large bottom bar should be done.

Important note:

While technically, this behavior does not completely remove access which would be needed to justify priority 1 "Critical", the combination of this issue with other issues, limiting the user experience with keyboard and screen reader navigation immensely already, still does make this issue a critical one.

Treating it as such in the current state, keyboard and screen reader users might not at all be able to navigate more than one page of products in the product list within the shop, is highly recommended.

Ensure, clicking the button "Weitere Geräte anzeigen" will result in:

• Loading more products into the product list

• Not announcing change of query parameters in the URL, as long as the change is not useful information to be announced

• But ideally do announce the change of content (e.g. by using an ARIA live region and announce "X weitere Geräte werden angezeigt")

• Setting the focus to the first focusable element before the first newly added element

  • This must be indicated by DOM structure, not by the element that was focused before the button was focused

  • This must work with keyboard and screen reader navigation alike

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

• Adding pagination (single pointer arrow buttons)

• Reflow to multiple lines of buttons (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.

This allows for another method to remediate, by only displaying the amount of buttons, fitting the available space. So while "all" buttons are shown on larger viewports, the number can decrease on smaller viewports, as long as the functionality parity is met, which is the case, with the filter buttons being accessible via the filter dialog window.

Positive side-effect of the latter option is one less mechanism (horizontally scrolling items) to be maintained.

The buttons MUST be user accessible interface components. Ideally, use a native semantic HTML <button> element for the filter button, <fieldset> including <input type="checkbox"> for the "direct manufacturer filter" buttons, and explicit labels to go with them. As is, there is neither a programmatically determinable connection between the "labels" and the buttons, nor does the buttons have any accessible name, let alone one including the label.

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

Using native semantic HTML is always the preferred method.

If this is absolutely impossible in a situation, re-building can be viable but comes with dramatically increased time and effort to meet technical requirements. The BFIT-Bund Handreichung "Accessible design of user interface elements" shows technical requirements (e.g. keyboard navigation, mouse operation, etc.) for interactive elements. Looking into Accessible design of user interface elements – Links, quickly shows the complexity of what is required to meet the functionality, a properly used <a href="..."> element already includes.

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

Ensure, only using button functionality for actual buttons. When button functionality is needed, ensure using a semantic HTML button element, instead trying rebuilding button functionality with generic non-semantic HTML elements.

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.

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,

• only links (that lead to resources) are using HTML link elements

• only buttons (that perform actions) are using HTML button elements

• no generic element is used, if a native, semantic HTML element with wanted functionality exists

• all interactive elements are labeled uniquely, to be identifiable by assistive technology