47 issues found on Alle Geräte

• Ankaufsbonus

  • Change the text alternative to communicate the icon's purpose, e.g. by setting alt="Ankaufspreis Ihres Altgerätes".

• Vorbestellung

  • Add <title> element to SVG or embed SVG from file and treat like <img>

  • If declaring icon as decorative, ensure <title> element is empty and SVG is hidden from screen readers by setting aria-hidden="true"

Change the text alternative to communicate the image's purpose, e.g. by setting it to the displayed text content: alt="2× Speicher-Upgrade".

There are multiple ways to remediate this issue.

Image description

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:

• "Apple iPad Air 13" (2025) M3 in Space Grau. Vorderseite mit generischem Wallpaper, Hinterseite mit Kamera"

• "Samsung Galaxy S25 Edge in Titanium Icyblue (hellblau). Vorderseite mit Gerätenamen als Schriftzug, Seitenansicht, Promotion für 2× Speicher-Upgrade inklusive"

• "Samsung Galaxy S25 Ultra in Schwarz. Vorderseite mit Gerätenamen als Schriftzug, Rückseite mit 5 Kameras"

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

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 class="visually-hidden">Speicherplatz</dt>
          <dd>
            Verfügbar in
            <ul></ul> <!-- Storage options -->
          </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>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>

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 "Alle Geräte mit Vertrag" (/shop/geraete/alle-geraete) only uses a single main heading and no more. A good structure could be:

<main>

1 Alle Geräte mit Vertrag
  2 Filter und Sortierung
  2 Geräteliste
    3 GERÄTENAME
    3 ...

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

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

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>

Use proper semantic headings to structure page content into parts.

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

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

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.

Treat scrollable area as carousel or make scrollbar visible.

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

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>

All <a> elements MUST have an href attribute.

Use actual semantic HTML to create interactive elements. If you need a button, use <button>, if you need a link, use <a>. Ensure, all <a> elements have a valid href attribute as this is what makes them links. Anchor elements without href attribute are not considered links and as such are not accessible by keyboard.

This is an info "i" button:

<span class="...">
  <i class="..." id="svg_wrapper_undefined">
    <svg width="1em" height="1em" viewBox="0 0 24 24" color="currentColor">
      <path>...</path>
    </svg>
  </i>
</span>

Instead, use:

<button aria-label="Tarifdetails zum Tarif MagentaMobil M">Tarifdetails</button>

This is perfectly keyboard accessible, will be listed in a button list for screen readers, can be operated via voice control and much more.

If using an SVG is a must, refer to e.g. Sara Soueidan's "Accessible Icon Buttons" article.

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. They must be closable via ESC and the close button must be operable by keyboard as well. This will remediate the obscuring of focused elements.

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.

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

No remediation necessary, as the contrast ratio does exceed the required ratio slightly.

No remediation necessary, as the icon is not adamant to the content's understanding, if the icon is declared purely decorative by using a null alt attribute.

Icon could get an outline with sufficient (3:1) color contrast to improve legibility.

Ensure, all text content meets required contrast minimum.

Ensure all text content meets minimum color contrast requirements.

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

If the icon is declared purely decorative by using a null alt attribute or an empty <title> element, no remediation is necessary, as the icon is not adamant to the content's understanding.

As it does not and as such is accessible to screen readers, the icon must meet color contrast of 3:1.

The dropdown MUST be a user accessible interface component. Ideally, use a native semantic HTML <select> element for the dropdown and an explicit label to go with it. As is, there is neither a programmatically determinable connection between the "label" "Sortieren:" and the dropdown, nor does the dropdown has 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.

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.

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.

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.

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.

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

• Adding pagination (single pointer arrow buttons)

• Reflow to multiple lines of buttons (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.

This allows for another method to remediate, by only displaying the amount of buttons, fitting the available space. So while "all" buttons are shown on larger viewports, the number can decrease on smaller viewports, as long as the functionality parity is met, which is the case, with the filter buttons being accessible via the filter dialog window.

Positive side-effect of the latter option is one less mechanism (horizontally scrolling items) to be maintained.

Important note:

While technically, this behavior does not completely remove access which would be needed to justify priority 1 "Critical", the combination of this issue with other issues, limiting the user experience with keyboard and screen reader navigation immensely already, still does make this issue a critical one.

Treating it as such in the current state, keyboard and screen reader users might not at all be able to navigate more than one page of products in the product list within the shop, is highly recommended.

Ensure, clicking the button "Weitere Geräte anzeigen" will result in:

• Loading more products into the product list

• Not announcing change of query parameters in the URL, as long as the change is not useful information to be announced

• But ideally do announce the change of content (e.g. by using an ARIA live region and announce "X weitere Geräte werden angezeigt")

• Setting the focus to the first focusable element before the first newly added element

  • This must be indicated by DOM structure, not by the element that was focused before the button was focused

  • This must work with keyboard and screen reader navigation alike

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.

Ensure, using semantic list elements for all list content.

Ensure proper functionality of keyboard navigation for all interactive elements. Especially non-native, complex components must adhere to all technical requirements for presentation, operation, keyboard navigation, assistive technology navigation. For technical requirements, refer to BFIT-Bund Handreichung "Accessible design of user interface elements" for the chosen interactive elements. Please note, all interactive elements must meet these requirements. If native, semantic HTML elements are used unchanged, these requirements are met by default. Changing default presentation or functionality, or using non-native elements, will always add drastically more difficulty and maintenance requirements.

That said, use of proper semantic HTML elements without the need of ARIA enrichments is always the preferred method. For the given component, functionality can be defined as "radio button group", as the user can choose one item from a list of items. The group is presented as a carousel, which has no (fully accessible) way of being built without use of JavaScript and/or ARIA enrichments. If presentation as carousel is not mandatory, simple, responsive reflow of the radio button content would suffice.

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