38 issues found on Roaming Optionen

Text content should be actual text, icon should then use a null alt attribute.

Ensure the table being accessible by avoiding nesting of semantic roles (table inside scrollbar)

Ensure, using semantic list elements (<ul>) for the country lists. The list can be styled with CSS grid or flexbox to use multiple columns if the screen real-estate allows it and to reflow if not. For a responsive layout, the following CSS grid implementation could be used:

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

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

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

Ensure no container, containing text content, has fixed dimensions.

Remediation for this issue cannot be appropriately estimated. It might be solvable, remediating the observed issue on 4.1.2 Name, Role, Value.

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.

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.

• Do not hide already existing labels to then add the same label again

• Use appropriate, meaningful labels, describing the purpose of the following input elements

• Best practice: avoid complicated questions and cognitive tasks to be done in forms; you can simplify by using YES/NO questions with appropriate and easy to understand questions and hints

<fieldset>
  <legend>Wählen sie aus, ob sie einen Vertrag haben oder Prepaid zahlen</legend>

  <input id="tarifart--vertrag" ...>
  <label for="tarifart--vertrag">Vertrag</label>

  <input id="tarifart--prepaid" ...>
  <label for="tarifart--prepaid">Prepaid</label>
</fieldset>

<fieldset aria-describedby="tarifzeitraum-hint">
  <legend>Wählen sie 'Ja', wenn sie einen aktuellen MagentaMobil-Tarif haben</legend>
  <p id="tarifzeitraum-hint">
    Aktuelle MagentaMobil-Tarife sind die, 
    die seit dem 01. Januar 1970 abgeschlossen wurden.
  </p>

  <input id="tarifzeitraum--neu" ...>
  <label for="tarifzeitraum--neu">Ja</label>

  <input id="tarifzeitraum--alt" ...>
  <label for="tarifzeitraum--alt">Nein</label>
</fieldset>

Use appropriate heading for the comparison table, like "Datenpässe und Optionen".

To have a meaningful page structure, you should look at the heading outline and evaluate its usefulness. See attached screenshot of the outline.

After opening dialog window via keyboard and closing the dialog window via keyboard again, the focus must be set to the element that initiated the opening of the dialog window.

Use a <ol> & <li> structure to match the visual presentation.

Ensure keyboard focus moves to opened dialog window and is trapped within the content. Evaluate the use of Dialog HTML element <dialog>.

Tabs can be created in a variety of ways in HTML, thus a general "fix" cannot be defined.

Ensure, the tabs activate on SPACE / ENTER (and screen reader equivalent) rather than activate on focus alone.

Resources to check for Tabs / Tab Groups:

• https://design-system.service.gov.uk/components/tabs/

• https://handreichungen.bfit-bund.de/accessible-uie/1.0/registerkartengruppe.html

Ensure enough contrast (3:1) between different radio button states (default, focused, active, ...).

Better approach: Use non-color indicator additionally to eliminate contrast issues. This can be an outline.

Use semantic HTML elements <strong> and <em> instead.

• For structuring, always use actual paragraph elements (<p>).

• For styling, always use CSS.

Only use line break element for specific purposes (e.g. in poetry).

For remediation notes on this topic, see observation for 3.3.2 Labels or Instructions.

Use appropriate alt texts to convey visually communicated information. This could be:

1. "Screenshot: Android Einstellungen. Menüpunkt 'Verbindungen' ist hervorgehoben"

2. "Screenshot: Menü 'Verbindungen'. Menüpunkt 'Mobile Netzwerke' ist hervorgehoben"

3. "Screenshot: Menü 'Mobile Netzwerke'. Menüpunkt Schalter 'Daten-Roaming' ist hervorgehoben und aktiviert"

Alternatively you can ensure the provided text is already serving an equivalent purpose:

1. Wählen Sie in den Android Einstellungen den Menüpunkt „Verbindungen“ aus.

2. Wählen Sie im Menü „Verbindungen“ den Menüpunkt „Mobile Netzwerke“ aus.

3. Aktivieren Sie im Menü „Mobile Netzwerke“ den Menüpunkt Schalter “Daten-Roaming”.

Doing so, the images could then be marked decorative by using a null alt attribute.

Decorative non-text content (images, icons) MUST not be described via alt attribute. They must use a null alt attribute (alt="").

Ensure, adding a visible label that is visible at all times to every input element to clearly and unambiguously identify the purpose of the input element. The Partnernetze input could be structured like this:

<div>
  <label for="partnernetze-country">
    Wählen sie ein Reiseland
  </label>
  <p id="partnernetze-country-hint">
    Das Land, zu dem Informationen über ...
  </p>
  <input 
    id="partnernetze-country" 
    aria-describedby="partnernetze-country-hint partnernetze-grenze-hint"
    ...>
  <p id="partnernetze-grenze-hint">Wenn sie sich in der Nähe ...</p>
</div>

Ensure, all required functionality is rebuilt on custom input elements. Confirm navigation and operation functionality with (drop-down list as an example, depending on use and definition) BFIT-Bund "Accessible design of user interface elements" – Drop-down list.

Ensure, the icons have a purpose equivalent text alternative present. On an <img> tag, use the alt attribute. On an <svg>, use the <title> element.

Purpose equivalent means, it is not a description of the icon but a description of its purpose. For the Partnernetze table this could be "Enthalten" & "Nicht enthalten" or similar.

If displaying data in tabular form, always use the appropriate semantic HTML element <table>.

Use appropriate label for button. Use main language and a text alternative that describes the purpose of the button. E.g. "Suchen" instead of "search outline".

Also ensure, the image icon inside the button is not announced as an image. You can fix both issues by moving the label of the button to the button's content, as is built-in in HTML and as is already done in the search button.

A <button> element also should not set a role, ARIA label nor title. Limit the use of ARIA to the exact situations it is actually needed.

<button 
  class="vs__clear">
  <svg>
    <title>Eingabe zurücksetzen</title>
    ...
  </svg>
</button>

For the search button that already uses role="presentation", evaluate the actual use of the button. If the button is not needed, remove it.

Remove the accordion structure from search results to simplify the code. By doing this, you also open up possibility to create one data table for search results, using the now accordion item title as your first table column. This would also drastically improve accessibility for screen reader users.

Netz | GPRS | ... |
...  | ✅   | ❌   |

Creating a full audio description, while often preferred, is not always feasible, making the media alternative an easier way to remediate.

There are exemptions for specific situations which can be used. One of those is, when a video only conveys information, already accessible on the page (e.g. in text).

To do so, you must

• ensure all information in the video, whether audio or visual information, is 1:1 conveyed in text surrounding the video

• clearly mark the video as "media alternative"

Ensure enough contrast (3:1) between different radio button states (default, focused, active, ...).

Better approach: Use non-color indicator additionally to eliminate contrast issues. This can be an outline.

Ensure the whole outline is visible on keyboard focus.

Ensure, focus states of interactive elements can be differentiated from default, un-focused states by at least one other visually perceivable factor. The issue may be remediated by ensuring high enough color contrast ratio of 3:1 for difference between states.

Preferably though, use focus outlines to indicate focus state of interactive elements, as it is browser default and known pattern to users.

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

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

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

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

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

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

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

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

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

Ensure, visually hidden elements cannot receive keyboard focus.

Especially elements in collapsed accordion items, non-active tabs, and un-opened dialog windows should not receive keyboard focus.

If they can receive keyboard focus, the elements must be made clearly visible on receiving keyboard focus. This is a common method to hide skip links and un-hide them on keyboard focus, using e.g. a CSS class visually-hidden with selector .visually-hidden:not(:focus):not(:active).

Ensure, for all dynamically added content that can be activated by user,

• focus cannot be set to focusable elements inside content, before content is being visually added (e.g. collapsed accordion items, or not yet opened dialog windows)

• dynamic content should be placed directly below the triggering element in the DOM order

• Opening e.g. a dialog window, will set the focus on the first focusable element inside the dialog window

• Activating a "Load more" button must ensure, focus, after content is loaded, either

  • is set to the first focusable element of newly loaded content or

  • is set to the first preceding focusable element of newly loaded content.

Ensure, for all dynamically added and then removed content that can be activated by user,

• keyboard focus

  • remains (e.g. collapsing/expanding accordion items) on the triggering element or

  • is set to (e.g. opening and closing a dialog window) the triggering element again.

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 purpose equivalent text alternatives are present for every non-decorative image. Depending on the purpose, the text alternative may be describing the contents of an image or the functionality it serves (e.g. as a link to a specific page).

Ensure, no information that is not visible in the image, is conveyed via alt attribute but all information that is visible, is conveyed.