Google snippets can include role="note" content. For example, you can see Google snippets for Wikipedia articles include <div role="note">See also...</div>, if you add "see also" to the search string.

Update re <figure> and <figcaption>:

At risk of straying off topic, I agree with Izno, use cases for <figure> aren't hard to find. There's a <div role="figure"> on en main page.

Thanks to @Jonesey95's report at en:Template talk:Noitalic: The same thing is happening inside navboxes at en. Apparently, whether the noitalic is inside a link or not.

Can anyone check the new "show" or "hide" label on IE11 + screen reader? (I don't have an IE11 capable machine.)

See the WAI-ARIA 1.1 role definitions to get started.

The parser shouldn't be overly strict. A one-item ul or ol is okay in the HTML spec. And there are reasons a wiki might legitimately want to do that. For example, a single placeholder item, with JavaScript to add or remove items to the list.

I think en: is, on the whole, amenable to breaking content out of layout tables. Even on en:Main Page, if the changes are invisible or too small to be noticed visually.

Ha, you beat me to this.

I agree with TheDJ - an infobox/sidebar skip link is easy to do with just template or module code, and a bit of JS or CSS if you want to hide the skip link.

I agree with use of <main>.

It's not a full solution, but MediaWiki since 1.27 allows <div role="complementary"> and <div role="note"> for part of the functionality of an <aside>.

As mentioned in T76100, this was fixed in 2015, in tidy-html5.

Thanks for the feedback.

Quick and dirty test page. Definition lists conforming or not conforming to HTML5 spec, with or without presentation role.

As Jdlrobson mentioned, TemplateStyles will solve this beautifully. In the meantime, as a temporary fix, the mobile-float-reset class is now added to Template:Stack's output element. It isn't ideal, as Template:Stack now takes 100% width in Minerva skin regardless of viewport size, but at least surrounding text can no longer be squished.

Mozilla devs leaning toward removing <style scoped> support, see Bugzilla 1291515.

Getting close to a patch.

Oh good, looks like there's already work being done on this!

There may be an alternative solution using WAI-ARIA roles.

If this is an issue of screen readers struggling with a single too-big landmark/region, could wrapping output in <section>-like <div>s do the trick?

tstarling suggested at Gerrit that validation on the role attribute is unnecessary, so this patch has been scaled way back. It now simply whitelists the aria-* and role attributes (and escapes id's passed as aria-* values, to avoid unexpected id mismatches).

I think it's safe to close this? includes/Sanitizer.php has whitelisted role="presentation" for all elements since 1.21.

It's a little surprising that the corner case of IE8 with JavaScript disabled is still taking priority over accessibility, nearly 5 years after IE8's last update.

I saw daniel also mentioned ARIA attributes, so the patch I submitted also whitelists a subset of aria-* attributes defining non-interactive properties, such as labels. Since they're non-interactive they're potentially useful even where user interaction like forms and scripts are not present. And since they all happen to be global properties, they're allowed on all elements by definition, so they can be dropped right into the $common array of attributes whitelisted for all elements.

WAI-ARIA roles allow HTML elements, such as <div>, to be given semantic associations for accessible browsing.(1) Several HTML5 semantic tags remain blacklisted (see T25932), so the role attribute is, in many cases, the only method to attach roles to wikitext elements.

<time> and <mark> were whitelisted in 1.21.