Evangelia Dendramis asked me “why use role=contentinfo instead of role=footer for <footer>?”
role attributes are from the Accessible Rich Internet Applications (WAI-ARIA) spec, and not part of HTML(5), although they’re allowed in pages. They’re developed by different groups, and for different reasons. ARIA is a bridging technlogy for any markup language – HTML4, SVG or HTML5 to “plugin” accessibility information that isn’t part of the host language:
WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page…
It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.
contentinfo is defined as an ARIA landmark on a page. It’s primarily there so assistive technology can allow a user to navigate around. The ARIA spec describes
A large perceivable region that contains information about the parent document. Examples of information included in this region of the page are copyrights and links to privacy statements. Within any document or application, the author SHOULD mark no more than one element with the contentinfo role.
This is a good description of a page footer, but HTML5 allows as many <footer> elements as you want:
The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.
The HTML5 <footer> does give “content info” but does so about its parent, which may be one of many <article>s or <section>s. Another element that gives information about the content it’s in is the <address> element, which may (but doesn’t have to) take an ARIA role of contentinfo.
So there’s not a 1-to-1 correspondence between <footer> and
role="contentinfo". This is exactly the same as the correspondence as we see between <header> and
role="banner". So it’s probably less confusing that the HTML5 element and the ARIA roles have different names.
It seems that the name <footer> was adopted as it was the most common class name found in a billion web pages analysed in 2005 by Ian Hickson, HTML5 editor. Arguably,
contentinfo is a better “semantic” name (after all, information about content doesn’t have to be below the content it refers to, which is what “footer” implies), but “footer” is what people were already using. Anyway, the naming of the new HTML5 elements is done now. There’s no use in bikeshedding once the ship has sailed, as Captain MixedMetaphor says.
The HTML5 spec says that a “footer element that is not a descendant of an article or section element” (that is, the footer for the whole page) has a default implicit ARIA semantic of
contentinfo. That is, assistive technologies are supposed to infer that role without the author specifying it. Good; that’s the way it should be.
However, until all do, you give a helping hand by explicitly adding that role on the page-wide footer.
Ex-Opera colleague and now Mozillian Anne van Kesteren writes a splendid little article today in which he says “I want to change the world so that the operating system is the browser and its app market the web” and describes in a little detail how.
I wholeheartedly agree with his aim, but I express my aim slightly differently: I want to change the world so the browser is the Operating System, the app market the web, and I can run any browser (indeed, any software) on a device I own.
After convincing my Member of Parliament, John Hemming, of the folly of Cameron’s plan to censor the web in the UK (sorry, I mean filter the web), he’s been doing some digging with the ISPs, writing to them to ask whether they plan to store your opt-ins privately on your router, or centrally.
He’s published the answers to his emails to BT, Sky and Virgin. BT were evasive, and TalkTalk didn’t formally respond, but it’s pretty clear they’ll store them in a centralised database. What could possibly go wrong with the government having access to a list of all those who want to see porn or “extremist” sites? It’s not like we live in a surveillance society, is it?
John and I would like to publish a fuller list. If you are a customer of an ISP that’s not on the list, please email them and ask them if they plan to store your opt-ins on a centralised database, what categories they intend to filter (eg, porn, extremism, alcohol, drugs) and how they will categorise them (eg, who will decide whether BNP/ EDL sites are “extremist”?) and paste it into a comment below. Please include the date and time the reply was sent, and who signed it (so we can double-check before publishing on John’s blog).
Apologies for the irregularity of the Reading List at the moment; September and October are autumn conference season and my schedule is bonkers.
A meeting at Mozilla Paris on how to solve Responsive Images, organised and summarised by Marcos Caceres concluded
- Browser vendors agree that srcset + DPR-switching is the right initial step forward (i.e., the 2x, 3x, etc. syntax).
- Agreement to then consider srcset + viewport size after some implementation experience (possibly drop height syntax from srcset spec). If not implemented, Width/Height syntax to possibly be marked at risk in srcset spec.
- Browser makers acknowledge the art-direction use case, but still think <picture> is not the right solution.
- Adding new HTTP headers to the platform, as Client-Hints proposes to do, has had negative impact in the past – so Client Hints might need to be reworked at bit before it becomes more acceptable to browser verndors.
So initially, we’ll use something like
Browsers that have “retina” displays will choose retina.png as they have 2 CSS pixels to one physical pixel. Browsers that aren’t retina, or don’t understand the new syntax, fall back to the good old
WebKit and Blink have implemented (but not yet shipped)
srcset, Mozilla is planning implemention now.
Meanwhile, an alternative “srcN” proposal has been put forward by Tab Atkins and John Mellor (excitingly, “John Mellor” was the real name of The Clash’s Joe Strummer). It claims to solve Resolution-based discrimination, Art-direction discrimination and Viewport-based discrimination usecases. Discussion here.
UK Government Web
The Cabinet Office’s Open Standards Board is recommending open standards technology. The first two to be approved are HTTP/1.1 and Unicode UTF-8. Francis Maude, the Minister, allegedly said “open standards will give us interoperable software, information and data in government and will reduce costs by encouraging competition, avoiding lock-in to suppliers or products and providing more efficient services”.
This may not be revelatory to those of us in the web world, but it’s a Good Thing for the nation.
I had the pleasure of hearing Paul Arnett (now of Twitter, previously of gov.uk) talking about the gov.uk initiative at From The Front conference a few days ago, and thought it was a sign of schizophrenia that the same government that can allow subject experts make a world-leading governmental portal is the same government that disregards experts and its own consultation in wanting to censor the web.
I realise now that it’s the old Tory DNA: the belief in encouraging competition by economic liberalism, reducing bureaucracy, while remaining socially authoritarian and reeling from one moral panic to the other. So no change there.