5G Netz (2 issues)
Footnote dialog window does not receive keyboard focus on open
+
Dialog window does not receive keyboard focus
+
Aktionen (3 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Dialog window does not receive keyboard focus
+
Footnote dialog window does not receive keyboard focus on open
+
Alle Geräte (5 issues)
"Weiter ohne Gerät" link not accessible via keyboard
+
Interactive elements in sidebar (links, buttons) not accessible via keyboard
+
Filter dialog window cannot be opened or operated
+
Dialog window does not receive keyboard focus
+
Footnote dialog window does not receive keyboard focus on open
+
Apple (2 issues)
Footnote dialog window does not receive keyboard focus on open
+
Dialog window does not receive keyboard focus
+
Apple Watch Familienkonfiguration (2 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Dialog window does not receive keyboard focus
+
Apple iPad Air 11 2025 (2 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Dialog window does not receive keyboard focus
+
Flex Tarife Weitere Informationen (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Handy Verkaufen (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Handyversicherung (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
IoT-Verteilerseite (2 issues)
FAQ not accessible via keyboard
+
Dialog window does not receive keyboard focus
+
Kider Uhr GPS Oneshop (4 issues)
Footnote dialog window does not receive keyboard focus on open
+
Video player controls in dialog windows cannot be operated by keyboard
+
Anchor links ("Notfallknopf", "GPS Standorte", ...) do not set focus correctly
+
Collapsible in intro section "... funktioniert im Schulmodus so" not keyboard accessible
+
Kids-Watch (5 issues)
Footnote dialog window does not receive keyboard focus on open
+
Video player controls in dialog windows cannot be operated by keyboard
+
Dialog window does not receive keyboard focus
+
Anchor links ("Notfallknopf", "GPS Standorte", ...) do not set focus correctly
+
Collapsible in intro section "... funktioniert im Schulmodus so" not keyboard accessible
+
Magena Sport (3 issues)
Footnote dialog window does not receive keyboard focus on open
+
Dialog window content cannot be scrolled by keyboard
+
Dialog window does not receive keyboard focus
+
Magenta TV Streaming Dienste Partner DAZN (4 issues)
Footnote dialog window does not receive keyboard focus on open
+
Video trailer dialog window does not receive keyboard focus on open
+
Dialog window does not receive keyboard focus
+
League information collapsible does not receive keyboard focus on open
+
Magenta TV Streaming Dienste Partner wow (2 issues)
Footnote dialog window does not receive keyboard focus on open
+
Dialog window does not receive keyboard focus
+
Magenta Tarife Young (3 issues)
Dialog window does not receive keyboard focus
+
Footnote dialog window does not receive keyboard focus on open
+
Disabled button does not use disabled attribute
+
Mobile Router (3 issues)
Device category links not accessible via keyboard
+
Filter dialog window cannot be opened or operated
+
Dialog window does not receive keyboard focus
+
Mobilfunk Netzausbau (3 issues)
Footnote dialog window does not receive keyboard focus on open
+
"Info" dialog window does not trap keyboard focus on open
+
Dialog window does not receive keyboard focus
+
Prepaid Tarife (2 issues)
Dialog window does not receive keyboard focus
+
Footnote dialog window does not receive keyboard focus on open
+
Roaming Optionen (6 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Dialog window does not receive keyboard focus
+
Content of Dialog Windows not scrollable
+
ESC closes dialog window instead of combobox
+
Accordion in search results not accessible
+
Tab content reachable, despite no interactive element available
+
Senioren Smartwatch (5 issues)
FAQ not accessible via keyboard
+
Interactive elements are not focusable by keyboard
+
Video player controls in dialog windows cannot be operated by keyboard
+
Dialog window does not receive keyboard focus
+
Dialog window does not receive keyboard focus
+
Shop (1 issues)
Dialog window does not receive keyboard focus
+
Smartphone Tarife (2 issues)
Dialog window does not receive keyboard focus
+
Dialog window does not receive keyboard focus
+
Smartphones (4 issues)
Device category links not accessible via keyboard
+
Filter dialog window cannot be opened or operated
+
Dialog window does not receive keyboard focus
+
Footnote dialog window does not receive keyboard focus on open
+
Smartwatch mit Gesundheitsfunktionen (5 issues)
FAQ not accessible via keyboard
+
Interactive elements are not focusable by keyboard
+
Collapsible elements not accessible via keyboard
+
Video player controls in dialog windows cannot be operated by keyboard
+
Dialog window does not receive keyboard focus
+
Smartwatches (4 issues)
Device category links not accessible via keyboard
+
Filter dialog window cannot be opened or operated
+
Dialog window does not receive keyboard focus
+
Footnote dialog window does not receive keyboard focus on open
+
Sonim XP100 (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Sport (3 issues)
Sports channel selection not keyboard accessible
+
Footnote dialog window does not receive keyboard focus on open
+
Dialog window does not receive keyboard focus
+
Sport Megasport Option (5 issues)
League information collapsible cannot be opened by SPACE/ENTER
+
Video trailer dialog window does not receive keyboard focus on open
+
Dialog window does not receive keyboard focus
+
League information collapsible does not receive keyboard focus on open
+
"Auswahlfeld" dropdown list not fully keyboard accessible
+
Tablets (3 issues)
Device category links not accessible via keyboard
+
Filter dialog window cannot be opened or operated
+
Dialog window does not receive keyboard focus
+
Tarife (2 issues)
FAQ not accessible via keyboard
+
Dialog window does not receive keyboard focus
+
Tastenhandys (3 issues)
Device category links not accessible via keyboard
+
Filter dialog window cannot be opened or operated
+
Dialog window does not receive keyboard focus
+
Travel Mobil Optionen (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
VIP Lieferung (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Vertragsverlängerung (2 issues)
Dialog window does not receive keyboard focus
+
Footnote dialog window does not receive keyboard focus on open
+
Xiaomi 15 (2 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Dialog window does not receive keyboard focus
+
iPad Vergleich (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
iPhone Erleben (2 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Dialog window does not receive keyboard focus
+
iPhone Vergleich (1 issues)
Interactive element, operable by mouse, not accessible by keyboard
+
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Accompanying Files
Observation Details
The tabs for "So aktivieren Sie Datenroaming im Ausland" can be navigated by keyboard, the content can be focused despite having no interactive elements inside. Non-interactive elements should not be focusable via TAB key.
Accompanying Files
Observation Details
Dialog windows can be opened via keyboard navigation. Inside the dialog window, TAB key is properly moving focus to interactive element (close button). ARROW UP / DOWN however do not work to scroll the dialog window content, making the list inaccessible to keyboard-only users. Using ARROW UP / DOWN scrolls the main page content below the dialog window.
See dialog windows with scrollable content. E.g.:
"Ländergruppe 3"
"Mobilfunknutzung auf Schiffen und Flugzeugen" (inside "Kann ich Roaming auf Schiffs- und Flugreisen nutzen?" FAQ accordion item)
Remediation Notes
Ensure keyboard focus moves to opened dialog window and is trapped within the content. Evaluate the use of Dialog HTML element <dialog>.
Observation Details
ESC key must close an opened selection/dropdown/combobox. ESC key on "Partnernetze" combobox is closing the dialog window instead.
Remediation Notes
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.
Observation Details
The search results of the input element uses accordions to group certain results. The accordions are interactive by mouse, but cannot be navigated nor operated by keyboard.
Remediation Notes
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 | ... |
... | ✅ | ❌ |Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Accompanying Files
Observation Details
Filter button is not accessible. All filtering is impossible to be operated by keyboard.
Inside filter dialog window, only collapsible and "main buttons" at dialog window bottom are accessible via keyboard navigation. All other elements are not.
All interactive elements MUST be accessible via keyboard. As a Level A success criterion, it is crucial for operating a website.
Remediation Notes
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>Accompanying Files
Observation Details
"Weiter ohne Gerät" link does not have an href attribute set, basically making it a "non-link" element. An <a> without href attribute is not considered a link.
Remediation Notes
All <a> elements MUST have an href attribute.
Accompanying Files
Observation Details
All interactive elements MUST be able to be navigated to/from and operated by keyboard. All interactive elements in sidebar do not match this requirement.
Remediation Notes
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.
Accompanying Files
Observation Details
Device category links do not use interactive semantic HTML elements. Thus is not accessible via keyboard and is not announced as interactive for screen reader users as well.
Remediation Notes
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.
Observation Details
FAQ section cannot be reached by keyboard navigation as the interactive elements are custom built and do not use correct semantic HTML.
Remediation Notes
Ensure, using correct semantic HTML elements for all interactive elements. In case of accordions, these could be <detail> and <summary> constructs or ones with <button> as the accordion item "header".
Keyboard navigation is a must.
For custom building an accessible accordion component, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a video trailer dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a league information collapsible, the keyboard focus is not set to said content.
The contents of the area are not accessible via keyboard directly (after opening the collapsible, the shown content area must be the next focusable content)
Remediation Notes
Opening a collapsible with the keyboard must ensure the shown content area to be the next focusable area. The collapsible uses "accordion" functionality.
A better approach would be to use a <details> and <summary> elements for those collapsibles.
Refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion" for necessary steps to ensure accessibility of accordion components / collapsibles.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening the "Info" dialog window in the interactive map, the keyboard focus is not trapped in said dialog window. This leads to these observations:
The non-interactive contents of the dialog window are not accessible via keyboard (scrolling should be available with ARROW keys).
Keyboard navigation out of the dialog window is possible. This can be the desired way and on its own is no failure of this criterion, as moving out of the dialog window while open, will move the focus out of the map completely, thus not interfering with other content.
Remediation Notes
Opening a dialog window with the keyboard sets the focus into the dialog window and traps it within the map component but not the whole page. This means, scrolling inside the dialog window is not possible with ARROW keys. Ensure, next to TAB for navigating interactive elements, ARROW keys can be used for navigating non-interactively (scrolling text content) within the dialog window.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
The selection of sports channels in section "Welchen Sport wollen Sie live bei MagentaTV sehen?" is not accessible by keyboard navigation. Depending on classification of page purpose, the selection of sports channels, leading to the recommendation of a tariff option ("Empfehlung" system) is a main function of the page. Having this function not available to keyboard users is a crucial error.
The interactive elements for the sports channel selection do not use semantic HTML structure and trying to rebuild functionality with non-interactive or with different interactive elements. E.g. a button element is used with a switch role to mimic functionality of a checkbox.
Remediation Notes
Ensure keyboard navigation is possible by using proper semantic HTML elements. For checkbox functionality for channel images, use base structure of
<div>
<fieldset aria-describedby="sports-hint">
<legend>
<h2>
Welchen Sport wollen Sie live bei MagentaTV sehen?
</h2>
</legend>
<div id="sports-hint">
Wählen Sie alle zutreffenden Optionen
</div>
<div>
<div>
<input id="sports-1" name="sports" type="checkbox" value="bundesliga">
<label for="sports-1">
<img src="..." alt="Bundesliga" />
</label>
</div>
<div>
<input id="sports-2" name="sports" type="checkbox" value="bundesliga2">
<label for="sports-2">
<img src="..." alt="2. Bundesliga" />
</label>
</div>
<div>
<input id="sports-3" name="sports" type="checkbox" value="bundesliga3">
<label for="sports-3">
<img src="..." alt="3. Liga" />
</label>
</div>
...
</div>
</fieldset>
</div>The accordion functionality (expanding/collapsing sports categories) could be built with a <details> & <summary> construct. For more information about accordions, you can also see BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion" and "GOV.UK Design System – Accordion"
By using existing semantic HTML elements instead of rebuilding functionality with generic elements, keyboard navigation can be ensured.
Observation Details
When opening a video trailer dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
When opening a league information collapsible, the keyboard focus is not set to said content.
The contents of the area are not accessible via keyboard directly (after opening the collapsible, the shown content area must be the next focusable content)
Remediation Notes
Opening a collapsible with the keyboard must ensure the shown content area to be the next focusable area. The collapsible uses "accordion" functionality.
A better approach would be to use a <details> and <summary> elements for those collapsibles.
Refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion" for necessary steps to ensure accessibility of accordion components / collapsibles.
Observation Details
League information collapsibles use generic containers to build interactive functionality.
<div role="button" tabindex="0">
<img alt="Bundesliga Logo" src="...">
</div>The element can receive keyboard focus but is not activated with click on SPACE / ENTER.
Remediation Notes
Use semantic HTML elements for interactive elements instead of rebuilding them from generic elements. Use <button> element to ensure possibility of keyboard navigation. This also removes the need of manually setting role attribute and tab index.
Side note: As the buttons are used to collapse / expand information, consider evaluating the use of a <details> & <summary> structure to get accordion functionality.
Side note: As the used image is a functional image, the text alternative must describe the purpose of the button's function rather than describing the image's contents.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Observation Details
FAQ section cannot be operated (expand / collapse) by keyboard navigation as the interactive elements are custom built and do not use correct semantic HTML. The FAQ accordion uses an HTML description list <dl>. Example code:
<dt class="accordion__term" data-accordion="term" tabindex="0">
<h3 class="accordion__title">...</h3>
</dt>
<dd
class="accordion__description accordion__description--hidden"
data-open-class="accordion__description--open"
data-hidden-class="accordion__description--hidden"
data-accordion="description"
>
<div class="accordion__content">
<p class="paragraph">...</p>
</div>
</dd>Observations about the example code:
Description lists consist of terms and descriptions. An FAQ question item can not be considered a term.
Setting
tabindex="0"to allow keyboard focus of non-interactive element is bad practice and should be avoideddata-*attributes in description try to build accordion functionality<div class="accordion__content">is an unnecessary hierarchy levelA CSS paragraph class
<p class="paragraph">should not ever be needed
Remediation Notes
Ensure, using correct semantic HTML elements for all interactive elements. In case of accordions, these could be <detail> and <summary> constructs or ones with <button> as the accordion item "header".
Keyboard navigation is a must.
For custom building an accessible accordion component, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".
Observation Details
FAQ section cannot be operated (expand / collapse) by keyboard navigation as the interactive elements are custom built and do not use correct semantic HTML. The FAQ accordion uses an HTML description list <dl>. Example code:
<dt class="accordion__term" data-accordion="term" tabindex="0">
<h3 class="accordion__title">...</h3>
</dt>
<dd
class="accordion__description accordion__description--hidden"
data-open-class="accordion__description--open"
data-hidden-class="accordion__description--hidden"
data-accordion="description"
>
<div class="accordion__content">
<p class="paragraph">...</p>
</div>
</dd>Observations about the example code:
Description lists consist of terms and descriptions. An FAQ question item can not be considered a term.
Setting
tabindex="0"to allow keyboard focus of non-interactive element is bad practice and should be avoideddata-*attributes in description try to build accordion functionality<div class="accordion__content">is an unnecessary hierarchy levelA CSS paragraph class
<p class="paragraph">should not ever be needed
Remediation Notes
Ensure, using correct semantic HTML elements for all interactive elements. In case of accordions, these could be <detail> and <summary> constructs or ones with <button> as the accordion item "header".
Keyboard navigation is a must.
For custom building an accessible accordion component, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".
Observation Details
FAQ section cannot be operated (expand / collapse) by keyboard navigation as the interactive elements are custom built and do not use correct semantic HTML. The FAQ accordion uses an HTML description list <dl>. Example code:
<dt class="accordion__term" data-accordion="term" tabindex="0">
<h3 class="accordion__title">...</h3>
</dt>
<dd
class="accordion__description accordion__description--hidden"
data-open-class="accordion__description--open"
data-hidden-class="accordion__description--hidden"
data-accordion="description"
>
<div class="accordion__content">
<p class="paragraph">...</p>
</div>
</dd>Observations about the example code:
Description lists consist of terms and descriptions. An FAQ question item can not be considered a term.
Setting
tabindex="0"to allow keyboard focus of non-interactive element is bad practice and should be avoideddata-*attributes in description try to build accordion functionality<div class="accordion__content">is an unnecessary hierarchy levelA CSS paragraph class
<p class="paragraph">should not ever be needed
Remediation Notes
Ensure, using correct semantic HTML elements for all interactive elements. In case of accordions, these could be <detail> and <summary> constructs or ones with <button> as the accordion item "header".
Keyboard navigation is a must.
For custom building an accessible accordion component, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Accompanying Files
Observation Details
Anchor links for on-page navigation are built using HTML button elements. Operating the link by keyboard, scrolls the page to the intended heading / section but does not move the focus. The focus stays on the link.
Remediation Notes
On-page navigation is done by links. To create a link, ensure using the semantic HTML link element <a> with a valid href attribute, referencing the id attribute's value of the intended target element.
<a href="#SosTasteSection">Notfallknopf</a><a href="#GpsTrackingSection">GPS-Standorte</a><a href="#Ausgezeichnet">Ausgezeichnete Qualität</a><a href="#ESimSection">Easy mit eSIM</a>
Side note: When remediating this issue, please also ensure correct order of navigation elements to match content order and optionally using a semantic navigation element <nav> for the navigation list.
Observation Details
The video player in dialog windows cannot be operated by keyboard. The dialog window can be opened and closed by keyboard but the video player controls are not accessible via keyboard navigation.
Keyboard focus is trapped (also see 2.1.2 No Keyboard Trap) on close button.
Remediation Notes
Ensure keyboard accessibility of all interactive elements.
Accompanying Files
Observation Details
The collapsible (caret icon) in intro section "Die Kinder Smartwatch XPLORA X6 Play eSIM funktioniert im Schulmodus so" can be expanded via keyboard navigation. Expanding the item should keep the focus on the same element so that a second click would collapse the item again.
Remediation Notes
Ensure keyboard accessibility by using semantic HTML elements, fitting the intended functionality. For a collapsible item, use the native dialog and summary elements and markup the code as follows (example structure):
<details>
<summary>
Der Schulmodus der XPLORA X6 Play eSIM Kids Smartwatch
</summary>
<ul>
<li>Eingehende Anrufe sind nicht möglich, sodass keine Ablenkung im Unterricht erfolgt.</li>
<li>Telefonieren ist nicht möglich, aber die SOS-Taste für Notfälle funktioniert auch im Schulmodus.</li>
<li>Das Kind kann auch im Unterricht oder in der Pause in einer Notsituation einen Notruf über die SOS-Taste absetzen.</li>
<li>Mit der Funktion „sichere Bereiche“ kann festgelegt werden, wo sich das Kind aufhalten darf.</li>
<li>Über das GPS-Tracking der Kids Watch wird transparent, wenn das Kind den sicheren Bereich verlässt.</li>
</ul>
</details>Accompanying Files
Observation Details
A variety of interactive elements are not focusable by keyboard navigation. This includes the collapsible in main heading section and the link list of different medical conditions. The collapsible uses a generic HTML element:
<div class="..." data-subline-addition="expander"></div>The links in the medical conditions link list do not have the obligatory href attribute for HTML link element:
<a data-scroll-trigger="epilepsie" data-tealium-rel="..." class="...">
Epilepsie
</a>Remediation Notes
Ensure, using correct semantic HTML elements for functionality that can be built using native HTML. Use proper HTML links by adding href attributes with target element's ID:
<a href="#epilepsie">Epilepsie</a>Consider use of HTML navigation element, as the list functions as on-page navigation to scroll to different sections.
For a collapsible element, ensure using the native details and summary elements:
<details>
<summary>Eine Smartwatch mit Gesundheitsfunktionen, wie die</summary>
<p>Safety Watch, unterstützt z. B. im Alltag, indem ...</p>
</details>Observation Details
The video player in dialog windows cannot be operated by keyboard. The dialog window can be opened and closed by keyboard but the video player controls are not accessible via keyboard navigation.
Keyboard focus is trapped (also see 2.1.2 No Keyboard Trap) on close button.
Remediation Notes
Ensure keyboard accessibility of all interactive elements.
Accompanying Files
Observation Details
A variety of interactive elements are not focusable by keyboard navigation. This includes the collapsible in main heading section and the link list of different watch functions. The collapsible uses a generic HTML element:
<div class="..." data-subline-addition="expander"></div>The links in the watch functions link list do not have the obligatory href attribute for HTML link element:
<a data-scroll-trigger="telefonfunktion" data-tealium-rel="..." class="...">
Telefonfunktion
</a>Remediation Notes
Ensure, using correct semantic HTML elements for functionality that can be built using native HTML. Use proper HTML links by adding href attributes with target element's ID:
<a href="#telefonfunktion">Telefonfunktion</a>Consider use of HTML navigation element, as the list functions as on-page navigation to scroll to different sections.
For a collapsible element, ensure using the native details and summary elements:
<details>
<summary>Eine Safety Watch ist eine Smartwatch, die ...</summary>
<p>...</p>
</details>Observation Details
The video player in dialog windows cannot be operated by keyboard. The dialog window can be opened and closed by keyboard but the video player controls are not accessible via keyboard navigation.
Keyboard focus is trapped (also see 2.1.2 No Keyboard Trap) on close button.
Remediation Notes
Ensure keyboard accessibility of all interactive elements.
Observation Details
Footnote dialog window is not keyboard accessible.
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
When opening a dialog window:
The non-interactive contents of the dialog window are not accessible via keyboard.
Dialog window "Alle Geräte ansehen" can be opened and closed by keyboard but contents cannot be scrolled by keyboard.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
The non-interactive content of the dialog window, when overflowing, must be accessible via scrolling by keyboard navigation (ARROW UP / DOWN).
Observation Details
Disabled navigation arrow buttons in "Young Smartphone Angebote" product carousel does not use HTML attribute disabled but only aria-disabled="true". While this results in correct "dimmed" announcement to assistive technology, keyboard navigation still allows focusing the button without providing information about its disabled state.
Observation Details
Navigation links using button elements. Clicking navigation links will result in scrolling page to section but keeping focus on triggering element (button).
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Accompanying Files
Observation Details
Filter button is not accessible. All filtering is impossible to be operated by keyboard.
Inside filter dialog window, only "main buttons" at dialog window bottom are accessible via keyboard navigation. All other elements are not.
All interactive elements MUST be accessible via keyboard. As a Level A success criterion, it is crucial for operating a website.
Remediation Notes
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>Accompanying Files
Observation Details
Device category links do not use interactive semantic HTML elements. Thus is not accessible via keyboard and is not announced as interactive for screen reader users as well.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Accompanying Files
Observation Details
Filter button is not accessible. All filtering is impossible to be operated by keyboard.
Inside filter dialog window, only collapsible and "main buttons" at dialog window bottom are accessible via keyboard navigation. All other elements are not.
All interactive elements MUST be accessible via keyboard. As a Level A success criterion, it is crucial for operating a website.
Remediation Notes
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>Accompanying Files
Observation Details
Device category links do not use interactive semantic HTML elements. Thus is not accessible via keyboard and is not announced as interactive for screen reader users as well.
Remediation Notes
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.
Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Accompanying Files
Observation Details
Filter button is not accessible. All filtering is impossible to be operated by keyboard.
Inside filter dialog window, only collapsible and "main buttons" at dialog window bottom are accessible via keyboard navigation. All other elements are not.
All interactive elements MUST be accessible via keyboard. As a Level A success criterion, it is crucial for operating a website.
Remediation Notes
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>Accompanying Files
Observation Details
Device category links do not use interactive semantic HTML elements. Thus is not accessible via keyboard and is not announced as interactive for screen reader users as well.
Remediation Notes
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.
Accompanying Files
Observation Details
Filter button is not accessible. All filtering is impossible to be operated by keyboard.
Inside filter dialog window, only collapsible and "main buttons" at dialog window bottom are accessible via keyboard navigation. All other elements are not.
All interactive elements MUST be accessible via keyboard. As a Level A success criterion, it is crucial for operating a website.
Remediation Notes
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>Accompanying Files
Observation Details
Device category links do not use interactive semantic HTML elements. Thus is not accessible via keyboard and is not announced as interactive for screen reader users as well.
Remediation Notes
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.
Accompanying Files
Observation Details
Filter button is not accessible. All filtering is impossible to be operated by keyboard.
Inside filter dialog window, only collapsible and "main buttons" at dialog window bottom are accessible via keyboard navigation. All other elements are not.
All interactive elements MUST be accessible via keyboard. As a Level A success criterion, it is crucial for operating a website.
Remediation Notes
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>Observation Details
When opening a footnote dialog window, the keyboard focus is not set to said dialog window. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed with the keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view.
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
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.
Accompanying Files
Observation Details
Anchor links for on-page navigation are built using HTML button elements. Operating the link by keyboard, scrolls the page to the intended heading / section but does not move the focus. The focus stays on the link.
Remediation Notes
On-page navigation is done by links. To create a link, ensure using the semantic HTML link element <a> with a valid href attribute, referencing the id attribute's value of the intended target element.
<a href="#SosTasteSection">Notfallknopf</a><a href="#GpsTrackingSection">GPS Standorte</a><a href="#Uhrzeitlernen">Uhrzeitlernen</a><a href="#Schulmodus">Schulmodus</a>
Side note: When remediating this issue, please also ensure correct order of navigation elements to match content order and optionally using a semantic navigation element <nav> for the navigation list.
Observation Details
The video player in dialog windows cannot be operated by keyboard. The dialog window can be opened and closed by keyboard but the video player controls are not accessible via keyboard navigation.
Keyboard focus is trapped (also see 2.1.2 No Keyboard Trap) on close button.
Remediation Notes
Ensure keyboard accessibility of all interactive elements.
Accompanying Files
Observation Details
The collapsible (caret icon) in intro section "Das Besondere an der Anio 6 ist die Reduktion auf das Wesentliche:" can be expanded via keyboard navigation. Expanding the item should keep the focus on the same element so that a second click would collapse the item again.
Remediation Notes
Ensure keyboard accessibility by using semantic HTML elements, fitting the intended functionality. For a collapsible item, use the native dialog and summary elements and markup the code as follows (example structure):
<details>
<summary>
...
</summary>
<ul>
<li>...</li>
<...
</ul>
</details>Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Accompanying Files
Observation Details
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
CAPTCHA reload icon button not operable by keyboard
Button uses non-semantic
<span>Button is hidden by using
aria-hidden="true"
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Ensure no interactive element that must be accessible is hidden from assistive technology by method of aria-hidden="true" or any other method for that matter.
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).
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
Footnote dialog window is not keyboard accessible.
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Accompanying Files
Observation Details
Device thumbnails + thumbnail gallery pagination
"Speichergröße"
"Einmalzahlung"
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
Footnote dialog window is not keyboard accessible.
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Accompanying Files
Observation Details
Device thumbnails
"Speichergröße"
"Einmalzahlung"
"Handyversicherung"
Details button
"radio buttons"
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Accompanying Files
Observation Details
The "Auswahlfeld" is using role="combobox", making the element a dropdown list. The dropdown list has limited keyboard accessibility. Observations:
Dropdown cannot be opened by
ALT+DOWN ARROW
UP/DOWN ARROW
Text input
Dropdown cannot be closed by
ALT+UP ARROW
ENTER
TAB
(Mouse click on triggering element)
Selecting list item and closing dropdown via ESC, keyboard focus is moved away from triggering element
Selection of list items not possible by
UP ARROW, DOWN ARROW
POS1, END
PAGE UP, PAGE DOWN
Entry of one or more characters (within a short time)
Remediation Notes
If presentation as drop-down list via role="combobox" is necessary, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Drop-down list" for technical requirements.
Alternatively, a simpler approach might be the use of a selection list instead. Please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Selection list" for technical requirements.
Observation Details
Collapsible elements throughout the page cannot be operated (expand / collapse) by keyboard navigation as the interactive elements are custom built and do not use correct semantic HTML. The elements use an HTML description list <dl>. Example code from FAQ:
<dt class="accordion__term" data-accordion="term" tabindex="0">
<h3 class="accordion__title">...</h3>
</dt>
<dd
class="accordion__description accordion__description--hidden"
data-open-class="accordion__description--open"
data-hidden-class="accordion__description--hidden"
data-accordion="description"
>
<div class="accordion__content">
<p class="paragraph">...</p>
</div>
</dd>Observations about the example code:
Description lists consist of terms and descriptions. An FAQ question item can not be considered a term.
Setting
tabindex="0"to allow keyboard focus of non-interactive element is bad practice and should be avoideddata-*attributes in description try to build accordion functionality<div class="accordion__content">is an unnecessary hierarchy levelA CSS paragraph class
<p class="paragraph">should not ever be needed
Remediation Notes
Ensure, using correct semantic HTML elements for all interactive elements. In case of accordions, these could be <detail> and <summary> constructs or ones with <button> as the accordion item "header".
Keyboard navigation is a must.
For custom building an accessible accordion component, please refer to BFIT-Bund Handreichung "Accessible design of user interface elements – Accordion".
Observation Details
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Examples:
Navigation arrow buttons in section "Unser nachhaltiger Smartphone-Kreislauf" use
<div role="button">instead of semantic button elementFAQ uses
<dl>; FAQ items use<dt tabindex="0">instead of semantic button elements
Remediation Notes
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).
Observation Details
FAQ "Häufig gestellte Fragen zum Thema „iPad vergleichen“" uses definition list instead of interactive elements
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
FAQ "Häufig gestellte Fragen zum Thema „iPhone vergleichen“" uses definition list instead of interactive elements
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
"Zum Wunschtermin buchen" buttons use non-semantic HTML and as such are not focusable and operable by keyboard
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Accompanying Files
Observation Details
Selection inputs not operable by keyboard as it does not use semantic HTML selection element:
"Modell"
"Farbe"
"Speicher"
Selection input element can be navigated to and from and opened and closed; a selection however cannot be made by the required input methods ARROW UP / DOWN.
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
Please refer to BFIT-Bund Handreichung "Accessible design of user interface elements" and see Dropdown / Selection list for technical requirements.
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).
Observation Details
"Telekom Netz" link in 5G / Netz dialog windows cannot always be interacted with by keyboard navigation. There are three occurrences of said dialog window on the page.
Navigating by keyboard only,
opening the first dialog window, moving to link and back to close button, closing the dialog window again.
Repeating this for the other two dialog windows, the dialog windows will open but leaving the link inside unable to be accessed by keyboard navigation.
This is usually happening when non-semantic HTML elements are used and functionality is not properly re-built with JavaScript and ARIA.
Remediation Notes
All interactive elements should use existing, native, semantic HTML elements to avoid these errors. For technical requirements, also refer to BFIT-Bund Handreichung "Accessible design of user interface elements" (Dialog windows).
Note: As this observation is marked in 2.1.1 Keyboard, it will not again be marked in 4.1.2 Name, Role, Value again, despite being an issue of both success criteria. The observation should be remediated with high priority, as footnote dialog windows are being used globally on most pages.
Accompanying Files
Observation Details
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Observation Details
CAPTCHA reload icon button not operable by keyboard
Button uses non-semantic
<span>Button is hidden by using
aria-hidden="true"
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).
Ensure no interactive element that must be accessible is hidden from assistive technology by method of aria-hidden="true" or any other method for that matter.
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).
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Interactive element, operable by mouse, not accessible by keyboard
+
Dialog window does not receive keyboard focus
+
Observation Details
When opening a dialog window (e.g. via footnote or info icon), said dialog window does not receive keyboard focus. This leads to multiple issues:
The contents of the dialog window are not accessible via keyboard.
The dialog window can not be closed by keyboard (easily or at all).
While the dialog window is open, keyboard navigation of the underlying page is still possible; the dialog window however blocks the view. (see also 2.4.11 Focus Not Obscured (Minimum))
Since keyboard navigation stays possible, opening multiple dialog windows above each other also is possible.
Remediation Notes
Opening a dialog window by keyboard navigation must set the focus to the dialog window's content. Opening a dialog window must trap keyboard focus inside the dialog window, so underlying content cannot be accessed while dialog window is opened. Closing the dialog window, focus must be set to the triggering element again.
Ideally, the first focusable element in a dialog window can be used to close the dialog window, so opening and closing of a dialog window can be done without the need of navigating through other focusable elements. Although simple dialog windows, e.g. asking for confirmation, and providing "Accept" and "Cancel" buttons, might not have an explicit "Close" button and may set focus to the dialog window's "main purpose action" instead.
Observation Details
Interactive element can be operated by mouse but not by keyboard. The issue may occur when:
Non-semantic HTML elements (e.g.
<div>,<span>) are used for interactive purposes (e.g. links, buttons, inputs), instead of semantic HTML elements (e.g.<a href="">,<button>). This often also leads to other issues, concerning 4.1.2 Name, Role, Value.Semantic elements are used but required attributes are missing (e.g.
<a>, missinghrefattribute)Semantic HTML elements are mis-used (e.g.
<a>used as a button, or<button>used as a link)
Remediation Notes
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).