@Aklapper, @Ramsey-WMF Works fine! That was my mistake as there was userscript in the background which loaded even in Incognito mode...

@Aklapper I tried Chrome 65.0.3325.162 (Official Build) (64-bit) in Incognito mode. I also tried with a browser form Electron app in the problem is also persistent. Maybe it has something to do with cookies settings?

@Aklapper I tried logged out in incognito mode on the newest Google Chrome and it didn't work.

@Legoktm I proposed this beacuse IMO url actions like &action=edit should be superseded in favor of a uniform Special pages system.

<keygen> is deprecated now.
See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen

You can test it with any Wikipedia article.

@Volker_E Here's the correct example:

#mw-navigation h2 {
    visibility: hidden;
}

I tested it with #mw-navigation h2, using a Firefox Inspector. Seems to work.

@DanielFriesen , this seems to work only with browsers with a full support of CSS3,

{ visibility: none; z-index: -1; }

would be better

This is a bug in MediaWiki parser, which prevents to comment with lines on page talks for example. Normal priority would be OK here.

My suggested solution is that VE should not touch things it doesn't understands, like these for example.

Here's a Commons category for this app – https://commons.wikimedia.org/wiki/Category:Wikipedia_Metro_App

Here's Windows Store link: https://www.microsoft.com/en-us/store/apps/wikipedia/9wzdncrfhwm4

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

@Jdforrester-WMF What's the state of this bug? Is it fixed already?

@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

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

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.

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

If the T12467 has the 'Low', this should has the same as well. These bugs are strictly connected.

In T25932#1855091, @Volker_E wrote:

Updated task description to reflect current state of W3C HTML5 recommendation of 28 Oct 2014 and WHATWG HTML Living Standard of 4 Dec 2015 -- removing <hgroup> and adding <main>, <picture> and <progress>,
<audio> and <video> are already supported by Extension:TimedMediaHandler

In T93470#1138068, @Ciencia_Al_Poder wrote:

How does this "bug" affect accessibility?

Also, HTML is meant to be interpreted by machines, not humans. If you want to look at the generated HTML, you can prettify it with any online tool, or just open the developer tools of your browser

I added it to the accessibility group because there's no HTML-related bugs tag on Phabricator yet. It has been present on Bugzilla. Unfortunately, I don't know how to create this tag here. Such tag would apply to many bugs, like T13555. Could you help me with this?