Page URL
https://www.telekom.de/netz/mobilfunk-netzausbau

Issues List

Non-text Content 1.1.1 (A)
Image does not have purpose equivalent text alternative
Non-text Content 1.1.1 (A)
Image does not have purpose equivalent text alternative
Non-text Content 1.1.1 (A)
Decorative images have alt attribute set
Non-text Content 1.1.1 (A)
Decorative images have alt attribute set
Non-text Content 1.1.1 (A)
Decorative images have alt attribute set
Info and Relationships 1.3.1 (A)
Improper use of semantic HTML list elements
Info and Relationships 1.3.1 (A)
Heading uses emphasis
Info and Relationships 1.3.1 (A)
Semantic HTML elements are used for styling or layout purposes
Identify Input Purpose 1.3.5 (AA)
Address input has autocomplete turned off
Use of Color 1.4.1 (A)
Links in body copy are indicated by color only
Use of Color 1.4.1 (A)
Map layers solely rely on color difference
Use of Color 1.4.1 (A)
FAQ focus state does not have enough contrast
Contrast (Minimum) 1.4.3 (AA)
Text on image does not meet contrast ratio minimum
Resize text 1.4.4 (AA)
Map not accessible with enlarged text
Reflow 1.4.10 (AA)
Map not accessible on small viewport
Non-text Contrast 1.4.11 (AA)
Map layers' color difference not meeting minimum contrast
Text Spacing 1.4.12 (AA)
Changing text spacing leads to text content flowing out of container
Keyboard 2.1.1 (A)
Footnote dialog window does not receive keyboard focus on open
Keyboard 2.1.1 (A)
"Info" dialog window does not trap keyboard focus on open
Page Titled 2.4.2 (A)
Page titled "5G Netzabdeckung: Stand des Netzausbaus" but map includes Mobilfunk, Festnetz and Hotspot
Link Purpose (In Context) 2.4.4 (A)
Link purpose "Mehr erfahren" not determinable
Link Purpose (In Context) 2.4.4 (A)
Link purpose in "Tarife" carousel not determinable
Headings and Labels 2.4.6 (AA)
Heading structure / outline not describing content
Focus Not Obscured (Minimum) 2.4.11 (AA)
Activated dialog window (footnotes) obscure element focus
Pointer Gestures 2.5.1 (A)
Map navigation not accessible by single pointer events
Pointer Gestures 2.5.1 (A)
Map navigation not accessible by single pointer events
Target Size (Minimum) 2.5.8 (AA)
Interactive element does not meet minimum target size
On Input 3.2.2 (A)
Choosing a dropdown in the map changes map content
Error Identification 3.3.1 (A)
Entering non-existent address to address input results in error which is not correctly determinable
Labels or Instructions 3.3.2 (A)
Address input element has no visible label
Name, Role, Value 4.1.2 (A)
Interactive element does not use correct semantic HTML
Observation Details

While further page content is 5G specific, the interactive map includes Mobilfunk, Festnetz, and Hotspots. Adding more content is not a failure of the success criterion, so the criterion still is marked as passed. There could be however a more fitting title for the page.

Remediation Notes

Observation Details

Opening a footnote dialog window can obscure underlying focused elements (partially AND completely).

Since the 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

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. This will remediate the obscuring of focused elements.

Priority: Moderate Significant Page: Mobilfunk Netzausbau Observation Permalink
Accompanying Files
Observation Details

Operating the interactive map, the default on page load is an activated accordion item "Mobilfunknetz" in which are three checkboxes (2G, 4G, 5G). It looks like it functions as a "Multiple Selection List". For reference, see BFIT-Bund Handreichung "Accessible design of user interface elements – Multiple Selection List".

When selecting and activating another accordion item, the map's context changes to that item's content, meaning when "Festnetz" item is activated, the Mobilfunknetz content is removed from the map. As the "dropdown" / accordion item itself should not have functionality to change content, but the interactive elements in it should, activating the "dropdown" evokes an unexpected context change. On a page about 5G Mobilfunknetz / Netzausbau, moving to a "Festnetz" map is considered unexpected behaviour.

Remediation Notes

Remediation of this issue might take significant effort. Ideally, the use of more fitting interactive elements helps users to navigate the options in a more predictable way. If "Mobilfunknetz", "Festnetz", and "HotSpot" are exclusive options, using a fitting component, like a singular selection list, a dropdown, or radio button group, would identify the interactive element right away.

There are a few easier ways to remediate but not without potentially "removing" content.

  • Removing Festnetz & HotSpot options from the map

  • Announcing change of context to make it an expected change, which then would not be considered a failure; this could be done by giving the accordion item button an accessible name of "Nur Festnetzausbau anzeigen"

Accompanying Files
Observation Details

The interactive map is not accessible on small viewport of 320px viewport width. The contents do not reflow responsively, so certain functionality cannot be reached.

Observation Details

The interactive map is not accessible on when page zoom is set to 200 %. The contents do not reflow responsively, so certain functionality cannot be reached.

Accompanying Files
Observation Details

Accessible name: "Telekom Netzausbau Bühne", content: "T 5G". Text alternative does not serve the same purpose as the image.

Remediation Notes

All non-decorative images must have a purpose equivalent text alternative.

All decorative images must be hidden from assistive technology (e.g. by providing a null alt attribute: <img alt="" />).

Accompanying Files
Observation Details

Accessible name: "Deutsche Funkturm - 5G Ausbau Funkmasten", content is image of 5G Funkmasten. Text alternative does not serve the same purpose as the image. Neither "Deutsche Funkturm", nor the aspect of "Ausbau" are part of the image. The image's text alternative must not include information that is not actually part of the image.

Remediation Notes

All non-decorative images must have a purpose equivalent text alternative.

All decorative images must be hidden from assistive technology (e.g. by providing a null alt attribute: <img alt="" />).

Accompanying Files
Observation Details

Accessible name: "Icon XYZ", content is decorative icon. Decorative icons must be hidden from assistive technology.

Remediation Notes

All decorative images must be hidden from assistive technology (e.g. by providing a null alt attribute: <img alt="" />).

Accompanying Files
Observation Details

Accessible name: "Telekom Netz / Mobilfunk", content is decorative icon / checkmark icon. Decorative icons must be hidden from assistive technology.

Remediation Notes

All decorative images must be hidden from assistive technology (e.g. by providing a null alt attribute: <img alt="" />).

Accompanying Files
Observation Details

Accessible name: "Abstand", content is empty, used as layout graphic / spacer. Decorative icons must be hidden from assistive technology.

Remediation Notes

All decorative images must be hidden from assistive technology (e.g. by providing a null alt attribute: <img alt="" />).

Side note: do not use graphics for layout purposes at all. Please (also) refer to observation 1.3.1 Info and Relationships – "Semantic HTML" for general remarks about the use of semantic HTML.

Accompanying Files
Observation Details

Autocompletion in address input is turned off and overwritten by aria-autocomplete="both". Input purpose cannot be identified programmatically this way. Input marked up as follows:

<input
  data-coin-che6yj=""
  data-v-36713002=""
  class=""
  placeholder="Adresse oder Koordinate"
  maxlength="200"
  title="Suche nach Adressen und Koordinaten"
  aria-expanded="false"
  aria-labelledby="autocomplete-list"
  aria-autocomplete="both"
  aria-controls="autocomplete-list"
  autocomplete="off"
  role="combobox"
  data-qa="input-autocomplete_value"
/>

The aria-autocomplete attribute is not a valid replacement to the HTML autocomplete attribute, as accessibility support is basically non-existent for most operating system and screen reader combinations. See Accessibility Support – aria-autocomplete attribute for further information about accessibility support.

Remediation Notes

Ensure, turning on autocompletion for all input elements that ask for user data. In this case, a user's address. The autocomplete attribute's value must be mapped to one of the W3C – Input Purposes for User Interface Components. For further reference, see MDN – HTML attribute: autocomplete.

Full street addresses are usually set to multi-line input using autocomplete="street-address".

Accompanying Files
Observation Details

Links are only differentiated from normal body text (black, #383838) by use of color (blue, #00739f). In addition, the contrast ratio of link text color and body text color also is insufficient (2.2:1 < 3:1).

Links can be found, e.g. as

  • "Handyverträgen" in section "Wissenswertes rund um den Netzausbau"

  • "5G-Netz" in section "Bleiben Sie auf dem neuesten Stand"

  • various links in FAQ section "Welches Smartphone ist 5G-fähig?"

  • Additionally, not quite fitting this success criterion but an accessibility issue anyway is the link "Deutschen Funkturm" in section "Helfen Sie dabei unser 5G-Netz noch größer zu machen!". This link does not even use any color difference (contrast ratio 1:1). The link is not visually identifiable at all. (see attached screenshot)

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.

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. Currently it is barely visible at 1.2:1

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

Main heading "Telekom Mobilfunk-Netzausbau" is set on background image. Text content set on background, no matter if color, gradient, or image, must meet minimum contrast ratio at all times. Ideally this is checked by taking the text color (rgb(255, 255, 255)) and measuring against similar color in the image (rgb(230, 223, 229)). This results in a contrast ratio of 1.3:1, far below the minimum of 3:1 for large text (and 4.5:1 for normal text).

Remediation Notes

Ensure, all text content meets minimum contrast ratio against its background.

Ideally, do not set text content onto background image unless it is robustly built, so that the closest color of background still meets minimum contrast ratio requirements.

Accompanying Files
Observation Details

Options in map layers rely on color alone to be identified. Doing so, while not meeting contrast ratio minimum (3:1) is an accessibility issue.

Remediation Notes

Preferably another mechanism, additionally to color, is used to differentiate the option layers.

This can be icons or forms (like "Schraffur") for both the "dot" in the options menu and the actual map part.

This could also be an outline that meets color contrast minimums for all color combinations. This must be set so that all polygons in the map are using the outline.

Priority: Critical Significant Page: Mobilfunk Netzausbau Observation Permalink
Accompanying Files
Observation Details

Options in map layers rely on color alone to be identified. Doing so, while not meeting contrast ratio minimum (3:1) is an accessibility issue.

Remediation Notes

Preferably another mechanism, additionally to color, is used to differentiate the option layers. See observation for 1.4.1 Use of Color for more information about this. Ideally, remediation of both criteria is done at the same time.

To remediate 1.4.11 on its own, ensure all used layer colors meet minimum contrast ratio of 3:1 to all other layer colors, and to the default background color(s). This is a lot harder to do, as the map base layer can even switch to satellite view which adds more background colors to it. Thus, remediating 1.4.11 Non-text Contrast and 1.4.1 Use of Color together is the preferred method.

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

When opening the "Info" dialog window in the interactive map, the keyboard focus is not trapped in said dialog window. This leads to these observations:

  • The non-interactive contents of the dialog window are not accessible via keyboard (scrolling should be available with ARROW keys).

  • Keyboard navigation out of the dialog window is possible. This can be the desired way and on its own is no failure of this criterion, as moving out of the dialog window while open, will move the focus out of the map completely, thus not interfering with other content.

Remediation Notes

Opening a dialog window with the keyboard sets the focus into the dialog window and traps it within the map component but not the whole page. This means, scrolling inside the dialog window is not possible with ARROW keys. Ensure, next to TAB for navigating interactive elements, ARROW keys can be used for navigating non-interactively (scrolling text content) within the dialog window.

Accompanying Files
Observation Details

The purpose for "Mehr erfahren" link in section "Helfen Sie dabei unser 5G-Netz noch größer zu machen!" is not easily programmatically determinable. The link on its own uses accessible name "Mehr erfahren", it has no directly surrounding text (paragraph), and the parent heading does not identify the link's purpose correctly.

Purpose can be determined by reading the full section from heading to link. This however cannot be declared "context".

Remediation Notes

Possible remediation options in order from preferred:

  1. Use purposeful button text like "Immobilie oder Grundstück zur Vermietung anbieten", which in context with the heading determines the purpose

  2. Rewrite the heading to identify section's purpose like "Vermieten Sie an uns und helfen Sie uns, das 5G-Netz noch größer zu machen", which again in context lets the link purpose be determined

  3. Any combination of heading and button text rewrite

What is not preferred is to use ARIA, when there is a non-ARIA way to do so. If above-mentioned options cannot be used, the use of aria-labelledby is another option. Usually this is done by labelling the button by referring to the headings id. In this case this will not work without rewriting the heading anyways and as such is not a viable option. The way for aria-labelledby to work in this situation would be to add a hidden (class="visually-hidden") text that makes the link's purpose determinable. This comes with the caveat that the visual link text ("Mehr erfahren") must be part (and ideally the first part) of the accessible name (See 2.5.3 Label in Name).

Accompanying Files
Observation Details

HTML markup for links in "Tarife" carousel (showing one as an example):

<a
  href="/unterwegs/handyvertrag"
  id=""
  title=""
  class="..."
  target="_self"
  data-tealium-rel="..."
  onclick=""
>
  <div class="...">
    <div class="...">
      <div class="...">
        <img
          src="/resources/images/594932/telekom-smartphone-tarife.jpg"
          alt="Icon Smartphone"
          title=""
          class="..."
          height="255"
          width="451"
          loading="lazy"
          style="height: 100.517%;"
          id="e_594932"
          usemap=""
        />
      </div>
    </div>
    <h3 class="...">Handyverträge</h3>
    <p class="...">Telefonieren und surfen mit Ihrem Smartphone.</p>
  </div>
</a>

The HTML link element <a> takes its accessible name from its contents. In this case, the contents are:

  • Image (alt="Icon Smartphone")

  • Heading "Handyverträge"

  • Paragraph "Telefonieren und surfen mit Ihrem Smartphone."

Making the accessible name of the link "Icon Smartphone Handyverträge Telefonieren und surfen mit Ihrem Smartphone."

Remediation Notes

See observation Content card link purpose not determinable (2.4.4 Link Purpose (In Context)) for remediation in the ideal way of creating accessible content cards.

Side notes: The link element also has a null id, a null title, and a null onclick attribute set. A link should not use the title attribute at all, a null id attribute sets id="" which leads to "duplicate ID" errors easily, and an onclick should never be useful on a link anyways. Ensure, removing non-used markup.

Observation Details

Heading structure found in code, observations marked with "!" at beginning of line:

   h1 Telekom Mobilfunk-Netzausbau
      h2 Wissenswertes rund um den Netzausbau
!     h2 Helfen Sie dabei unser 5G-Netz noch größer zu machen!
         h3 Handyverträge
         h3 Datentarife
         h3 Festnetz Tarife
         h3 Hotspot
      h2 Warum Mobilfunk von der Telekom? Ganz einfach!
!        h3 Größes und bestes 5G-Netz*
         h3 Ausgezeichneter Service
         h3 Nachhaltig betriebenes Netz
!     h2 Bleiben Sie auf dem neuesten Stand
      h2 Häufig gestellte Fragen zur 5G Netzabdeckung
         h3 Wer baut das 5G-Netz in Deutschland aus?
         h3 Wie geht es mit der 5G Netzabdeckung voran?
         h3 Welches Smartphone ist 5G-fähig?
         h3 Wie wird das 5G-Netz ausgebaut?
  • Heading level 2 "Helfen Sie dabei unser 5G-Netz noch größer zu machen!" does not accurately describe topic/purpose of the grouped children heading levels

  • Heading level 3 "Größes und bestes 5G-Netz*" has typo

  • Heading level 2 "Bleiben Sie auf dem neuesten Stand" does not accurately describe topic/purpose of the section's content

Heading structure / outline is the most used mechanism to navigate a website for users of assistive technology.

Remediation Notes
  • Group carousel (headings level 3 "Handyverträge", "Datentarife", ...) in its own heading level 2, e.g. "Jetzt mit unseren Tarifen im 5G-Netz starten"

  • Typo: "Größes" → "Größeres"

  • Heading "Bleiben Sie auf dem neuesten Stand" teasers some kind of newsletter form, news section, link or resources list, etc. but does not deliver any of those; either add fitting content into or remove the section

Priority: Serious Significant Page: Mobilfunk Netzausbau Observation Permalink
Observation Details
  • Map on mobile uses two-finger zooming, not displaying the zoom buttons from desktop view and not allowing zooming by single pointer, e.g. double tap, tap and hold, etc.

  • Map on mobile uses "swiping" for scrolling the map. No single pointer mechanism is available, e.g. arrow buttons

Remediation Notes

While one functionality of the map can still be accessed by entering address or coordinates, the functionality of overview, of moving freely within the map, etc. is not accessible. Ensure navigational buttons (zoom, scroll) are present and accessible and especially stay accessible on mobile viewports.

Priority: Serious Significant Page: Mobilfunk Netzausbau Observation Permalink
Observation Details

Map on mobile uses "swiping" for scrolling the map. No single pointer mechanism is available, e.g. arrow buttons

Remediation Notes

While one functionality of the map can still be accessed by entering address or coordinates, the functionality of overview, of moving freely within the map, etc. is not accessible. Ensure navigational buttons (zoom, scroll) are present and accessible and especially stay accessible on mobile viewports.

Accompanying Files
Observation Details

Error message is displayed but

  • input field is not reflecting error state

  • error message is not programmatically connected to input

Remediation Notes
  • All input elements that can error must have a visually distinguishable error state. E.g. colored outline and added error icon

  • The input element must have a visible label (do not use placeholder as label) that stays visible while entering content

  • The input element must have a programmatic connection to the error message, e.g. by using aria-describedby on the input with the ID of the error message container

Accompanying Files
Observation Details

The map's address input

  • has no visible label

  • uses a placeholder as "label", which disappears when entering text

Additionally, while not a failure of this success criterion, the required input format is only displayed as an error message to the user after unsuccessful input.

Remediation Notes
  • Visually display the input's label at all times.

  • Do not use placeholders for labels, as they disappear on text input and they might not be announced by assistive technology.

  • When a certain input format is required, use a method like aria-describedby on the input, even before the input errors, so the user knows what to enter and what not to enter.

Accompanying Files
Observation Details
  • The page uses HTML list elements for non-list content. See class="container-grid--list". E.g. stage section with main heading.

  • On the other hand, what is arguably list content in the "Tarife" carousel (Handyverträge, Datentarife, ...), is not using semantic list elements.

  • Also, while the section "Warum Mobilfunk von der Telekom? Ganz einfach!" again uses a list element for non-list content, the actual lists inside the section (checkmark lists) are built with HTML paragraphs.

Remediation Notes

Do not use semantic lists for non-list content. But do use semantic list for all list content.

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

Accompanying Files
Observation Details

FAQ "Häufig gestellte Fragen zur 5G Netzabdeckung" uses <ul role="tablist">.

Observations:

  • The whole list is one focusable element; TAB can navigate to it, but the next TAB will already leave the FAQ and navigate to the next focusable element; expected behavior is to use TAB to navigate to each individual FAQ item


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, using appropriate semantic HTML elements to construct accordion components. For technical requirements and possible implementations, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".

Accompanying Files
Observation Details
  • Main heading "Telekom Mobilfunk-Netzausbau" uses <h1><strong></strong></h1>

  • Heading "Warum Mobilfunk von der Telekom? Ganz einfach!" uses <h2><strong></strong></h2>

As the whole visible text content is wrapped in emphasis, the emphasis itself becomes useless. For the heading level 2, additionally the actual emphasis

Remediation Notes

Ensure, using emphasis only to emphasize in comparison to surrounding content. In this case, styling should be done by CSS instead of using a semantic HTML element.

Accompanying Files
Observation Details

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

  • There are numerous instances of these failures. See attached screenshots for line breaks, non-breaking spaces, empty semantic elements, etc.

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

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.