Project

General

Profile

Actions

Bug #103973

closed

Missing sectioning for CE header

Added by Swen Greif 6 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Content Rendering
Target version:
-
Start date:
2024-06-04
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
Tags:
Accessibility
Complexity:
Is Regression:
Sprint Focus:

Description

During an Accessibility Check of one of our websites, the certificated tester told us that the <header>-tag of the Content Elements is an issue for Accessibility. As the <header> -element of CE are only embedded in generic <div> it is associated automatically to the <body> of the site, and therefore it is treated like a banner landmark.

The <header> element has an identical meaning to the site-wide banner landmark role, unless nested within sectioning content. Then, the <header> element is not a landmark.

[[https://developer.mozilla.org/en-US/docs/Web/HTML/Element/header?retiredLocale=de#usage_notes]]

For accessibilty reasons and to have a clear structure, there should only be one <header> ( and <footer>) Element in the body. Additional structure Elements should be embedded into a sectioning-content-element ( <article> , <aside>, <main>, <nav>, or <section> element).


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Epic #97395: Improve accessibility of FrontendNew2020-09-04

Actions
Actions #1

Updated by Garvin Hicking 6 months ago

  • Status changed from New to Closed

Hi!

Thanks a lot for forwarding this to us. The implementation of content elements is commonly part of the integrator's work. The default templates just provide a small "stub" to work from, and integrators can enhance this with the mentioned HTML tags. So we regard this as a matter of the integrator's domain.

The "Bootstrap package" template tries to address this, and several other sitepackages have implementations for it. Generally, efforts are being made to make also the TYPO3 default HTML output more accessible, and this is part of the general TYPO3 v13 effort, for which distinct epics/issues are created. Also the "Content Blocks" extension will allow integrators to easier switch between different HTML-frontend implementations of content elements that can address this markup.

We cannot easily change and add HTML tags to the core's default Content-Element output, as this might then break the frontend of existing installations, so this must always be well-considered, and breaking changes can also no longer happen in TYPO3v13, but will be continued to work in in TYPO3v14.

I will close this issue for now to not create redundancy.

Actions #2

Updated by Mathias Brodala 6 months ago

I wonder why this was closed right away instead of keeping it open. This is a valid issue and TYPO3 recently put a lot of work into improving accessibility.

While it is true that this may be a breaking change to be introduced as early as v14 it could be added to v13 too e.g. using a feature toggle. Even without the latter an Important RST could be added to v13 to notify about the upcoming change for v14.

As for "to not create redundancy": does this mean that there is a similar ticket anywhere already which this one duplicates? If not then I'd vote for reopening it and keeping it on the umbrella for upcoming FE rendering changes.

Actions #3

Updated by Garvin Hicking 6 months ago

  • Related to Epic #97395: Improve accessibility of Frontend added
Actions #4

Updated by Garvin Hicking 6 months ago

We somehow need to triage and decide what to do with issues, this is currently an effort made by Ricardo, Georg, Benni and me. This was the reason and we discussed this in the "working group", but of course feedback is always welcome and possible :)

I've now associated the Epic https://forge.typo3.org/issues/97395 with this issue and would prefer to keep this one closed though for a "leaner" issue tracking.

Would that be okay with you?

Actions

Also available in: Atom PDF