29 issues found on Xiaomi 15

Focusing interactive element adds visual focus indicator that does solely rely on color to be differentiated from default, un-focused state and color contrast ratio of default and focused states does not meet minimum required 3:1 color contrast ratio. Interactive elements' focus states, relying on color only and with insufficient color contrast ratio to default, un-focused state include:

• "Close" button in footnote dialog window

The silhouette icon on the "Anmelden" button has no alt attribute. When the icon is considered decorative, as it arguably can be, the image must have a null alt attribute set to hide it from the accessibility tree.

Purely decorative images must not have an accessible text alternative present. They must be excluded from the accessibility tree.

Decorative images with text alternative present:

• Check mark icons in sidebar use <svg aria-hidden="false" aria-label="Not Activated" while arguably being decorative

Images that are not purely decorative, must have a purpose equivalent text alternative set, to be accessible if the image cannot be visually perceived. A prime example is a blind screen reader user. But also if an image cannot be loaded due to network issues, the text alternative ensures perception of the conveyed information.

Images with non-equivalent text alternative:

• Product images all use alt="Xiaomi 15"

• "Netzteil" images in "Produktinformationen" have empty alt attribute

What is arguably list content, is not using semantic list elements. See

• check mark list in "Tarif- und Gerätepreis" section

Semantic HTML elements must not be used for styling and layout purposes. Semantic elements carry a certain role that is communicated to assistive technology. Using semantic elements with a certain role for styling or layout purposes while the content does not match the communicated role, it will confuse users of assistive technology. Certain elements will be announced in certain ways, so that e.g. line break elements <br> or empty paragraph elements <p></p> are announced as "empty group".

• "Herstellerangaben" section

• "Weitere Details" dialog window

• Footnote dialog window

• Info icon collapsible in sidebar & "Tarifdetails" dialog window in "Tarif ändern" dialog window

  • line break elements

  • Non breaking spaces

Error state in "Handyankauf" dialog window uses color on the input field. Color used has not enough contrast ratio to background color and not enough color contrast ratio to default or success state of input field.

Links solely rely on color to be differentiated from other, surrounding text content and color contrast ratio of link text color to surrounding text color does not meet minimum required 3:1 color contrast ratio. Links, relying on color only and with insufficient color contrast ratio to surrounding text content include:

• "Weitere Details"

  • links in "Weitere Details" dialog window do not use any differentiating style

• "Teilnahmebedingungen" in "Ankaufsbonus" dialog window

• links in "Herstellerangaben" section

• links in collapsible item (info i icon in sidebar)

• links "Tarif ändern" and "Tarif entfernen" in sidebar

• link "Preisliste, Leistungsbeschreibung und AGB" in "Tarif ändern" dialog window

List content in section "Spezifikationen" uses generic HTML element instead of semantic list element.

Measured at 320 × 256px with 100% page zoom, barely 25px vertical space is available when the "Preisübersicht" footer gets sticky.

Text content in certain containers may overflow the container's boundaries, when text spacings are changed, making some text harder, other text impossible to perceive. This often includes:

• Stage areas

• Badges

• Manually outlined elements like buttons (e.g. footnote icon buttons)

• Teasers

• Card components

Content that is shown on hover –like tool tips– must be dismissible (usually on ESC), to allow hiding the content without changing focused element.

Text content must meet minimum color contrast ratio of 4.5:1 to its background. Large text (>24px) content must meet minimum color contrast ratio of 3:1 to its background. The following text content does not meet the required minimum contrast ratios:

• Sidebar links

  • Produktinformationsblatt (PDF)

  • Preisliste, Leistungsbeschreibung und AGB

  • Jetzt Handy verkaufen / Jetzt aktivieren

• "Preisübersicht" dialog window – hovered tabs

On base viewport size of 1024×768px and page zoom of 200%, the available:

• vertical space on the page after "Preisübersicht" is sticky < 400px

• vertical space in the tariff carousel < 400px.

• horizontal space, due to page zoom, is limited and cuts of hover tooltips

All content must be presented without loss of information or functionality.

Footnote dialog window is not keyboard accessible.

When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:

• The contents of the dialog window are not accessible via keyboard.

• The dialog window can not be closed by keyboard (easily or at all).

• While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))

• Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.

• Device thumbnails

• "Speichergröße"

• "Einmalzahlung"

• "Handyversicherung"

  • Details button

  • "radio buttons"

Interactive element can be operated by mouse but not by keyboard. The issue may occur when:

• Non-semantic HTML elements (e.g. <div>, <span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g. <a href="">, <button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.

• Semantic elements are used but required attributes are missing (e.g. <a>, missing href attribute)

• Semantic HTML elements are mis-used (e.g. <a> used as a button, or <button> used as a link)

Open dialog windows can obscure focus of underlying interactive elements. Obscuring can be partial or complete. This will impact users of keyboard navigation as focus cannot be tracked while a dialog window is open. Dialog windows triggered by:

• Footnotes

Fixed content:

• Bottom bar in "Tarif ändern" dialog window obscures multiple focusable elements

• Zahlungsinformation in sidebar fixed; links in collapsible (info icon)

When dynamically added content can be activated by the user, correct focus order must be ensured. This includes:

• Opening a dialog window

• Expanding an accordion item

• Dynamically loading more content (e.g. more products in a product list) via "Load more" button

Adding and removing dynamic content must not remove focus from the triggering element. E.g. a footnote or info icon opening (adding) a dialog window. When the dialog window is closed (removed) again, focus must be on the triggering element.

Content out of focus order found:

• Footnote dialog window is not keyboard accessible.

Text content "Anmelden" in button "Anmelden" uses <text-replacer tabindex="0"> making text content focusable, while surrounding button already can be focused and interacted with. The button markup looks as follows:

<button class="...">
  <span class="...">
    <span class="...">
      <div class="...">
        <div class="...">
          <img class="..." 
               src="....svg" 
               data-img="...">
          <div class="...">
            <svg width="..." height="..." viewBox="..." fill="none" xmlns="...">...</svg>
          </div>
        </div>
      </div>
      <span>
        <text-replacer data-id="..." 
                       style="..." 
                       tabindex="0">
          <span style="...">Anmelden</span>
        </text-replacer>
      </span>
    </span>
  </span>
</button>

Nesting focusable elements like this will make assistive technology focus all elements in sequence, adding duplication without added information.

Same goes for sidebar buttons

• Tarif ändern

• Tarif entfernen

• Preisübersicht anzeigen

• Links without programmatically determinable context; not part of a paragraph, preceding heading is main heading with device name

  • Produkthinweise – "Weitere Details"

The purpose of a link must not solely rely on visually perceived aspects like layout, proximity, placement. The purpose of a link should be understandable from the link text itself or its programmatic context, ensuring it's accessible to assistive technologies and a wider range of users.

Relying solely on visual cues to convey a link's purpose makes it inaccessible to:

• Users of assistive technology like screen readers.

• Users with cognitive disabilities who might not interpret visual layouts correctly.

• Users with customized displays (e.g. unexpected viewport sizes, or turned off styles).

• Device image views buttons "Ansicht von..."

• Ankaufsbonus Aktionsübersicht dialog window – close button

Focusable elements must have a visually distinct focus state. Moving keyboard focus to a focusable element must clearly identify the element as being focused. If this is not the case, sighted users of keyboard navigation will have difficulties navigating a page. Especially when multiple focusable elements do not show visible focus indicators, properly navigating the page may become impossible.

• "Anderes Gerät verkaufen" labelled "Handyankauf"

Interactive elements, like links, buttons, inputs, must have a label that is visible at all times and an accessible name that is programmatically determinable. The visible label of interactive elements must be equal to, or part of the accessible name.

If the accessible name is changed programmatically to differ from the natively set name, the visible label must be part of it in the exact wording. If the accessible name is changed, ideally, the visible label is the first part of the accessible name.

Assistive technology like voice control software uses the accessible name to control interactive elements. By stating the accessible name, the interactive element can be activated. So to activate a button, labeled "Submit", a user of voice control software can say "Click button Submit". If the accessible name of the button has been changed to "Send Form", the user is not able to access the button this way. If the accessible name of the button has been changed to "Submit Form", the name differs from the visible label but still includes the visible name as first part, making it still accessible to voice control software.

This observation is set to priority 5 "Best Practice", so it is not considered a failure. As the full header section of the page is out of scope for this audit, the authentication process via "Anmelden" button cannot be tested in the scope of this audit. Thus, 3.3.8 Accessible Authentication (Minimum) is marked as "Not Evaluated".

• Device color buttons do not use semantic button element; no content given, no label given

  • assistive technology announces wrong colors

  • assistive technology announces button, group

• While not a failure of this criterion, device color choice arguably should be a radio button group instead; as should storage option and "Einmalzahlung" option

• "Handyversicherung" is displayed as radio button group but is not using proper radio button group syntax

All interactive elements that do not use the correct interactive HTML elements must be built in a way, that semantic information is provided and updates to semantic information are accessible via assistive technology. Building interactive components with incorrect HTML elements results in inaccessible content. These accessibility issues might occur:

• Interactivity of element is not announced → user will not know, that element is interactive

• Changes to states (e.g. collapsed/expanded) is not announced → user will not know of the change

• Target resource is not announced → e.g. user will not know, where a link leads to

• Interactive action is not announced → e.g. user will not know, that a dialog window will be opened

Issues in 4.1.2 Name, Role, Value often occur together with other issues e.g. in 2.1.1 Keyboard and 2.4.7 Focus Visible.

Buttons and links not used correctly.

• Dialog windows should be triggered by button elements, instead, many are triggered by link elements with missing href attribute

  • Weitere Details

  • Jetzt gebrauchtes Handy verkaufen / Anderes Gerät verkaufen

  • "Details" links in "Handyversicherung"

  • Tarif ändern

  • Tarif entfernen

  • Preisübersicht anzeigen

All interactive elements that do not use the correct interactive HTML elements must be built in a way, that semantic information is provided and updates to semantic information are accessible via assistive technology. Building interactive components with incorrect HTML elements results in inaccessible content. These accessibility issues might occur:

• Interactivity of element is not announced → user will not know, that element is interactive

• Changes to states (e.g. collapsed/expanded) is not announced → user will not know of the change

• Target resource is not announced → e.g. user will not know, where a link leads to

• Interactive action is not announced → e.g. user will not know, that a dialog window will be opened

Issues in 4.1.2 Name, Role, Value often occur together with other issues e.g. in 2.1.1 Keyboard and 2.4.7 Focus Visible.

In "Tarif ändern" dialog window, keyboard focus is trapped after selecting tariff. Following these steps:

1. Open "Tarif ändern" dialog window

2. Press TAB until tariff slider is focused

3. Press ARROW LEFT / RIGHT to focus tariff

4. Press ENTER to select focused tariff

5. Pressing TAB now will rotate within tariff card

Interactive elements not announced interactive, making it inaccessible to users of assistive technology

• Device thumbnails announced as images

• "Speichergröße"

• "Einmalzahlung"

• "Handyversicherung"

  • Details button

  • "radio buttons"

Interactive elements not using correct semantic HTML

• "Spezifikationen" collapsible button is announced; assistive technology can navigate into content but is trapped inside until collapsible is closed again

Interactive element can be operated by mouse but not by keyboard. The issue may occur when:

• Non-semantic HTML elements (e.g. <div>, <span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g. <a href="">, <button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.

• Semantic elements are used but required attributes are missing (e.g. <a>, missing href attribute)

• Semantic HTML elements are mis-used (e.g. <a> used as a button, or <button> used as a link)

Images that are not purely decorative, must have a purpose equivalent text alternative set, to be accessible if the image cannot be visually perceived. A prime example is a blind screen reader user. But also if an image cannot be loaded due to network issues, the text alternative ensures perception of the conveyed information.

Images with non-equivalent text alternative in SEO content:

• "Sternstunde der Fotografie"

• "Smart, schnell und intuitiv"

• "Leistung, die überzeugt"

The HTML image element must always use have alt attribute present. Either

• null alt attribute for purely decorative or

• non-null alt attribute for informative/functional images.

Image elements missing alt attribute:

• connect Testsiegel

<img 
    class="sc-kpDqfm bOhZXF dt_mainImage customStyle imgLoaded pdp__award__image" 
    src="https://www.telekom.de/resources/images/1207130/xiaomi-15-connect-sehr-gut.png" 
    data-img="isSafari_undefined isSsr_undefined"
>