Page URL
https://www.telekom.de/unterwegs/vertragsverlaengerung

Issues List

Non-text Content 1.1.1 (A)
Image text alternative does not serve equivalent purpose
Non-text Content 1.1.1 (A)
Image text alternative does not serve equivalent purpose
Non-text Content 1.1.1 (A)
Image is decorative but has text alternative
Info and Relationships 1.3.1 (A)
Visual presentation of heading structure does not match code markup
Meaningful Sequence 1.3.2 (A)
Step by Step Guide not using correct sequence
Use of Color 1.4.1 (A)
FAQ focus state does not have enough contrast
Use of Color 1.4.1 (A)
Magenta button's keyboard focus does not have enough contrast
Use of Color 1.4.1 (A)
Links in body copy are indicated by color only
Contrast (Minimum) 1.4.3 (AA)
White text on (light) Magenta background barely reaches contrast minimum
Reflow 1.4.10 (AA)
"Frag Magenta" popup flows out of viewport
Non-text Contrast 1.4.11 (AA)
Product color option does not have enough color contrast
Non-text Contrast 1.4.11 (AA)
Interactive element does not have enough color contrast
Text Spacing 1.4.12 (AA)
Changing text spacing lets parts of text spill out of their containers
Keyboard 2.1.1 (A)
Footnote dialog window does not receive keyboard focus on open
Page Titled 2.4.2 (A)
Page title not optimal
Focus Order 2.4.3 (A)
User-activated dynamic content not in correct focus order
Focus Order 2.4.3 (A)
Closing dialog does not set the right focus
Focus Order 2.4.3 (A)
Content of hidden accordion area is keyboard focusable
Link Purpose (In Context) 2.4.4 (A)
Link purpose of product tiles not determined by accessible name
Focus Visible 2.4.7 (AA)
Element's focused state is not visible
Focus Not Obscured (Minimum) 2.4.11 (AA)
Dialog windows obscure focus of underlying elements
Label in Name 2.5.3 (A)
Discrepancy of Label and Accessible Name
Target Size (Minimum) 2.5.8 (AA)
Interactive element does not meet minimum target size
Language of Page 3.1.1 (A)
Country specific language "de-DE" might not be necessary
Name, Role, Value 4.1.2 (A)
Interactive element uses non-semantic HTML
Name, Role, Value 4.1.2 (A)
Button uses HTML link element
Name, Role, Value 4.1.2 (A)
Accordion not using semantic HTML
Accompanying Files
Observation Details

The accessible name of product tiles is set within a <span> inside the <a> tag.

<a ...><span ...>Galaxy S25 Ultra</span></a>

The accessible name does not include the manufacturer's name but only the product's model name. While for a Samsung Galaxy S25 Ultra in the context of the Telekom website, the model name might be enough to identify the link's purpose, it will fall apart on devices like the Xiaomi 15 Ultra.

Generally, the assumption of a user's knowledge should not be made, making it hard even for devices like (Samsung) Galaxy S25 Ultra or (Google) Pixel 9a.

Remediation Notes

Setting the accessible name of the product tile link to the span.A11yText__a11y__XYZ is a viable option but it should be using the product's manufacturer and model name.

A better approach would be to use aria-labelledby, using the existing visible text. To follow this approach, the manufacturer and model name must have an id attribute set. The product tile link could then follow a structure like this:

<a href="..." aria-labelledby="product__manufacturer__X product__model__X">
  <h3>
    <span id="product__manufacturer__X">
    <span id="product__model__X">
  </h3>
  ...
</a>
Observation Details

Dialog windows "So verlängern Sie Ihren Vertrag" and "So wechseln Sie Ihren Tarif" can be opened and closed via keyboard navigation. Closing the dialog window does not set the focus to the right element.

Closing a dialog window must reset the focus to the previously focused element that was used to open the dialog window.

Remediation Notes

On closing a dialog window, the keyboard focus must be set to the element that previously opened the dialog window.

A better approach would be, using the <dialog> element.

Observation Details

When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:

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

  • The dialog window can not be closed with the 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.

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

Remediation Notes

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.

Accompanying Files
Observation Details

Content, including interactive elements, in hidden accordion areas are reachable via keyboard navigation.

Using TAB / SHIFT + TAB, links in collapsed accordion items can be reached. See the attached screenshot for a focus order visualization.

Remediation Notes

Hidden areas and their contents must not receive keyboard focus. If using ARIA attributes to extend accessibility for the accordion and aria-hidden="true" is used on collapsed accordion items, ensure also using display: none; in CSS styles for said collapsed accordion items as well.

Evaluate the use of <detail> + <summary> constructs to build a more accessible base-line accordion.

Accompanying Files
Observation Details

Links are only differentiated from normal body text (black, rgb(38, 38, 38)) by use of color (blue, rgb(0, 115, 159)).

In addition, the contrast ratio of link text color and body text color also is insufficient (2.8:1 < 3:1).

Remediation Notes

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.

Priority: Best Practice Unknown Page: Vertragsverlängerung Observation Permalink
Accompanying Files
Observation Details

The contrast ratio of white text on (light) Magenta background barely hits 4.5:1 target. As the white is absolute white, the upper limit is fixed. If it can be ensured, that the background Magenta is the lightest the Magenta can be, there is no issue. If a lighter Magenta could be possibly be used, a failure might arise.

Accompanying Files
Observation Details

The "Frag Magenta" chat bubble, when popping up on its own, flows out of viewport at 320px viewport width. Horizontal scrolling is not possible, making parts of the popup unreachable.

Remediation Notes

Either disable functionality to automatically popup the chat bubble or ensure reflow on it as well. The popup must not leave the viewport and its contents must reflow to be reachable even on 320px viewport width.

Accompanying Files
Observation Details

Some text, when text spacing is changed, spills out of its parent containers, making some text hard, other text impossible to read. This includes:

  • Stage

  • Badges

  • Footnotes

  • Teaser

Remediation Notes

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

Priority: Best Practice Unknown Page: Vertragsverlängerung Observation Permalink
Observation Details

The page title is "Vertragsverlängerung für Mobilfunkkunden | Telekom". While no failure of the success criterion, improvements are possible:

  • Page part "Vertragsverlängerung für Mobilfunkkunden" does not directly match the main page heading; if e.g. there is another "Vertragsverlängerung für ..." for something else, this should also be reflected in the main page heading

  • The vertical bar "|" sometimes is announced by assistive technology as "vertical bar"; using other symbols, usually not announced, could improve the page title even more

Remediation Notes

Replacing the vertical bar with a character, usually not announced by a screen reader. E.g.:

  • , – comma

  • … – ellipses typed as &#8230;

  • › – caret written as &#8250;

Observation Details

Keyboard focus of Magenta button changes background color. Difference between default and focused state does not meet minimum contrast ratio (3:1). Instead, the difference is barely visible at 1.1:1.

Remediation Notes

Ensure enough contrast (3:1) between different button states (default, focused, active, ...).

Accompanying Files
Observation Details

Focusing an FAQ item via keyboard changes its background color. The color difference alone is not enough to visually indicate a focus state. The color difference must meet a 3:1 contrast ratio.

Remediation Notes

Ensure, meeting the 3:1 minimum contrast ratio from unfocused to focused state.

Better: Do not rely solely on color to indicate the focus state. You can do so by adding visible outline to focused interactive elements.

Accompanying Files
Observation Details

The product tiles are complicated card components with a lot of content. The surrounding link, using <a>, uses the product's model name as its accessible name. (e.g. "Galaxy A56" or "15 Ultra")

Assistive technology like voice control software uses the accessible name to control interactive elements. By stating the accessible name, I can activate the element. To activate the product tile link I must state the product's model name (e.g. "Galaxy A56" or "15 Ultra"). As there is no indication of this part of the tile's content being "the clickable link", a user of voice control software will not be able to navigate the product tiles.

Remediation Notes

The visible label must be the (or part of the) accessible name of an interactive element. In a card component this means, there should be an element inside that is visually identifiable as an interactive element (e.g. a link or a button) that then is labeled as such to match the accessible name.

The product tile as is cannot be made accessible in that effect, as the "visible label" would be the full text content of the tile. The tile should include a visible link or button that could be labeled by "Manufacturer + Model" (i.e. "Samsung Galaxy A56" or "Xiaomi 15 Ultra").

Observation Details

The page uses lang="de-DE" on the <html> element. The specification of the country "DE" might not be necessary. While most assistive technology can fallback to the primary language tag "de" if a different secondary language tag is used on the user's system, removing the secondary tag might be an even more robust implementation.

Remediation Notes

If specifying the country is not necessary, removing it, leaving the primary language tag, is an option.

Priority: Best Practice Medium Page: Vertragsverlängerung Observation Permalink
Observation Details

Accordions (e.g. FAQ) are built with <div> and ARIA attributes. While the implementation meets the current success criterion, it introduces problems (or possible problems) in other success criteria. E.g. hidden links being focusable by keyboard, while being successfully hidden from screen readers. These discrepancies and problems can be avoided, using semantic HTML.

Remediation Notes

For accordions, evaluate the use of <detail> & <summary> elements.

Observation Details

Footnote trigger (star icon) does not meet minimum target size.

Interactive elements must have a target size of at least 24×24px. Minimum target size is required also for single icon buttons, stand-alone interactive icons and links. When target size is smaller, it will make it difficult for people to reliably interact with the elements. This includes people with motor disabilities, people using devices like styluses, people in moving vehicles, and mobile users altogether. Especially considering its use inside other interactive elements (e.g. footnote in badge) or multiple small interactive elements next to each other (e.g. social icons in a list).

Remediation Notes

Ensure, all interactive elements' target size is at least 24×24px.

While this does not necessarily mean, e.g. an icon itself must be 24×24px, the clickable area around it counts as the target size, if there is no overlapping interactive element in that area. Ideally, the element's visual boundaries adhere to the minimum target size of 24×24px itself.

Observation Details

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 may be triggered by:

  • Footnotes

  • Info Icons

  • Buttons

Remediation Notes

When opened,

  • dialog windows must receive keyboard focus and

  • keyboard focus must be trapped inside the dialog window.

Ensuring placed and trapped keyboard focus to the opened dialog window will remediate this issue, as no interactive element outside of the opened dialog window should be focusable, thus cannot be focus obscured.

For more information about technical requirements of modal dialogs, refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Modal Dialog". Also, consider/evaluate use of HTML dialog element <dialgo>. See HTML specifications – The dialog element and Can I Use – Dialog for browser support information.

Observation Details

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.

Focussing a product tile by keyboard navigation does not visually indicate the tile being focused. This makes it incredibly difficult to navigate the page with a keyboard.

Remediation Notes

Ensure product tiles (and all other focusable elements) have visual focus states that differ enough from the default states. Keep in mind to adhere to success criterion 1.4.1 and ensure, when only using color to indicate a focus state, that the color difference must be 3:1 or higher.

Ensure, all focusable elements have a visible focus indicator.

  • The focus indicator should ideally be clearly visible

  • The focus indicator should not solely rely on change of color (see 1.4.1 Use of Color)

  • The focus indicator should not create contrast issues of focused text content (see 1.4.3 Contrast (Minimum))

  • The browser's native focus indicator can be used if it itself passes contrast minimum requirements to the element's background (see 1.4.11 Non-text Contrast).

Accompanying Files
Observation Details

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:

  • MagentaEins Vorteil

  • Apple und Telekom im besten Netz

Remediation Notes

Ensure purpose equivalent text alternatives are present for every non-decorative image. Depending on the purpose, the text alternative may be describing the contents of an image or the functionality it serves (e.g. as a link to a specific page).

When the image shows informational content, it must set an alt attribute that serves the equivalent purpose. This arguably is the case for images of devices. In that case, the description of the device must be set. E.g. "Apple iPhone 15 Pro in silber und Apple iPhone 15 in blau. Jeweils mit Vorder- und Rückseite".

Accompanying Files
Observation Details

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

Remediation Notes

Ensure, all purely decorative images are not accessible by assistive technology. Depending on the way, in image is embedded, the following methods can be used to remove it from the accessibility tree:

  • HTML image element: Set a null alt attribute as follows: <img alt="" />; do not use ARIA to hide the HTML image element

  • HTML SVG element: Remove the SVGs <title> element or keep it empty and use ARIA to explicitly hide the element to ensure highest compatibility across browsers and assistive technology: <svg aria-hidden="true">

Accompanying Files
Observation Details

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

1 Vertrag verlängern
  2 Vertrag verlängern
  2 Tarif wechseln
  2 Top-Smartphones zum Spitzenpreis
    3 Samsung Galaxy S25 Ultra
    3 ...
  2 MagentaEINS-Vorteil
  2 Apple und Telekom im besten Netz
  2 Unser Dankeschön für Sie:
  2 Sie möchten eine persönliche Beratung?
    3 Telekom Shops in Ihrer Nähe
    3 Magenta Service Live
  2 Häufig gestellte Fragen rund um die Telekom Vertragsverlängerung
    3 Sie möchten Ihren Mobilfunktarif wechseln?
    3 ...

The programmatically determinable heading structure, using HTML heading elements is limited to the FAQ section.

Observations for heading structure:

  • The main heading "Vertrag verlängern" is not using an <h1> element.

  • The <h1> element instead is used on the FAQ section at the end of the page.

  • Headings do not use semantic HTML elements (<h1>, <h2>, <h3>, ...). They are using more generic (<span>) or even wrong (<p>) HTML elements and add CSS classes to style them so they look like headings.

  • "Vertrag verlängern" heading is duplicated

  • "Vertrag verlängern" & "Tarif wechseln" are presented as a group of headings but do not have a parent heading to group them

  • "MagentaEINS-Vorteil" & "Apple und Telekom im besten Netz" are presented as a group of headings but do not have a parent heading to group them

  • The sections "Top-Smartphones zum Spitzenpreis", "MagentaEINS-Vorteil" & "Apple und Telekom im besten Netz", "Unser Dankeschön für Sie:" do not show their relevance to the page's topic and do not fit the general outline of the page as they function as a group but are not grouped

  • ("Unser Dankeschön für Sie:" uses a colon ":"; best practice is to not use punctuation (except "!" and "?") in headings. If the use of punctuation is necessary, there probably is an issue with either styling or outline structure)

Remediation Notes

Ensure, visually presented heading structure matches programmatically determinable heading structure by only using HTML heading elements for heading content and using HTML heading elements for all heading content.

Taking the presented headings and building a better outline could look like this:

1 Vertrag verlängern
  2 Was möchten Sie tun?
    3 Vertrag verlängern
    3 Tarif wechseln
  2 Ihre Vorteile bei einer Vertragsverlängerung
    3 Top-Smartphones zum Spitzenpreis
      4 Samsung Galaxy S25 Ultra
      4 ...
    3 MagentaEINS-Vorteil
    3 Apple und Telekom im besten Netz
    3 Unser Dankeschön für Sie:
  2 Sie möchten eine persönliche Beratung?
    3 Telekom Shops in Ihrer Nähe
    3 Magenta Service Live
  2 Häufig gestellte Fragen rund um die Telekom Vertragsverlängerung
    3 Sie möchten Ihren Mobilfunktarif wechseln?
    3 ...

This creates a good, scannable base outline of the page, representing the most important sections and grouping existing content within this structure:

  2 Was möchten Sie tun?
  2 Ihre Vorteile bei einer Vertragsverlängerung
  2 Sie möchten eine persönliche Beratung?
  2 Häufig gestellte Fragen rund um die Telekom Vertragsverlängerung

Side note: This criterion does not specifically look at proper heading content (i.e. wordings, usefulness of headings). See 2.4.6 Headings and Labels for this.

Accompanying Files
Observation Details

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:

  • Smartphone images use device name as text alternative, not describing the actual contents, nor the purpose of the image

  • Text alternative duplicates existing text content

Remediation Notes

Ensure purpose equivalent text alternatives are present for every non-decorative image. Depending on the purpose, the text alternative may be describing the contents of an image or the functionality it serves (e.g. as a link to a specific page).

The smartphone images need to be described properly. The text alternative must be equivalent to the images' purpose and must not duplicate existing text content.

Observation Details

The display of a product's color options is not using high enough contrast.

As the information conveyed is necessary to understand the content, the color contrast ratio must be at least 3:1. Some color options barely reach color contrast ratio of 1.1:1.

Please note: This observation describes one example product with example color option(s). This observation spans multiple products.

Remediation Notes

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.

Please note: Ensure, all color options meet required minimum contrast ratio. It is not recommended, trying remediation of single color options individually.

Observation Details

Footnote dialog window is not keyboard accessible.


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.

Remediation Notes

Ensure, for all dynamically added content that can be activated by user,

  • focus cannot be set to focusable elements inside content, before content is being visually added (e.g. collapsed accordion items, or not yet opened dialog windows)

  • dynamic content should be placed directly below the triggering element in the DOM order

  • Opening e.g. a dialog window, will set the focus on the first focusable element inside the dialog window

  • Activating a "Load more" button must ensure, focus, after content is loaded, either

    • is set to the first focusable element of newly loaded content or

    • is set to the first preceding focusable element of newly loaded content.

Ensure, for all dynamically added and then removed content that can be activated by user,

  • keyboard focus

    • remains (e.g. collapsing/expanding accordion items) on the triggering element or

    • is set to (e.g. opening and closing a dialog window) the triggering element again.

Accompanying Files
Observation Details

The items in the step by step "Vertrag verlängern – so funktioniert's" (and "Tarif wechseln – so funktioniert's") dialog window are announced by assistive technology in the order shown in the attached screenshot. The number icon items are announced separately after the other items.

Observation Details

The buttons to open "Vertrag verlängern" and "Tarif wechseln" guide dialog windows use <a href="#"> instead of HTML button elements. The announcement of "link" in assistive technology will imply, moving to a different resource, may it be a different page or document. All performed actions, like opening and closing dialog windows, must use HTML button elements.

Accompanying Files
Observation Details

Pagination buttons below product carousel use non-semantic elements instead of semantic HTML button elements. Role / functionality of buttons is not correctly conveyed to assistive technology.


All interactive elements that do not use native, 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 non-semantic 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.

Remediation Notes

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.

Observation Details

Interactive element –pagination button below product carousel– does not have high enough color contrast ratio to its background.

Remediation Notes

For interactive elements (non-text), ensure a color contrast ratio of at least 3:1 to its background.