32 issues found on Mobile Router

There are multiple ways to remediate this issue.

Image description

The ideal way would be to use the actual image description.

Declare decorative

A less ideal way would be to declare the device image as decorative by using a null alt attribute, removing it from the accessibility tree. There are a few caveats to this "tactic", though and if using it, there are multiple other steps to be done, to ensure conformance with this success criterion.

• While this would improve the current use of the images' text alternatives, removing the content duplication, it does not really solve the issue of the images' purpose not being communicated.

• A decorative image only is purely decorative, if not adding any information that is not communicated otherwise. While device name and device color might be information which is available elsewhere, the actual description of the device is not.

• Declaring the images decorative, you additionally MUST ensure, all other information (color, promotions, add-ons, extra devices like styluses, etc.) is available as text in the product card.

Change the text alternative to communicate the icon's purpose, e.g. by setting alt="Tarifdetails anzeigen/ausblenden".

Ensure, code markup matches the visual presentation. One possible solution could be a structure as follows:

<h2></h2> <!-- Heading to introduce device list -->
<!-- Device list -->
<ul>
  <li>
    <!-- Device card -->
    <article>
      <h3></h3> <!-- Device name -->
      <span></span> <!-- Badge with promotion/info -->

      <dl>
        <div>
          <dt class="visually-hidden">Verfügbar in den Farben</dt>
          <dd>
            <ul></ul> <!-- Available colors -->
          </dd>
        </div>

        <div>
          <dt>Preis, einmalig</dt>
          <dd></dd> <!-- Price -->
        </div>
      </dl>

      <img /><!-- Device image -->
    </article>
  </li>

  <!-- More device cards -->
</ul>

Improvements made and notes to implement:

• Clear structure without unnecessary nesting, without sections/articles nested, etc.

• Use actual semantic list (<ul>) for the list

• Each product is an <article> so it can be navigated to easily via screen reader

• Product is defined by semantic heading <h3> as first child of product card

• <span> with badge positioned right after heading, so it will be announced after the device name; badge can be positioned absolute or visually be moved up by using CSS order: -1

• Product description is moved into description list to make each description detail easily navigable

• Lists within the description (color list, storage option list) are using semantic list elements

• Some <dt> can use a class="visually-hidden" to be accessible to screen readers while not being visible; check example class below

.visually-hidden:not(:focus):not(:active) {
  clip: rect(0 0 0 0); 
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap; 
  width: 1px;
}

Added side-effect of a semantic structure like this is the improved simplicity to build a responsive layout for the list, using CSS grid and Flexbox.

Use proper semantic HTML headings to indicate the structure of the sidebar content.

<h2>Unsere Empfehlung</h2>

<h3>MagentaMobil Speedbox S mit 100 GB</h3>
<p>...</p>
<p><a href="...">...</a></p>

<h2>Ich möchte</h2>
<p>...</p>
<p><a href="...">...</a></p>

Semantic HTML

Ensure, using proper semantic HTML. This means,

• If there is an HTML element with needed or wanted functionality, use it.

  • If a link is needed, use <a>, if a button is needed, use <button> – also, using links and buttons as intended (links to move to content and buttons to do an action) will help navigation immensely, as e.g. screen readers can return lists of buttons/links independently. So knowing what elements will keep you on the page (footnote buttons) and what elements will bring you somewhere (product detail page) is simply made possible by using the correct element.

  • If creating user interface components with input controls like checkboxes, radio buttons, etc., use the appropriate, native semantic HTML elements for them. Use <input type="">, <select>, <button>, ... to ensure accessibility.

  • If writing headings, use the proper semantic HTML headings (<h1>, <h2>, <h3>, <h4>)

  • If you are listing elements (color variants, storage options, products, ...), use semantic list elements (<ul> for lists, where the order is not relevant, <ol> for lists, where the order is relevant, <dl> for key-value-paired descriptions)

• Visual presentation MUST match code markup. If it looks like a heading, semantic HTML heading elements MUST be used. If it does not look like a heading, semantic HTML heading elements MUST NOT be used. Same goes for every other native HTML element.

• Grouping elements/objects/content for layout or styling purposes must only be done, using generic HTML elements.

  • There are only 2 generic HTML elements named in MDN docs – ARIA: generic role. No other element shall be used for this purpose. Those are <div>, <span>,

  • Additionally, the <section> element has the generic role, too. The section however comes with a very crucial limitation, as it "should always have a heading, with very few exceptions".

Best practice HTML nesting

Ensure, using as little nesting as possible. Every single level of nesting inside HTML code will impact website performance. Using a 10-level-hierarchy to create a button with <div>s etc., is completely unnecessary, as a <button>Button text</button> will result in accessible, robust, portable solution and will always outperform.

Outline / Heading structure

Ensure use of heading structure for a page's content. Headings are the most used method to navigate the broad structure of a website for users of screen readers. A clear heading structure will also increase SEO performance. The shop page only uses a single main heading and no more. A good structure could be:

<main>

  2 Passende Tarife zu den mobilen Routern
1 Mobile 5G-Router mit Vertrag
  2 Filter und Sortierung
  2 Geräteliste
    3 GERÄTENAME
    3 ...
  2 Verlässlicher Service rund um Ihre Bestellung
    <!-- as each "feature" has very limited content, headings may not be the best way to organize; evaluate use of list structure -->
  2 Mit den Surfsticks und mobilen ...
  2 Häufig gestellte Fragen ...
    3 ...

<aside>
  
  2 Auswahl ("Warenkorb")
    3 Tarif
    3 Gerät
  2 Vorteile im Überblick
    3 Unbegrenztes Datenvolumen
    3 MagentaEINS Vorteil

Ensure, using semantic list elements for all list content.

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.

Ensure the site is responsive. A viewport of 320px width must keep all content visible and all functionality intact. For the product cards, use a responsive layout method like the following to ensure correct reflow:

.product-list {
  --min-card-width: 200px;
  --product-list-gap: 1rem;

  display: grid;
  grid-gap: var(--product-list-gap);
}

@supports (width: min(var(--min-card-width), 100%)) {
  .product-list {
    grid-template-columns: repeat(auto-fit, minmax(min(var(--min-card-width), 100%), 1fr));
  }
}

While not a failure for the given success criterion, the limited vertical space in the dialog window makes navigating the dialog's contents extremely difficult. Evaluation of the need for the fixed top bar and the large fixed bottom bar should be done.

Consistency with other dialog windows could remove the (empty) top bar and/or add the close button to a fixed position of the scrollable dialog window.

The fixed bottom bar could e.g. be shrunken by

• decreasing margins and/or paddings,

• decreasing the size of the primary button,

• changing the layout to display price information and primary button side-by-side.

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.

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

Ensure, all text content meets required contrast minimum.

Ensure minimum color contrast ratio is met for all text content.

The contents of the tooltip must stay accessible on smaller viewports. Ensure to display the contents within the boundaries of the viewport.

As the site is already working with dialog windows and collapsible elements, the easiest way to achieve this is to eliminate the tooltip functionality, as they (tooltip, dialog window, collapsible) serve the same purpose of hiding information. For this, the other used method must meet all success criteria, but this would eliminate the need of meeting them with yet another mechanism.

Hiding information from the user never is good user experience but the use of dialog windows or collapsible elements is widespread. While the use is no clear failure of accessibility criteria, concerning WCAG, one could argue it being at least a grey area for 3.2.4 Consistent Identification: "Components that have the same functionality within a set of Web pages are identified consistently." – this audit will not add this as a failure but asks to evaluate the use of multiple components that have the same purpose. Ideally, the functionality "hide from user" has a single way to be done. Splitting into a trigger being "block level" (FAQ) and "inline level" (Footnotes) seems reasonable, but adding another mechanism does not seem necessary.

While not a failure for the given success criterion, I also attached a screenshot showing the limited vertical space in the dialog window, which makes navigating the dialog's contents extremely difficult. Evaluation of the need for the top bar and the large bottom bar should be done.

Ensure complete navigation and operation by keyboard is possible. All interactive elements MUST be reachable by keyboard.

Only use semantic HTML elements to create interactive elements to ensure the base accessibility. If building custom interactive elements instead, you MUST refer to something like BFIT-Bund Handreichung "Accessible design of user interface elements" to ensure all necessary functionality is available. This MUST be done for all interactive elements that are custom built. Every button, every input, every link, ... Thus, using proper semantic HTML will decrease time and necessary effort to complete dramatically.

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

For example, filtering dialog window should use buttons, radio button groups, checkmark groups, etc. instead of relying on dozens/hundreds of nested <div> to "rebuild" functionality, native HTML elements already deliver.

The "Filter" button to open the filter dialog window looks as follows:

<div class="... clickable" data-qa="LST_FilterButton">
  <i class="..." id="svg_wrapper_undefined">
    <svg width="1em" height="1em" viewBox="0 0 20 20" color="currentColor">
      <path>...</path>
    </svg>
  </i>
  <p class="...">Filter</p>
</div>

When it could just be:

<button><svg aria-hidden="true">...</svg>Filter</button>

Ensure use of proper structure of of the page and easy identification of repeated content blocks by using a combination of landmarks, and HTML headings. An example structure for the shop pages containing product lists, could be as followed:

1. HTML header

   1. The current header element is not part of this audit, thus its current contents are not listed in here.

   2. Breadcrumb navigation as HTML <nav> element, labeled to differentiate from main menu, and including an ordered list <ol>

   3. Option product highlights identified by <h2> heading

   4. Device group navigation, using <nav> navigation element, labeled to differentiate from other menus

2. <main> landmark

   1. <h1> main heading and description text content

   2. <section> for filtering and sorting

      1. evaluate use of ARIA role search

      2. add <h2> heading with id attribute and

      3. label the section by using aria-labelledby="" with the heading ID

   3. <section> for product list as your main content

      1. add <h2> heading with id attribute and

      2. label the section by using aria-labelledby="" with the heading ID

      3. The actual device list should use <ul>

      4. Each product card should be <article> including <h3> with product name

      5. No further nesting of landmarks should be needed inside this section as the structure is well defined by the article elements and their nested heading

   4. <section> for sidebar content; ideally labeled by a visible heading <h2> that describes all sidebar content; sections inside sidebar should not use <section> but only <h3> for structure

   5. <section> for landing page, SEO content and FAQ; sections inside should not use <section> but only <h2> and <h3> for structure

3. HTML footer

Additionally, the use of skip links should be evaluated. Skip links are not only meant to be the first links on a page, but can also be used before certain repeated content blocks. For example, at the start of the main landmark, there could be a skip link that skips the product list and brings the user to the sidebar content or the FAQ section. Skip links can also be used at the end of a section or landmark to go back to its beginning. For example, at the end of the product list, which can be quite long, there could be a skip link to reach the start of the product list again.

Using proper structure of HTML headings usually makes "custom landmarks" (by sections) a redundant mechanism to navigate on a page, so they should not be used on everything. Only use landmarks for broad page structure.

The same goes for skip links. If a proper heading structure and optional landmarks already exist, there usually is no need for additional skip links.

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

Ensure, link purpose is determinable. This can be done by adding "GERÄT XYZ in den Warenkorb legen" as text alternative. Ideally, a proper semantic structure on product card is used.

<article>
  <h3 id="heading-PRODUCT">PRODUCT NAME</h3>
  ...
  <a href="..." id="link-PRODUCT" aria-labelledby="heading-PRODUCT link-PRODUCT">
    Produktdetails
  </a>
</article>

A focus state must be defined for all interactive, focusable elements. Ideally, a visual distinct focus state uses an outline or other larger area changes to the product card.

If using color change for focus state, ensure to meet minimum color contrast between different states (1.4.3 Contrast (Minimum)) and to not only rely on color change (1.4.1 Use of Color).

The buttons MUST be user accessible interface components. Ideally, use a native semantic HTML <button> element for the filter button, <fieldset> including <input type="checkbox"> for the "direct manufacturer filter" buttons, and explicit labels to go with them. As is, there is neither a programmatically determinable connection between the "labels" and the buttons, nor does the buttons have any accessible name, let alone one including the label.

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

Ensure, making all interactive elements at least 24×24px in size. This does not necessarily mean to make the icon itself 24×24px, if you can ensure a surrounding area of said size to be the clickable area of the icon.

A better approach would however be to not use interactive elements below this minimum size. Also consider mobile users when designing these elements. An increased target size of 44×44px (see success criterion 2.5.5 Target Size (Enhanced) [AAA]) will immensely help mobile users as well.

Using native semantic HTML is always the preferred method.

If this is absolutely impossible in a situation, re-building can be viable but comes with dramatically increased time and effort to meet technical requirements. The BFIT-Bund Handreichung "Accessible design of user interface elements" shows technical requirements (e.g. keyboard navigation, mouse operation, etc.) for interactive elements. Looking into Accessible design of user interface elements – Links, quickly shows the complexity of what is required to meet the functionality, a properly used <a href="..."> element already includes.

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

Ensure, only using button functionality for actual buttons. When button functionality is needed, ensure using a semantic HTML button element, instead trying rebuilding button functionality with generic non-semantic HTML elements.

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.

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.

Ensure,

• only links (that lead to resources) are using HTML link elements

• only buttons (that perform actions) are using HTML button elements

• no generic element is used, if a native, semantic HTML element with wanted functionality exists

• all interactive elements are labeled uniquely, to be identifiable by assistive technology

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.

Ensure, purely decorative images have a null alt attribute set. SVGs must have an empty <title> element instead and ideally be hidden manually via aria-hidden="true".

For more information about accessible icon buttons, refer to Sara Soueidan's "Accessible Icon Buttons" article.

If an image is declared to be informative rather than decorative, a purpose equivalent text alternative must be programmatically determinable. Duplicating already existing text content never is purpose equivalent of an image. See the W3C Alt-decision tree for more information about types of non-text content.

Ideally, creation of empty paragraph elements will technically be prohibited.

Content management however must ensure, not creating empty paragraph elements, not in rich text nor source code editor.

Side note: while this issue is about the found empty paragraph element, there are rare occasions, any element should be empty.

Use proper semantic HTML structure to create navigation landmark. Ensure, labelling the <nav> element to differentiate from main, breadcrumb and other menu(s).

Visually hidden text should only be added if absolutely necessary, because there is no other way to achieve the wanted result.

Especially when content is already accessible to assistive technology, there should not be any duplication by using unnecessary ARIA attributes or visually hidden text content.

The use of semantic HTML is adamant to a good user experience and web accessibility. Ideally, native HTML is used. In case of an accordion, this could be realized by using the <detail> and <summary> elements.

If there is a valid reason to not use those, ensure the use of interactive elements (<button>) for the interactive parts of the accordion.

The technical requirements for building an accessible accordion component can be found in the BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".

The accordion, while not strictly defined as such, can be defined as an opposite to a tab group. They both have the purpose of hiding content from the user to be revealed on user interaction. Defining accordion and tab group as opposites allows for an easy rule of usage. Tab groups are used, if and only if there must always be exactly one content panel visible. The accordion is then used, whenever the possibility of showing more than one content panel at the same time is needed or wanted. This distinction can e.g. be found in the documentation of the GOV.UK Design System at Accordion – "Decide between using accordions, tabs and details".

Use anchor elements for links instead of trying to build custom interactive components. All <a> elements MUST have an href attribute. To demonstrate, this is one of the links:

<div class="style__StyledNavigationChips-sc-h2fd9x-0 IhoCS dt_navigationChips clickable selected"
     data-qa="LST_DeviceCategory_smartphones">
  <article class="style__StyledIconWrapper-sc-h2fd9x-1 jAhAws">
    <div class="iconWrapper" role="image" aria-label="Handys">
      <div class="sc-imWYAI iYZqNY es_preloadImage">
        <img class="sc-kpDqfm bxTqZb dt_mainImage customStyle imgLoaded"
          alt="Handys"
          src="..."
          data-img="isSafari_false isSsr_undefined">
        <div class="sc-jXbUNg jYexhV dt_placeholderImage">
          <svg width="100%" height="100%" viewBox="0 0 121 242"
            fill="none" xmlns="http://www.w3.org/2000/svg">
            <path d="..."
              fill="#F3F3F3"></path>
          </svg>
        </div>
      </div>
    </div>
  </article>
  <div class="sc-YysOf esSDcz dt_typography variant_smallBold">
    Handys
  </div>
</div>

When it easily could be:

<nav aria-labelledby="heading-device-categories" id="menu-device-categories">
  <h2 id="heading-device-categories">Geräte-Kategorien</h2>
  <ul>
    <li><img alt="" src="..."><a href="">Handys</a>
    <li><img alt="" src="..."><a href="">Smartwatches</a>
    <li><img alt="" src="..."><a href="">Tablets</a>
    <li><img alt="" src="..."><a href="">Mobile Router</a>
    <li><img alt="" src="..."><a href="">Tastenhandys</a>
  </ul>
</nav>

for the whole navigation to be perfectly accessible. The clean semantic structure with the id on the navigation element allows for all necessary CSS selectors to be created from the id alone without the need of countless CSS classes.

Simple structured HTML outperforms in many ways.

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

Possible methods to remediate and to ensure access to the links:

• Adding pagination (single pointer arrow buttons)

• Reflow to multiple lines (also see 1.4.10 Reflow)

Note, that the WCAG, and success criterion 2.5.7 Dragging Movements specifically, do not require presentation / layout parity of different devices, viewports, etc. This means, while functionality and information parity is a must, the layout and presentation can be different.