33 issues found on Handy Verkaufen

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

The device cards in "Jetzt altes Smartphone verkaufen und von attraktiven Ankaufsaktionen profitieren" can be focused. The nested elements inside (footnote, CTA button) are focused before the card itself is focused

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.

• Cards in "Unser nachhaltiger Smartphone-Kreislauf"

The manufacturer filter (direct filter buttons in device carousel) can only be operated by horizontal scroll on desktop and by dragging movement on a mobile device. As the dragging needs a base precision to stop the movement at the right time to reach the wanted filter button, a single pointer alternative for operation / navigation must be offered.

The viewport of the example screenshot is 375×635px, simulating an Apple iPhone 11 Pro. While this is an old device and more current phones do tend to have increased viewport widths, this test would look even more drastic on the 320px viewport width, the WCAG sets for e.g. 1.4.10 Reflow.

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:

• Hover states of interactive elements

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:

• "Teilnahmebedingungen"

• Form

  • "Wo finde ich die IMEI-Nummer?"

  • "Wo finde ich die Angaben?"

  • "Ankaufsbedingungen"

  • "Datenschutzbestimmungen"

• Handyankauf form

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:

• Buttons

• Input elements (e.g. radio buttons, checkboxes)

Input form "Handyankauf" has no "Zurück" button on

• step 6 as opposed to all previous steps. As data, entered to the form, is not saved, and the only way to go back from step 6 is to reload the page, all entered data will be erased. By ensuring, users can navigate all steps back and forth, ideally also being able to jump to specific steps, users will have an easier time, navigating the multi-step form.

• step 3 when choosing "wrong" radio buttons. When choice of radio buttons will terminate the form process, those radio buttons should be separated from the others. When 3 of 4 radio buttons are required to be marked as "YES", this information should be available to the user beforehand. Information like "Wir können Ihr Gerät nur ankaufen, wenn es keine der folgenden Schäden hat" is important to know in advance and is better suited to be displayed as a type="checkbox", where the user can confirm all 3 items ("Ich versichere, dass mein Handy funktionsfähig ist – 1. Das Handy lässt sich einschalten, bleibt mindestens 45 Sekunden lang eingeschaltet und lässt sich aufladen [✔︎], ...") Then adding the last "optional" question that determines the Ankaufs value, could remain a radio button group to differentiate from the mandatory "YES" questions.

Observations:

• Handyankauf form

  • Step indicators use <button type="button" disabled> but are not buttons

  • CAPTCHA reload button uses span aria-hidden="true" instead of button element

  • "Wo finde ich die IMEI-Nummer" uses a href="#imei" title="..." instead of button element; side note, #imei is not found in DOM

    • Close button in dialog window uses <button type="button"> which is redundant and unnecessary

  • "Zurück" button use a href="#" title="Zurück" instead of button element

  • Info "i" icon buttons (step 3) use <span aria-hidden="true"><svg>... instead of semantic (accessible) button element

    • Close button in dialog window uses <button type="button"> which is redundant and unnecessary

  • "Wo finde ich die Angabe" uses a href="#imei" title="..." instead of button element; side note, #imei is not found in DOM

    • Close button in dialog window uses <button type="button"> which is redundant and unnecessary

  • "Prüfen" button uses <button type="button"> which is redundant and unnecessary

  • "Ohne Aktion fortfahren" button uses <button type="button"> which is redundant and unnecessary

  • "Anrede" dropdown uses span role="button" tabindex="0" ... and select id="..." name="title" (with non-unique id) instead of semantic input element

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.

The "Handyankauf" form provides two steps for entering a device IMEI. The IMEI is not auto-populated to the second occurrence.

Handyankauf form does not implement error prevention. At least one of the following must be true for submitting data:

• Reversible – Submissions are reversible.

• Checked – Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

• Confirmed – A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Handyankauf form input throws errors but known suggestions are not made.

• Step 2: "IMEI ungültig" does not hint to specific format requirements (e.g. number of characters, as shown in label, omitting spaces, etc.)

• Step 5: "Code/IMEI-Nummer ungültig." does not suggest Code/IMEI format requirements (compared to e.g. step 2)

• Step 5: "Achten Sie genau auf die Buchstaben oder Nummern." is not accurate wording for input of IMEI number

• Step 6:

  • "Der Vorname ist ungültig."

  • "Der Nachname ist ungültig."

  • "Die IBAN ist ungültig"

Radio button groups in "In welchem Zustand ist Ihr X?" in Handyankauf form step 3 do label each individual radio button by visible text content. The radio button group however does not have appropriate label linked to the inputs.

IMEI-Nummer form input requires "15-stellig" which is part of visible label. It also requires the input without spaces, which is not part of the visible label.

Handyankauf form marks (some) "Pflichtfelder" with "*". But there is not explanation present.

• Step 1: Modell is Pflichtfeld but not marked

• Step 6

  • Anrede is Pflichtfeld but not marked

  • Checkboxes are Pflichtfeld but not marked

Observations on input field "Modell, z. B. Apple iPhone 11":

• Moving screen reader focus to input field announces editable text field.

• Entering character shows list.

• The first item in list is automatically selected.

  • This traps focus of screen reader in the list box.

  • Entering next character will auto select first item.

  • Selection is possible via ARROW UP / DOWN

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.

Elements in "Handyankauf" form:

• "In welchem Zustand ist Ihr..." Radio buttons

• CAPTCHA reload icon button not operable by keyboard

  • Button uses non-semantic <span>

  • Button is hidden by using aria-hidden="true"

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)

While disabled interactive elements do not have to adhere to same contrast requirements as enabled elements, text content still should use proper color contrast ratio.

Given that this usually is not too easy to manage with existing design system guidelines, it should be evaluated to remove disabled form elements completely. Especially if they will not be editable anyways.

Focused interactive elements with focus states solely relying on color difference:

• "Handyankauf" form

  • All/most steps

    • Buttons

      • Weiter

      • Ohne Aktion fortfahren

      • Verbindliche Anfrage abschicken

  • Step 2

    • Close button in dialog window "Wo finde ich die IMEI-Nummer?"

  • Step 3

    • Close button in dialog windows (triggered by info icon)

  • Step 5

    • Close button in dialog window "Wo finde ich die Angaben?"

    • "Prüfen" button

  • Step 6

    • Select / Dropdown "Anrede"

    • Checkboxes

      • Focus state

      • Error state

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:

• Links

• Buttons

• Input elements (e.g. radio buttons)

• Accordion items

Form inputs in "Handyankauf" form Step 6 do not use appropriate autocomplete values.

• "PLZ" → "new-password"

• "Ort" → "new-password"

• "Straße" → "new-password"

• "Hausnr." → "new-password"

Some form inputs have autocomplete="off"

• (Anrede) – not using semantic HTML input element

• "Vorname"

• "Nachname"

• "E-Mail Adresse"

• "IBAN"

List in Handyankauf form does not use semantic HTML list element.

"Handyankauf" form step headings use control characters for line breaks.

<h2 class="...">
  "IMEI-Nummer "
  "Ihres"
  "iPhone 11"
  " mit "
  "128"
  "GB "
  " für Ihren Ankauf "
</h2>

Character codes are 000D, Carriage Return, \r & 000A, Line Feed, \n.

A screen reader announces this as follows:

Heading
IMEI-Nummer Ihres iPhone 11 mit 128GB für Ihren Ankauf
8 Items
You are currently on a Heading level 2
IMEI-Nummer, level 1
Ihres, level 1
Leerzeichen, level 1
iPhone 11, level 1
mit, level 1
128, level 1
GB, level 1
für Ihren Ankauf, level 1
End of Heading Level 2

Subsequent heading levels (e.g. right now the whole body copy text below this heading level 2 in step 2 is a heading with 9 items, including announced space characters) will further worsen the announcements as levels are going deeper.

The icons in "Zusammenfassung" list are hidden from assistive technology by using aria-hidden="true". The icons however are not decorative. The inform the user about the state of their answers from previous steps. As the icons are hidden, assistive technology announces the list items only.

"Handyankauf" form has explanation dialog windows in step 3 (triggered by info icon).

Images all use same alt text "Gerät Schäden".

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.

CAPTCHAs will always exclude user groups from accessing functionality of a page. Manually entered CAPTCHAs should always be avoided. If CAPTCHA is used, a text alternative must be presented so users of assistive technology can still access the functionality.

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".

FAQ section cannot be operated (expand / collapse) by assistive technology as the interactive elements are custom built and do not use correct semantic HTML. The FAQ accordion uses an HTML description list <dl>. Example code:

<dt class="accordion__term" data-accordion="term" tabindex="0">
  <h3 class="accordion__title">...</h3>
</dt>
<dd
  class="accordion__description accordion__description--hidden"
  data-open-class="accordion__description--open"
  data-hidden-class="accordion__description--hidden"
  data-accordion="description"
>
  <div class="accordion__content">
    <p class="paragraph">...</p>
  </div>
</dd>

Observations about the example code:

• Description lists consist of terms and descriptions. An FAQ question item can not be considered a term.

• Setting tabindex="0" to allow keyboard focus of non-interactive element is bad practice and should be avoided

• data-* attributes in description try to build accordion functionality

• <div class="accordion__content"> is an unnecessary hierarchy level

• A CSS paragraph class <p class="paragraph"> should not ever be needed

Manufacturer icons missing text alternative

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:

• Device images using generic device name instead of purpose equivalent text alternative; some text alternatives duplicate existing text content, some even name the wrong device

• "GreenMagenta"

• "Junger Mann mit Smartphone"

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

The visually presented heading structure of the page does not match the use of semantic HTML heading elements. The visually presented structure is as follows:

h1 Handy verkaufen, sparen, Ressourcen schonen
  h2 Der Telekom Handy-Ankauf: Jetzt altes Smartphone oder Handy verkaufen und die Umwelt schonen
    h3 Schnell
    h3 Sicher
    h3 Fair
  h2 Jetzt altes Smartphone verkaufen und von attraktiven Ankaufsaktionen profitieren
    h3 Welches Smartphone wollen Sie verkaufen?
    h3 <!-- MULTI STEP FORM HEADINGS -->
  h2 Unser nachhaltiger Smartphone-Kreislauf
    h3 Neugerät
    h3 Handyversicherung (Insure MyMobile)
    h3 Handyankauf
    h3 Neuwertige Handys (ReUse MyMobile)
    h3 Handyrücknahme im Shop
  h2 Helfen Sie uns, Ressourcen zu schonen und geben Sie uns Ihr altes Handy
    h3 Eignet sich das Smartphone nicht mehr für eine weitere Verwendung oder hat keinen Wert mehr?
    h3 Datensicheres Recycling
  h2 Häufig gestellte Fragen zum Thema Handy verkaufen
    h3 <!-- FAQ ITEMS -->

The programmatically determinable heading structure, using HTML heading elements is as follows:

h1 Der Telekom Handy-Ankauf: Jetzt altes Smartphone oder Handy verkaufen und die Umwelt schonen
  h2 Jetzt altes Smartphone verkaufen und von attraktiven Ankaufsaktionen profitieren

  <!-- MULTI STEP FORM WITH VARIOUS STEP HEADINGS-->
  h2 Welches Smartphone wollen Sie verkaufen?
    h3 Geben Sie den Namen Ihres Smartphones ein und wählen Sie es aus der Liste aus.
      h4 Bitte beantworten Sie vier kurze Fragen, damit wir ermitteln können, ob wir Ihr Gerät ankaufen und um Ihnen ein vorläufiges Angebot machen zu können.

  h2 Unser nachhaltiger Smartphone-Kreislauf
    h3 Neugerät
    h3 Handyversicherung (Insure MyMobile)
    h3 Handyankauf
    h3 Neuwertige Handys (ReUse MyMobile)
    h3 Handyrücknahme im Shop
  h2 Helfen Sie uns, Ressourcen zu schonen und geben Sie uns Ihr altes Handy
    h3 Eignet sich das Smartphone nicht mehr für eine weitere Verwendung oder hat keinen Wert mehr?
    h3 Datensicheres Recycling
  h2 Häufig gestellte Fragen zum Thema Handy verkaufen
    h3 <!-- FAQ ITEMS -->

Observations for heading structure:

• Main heading content not using HTML heading element

• "Schnell, Sicher, Fair" not using HTML heading element

• Multi Step Form does not use correct heading hierarchy throughout the form. When using multi step form, each step is treated as a page, and on each page, the hierarchy levels must fit the overall structure

Device color variants use CSS circles <span style="background:#...;" class="hardware-tile-lpg__color-selection-element"></span> without any text alternative present.