T63801 should be present here, we need to distinguish the content from the footer of the page, which is important for screen readers.

@Rezonansowy This is not true as long as role=contentinfo is present in the markup at the contentinfo element. The new HTML5 sectioning elements are just mapped to the corresponding ARIA roles.
IE up to v11 doesn't support any of the mapping of HTML5 structural elements like for example <footer> to role=contentinfo.
As long as we use ARIA role attributes we're well-supporting older and current browsers/screen readers. That was the reason for me to remove this task from the specific UI-Standardization goal.

In T111117#1898484, @Volker_E wrote:

@Rezonansowy This is not true as long as role=contentinfo is present in the markup at the contentinfo element. The new HTML5 sectioning elements are just mapped to the corresponding ARIA roles.
IE up to v11 doesn't support any of the mapping of HTML5 structural elements like for example <footer> to role=contentinfo.
As long as we use ARIA role attributes we're well-supporting older and current browsers/screen readers. That was the reason for me to remove this task from the specific UI-Standardization goal.

But how the screen reader could detect where's the page's footer? It's important, as there are such information like: when the page was last modified or the license of the content and others. These things should be provided to the user by some way.

@Rezonansowy I might misunderstand what you're referring to. But that's exactly what the already present role=contentinfo is for. See for example view-source:https://en.wikipedia.org/wiki/WAI-ARIA - Source of WAI-ARIA article on English Wikipedia:

<div id="footer" role="contentinfo">

@Volker_E But the content and footer are not the same. They both contain some information, but they should be distinguished in some way. Using <footer> is only idea, I know. That's why I carry T63801 on.

@Rezonansowy I still don't understand what you are referring here? What do you mean by content? A screen reader accesses the DOM in modern browsers via the accessibility tree. In Google Chrome you can see what's exposed by visiting chrome://accessibility/
It doesn't matter if you wrap the footer contents in a <footer> or a <div> element as long as the broader supported attribute role=contentinfo is available on either. There is currently no accessibility advantage on using <footer> over <div>, besides the future possibility of getting rid of the role attribute. But IE up to 11 and also older browsers need us to stay with the attribute.

@Volker_E Like I said, footer div is not the same, as div with article contents. That's why HTML5 comes with aside, article and footer tags. Every piece of website should be named properly. And that's the accessibility deal. https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/landmarks.html

@Rezonansowy For whom is it not the same? For humans (developers in love with HTML5 semantic elements, like myself) or for rendering and parsing software? The article you're linking to is pointing out the same that I've laid out in my arguments above:

Similar functionality is available using the ARIA (Accessible Rich Internet Application) attributes role="banner", role="navigation", role="main" and role="contentinfo".

So there's currently no accessibility deal connected with not using <footer> as long as role=contentinfo is present in the footer div for parsing/rendering software/assistive technology. Is your definition of accessibility probably different than mine or might I miss something out?

@Volker_E Well, OK. If the article on the page has role=main, this would be enough to achieve this goal.

Since Jan 1, we entered a new quarter (Q3) and this task was our goal for the last quarter (Q2). We still have our eyes on these unchecked tasks and they are continuously being worked on and awaiting finalization.

We'll be renaming the [GOAL] part the label to avoid confusion.

In T111117#3445653, @Volker_E wrote:

This has been established as a task combining mixed topics on different products. We've been successfully tackling the technical parts of it, testing and documentation don't need this as umbrella task any further.

I had been thinking the same

@Volker_E closed this task as Resolved.

Sorry to bring this up here but https://www.mediawiki.org/wiki/Wikimedia_User_Interface has a "Collaborate with us" link which directly links to this resolved task. Should that link be changed? (Apart from that I do not know who "us" and "we" is in the text and basically all links under "Design Resources" are dead on that page.)

@Aklapper Thanks and updated (removed link here).