37 issues found on Smartwatches

The ideal way would be to use the actual image description. Possible text alternatives for the example devices in the screenshot could be in the following style:

• "Kids Watch Xplora X6 Play in schwarz mit orangenem Akzent. Auf dem Display die Anzeige eines eingehenden Anrufs von 'Mama'."

• ...

All headings must use semantic HTML elements (<h1>, <h2>, <h3>, ...). Ensure, adding text alternative to the images to convey displayed heading structure in text as well.

Please (also) 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.

Change the text alternative to communicate the icon's purpose, e.g. by setting alt="Geräte von Apple anzeigen". Ensure to deliver accessible, purpose equivalent text alternatives for all filter states.

• No manufacturer filter selected: "Nur Geräte von MANUFACTURER anzeigen"

• One manufacturer filter selected

  • selected filter: "Alle Geräte anzeigen"

  • non-selected filter: "Geräte von MANUFACTURER anzeigen"

• Multiple manufacturer filters selected

  • selected filter: "Geräte von MANUFACTURER nicht mehr anzeigen" (or ideally even announcing the still selected filters, see notes below)

  • non-selected filter: "Geräte von MANUFACTURER anzeigen"

One possible solution would be to use native checkbox inputs for the manufacturer filters. But the structural idea down below can be used with other methods as well.

<fieldset>
  <legend>Filter nach Endgeräte-Hersteller</legend>

  <input type="checkbox" 
         id="manufacturer-apple" 
         name="manufacturer" 
         value="Apple" 
         checked />
  <label for="manufacturer-apple">
    <svg><title>Apple</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-google" 
         name="manufacturer" 
         value="Google" />
  <label for="manufacturer-google">
    <svg><title>Google</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-samsung" 
         name="manufacturer" 
         value="Samsung" 
         checked />
  <label for="manufacturer-samsung">
    <svg><title>Samsung</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-telekom" 
         name="manufacturer" 
         value="Telekom" />
  <label for="manufacturer-telekom">
    <svg><title>Telekom</title>...</svg>
  </label>

  <input type="checkbox" 
         id="manufacturer-xiaomi" 
         name="manufacturer" 
         value="Xiaomi" />
  <label for="manufacturer-xiaomi">
    <svg><title>Xiaomi</title>...</svg>
  </label>
</fieldset>

From there work with the ids of checked/unchecked to create the accessible names by dynamically adding IDs of checked inputs. This way, you could create something like "Geräte von MANUFACTURER nicht mehr anzeigen. Es werden Geräte gezeigt von: CHECKED_MANUFACTURERS"

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. How the heading is worded, potentially the most fitting element structure would be a a heading level 2 and an unordered list.

<h2>Ich möchte...</h2>
<ul><li>...

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.

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));
  }
}

Treat scrollable area as carousel or make scrollbar visible.

Ideally, the filter buttons should reflow correctly into multiple rows.

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

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.

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.

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>

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.

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

As used in the filter dialog window already, a "Filter anwenden" button could fix this issue, although for the given structure, this might not be the best option.

The buttons should have appropriate accessible names to describe their purpose. See ___ for an example solution. The success criterion says, the change of content or context can be announced prior to making the change. Having the accessible name set properly, would meet this for screen reader users. For other users it would be best to visually indicate by text. E.g., introducing the filter section by a short text:

<section>
  <h2>Geräteliste filtern und sortieren</h2>
  <h3>Filter</h3>
  <p> <!-- Add description -->
  <button> <!-- Filter dialog window -->
  <fieldset> <!-- Checkbox Group for direct filters -->

That description could be:

"Öffnen Sie die gesamten Filteroptionen über einen Klick auf den 'Filter' Button oder klicken sie auf einen der darauffolgenden Hersteller-Buttons, um die Geräteliste entsprechend zu filtern."

Or you could even set a <legend> inside the checkbox group to properly describe their purpose.

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