28 issues found on Tastenhandys

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.

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.

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

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

<h2>Vorteile im Überblick</h2>

<h3>Unbegrenztes Datenvolumen</h3>
<p>...</p>
<p><a href="...">...</a></p>

<h3>MagentaEINS Vorteil</h3>
<p>...</p>
<p><a href="...">...</a></p>

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

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.

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.

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.

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

Ensure all text content meets minimum color contrast requirements.

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.

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.

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, contents of the filtering dialog window are in correct focus order (after filter button)

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

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 focused element.

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

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.

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.

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.

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