Important Notice: This website shows interim results and does not represent a complete accessibility audit. The content is not final, is under heavy development, and is not legally binding. The website and all its content is for internal use only; unauthorized use or distribution may result in legal consequences.

Documentation of accessibility observations for Deutsche Telekom – Mobilfunk & OneShop

14 issues found on Handyversicherung

Page URL
https://www.telekom.de/unterwegs/apps-und-dienste/sicherheit/handyversicherung

Issues List

Non-text Content 1.1.1 (A)
Image is missing text alternative
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)
Semantic HTML elements are used for styling or layout purposes
Info and Relationships 1.3.1 (A)
Visual presentation of heading structure does not match code markup
Use of Color 1.4.1 (A)
Links are indicated by color only
Contrast (Minimum) 1.4.3 (AA)
Hovered links' text content does not have enough color contrast
Non-text Contrast 1.4.11 (AA)
Icon does not have enough color contrast
Text Spacing 1.4.12 (AA)
Text content overflows containers with user changed text spacing
Keyboard 2.1.1 (A)
Interactive element, operable by mouse, not accessible by keyboard
Headings and Labels 2.4.6 (AA)
Heading has single sub heading
Focus Visible 2.4.7 (AA)
Element's focused state is not visible
Name, Role, Value 4.1.2 (A)
Interactive element does not use correct semantic HTML
Name, Role, Value 4.1.2 (A)
FAQ not accessible via assistive technology
Priority: Critical Medium Page: Handyversicherung Observation Permalink
Accompanying Files
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.

  • Cards in section "Unser nachhaltiger Smartphone-Kreislauf"

Remediation Notes

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

Priority: Critical High Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

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

Remediation Notes

Container elements must not use fixed dimensions, if they contain text content, to allow proper reflow without obscuring / overlapping content. Changing text spacings to values

  • Line height (line spacing) to at least 1.5 times the font size;

  • Spacing following paragraphs to at least 2 times the font size;

  • Letter spacing (tracking) to at least 0.12 times the font size;

  • Word spacing to at least 0.16 times the font size.

must be possible and must not lead to any loss of content or functionality.

Priority: Critical Low Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

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:

  • Body copy links with color #007faf barely go over 4.5:1 threshold but on hover, change color to #0082b2 which does not meet 4.5:1 minimum color contrast

Remediation Notes

Ensure, all text content is clearly visible, using color contrast ratios of 4.5:1 and higher. For large text content a reduced contrast ratio of 3:1 is acceptable, but not recommended.

Especially color variants that barely meet color contrast ratio requirements for default background colors are subsceptible to fail minimum color contrast ratio, when used on non-default background colors. When a certain color barely meets color contrast ratio on default white background, ensure, this color variant is only used on said background color and provide a different foreground color variant for darker background colors.

Ideally, aim for enhanced contrast ratio 7:1 (see 1.4.6 Contrast (Enhanced) (Level AAA)), to often ensure passing minimum contrast ratio, even on non-default background colors.

Side Note: this success criterion is not specifically about identification of links. When a link would have no underline and its color is the only way to differentiate from surrounding text, it is considered a failure under 1.4.1 Use of Color. This criterion is for all text content.

Priority: Minor Low Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

Icon does not have high enough color contrast ratio to its background.

  • Section "Unser nachhaltiger Smartphone-Kreislauf" cards' arrow icons, contrast ratio 1.4:1

Remediation Notes

For icons, not declared purely decorative, ensure a color contrast ratio of at least 3:1 to its background.

If the icon is purely decorative and declared as such, e.g. by using a null alt attribute on HTML image element or properly hiding an HTML SVG element by setting aria-hidden="true", meeting a 3:1 color contrast ratio, while providing better user experience overall, is not a requirement.

Priority: Serious Low Page: Handyversicherung Observation Permalink
Observation Details

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:

  • Body copy links

  • Links in FAQ items

Remediation Notes

Ensure, links can be differentiated from surrounding text content by at least one other visually perceivable factor. Preferably use underline to indicate link text as it is browser default and known pattern to users.

Priority: Critical Low Page: Handyversicherung Observation Permalink
Observation Details

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)

Examples:

  • Navigation arrow buttons in section "Unser nachhaltiger Smartphone-Kreislauf" use <div role="button"> instead of semantic button element

  • FAQ uses <dl>; FAQ items use <dt tabindex="0"> instead of semantic button elements

Remediation Notes

Ensure, using native, semantic HTML elements for interactive elements and not re-building existing functionality with generic elements like <div> and <span>.

Ensure, choosing the proper elements, depending on purpose (e.g. links, using <a href=""> to link to resources, and <button> to perform actions).

This way, the need for added JavaScript (e.g. on click events / event handlers) and ARIA methodologies is reduced to a minimum, which will ensure clean and simple code and backwards compatibility, will future-proof functionality, and will avoid issues with keyboard navigation or other assistive technology (see also 4.1.2 Name, Role, Value).

Priority: Critical Low Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

All images that are not purely decorative must have a purpose equivalent text alternative present. The stage image is using CSS background-image and no text alternative is present.

Remediation Notes

Ensure, all HTML image elements properly set the alt attribute. Depending on the purpose of the image, choose whether to declare an image decorative, informative, or functional. For more guidance in choosing, refer to the W3C Alt-decision tree.

If the image is

  • purely decorative, set a null alt attribute as follows: <img alt="" />

  • not purely decorative, the alt attribute must not be null

Priority: Moderate Low Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

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

Arguably decorative images with text alternative present in attached screenshots:

  • Icons and symbols

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

Priority: Critical Low Page: Handyversicherung Observation Permalink
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:

  • Section "Im Falle der Fälle helfen wir gerne" – "Schadensmeldung aufgeben"

    • Uses "Handy mit zersprungenem Display"

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

Priority: Moderate Low Page: Handyversicherung Observation Permalink
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".

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

Priority: Moderate Low Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

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

  • Heading "Rechtliche Hinweise" is sub heading of FAQ list but is represented as new stand-alone heading

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.

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.

Priority: Best Practice Low Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

Heading level 2 "Im Falle der Fälle helfen wir gerne" has one single sub heading level 3 "Schadensmeldung aufgeben". As with nested lists, where a list with a single item can be omitted, when having a single sub heading with a heading, the content should be evaluated and it should be considered to remove the unnecessary hierarchy level.

Priority: Critical Low Page: Handyversicherung Observation Permalink
Accompanying Files
Observation Details

Links use <a href=""></a><div><span>LINK TEXT</span></div> instead of labeling the link by its content.

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 proper usage of semantic HTML link element. For the card example above, please also refer to previous observations and card examples. E.g.: /observations/9ef22c7a-5c20-4107-aed4-23f56268e95a

Priority: Critical Low Page: Handyversicherung Observation Permalink
Observation Details

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

Remediation Notes

Ensure, using correct semantic HTML elements for all interactive elements. In case of accordions, these could be <detail> and <summary> constructs or ones with <button> as the accordion item "header".

For custom building an accessible accordion component, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".