Page URL
https://www.telekom.de/start/magenta-tarife-young

Issues List

Non-text Content 1.1.1 (A)
Product image text alternative not purpose equivalent of image
Non-text Content 1.1.1 (A)
Image's text alternative does not accurately describe image's purpose
Info and Relationships 1.3.1 (A)
Heading structure
Info and Relationships 1.3.1 (A)
Semantic HTML elements are used for styling or layout purposes
Info and Relationships 1.3.1 (A)
Decorative text content is announced to assistive technology
Info and Relationships 1.3.1 (A)
List marker count announced twice
Non-text Contrast 1.4.11 (AA)
Buttons do not have enough contrast to background
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
Keyboard 2.1.1 (A)
Disabled button does not use disabled attribute
Page Titled 2.4.2 (A)
Page title states "Studententarife", page states "Für junge Leute unter 28"
Focus Order 2.4.3 (A)
User-activated dynamic content not in correct focus order
Link Purpose (In Context) 2.4.4 (A)
Link purpose not directly determinable
Headings and Labels 2.4.6 (AA)
Tariff card label not conveying card purpose
Headings and Labels 2.4.6 (AA)
Button label not accurately describing purpose
Focus Not Obscured (Minimum) 2.4.11 (AA)
Activated footnote dialog windows obscure element focus
Target Size (Minimum) 2.5.8 (AA)
Interactive element does not meet minimum target size
Name, Role, Value 4.1.2 (A)
Interactive element does not use correct semantic HTML
Name, Role, Value 4.1.2 (A)
Switch is not accessible to assistive technology
Name, Role, Value 4.1.2 (A)
Interactive element uses title attribute
Unrelated to Success Criteria / Best Practice
Inconsistent use of abbreviation element
Accompanying Files
Observation Details

Text content within stage spills over when text spacing is adjusted (increased).

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.

Observation Details

Opening a footnote dialog window can obscure underlying focused elements (partially AND completely). Since the footnote dialog window cannot be closed via ESC in that situation, the underlying element cannot be made visible without removing the keyboard focus from it.

Remediation Notes

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.

Remediation Notes

Ensure consistency of messaging throughout URL, page title, main heading, and actual page content.

Observation Details

The complete heading structure is hidden inside a collapsible, not at all representing the visually displayed outline.

Not a single heading is using semantic HTML heading elements and all semantic HTML heading elements are used on non-heading text.

Keep in mind, this "trick" might have worked in SEO years ago, but will de-rank the page in search engines. Accessibility will always be good for SEO.

Remediation Notes

The visually displayed heading structure MUST be represented by the programmatically determinable heading structure.

Observation Details

The link text "hier" does not convey the link's purpose on its own. The context (surrounding paragraph) does not convey the purpose either.

Remediation Notes

Use link text to convey the link's purpose. Clearly stating, where exactly a link goes, will help all users.

Accompanying Files
Observation Details

The streaming service logos are using "Telekom Young ..." text alternative. The images themselves however are simply service logos, having nothing to do with "Telekom Young".

Remediation Notes

Use appropriate, purpose equivalent text alternative on images. This can be "Logo Apple TV+", "Logo Disney+", ...

Accompanying Files
Observation Details

The product images of the smartphones use "Produktbild des ..." with the product's heading as their text alternative. While this may suffice for some images, it fails for others. The text alternative must serve an equivalent purpose to the image itself.

Remediation Notes

Describe the actual content of the image like "Samsung Galaxy S25 in Farbe XYZ". While this is not necessary for all, the screenshot example shows at least one product that will fail under this success criterion. The text alternative of the Google Pixel 9a must include not only the smartphone but also a mention of the headphones.

Ideally, these images are taken from the product detail pages, making it easy to also get a designated text alternative in programmatically. This text alternative should be set manually to ensure it being purpose equivalent.

Accompanying Files
Observation Details

Multiple line break elements found.


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

Remediation Notes

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

Observation Details

Button "Mehr anzeigen" in SEO content uses <a href="#"> instead of semantic button 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.

Remediation Notes

Ensure, only semantic button elements are used for button functionality. <a href=""><button>

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

Observation Details

The title attribute can be used to provide additional information to the already existing accessible name of an interactive element like a link. It should not be used for the same or less information. If the attribute does not provide additional information, it should not be used.

Some assistive technology do not announce the title at all, so providing relevant information only through the title attribute should always be prevented. If assistive technology announces the title attribute, it will do so after announcing the accessible name of the element, usually resulting in duplicate announcement of the same information.

For more information about using the title attribute to provide additional information, refer to W3C Technique H33: Supplementing link text with the title attribute.


Title attribute with same content as existing accessible name found on links:

  • "Gerät hinzufügen" in tariff cards

  • "Tarif ohne Gerät" in tariff cards

  • "Weiter zum XYZ" in product cards

Title attribute with different content but same information as existing accessible name found on links:

  • "Weiter zu XYZ" in "Weitere Young Vorteile" section

Remediation Notes

Observation Details

The switch "Mit Young-Streaming-Vorteil" can be operated by keyboard and assistive technology. Operating the switch by assistive technology has the following issues:

  • Off state is announced as "invalid data off" (using attribute aria-invalid="true")

  • Changes made to the following content are not announced; the user will not know of the changes

Remediation Notes

Remove aria-invalid="true" from the button element to allow for correct announcement of "on" and "off" states.

Announcing content changes that are happening on toggling the switch can be done in multiple ways. ARIA live regions are a ways to do so but are highly complex for the limited changes made. It is recommended to avoid ARIA use if possible (see First Rule of ARIA Use), so the easiest way would be:

  • Announce changes prior to toggle element, to make changes expected; this can be via a description text like "50 % mehr Datenvolumen bei Buchung einer Streaming-Option sichern. Klicke den Schalter 'Mit Young-Streaming-Vorteil' und das extra Datenvolumen wird in der Tarifliste angezeigt"; it also is possible to hide some of this via a visually-hidden CSS class, if necessary

Another option is to use the toggle element's accessible name and not simply providing the toggle label via the visible text but adding hidden text to it as well that could read "Young-Streaming-Vorteil einschalten und extra Datenvolumen in der Tarifliste anzeigen lassen". It is important to notice, that the visible label must be changed to "Young-Streaming-Vorteil" to not fail 2.5.3 Label in Name, though.

Observation Details

The HTML abbreviation element is used inconsistently. E.g. used on "mtl." but not on "zzgl." in the same paragraph.

<p class="...">
  zzgl. <abbr title="monatlich">mtl.</abbr> Kosten der Streaming-Option
</p>

It also isn't used at all for other paragraphs:

<p class="Stage_Stage__subtitle30jahre__ZAtNI CopyText__copy-text___78uN4">
  ... 
  inkl. 100 GB für nur 34,95 € mtl.
  ...
</p>
Remediation Notes

It is best practice to follow a consistent rule of when to use abbreviation elements to allow for a consistent user experience:

  • Not at all (ideally combine with using less or no abbreviations at all)

  • All the time (most consistent)

  • Once for the first instance of the abbreviated phrase

Observation Details

The tariff cards in section "Young-Smartphone-Tarife" are labeled "Slide X von 4", providing no information about the card's contents. The content itself then starts with "S", "40", "GB", "+ 20 GB mit Young-Streaming-Vorteil".

The actual tariff name is not stated in the section at all.

Remediation Notes

Using the HTML article element for the cards is recommended. As it already uses the article element, the surrounding <div> can be removed or stripped of its ARIA attributes.

The card's first content element should be a heading that describes the card's content in total. This can be the tariff name for a low effort solution.

Ideally, this will be the tariff name or a combination of the most important information, like tariff name, GB count, and maybe even price, all of which should be done by existing content:

<article aria-labelledby="s-heading s-data s-price-offer">
  <h3 id="s-heading">MagentaMobil S</h3>
  <p id="s-data">40 <abbr title="Gigabyte">GB</abbr></p>
  <p>+ 20 GB mit Young-Streaming-Vorteil</p>

  ...

  <dl>
    <!-- Price information -->
    <dt>Ursprünglicher Preis</dt>
    <dd>statt <s>29,95 €</s> <abbr title="monatlich">mtl.</abbr></dd>

    <dt>Angebotspreis</dt>
    <dd id="s-price-offer">19,95 € <abbr title="monatlich">mtl.</abbr></dd>
  </dl>

  ...
</article

This way, a user of assistive technology will get announced "MagentaMobil S. 40 Gigabyte. 19,95 € monatlich." when the article receives focus. The user than may navigate between articles in the section without moving into or through each card but still getting the most relevant data.

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

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 decorative text content:

  • Young Tarif | Streaming-Vorteil | Young Tarif | Streaming-Vorteil | Young Tarif | Streaming-Vorteil | Young Tarif | Streaming-Vorteil |

Is announced to assistive technology as

  • Young Tarif vertical bar Streaming-Vorteil vertical bar Young Tarif vertical bar Streaming-Vorteil vertical bar Young Tarif vertical bar Streaming-Vorteil vertical bar Young Tarif vertical bar Streaming-Vorteil vertical bar

Remediation Notes

If the information, provided in text content, is already provided in the preceding content, the decorative text content should be hidden from assistive technology e.g. by using aria-hidden="true".

A role="presentation", while useful in other situations, would not have the intended effect in the given situation, as it only removes the semantics from the element. As the content uses <div><span>...</span></div> there is no removable semantics.

Observation Details

Disabled navigation arrow buttons in "Young Smartphone Angebote" product carousel does not use HTML attribute disabled but only aria-disabled="true". While this results in correct "dimmed" announcement to assistive technology, keyboard navigation still allows focusing the button without providing information about its disabled state.

Observation Details

Carousel navigation buttons have labels:

  • Zurück (if disabled)

  • Gehe zurück auf Slide X von 6

  • Gehe vor auf Slide X von 6

Carousel pagination buttons have labels:

  • Zeige Slide X von 6

Observations:

  • Definition of "slide" is vague when showing product cards

  • Carousel shows X slides at a time, moving "by slide" is not ideal

  • Pagination says "X von 6" but on largest viewport only showing 3 pagination buttons

Remediation Notes

Ensure, button labels provide accurate information about button purpose. If button action is "show slide 1 of 3" but label is "show slide 1 of 6", users of assistive technology can get confused.

Possible improvements:

  • Use product names instead of generic slide numbers (e.g. "Show iphone 16e, iphone 16, Samsung Galaxy S25")

  • Use slide ranges instead of navigating "by slide" (e.g. "show slide 1-4 of 6")

Accompanying Files
Observation Details

Carousel navigation and pagination buttons do not meet minimum color contrast ratio (3:1):

  • Navigation arrows: 2:1

  • Pagination dots (grey): 1.5:1

(Navigation arrow disabled has 1.4:1 ratio, which is not a failure of this criterion if the button is disabled to all users properly)

Remediation Notes

Ensure minimum color contrast ratio for all interactive elements is 3:1 or higher.

  • The easiest way to achieving this is to provide a high enough contrast outline or border that meets contrast ratio minimum.

  • Ideally the element's color itself would meet contrast ratio minimum.

Accompanying Files
Observation Details

The ordered list in dialog window "So einfach bekommst Du den Vorteil" uses "custom list markers" with CSS content: counter(magenta-counter).

List items in semantic HTML lists are automatically numbered and the count is announced by assistive technology by default. Adding a separate count as accessible content via CSS content results in duplication of count announcement.

Remediation Notes

Ideally, remove custom counter content and use semantic HTML elements without modification to keep correct announcement for assistive technology.

If customization is obligatory, use the custom marker on the actual ::marker instead of removing it and providing custom content in ::after. For more information about this, refer to W3C – CSS Lists and Counters.