Yesterday we announced the HTML5 Recommendation. One of the most significant features of HTML5, and one that has been deployed for some time, is the <video> element, which will make it easier to include video in pages and applications without requiring users to download plug-ins.
There is already strong browser support for video today, but we have more work to do on interoperable support for streaming video. That is why we are working on a number of specifications to support streaming media interoperability, including Media Source Extensions, currently a Candidate Recommendation.
We ran into live stream interop issues as part of planning our W3C20 Webcast today (from 3pm-6pm Pacific Time) and ensuring the widest audience as possible. The deployed solutions we found (and will be using) rely on Flash plugins and other platform-specific approaches such as HTTP Live Streaming (HLS).
Despite that limitation, we are happy to offer the live stream with captions to those who cannot join us in Santa Clara.
Interoperable streaming is just one area where we want to make it easier for developers and users to play video and audio on the Web. We still need Royalty-Free codecs, the ability to play the content on second screens, improved support for accessibility, and more.
Today HTML5 reached the Recommendation stage inside the W3C, the last stage of W3C standards. Mozilla was one of the first organizations to become deeply involved in the evolution and standardization of HTML5, so today’s announcement by the W3C has a special connection to Mozilla’s mission and our work over the last 10 years.
Mozilla has pioneered many widely adopted technologies such as WebGL which further enhance HTML5 and make it a competitive and compelling alternative to proprietary and native ecosystems. With the entrance of Firefox OS into the smartphone market we have also made great progress in advancing the state of the mobile Web. Many of the new APIs and capabilities we have proposed in the context of Firefox OS are currently going through the standards process, bringing capabilities to the Web that were previously only available to native applications.
W3C Standards go through a series of steps, ranging from proposals to Editors’ Drafts to Candidate Recommendations and ultimately Recommendations. While reaching the Recommendation stage is an important milestone, we encourage developers to engage with new Web standards long before they actually hit that point. To stay current, Web developers should keep an eye on new evolving standards and read Editors’ Drafts instead of Recommendations. Web developer-targeted documentation such as developer.mozilla.org and caniuse.com are also a great way to learn about upcoming standards.
A second important area of focus for Mozilla around HTML5 has been test suites. Test suites can be used by Web developers and Web engine developers alike to verify that Web browsers consistently implement the HTML5 specification. You can check out the latest results at:
These automated testing suites for HTML5 play a critical role in ensuring a uniform and consistent Web experience for users.
At Mozilla, we envision a Web which can do anything you can do in a native application. The advancement of HTML5 marks an important step on the road to this vision. We have many exciting things planned for our upcoming 10th anniversary of Firefox (#Fx10), which will continue to move the Web forward as an open ecosystem and platform for innovation.
Filed under: Mozilla
TL;DR: The Trondheim Development Conference 2014 was incredible. Well worth my time and a fresh breath of great organisation.
I am right now on the plane back from Oslo to London – a good chance to put together a few thoughts on the conference I just spoke at. The Trondheim Developer Conference was – one might be amazed to learn – a conference for developers in Trondheim, Norway. All of the money that is left over after the organisers covered the cost goes to supporting other local events and developer programs. In stark contrast to other not-for-profit events this one shines with a classy veneer that is hard to find and would normally demand a mid-3 digit price for the tickets.
This is all the more surprising seeing that Norway is a ridiculously expensive place where I tend not to breathe in too much as I am not sure if they charge for air or not.
The location of the one day conference was the Clarion Hotel & Congress Trondheim, a high-class location with great connectivity and excellent catering. Before I wax poetic about the event here, let’s just give you a quick list:
- TDC treats their speakers really well. I had full travel and accommodation coverage with airport pick-ups and public transport bringing me to the venue. I got a very simple list with all the information I needed and there was no back and forth about what I want – anything I could think of had already been anticipated. The speaker lounge was functional and easily accessible. The pre-conference speaker dinner lavish.
- Everything about the event happened in the same building. This meant it was easy to go back to your room to get things or have undisturbed preparation or phone time. It also meant that attendees didn’t get lost on the way to other venues.
- Superb catering. Coffee, cookies and fruit available throughout the day.
- Great lunch organisation that should be copied by others. It wasn’t an affair where you had to queue up for ages trying to get the good bits of a buffet. Instead the food was already on the tables and all you had to do was pick a seat, start a chat and dig in. That way the one hour break was one hour of nourishment and conversation, not pushing and trying to find a spot to eat.
- Wireless was strong and bountiful. I was able to upload my screencasts and cover the event on social media without a hitch. There was no need to sign up or get vouchers or whatever else is in between us and online bliss – simply a wireless name and a password.
- Big rooms with great sound and AV setup. The organisers had a big box of cable connectors in case you brought exotic computers. We had enough microphones and the rooms had enough space.
- Audience feedback was simple. When entering a session, attendees got a roulette chip and when leaving the session they dropped them in provided baskets stating “awesome” or “meh”. There was also an email directly after the event asking people to provide feedback.
- Non-pushy exhibitors. There was a mix of commercial partners and supported not-for-profit organisations with booths and stands. Each of them had something nice to show (Oculus Rift probably was the overall winner) and none of them had booth babes or sales weasels. All the people I talked to had good info and were not pushy but helpful instead.
- A clever time table. Whilst I am not a big fan of multi-track conferences, TDC had 5 tracks but limited the talks to 30 minutes. This meant there were 15 minute breaks in between tracks to have a coffee and go to the other room. I loved that. It meant speakers need to cut to the chase faster.
- Multilingual presentations. Whilst my knowledge of Norwegian is to try to guess the German sounding words in it and wondering why everything is written very differently to Swedish I think it gave a lot of local presenters a better chance to reach the local audience when sticking to their mother tongue. The amounts of talks were even, so I could go to the one or two English talks in each time slot. With the talks being short it was no biggie if one slot didn’t have something that excited you.
- A nice after party with a band and just the right amount of drinks. Make no mistake – alcohol costs an arm and a leg in Norway (and I think the main organiser ended up with a peg leg) but the party was well-behaved with a nice band and lots of space to have chats without having to shout at one another.
- Good diversity of speakers and audience There was a healthy mix and Scandinavian countries are known to be very much about equality.
- It started and ended with science and blowing things up. I was mesmerised by Selda Ekiz who started and wrapped up the event by showing some physics experiments of the explosive kind. She is a local celebrity and TV presenter who runs a children’s show explaining physics. Think Mythbusters but with incredible charm and a lot less ad breaks. If you have an event, consider getting her – I loved every second.
I was overwhelmed how much fun and how relaxing the whole event was. There was no rush, no queues, no confusion as to what goes where. If you want a conference to check out next October, TDC is a great choice.
My own contributions to the event were two sessions (as I filled in for one that didn’t work out). The first one was about allowing HTML5 to graduate, or – in other words – not being afraid of using it.
You can watch a the screencast with me talking about how HTML5 missed its graduation on YouTube.
The other session was about the need to create offline apps for the now and coming market. Marketing of products keeps telling us that we’re always connected but this couldn’t be further from the truth. It is up to us as developers to condition our users to trust the web to work even when the pesky wireless is acting up again.
I had a blast and I hope to meet many of the people I met at TDC again soon.
Microsoft wrote a spec called Pointer Events API that unifies touch, stylus and mouse inputs, and implemented it in IE11 (partially in IE10). Firefox are implementing it too. After initial enthusiasm from Google, Chrome announced that it won’t support it, after all.
- HTTP 203: Pointer Events – 4 min video in which Jank Architect and Longpoll Lewis explain why Chrome thinks the Pointer Events API smells.
- Jacob Rossi of Microsoft disputes the claims (G+ link, sorry).
- More discussion about the Pointer Events Smell video from @SlexAxton, @davemethvin (jQuery): “It all boils down to ‘Why is Chrome+IE+Firefox not enough for Pointer Events, but Chrome+Firefox enough for Touch Events extensions?'”
Other standards ‘n’ shiz
- Preloading and deferred loading of scripts and other resources – Hixie suggests stuff like
<script src=.. needs="previous-script" load-policy="optimistic">
- Building for mobile? Don’t forget that 2G is still “a thing”… a big thing, in fact. says Ilya Grigorik. (Google+ link, sorry)
- Status of Promises in gUM discussion – now gUM is being “moved” to the snappily-named
navigator.mediaDevices.getUserMediaand will use Promises, should “legacy”
navigator.getUserMediacontinue to use callbacks? Yes, in my opinion – there is a lot of stuff already out there.
- Brum Tech Scene – Stuart Langridge interviews @SusannahGoh of Birmingham Science City about health, data, and innovation. Having just returned from Fronteers conference in Amsterdam, I confirm Susannah’s assertion that stroopwafel is a biscuit made of superglue.
- anonabox : a Tor hardware router to anonymise all net use and bypass censorship, easy to hide/ destroy if the Secret Police/ Mullahs are at your door.
That nice Stephen Shankland just published a news report HTML5 is done, but two groups still wrestle over Web’s future on CNET, quoting me a couple of times.
As I’m occasionally asked questions about how I see the two different organisations working together (or not), here are the full questions that Steve asked me, and my responses (as approved unchanged by my bosses at Opera). I’m grateful to Steve for giving me his permission to reproduce them.
SS: How big a problem is it that WHATWG and W3C both are sorta kinda in charge?
BL: It’s not an especially big problem for the vast majority of developers who aren’t developing sites using still-fluid features that are only available in the latest nightlies. Where they differ, the W3C spec is a better guide to the stable features as implemented already in browsers – for example, it has dropped the <hgroup> element, warns about the lack of implementations of the outlining algorithm and has much better advice on using the <main> element today to make websites more accessible to people with disabilities.
SS: Which do you think has more power in charting the future of the standard?
BL: Neither. The power is with browser makers. As Ian Hickson of WHATWG said, it doesn’t matter what the specs say if browsers don’t implement them.
SS: It seems kind of like we have two horses pulling the same cart, with no coordination between the horses. Is this a bad use of resources? Or is that a bad metaphor?
BL: The web is the biggest platform we’ve ever had. Therefore, it has more constituencies and competing interests than we’ve ever seen. It’s absolutely right that those different interest groups slug it out. At least it’s (mostly) done openly, unlike the decisions made behind closed doors by proprietary organisations answerable to no-one.
SS: We can’t rewrite history to excise XHTML 2.0, but should the two communities work to converge into one somehow? Is that even possible?
BL: I’d like to see one community , but suspect the cultural clashes are too large. So we have to get along, working together mostly and fighting occasionally, just like a family – albeit sometimes most like the Addams Family.
SS: How much actual real-world confusion is there among developers? Where should they go to see what the “true” spec says?
BL: If you want to see what’s already implemented in browsers now, look at W3C spec. If you want to see what might be coming (or how things may change) look at WHATWG spec.
Opera implements following the WHATWG spec, because that’s where nitty-gritty of the leading-edge stuff is discussed. But we also actively support and participate in the W3C as we see the value in having stable snapshots that developers can refer to, and it’s also the forum for many other vital spec discussions about Web Manifest, Device APIs etc. It’s possible to love both and, as we’re Norwegian, our hearts are full of love for all.
HTML5 is a great leap forward for an accessible web. In HTML5, accessibility is a core design principle. For the first time the semantics of HTML have been mapped, and implementation requirements defined in terms of the way HTML semantics are conveyed to people using assistive technologies.
The addition of new interactive controls, native video and captioning and new structural elements in HTML5, make it easier than ever for developers to create HTML interfaces that are usable by everyone. The inclusion of WAI-ARIA in HTML5 also provides developers with the tools and information to create accessible custom content and controls that extend the core features of HTML.
The Paciello Group (TPG) is both proud and honored to have contributed to the development of HTML5, but recognizes that it is not an end in itself. HTML5 represents a very positive step in the evolution of the language of the web and TPG welcomes the opportunity to continue contributing to its positive development.<footer>Mike Paciello- Founder, The Paciello Group (TPG)</footer>
Since 2007, TPG staff have actively contributed to the development of HTML5 at the W3C. Our involvement includes:
- W3C HTML5 Recommendation A vocabulary and associated APIs for HTML and XHTML
- HTML 5.1 Nightly A vocabulary and associated APIs for HTML and XHTML
- HTML5: Techniques for providing useful text alternatives
- HTML Accessibility API Mappings 1.1
- Using WAI-ARIA in HTML
- Implementation status for HTML5 element/attribute accessibility mappings
In recent weeks I contacted around 40 people, a cross section of those who have banged away at, or banged on about, HTML5. I asked them for their perspectives on HTML5 becoming a W3C Recommendation. Below are the words of the 28 people who responded, pretty much in the order they hit my inbox:
HTML5 is a W3C Recommendation, what do you think?
- Director of the World Wide Web Consortium (W3C), the place to agree on web standards.
HTML began 25 years ago to provide content and links, the initial flesh and bones of the web. HTML5 is still the basis of a web of links and content, but it is now also the user interface part of an entire computing platorm. Now every web page can be programmed like a computer. That is a huge change, and we can only imagine what will be deployed in the future on top of the Open Web Platform.
I showed up at the W3C in 2007 to do three things: chew bubblegum, help get a new HTML spec to Recommendation, and kick ass. We’re now near the end of 2014, HTML5 has finally reached Rec, and I’m all out of bubblegum.
The path to HTML5 has been more than a little rocky, and if the road to get to this point isn’t littered with dead bodies, there are some walking wounded among the specification participants.
But none of the interesting times spent working on this spec matters once HTML5 is officially done, and launched. All that matters is we have something we can all live with, being implemented in all our favorite tools, and providing us so much more than what we had before the effort started. That’s the win, the gold star, and the only reward so many hard working people will get for their effort with this spec: the web is a better, richer place.
So thank you hard working people, in the W3C and out. Thank you for not giving up, and seeing it to the end.
All systems that are going to improve must “breathe”; they must undergo periods of expansion and consolidation. HTML5 represents important consolidation for the web platform and I’m glad that the W3C is putting a bow on it and getting broad agreement about what it “is”.
This isn’t to say we’re done; the reason I’ve worked on Web Components in the recent past is to help ensure that the next breath won’t need to be so deep or long. The driver of nearly all progress is iterative improvement. That HTML5′s parsing includes support for custom-element definitions helps ensure that we can democratize the evolution of our shared platform so that when we get around to it, HTML6 can be informed by a vibrant community of extensions that pave a path for new semantics without fighting the language in the interim.
Finally a stable HTML5 specification that authors can develop against, knowing it will not change from one day to the next. And a lot sooner than the 2022 date that was previously mentioned.
There are some really good things in HTML5. The re-think of how the spec works, as a way to take more or less anything that claims to be HTML and produce a DOM is a big step forward. And of course it is aligned with reality, and browsers have worked much harder to align with it than they ever did with HTML4 or 3.2, which makes everyone a winner.
There are things that are not that great. Writing a huge pile of algorithms makes the document very hard to read, and it is *very* big, which in itself is a drawback. Similarly, there are some steps forward for accessibility, and the inclusion of SVG and MathML is a step forward accessibility that should bring other advantages, although there are some problems in the real world that make this less valuable than one could hope.
But the disadvantages are minor compared with the advantage of having a modern spec that is pretty close to what browsers, web pages, and other tools actually work with. It’s high time to publish what is there, although it is important to keep working – the web is a living platform, and while different bits move at very different speeds we have been a bit slow in offering a stable target since XHTML 1.0 was published as the last significant revision of HTML.
— Sylvain Galineau (@sgalineau) October 20, 2014
— вкαя∂εℓℓ (@briankardell) October 20, 2014
<script async="" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script><script async="" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>
The fact is, HTML5 is now the de facto language of the web. We know that already, so arguably a ‘recommendation’ from on high feels somewhat irrelevant. I see it like this: Together we – the implementers and authors – have embraced and advanced HTML5. We are the tide and the recommendation is the high water mark. It’s nice to see how far we’ve come.
Developing standards is not unlike developing software: you can’t just continue to develop new features – you have to stop from time to time, assess the features that you have, remove those that aren’t working, fix those that have bugs, and release a new version. HTML is such a beast and while it is important to continue its development, it’s also good to have a fixed feature set that people can reference and rely on. So: congratulations to the W3C for getting HTML5 to Recommendation status.
But what does it mean? HTML5 is the basis for a new stable and fully interoperable Web. It lists a feature set that Web developers should be able to rely on in all browsers. Thus, HTML5 is a Recommendation to browser developers to make that interoperability uniform. Find those features that your browser isn’t supporting yet in the list of HTML5 features and implement them (well, yeah: by also looking at the version of that feature in the WHATWG spec, where bugs are fixed and features continue to evolve).
This means, to everyone else: HTML5 is a Recommendation to develop more benchmarks that test the interoperability of the features. There are places like http://html5test.com/ , http://caniuse.com/ , or the W3C’s own test suite, already, but HTML5 is big, so find your favorite features and help make the Recommendation become a real standard.
It’s marvellous that HTML5 has reached this point of maturity, and that accessibility has truly emerged as a core design principle. The inclusion of ARIA puts critical semantic information right where developers need it – at the heart of the HTML specification. Coupled with features that were introduced in HTML5 (like native controls and new structural elements), we’re now in a position to design and build innovative interfaces that are usable by everyone.
This milestone is a time to look to the future as much as to past accomplishments though. As HTML development continues, we need to achieve and maintain a faster and more flexible way of working, without sacrificing the inherent stability and resilience of this open W3C standard.
People hardly remember in what limbo state was (X)HTML in 2007. At the time, I was part of W3C staff. We were struggling and discussing about the best outcome for the future of HTML. WhatWG had started since 2004 to rewrite the lingua franca MarkUp language with a much more implementers oriented specification. Finally W3C rebooted the HTML WG on March 2007.
To see HTML5 being finally released is a huge step for all people of good will participating into this effort. Imagine that. For the first time, we defined a precise algorithm for parsing HTML as it is written on the Web. It means less ambiguity. We got an enriched semantics for authors with a lot better support by browsers than in the past. It means better accessibility. And so many other things.
There will be more struggles in the future. How do we, the Web community altogether, decide to evolve the Web? But, we now have a solid foundation where we can build upon and explore new areas. This is HTML5. Let’s celebrate.
HTML 5.0 isn’t a destination, but rather a long-overdue step on a long journey.
I have mixed feelings about the process, but I’m delighted that HTML5 will be “finished” in 2014. Sure beats 2022. As for the idea that there will be subsequent updates (HTML5.1, HTML5.2, etc.), well, of course there will be. Specifications make more sense to me than the idealistic but somewhat vague idea of HTML as a “living standard.” Living standards are nice, but it’s also nice to be able to say that Browser X fully supports HTML 5.0 (or HTML 5.1, and so on).
Prior to HTML5, HTML did little to ensure consistent implementation across browsers and accessibility features were added late in the cycle without a comprehensive look at accessibility and how accessibility could be added in a way that made it easier for the developer to produce custom accessible applications. The release of HTML5 to recommendation status by the W3C specifies how HTML must be implemented across browsers to ensure consistency.
HTML5 is also the first host language to give authors a comprehensive set of tools to produce accessible custom rich internet applications, through its integration of WAI-ARIA, and accessible rich media to support the blind and visually impaired. These changes leverage the browser to produce cross-platform accessible applications at a dramatically reduced cost over native platforms as the cost of mapping the accessibility information to platform accessibility API services layers is pushed off to the user agent.
In short, HTML5 has established the core plumbing needed for accessibility and browser consistency and the work here can now be carried over and built upon for electronic books, Scalable Vector Graphics, and CSS – the bar has been raised. With the core plumbing in place the greater areas of innovation will now be in accessible graphics, device independent interaction, enhance web application functionality, CSS driven content and navigation, and context aware application infrastructure development.
On the one hand, it doesn’t really matter whether HTML5 is W3C recommendation or not. After all, what really matters to developers is what they can use in browsers today. So, from that perspective, the way the WHATWG views HTML as a “Living Standard” makes a lot of sense.
On the other hand, it’s awfully nice to have some stability in the ever-changing world of web standards and browsers. That’s where the W3C provides balance. They are the yin to the WHATWG’s yang.
HTML5 reaching recommendation status provides a welcome punctuation in the ongoing story of the most important format ever created.
Gosh! It’s not 2022, yet we’re getting HTML5 early! Of course, many web developers know that much of “HTML5″ has been ready for a long time in browsers, but it’s important that IT Directors, compliance people and clients know that this is a *stable* standard that reflects what’s in browsers now. With an incredibly active community of developers, browser vendors and spec authors, this is a milestone but emphatically *not* the destination. Onwards, and vive le web!
— Vader (@html5_vader) October 24, 2014
<script async="" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>
Many people do not realize that agreement and adoption happens on a continuum: Early adopters pay a price to do it. As things settle down, waves of increasingly less knowledgeable or risk-averse adopters join in, and all the while we are honing the proposal, and implementations. Given this, for many of us, promotion of HTML 5 to REC will seem like a non-event – a kind of statement of the obvious. At some level, it is: A recommendation, at its best, is a statement of agreement about already at that point *is* standard, not what should be. The value in REC is setting of a goal more than the eventual arrival. It’s true that there is a long tail of developers who are unwilling (or even unable) adopt until something reaches this level of maturity officially, and for them, this move will be a very big deal indeed. For the rest of us, I’d suggest that this is the time to appreciate the many hurdles crossed and the long struggles to arrive to this point – step back, assess and examine the things that made it much harder and more frustrating than it should have been at times and the ways that we can improve it all dramatically by changing the model, involving developers, building up and letting us #extendthewebforward.
I am very pleased to see the World Wide Web Consortium release a new version of html in a specification that is not going to change overnight. Even if a frozen state implies imperfections, I don’t see that as a problem if errata are correctly and timely dealt with. That’s the mistake the W3C made years ago not maintaining HTML4 and I think they got the message. A frozen html5 was needed by some industries out there that just cannot cope with living standards. Some of our partners in Standardization, like IDPF or ISO, also need to refer to a given version of our specifications. The world of our users is very different from the world of our implementers and we neglected some of them. The W3C has implemented considerable changes to its process to achieve that html5 release. Some came easily, some were heavily discussed and triggered a lot of noise. After a start based on a rather heavy process, the HTML WG came back to more pragmatism. I see that as a mark of maturity. I now look forward to the modularization of html, the specification looking too heavy to me to remain as is in the future.
HTML5! HTML5! HTML5! — Chewbacca (@HTML5_Chewbacca) October 23, 2014
<script async="" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>
The relatively popular opposition between living standards and snapshots is a false dichotomy. More importantly, we don’t need to choose: as a community we have vast amounts of experience with a processes that marry continuous updates, testing, and periodic releases as that is a common and proven way of producing software.
Standards are similar to software in more ways than one, yet we have long been remiss in applying our knowledge of the latter to the former. This needs to change.
HTML5 exhibits many of the travails of large software projects. Is it perfect? No. Is it complete? Not in the least. But we’re now in a good place to move on to a new phase in which we push open standards towards a saner, happier open source-like model. I for one welcome this bright future.
Milestones are an important part of any journey, and this is a significant milestone. I’m glad to see us reach this one, and I’m looking forward to seeing what comes as we approach the next.
It will be great to finally have a version of HTML that can be used as a standard to work from. Although some of us are lucky enough to work in an environment where we can happily use experimental and non-standard HTML features, there are others for whom standards are very important – perhaps even mandatory – and having one for HTML allows them to move up a step to something stable. This can only be a good thing.
In the beginning it was said that HTML5 would not be “ready” until 2022, but here we are at the end of 2014 and we’re nearly there. A lot of hard work by a lot of different people – in the W3C, WHATWG, and outside – has gone into getting the specification this far, and long may it continue to evolve.
HTML5 going to Rec is a significant milestone and something of significant value for society. It will be the first time we have an actual (royalty) free and open standard that describes how core parts of the Web Platform *actually work*. Despite the success of the Web, previous attempts to standardize HTML were not very successful, forcing browser vendors to reverse engineer each others browsers. This led to many years of stagnation in the platforms.
With HTML, we actually have a more realistic understanding of how the platform works. And with the IPR assurance that comes from HTML5 going to Rec, it means that everyone will be free to implement what is in the HTML5 specification without fear of legal repercussion from other W3C members who were part of the HTML WG. We are talking about big big big companies with large patent portfolios potentially worth millions, which they are essentially giving to the commons. Thanks, Apple, Google, Microsoft, IBM, etc.! you is good peoples.
It is time for HTML5 to graduate. It seems to me that we’ve done a too good job hyping HTML5 whilst we created and implemented it in browsers and we moved fast and broke a lot of things. You’d be hard pushed to find “HTML5 solutions” out there using plain vanilla code and not rely on many abstractions, polyfills and libraries. Even worse, many tell you flat out to use a certain browser – a massive mistake we already made with IE6 in the past. In the enterprise world, none of these “fixes” are applicable without certification or auditing and even HTML5 wasn’t really an option until it is a recommendation.
It will be an interesting talk to convince people to upgrade all the old systems that rely on bespoke browser technology of 1999 and move towards a multi-browser world. Having a recommendation sanctified by the W3C is a great stake in the ground to work from.
I think the W3C HTML5 Recommendation is important in the sense that some very big companies have committed (or are about to commit) to exclude the important Web functionality described by the W3C HTML5 Recommendation (which is a modified snapshot of WHATWG HTML) from patent aggression. However, I think the W3C HTML5 Recommendation should not be oversold as being useful for purposes other than a reference point under the W3C Patent Policy. In particular, the “Plan 2014” process arrangement that allowed HTML5 to proceed to Recommendation with relatively sparse test coverage means that it’s quite possible that there are areas of the specification that developers shouldn’t be relying on in case those areas of the specification turn out to be wrong due to inadequate test coverage.
In general, it’s a bad idea for both browser developers and Web developers to read old specification snapshots. Browser developers should generally read Editor’s Drafts instead of Recommendation snapshots and test suites should also track the most recent spec edits instead of reflecting snapshots whose bugs may already have been fixed in more recent edits. For Web developers it often makes sense to refer to Web developer-targeted documentation such as Mozilla Developer Network or Can I Use and, when those fail, also refer to Editor’s Drafts of the relevant specifications.
The cost of getting to this snapshot has been very high, unfortunately. It’s very sad that the HTML WG ended up driving away many of the people who had contributed to the HTML5 effort at the WHATWG and had come over to the HTML WG when the new HTML WG was established in 2007 to bring the WHATWG’s work on HTML5 into the W3C. I hope the divergence between WHATWG HTML and W3C HTML won’t be permanent.
One of the most pleasing aspects of the W3C’s work on HTML 5 has been the renewed commitment to testing, through initiatives such as Test the Web Forward and the web-platform-tests open source project. Implementation differences have long been a source of frustration for web developers, and the creation of cross-browser testsuites for the web platform is the best way to eliminate them in the future.
Just because HTML 5 has now reached Recommendation status, this testing work does not stop. Although HTML now has a more substantial testsuite than at any time in the past, we know that there are large areas that still have poor test coverage. Rectifying this is an ongoing project, and one where all web developers can make an invaluable contribution by submitting tests to web-platform-tests whenever they encounter incompatibilities between different browsers.
HTML5 is an important step forward for browser interoperability. When HTML 4.01 was published back in 1999, it said “Since user agents may vary in how they handle error conditions, authors and users must not rely on specific error recovery behavior.” This meant that the behaviour of malformed HTML was undefined despite a huge percentage of pages being malformed (some deliberately for better performance in some browsers). Back them, few would have believed that it was possible to write down a common algorithm for parsing HTML and then get all the popular browser engines to adopt and implement it. But HTML5 did that. And it did so much more. The HTML5 Recommendation brought a level of preciseness to the core pieces of the web that we didn’t have before.
Is HTML5 finished? Is it perfect? No, it’s a software project and it is a work in progress as is the whole web. The web keeps growing, keeps adding new capabilities, and keeps getting better. But shipping is a feature and the web community has spent the last couple of years stabilising and scoping the HTML5 specification. This is an important stabilisation milestone on the way to an even better future.
The HTML5 parsing steps and I become acquainted long before I joined the editor team; I ran the spec algorithm on a particular input that was exploiting a defect in IE to confirm both that 1) if IE had only implemented the spec this wouldn’t be a problem and that 2) the HTML5 spec was going to take more than a mild investment to fully understand. Boy, was that an understatement.
HTML5 changed a lot of things. It redefined the expectations of what degree of detail is necessary to achieve broad interop. It brought together and standardized diverse new capabilities like media and canvas. It demystified name lookup on the window. It even provided all those who had the pleasure of working with it a great deal of </sarcasm>. Literally.
Getting this spec to Rec is a major accomplishment for so many people. While HTML’s journey will surely continue on, it’s great to pause and appreciate this significant milestone. I’ve had a wonderful time getting to know the many amazing, talented, and persistent people behind the scenes making it all happen. Thanks and congratulations!
Work continues apace on HTML at the W3C and WHATWG and any place where people are working on HTML and the Open Web Platform. HTML5 to REC is a promise to the Open Web Platform. Now there is no excuse, we can all officially say goodbye to HTML 4 and XHTML 1.1.
…and right now, RIGHT NOW, its time to KICK OUT THE JAMS MOTHERFUCKER!
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/uo35O1AJOfg?rel=0" width="480"></iframe>
Today, while several Internet Explorer team members are at W3C TPAC 2014, the IE team is happy to join Microsoft Open Technologies, other browser vendors, and the web community at large in celebrating the HTML5 specification reaching W3C Recommendation.
This milestone represents many years of commitment from people and organizations around the world to produce and stabilize the next generation of the W3C Open Web Platform. The IE team believes that the standards process is vital to creating an interoperable Web and ensuring that the web just works for everyone.
We’d also like to congratulate the W3C on its 20th anniversary and look forward to continued collaboration on the future of the open web.
As of today, there are 706 Firefox Mobile bugs and 205 Firefox Desktop bugs in Mozilla Web Compatibility activity. These are OPEN bugs for many different companies (not only Google). We could add to that the any browser 237 bugs already collected on Webcompat.com. Help is welcome.
On these, we have a certain number of bugs related to Google Web properties.
Google and Mozilla
Let's make it very clear. We have an ongoing open discussions channel with Google about these bugs. I will not cite names of people at Google helping to deal with them for their own sake and privacy, but they do the best they can for getting us a resolution. It's not the case for all companies. So they know themselves and I want to thank them for this.
That said, there are long standing bugs where Firefox can't properly access the services developed by Google. The nature of bugs is diverse. It can be wrong user agent sniffing,
-webkit- CSS or JS, or a codepath in JS using a very specific feature of Chrome. The most frustrating ones for the Web Compatibility people (and in return for users) are the ones where you can see that there's a bit of CSS here and there breaking the user experience but in the end, it seems it could work.
The issue is often with the "it seems it could work". We may have at first sight an impression that it will be working and then there is a hidden feature which has not be completely tested.
Also Firefox is not the only browser with issues with Google services. Opera browser, even after the switch to blink, has still issues with some Google services.
List Of Google Bugs For Firefox Browsers
Here the non exhaustive list of bugs which are still opened on Bugzilla. If you find bugs which are not valid anymore or resolved, please let us know. We do our best to find out what is resolved, but we might miss some sometimes. The more you test, the more it helps all users. With detail bug reports and analysis of the issues we have a better and more useful communications with Google Engineers for eventually fixing the bugs.
You may find similar bugs on webcompat.com. We haven't yet made the full transition.
- 627155: Impossible to download document attachments in gmail on Firefox Android (mail.google.com)
- 668275: GMail sends a lowfi version to Firefox for Android to Firefox OS (instead of touch)
679025: finance.google.com presents null error on initial load
- 691227: gmail.com - Rendering of checkboxes cut off on Windows 8 (when text size is set to 125% or 150% in Control Panel)
714037: youtube.com - Text box displayed incorrectly on youtube html5 in Linux overlap text box 745191: gmail.com - a Labs feature showing an unread inbox count in favicon doesn't work with Iceweasel user agent 754750: Google Finance - Suboptimal site, not optimized site renders on Fennec Native Due to UA sniffing and XHTML content-type
- 754752: Google Books - Firefox on mobile receives desktop content on home page instead of mobile
- 755590: sites.google.com - top bar doesn't show up in Firefox for Android
- 793216: images.google.com image single view carrousel is stacked on tablet
- 802731: Google Groups new interface hangs in a group with over 700 spam posts
- 819497: Google search doesn't work with cookies disabled
- 865043: news.google.com doesn't send tier1 to Firefox OS
- 872300: docs.google.com/spreadsheet tells me (SeaMonkey) is an unsupported Firefox version
- 902531: Google Play Music not working on Firefox for Android/Firefox OS
- 911837: Google Play Music HTML5 Audio Feature broken (because it sniffs browsers, but it also requires window.MediaSource and audio/mpeg)
- 914252: Google calendar tier1 header would not render in Firefox Android and Firefox OS
- 921532: Google images on Firefox Android doesn't load images as you scroll
- 921536: Google menu icon in the top-left corner in Firefox doesn't open a menu
- 932521: Google Cache Doesn't Work if DOM Storage Disabled
- 958575: Google News - Tablet experience in Chrome for Android superior to Firefox for Android
- 973754: https://www.google.com offers ""voice search"" in Chrome but not Firefox
- 975444: Google cards not shown in Firefox for Android
- 976013: Google Translate Widget box does not work (requires Flash for Firefox browsers)
- 976749: Missing connect button in main google page in certain locales
- 976753: google.com ""Connect"" Text is cut in different l10n
- 980833: Latest YouTube API defaults to Flash player in Firefox even when html5=1 is used
- 984301: Google Chrome app is opened when tapping on the helper app in m.youtube.com
- 990767: zooming in/out in google maps does not display properly
- 993664: translate.google.com icons not there
- 995140: Google Calendar sends a lowfi version to Firefox OS
- 1013702: Google: Patent search will not work on mobile (phones)
- 1036987: XML Parsing error: not well-formed when trying to reply to an email through the Gmail web interface on Firefox OS
- 1047854: ""Advanced Search"" options missing on Google search in Firefox for Android (vs Chrome)
1048324: Google webfont 'Basic' has a bogus rendering of 'gg' characters sequence when contextual alternates is on.
- 1052200: Google calendar columns in week view are misaligned on Retina Mac & with full-page-zoom on other platforms, due to ""wk-dummyth"" element being a different size from the scrollbar
- 1053323: GMail overrides/blocks previous tab/next tab (Ctrl-PageUp, Ctrl-PageDown) when ""Compose Mail"" is open
- 1053648: drive.google.com sends Desktop version to Firefox OS
- 1053712: Youtube shows desktop content on tablet (http://m.youtube.com)
- 1055025: cannot add Youtube comments - just get a popup window
- 1065319: UI truncation happened when you import contacts from Gmail
- 1067364: Google images on Firefox OS doesn't load images as you scroll
- 1076439: Requesting a mobile google+ page returns 404
- 1076999: GMail: Clicking on a Hangouts contact in doesn't focus on the text input of the chat box
- 1083932: Google News dropdown menus rely on setting non-standard document.body.scrollTop
You can help us.
Here at The Paciello Group (TPG) we have a technical accessibility testing process which does not involve the use of automated tools. The technical audit results we provide to our clients are based solely on manual testing of a web site, web application, mobile or desktop application.
Typically, but not solely, we conduct technical testing in reference to the following accessibility standards:
- Web Content Accessibility Guidelines 2.0 (web sites and web applications and other ICT)
- Section 508 1194.21- Software Applications and Operating Systems (desktop applications and web applications)
- Section 508 1194.22 – Web-based Intranet and Internet Information and Applications (web sites and web applications)
- Section 508 Refresh Standards (Formal title: Draft Information and Communication Technology (ICT) Standards and Guidelines).
To aid us in our manual testing process we use a number of tools and assistive technologies, the following is not a complete list of the tools we use, but these are the tools I currently use on a daily basis:
- The Web Accessibility Toolbar (free add on for Internet Explorer)
- The Color Contrast Analyser (free desktop application for windows and Mac)
- aViewer (free desktop application for windows )
- W3C Nu markup HTML conformance checker
- Firebug (free Firefox extension)
- Dom Inspector (free Firefox extension)
- Accprobe (free open source desktop application)
- Accessibility Inspector (free Mac appplication)
- UI Browser (NOT free Mac appplication)
- JAWS (Screen Reader for windows, demo version available)
- NVDA (Free open source Screen Reader for windows)
- VoiceOver (Built in Screen Reader, Mac desktop and iPhone/iPod)
- ChromeVox (screen reader for Chrome and Chrome OS)
- Talkback (screen reader for Android)
- Zoomtext (Screen Magnifier for windows, demo version available)
I asked around the TPG virtual office (Skype group chat) and people recommended some more notable and useful tools:
- aDesigner (free open source desktop application)
- Juicy Studio Tools (free online tools and Firefox extensions)
- Accessibility Evaluation Toolbar (free Firefox extension)
- Wave Toolbar (free Firefox extension)
- Web Developer (free Firefox extension)
- Dragon (speech recognition software)
- Accessibility Developer Tools (for Chrome)
- iOS Simulator
- Jim Thatchers Favelets
- ARIA validator (for chrome)
- Quail (Accessibility testing in the browser and on the server)
- We do not use assistive technology in our technical testing to carry out user testing, we leave that up to actual users of assistive technology, who we work with as part of our user research and usability testing services. But as technical testers we do use assistive technology to evaluate the data we gather. Assistive technology is an essential part of the process for understanding how the accessibility information provided in user interfaces is conveyed to users.
- The tools listed above are only the tools I use regularly, other accessibility engineers at TPG may use other tools.
Two days ago I was in Berlin for a day to present at the SAE alumni Conference in Berlin, Germany. I knew nothing about SAE before I went there except for the ads I see on the Tube in London. I was pretty amazed to see just how big a community the alumni and chapters of this school are. And how proud they are.
My presentation The things browsers can do – go play with the web was a trial-run of a talk I will re-hash a bit at a few more conferences to come.
In essence, the thing I wanted to bring across is that HTML5 has now matured and is soon a recommendation.
And along the way we seem to have lost the excitement for it. One too many shiny HTML5 demo telling us we need a certain browser to enjoy the web. One more polyfill and library telling us without this extra overhead HTML5 isn’t ready. One more article telling us just how broken this one week old experimental implementation of the standard is. All of this left us tainted. We didn’t believe in HTML5 as a viable solution but something that is a compilation target instead.
In this talk I wanted to remind people just how much better browser support for the basic parts of HTML5 and friends is right now. And what you can do with it beyond impressive demos. No whizzbang examples here, but things you can use now. With a bit of effort you can even use them without pestering browsers that don’t support what you want to achieve. It is not about bringing modern functionality to all – browsers; it is about giving people things that work.
I recorded a screencast and put it on YouTube
All in all I enjoyed the convention and want to thank the organizers for having me and looking after me in an excellent fashion. It was refreshing to meet students who don’t have time to agonize which of the three task runners released this week to use. Instead who have to deliver something right now and in a working fashion. This makes a difference
I’m really sorry it’s taken me so long to write back to you (over a month!)—I’m really crap at email.
I’m writing to you hoping you can help me make my colleagues take html5 “seriously”. They have read your book, they know it’s the “right” thing to do, but still they write !doctype HTML and then div, div, div, div, div…
Now, if you could provide me with some answers to their “why bother?- questions” would be really appreciated.
I have to be honest, I don’t think it’s worth spending lots of time agonising over what’s the right element to use for marking up a particular piece of content.
That said, I also think it’s lazy to just use divs and spans for everything, if a more appropriate element is available.
Paragraphs, lists, figures …these are all pretty straightforward and require almost no thought.
Deciding whether something is a section or an article, though …that’s another story. It’s not so clear. And I’m not sure it’s worth the effort. Frankly, a div might be just fine in most cases.
For example, can one assume that in the future we will be pulling content directly from websites and therefore it would be smart to tell this technology which content is the article, what are the navigation and so on?
There are some third-party tools (like Readability) that pay attention to the semantics of the elements you use, but the most important use-case is assistive technology. For tools such as screen readers, there’s a massive benefit to marking up headings, lists, and other straightforward elements, as well as some of the newer additions like nav and main.
But for many situations, a div is just fine. If you’re just grouping some stuff together that doesn’t have a thematic relation (for instance, you might be grouping them together to apply a particular style), then div works perfectly well. And if you’re marking up a piece of inline text and you’re not emphasising it, or otherwise differentiating it semantically, then a span is the right element to use.
So for most situations, I don’t think it’s worth overthinking the choice of HTML elements. A moment or two should be enough to decide which element is right. Any longer than that, and you might as well just use a div or span, and move on to other decisions.
But there’s one area where I think it’s worth spending a bit longer to decide on the right element, and that’s with forms.
When you’re marking up forms, it’s really worth making sure that you’re using the right element. Never use a span or a div if you’re just going to add style and behaviour to make it look and act like a button: use an actual button instead (not only is it the correct element to use, it’s going to save you a lot of work).
Likewise, if a piece of text is labelling a form control, don’t just use a span; use the label element. Again, this is not only the most meaningful element, but it will provide plenty of practical benefit, not only to screen readers, but to all browsers.
So when it comes to forms, it’s worth sweating the details of the markup. I think it’s also worth making sure that the major chunks of your pages are correctly marked up: navigation, headings. But beyond that, don’t spend too much brain energy deciding questions like “Is this a definition list? Or a regular list?” or perhaps “Is this an aside? Or is it a footer?” Choose something that works well enough (even if that’s a div) and move on.
There’s a bit of a contradiction to what I’m saying here.
On the one hand, I’m saying you should usually choose the most appropriate element available because it will save you work. In other words, it’s the lazy option. Be lazy!
On the other hand, I’m saying that it’s worth taking a little time to choose the most appropriate element instead of always using a div or a span. Don’t be lazy!
I guess what I’m saying is: find a good balance. Don’t agonise over choosing appropriate HTML elements, but don’t just use divs and spans either.
Hope that helps.
Hmmm… you know, I think I might publish this response on my blog.
Tantek Çelik — 5pm TODAY @HTML5DevConf Rm N120 The future of open APIs feeds actions by @benwerd #HTML5DevConf werd.io/2014/the-web-is-your-api-feeds-and-actions-using-html5
A couple of weeks ago we had accidentally broken our production server (for a particular report) because of broken HTML. It was an unclosed tag which rendered everything after that tag to just plain white. Our comprehensive test suite failed to notice it because it didn't look at details like that. And when it was tested manually we simply missed the conditional situation when it was caused. Neither good excuses. So it got me thinking how can we incorporate HTML (html5 in particular) validation into our test suite.
So I wrote a little gist and used it a bit on a couple of projects and was quite pleased with the results. But I thought this might be something worthwhile to keep around for future projects or for other people who can't just copy-n-paste a gist.
With that in mind I put together a little package with a README and a
setup.py and now you can use it too.
There are however some caveats. Especially if you intend to run it as part of your test suite.
Caveat number 1
You can't flood
htmlvalidator.nu. Well, you can I guess. It would be really evil of you and kittens will die. If you have a test suite that does things like
response = self.client.get(reverse('myapp:myview')) and there are many tests you might be causing an obscene amount of HTTP traffic to them. Which brings us on to...
Caveat number 2
htmlvalidator.nu site is written in Java and it's open source. You can basically download their validator and point
django-html-validator to it locally. Basically the way it works is
java -jar vnu.jar myfile.html. However, it's slow. Like really slow. It takes about 2 seconds to run just one modest HTML file. So, you need to be patient.
I’m guilty of it myself, and I see it a lot: making fun of Microsoft in a presentation. Sure, it is easy to do, gets a laugh every time but it is also a cheap shot and – maybe – more destructive to our goals than we think.
Let’s recap a bit. Traditionally Microsoft has not played nice. It destroyed other companies, it kept things closed that open source could have benefited from and it tried to force a monoculture onto something that was born open and free: the web.
As standard conscious web developers, IE with its much slower adaption rate of newer versions was always the bane of our existence. It just is not a simple thing to upgrade a browser when it is an integral part of the operating system. This is exacerbated by the fact that newer versions of Windows just weren’t exciting or meant that a company would have to spend a lot of money buying new software and hardware and re-educate a lot of people. A massive investment for a company that wasn’t worth it just to stop the web design department from whining.
Let’s replace IE then!
Replacing IE also turned out to be less easy than we thought as the “this browser is better” just didn’t work when the internal tools you use are broken in them. Chrome Frame was an incredible feat of engineering and – despite being possible to roll out on server level even – had the adoption rate of Halal Kebabs at a Vegan festival.
Marketing is marketing. Don’t try to understand it
It seems also fair to poke fun at Microsoft when you see that some of their marketing at times is painful. Bashing your competition is to me never a clever idea and neither is building shops that look almost exactly the same as your main competitor next to theirs. You either appear desperate or grumpy.
Other things they do
The thing though is that if you look closely and you admit to yourself that what we call our community is a tiny part of the overall market, then Microsoft has a massive part to play to do good in our world. And they are not cocky any longer, they are repentant. Not all departments, not all people, and it will be easy to find examples, but as a whole I get a good vibe from them, without being all marketing driven.
Take a look at the great tools provided at Modern.ie to allow you to test across browsers. Take a look at status.modern.ie which – finally – gives you a clear insight as to what new technology IE is supporting or the team is working on. Notice especially that this is not only for Explorer – if you expand the sections you get an up-to-date cross-browser support chart linked to the bugs in their trackers.
This is a lot of effort, and together with caniuse.com makes it easier for people to make decisions whether looking into a technology is already worth-while or not.
Reaching inside corporations
And this to me is the main point why Microsoft matters. They are the only ones that really reach the “dark matter” developers they created in the past. The ones that don’t read hacker news every morning and jump on every new experimental technology. The ones that are afraid of using newer features of the web as it might break their products. The ones that have a job to do and don’t see the web as a passion and a place to discuss, discard, hype and promote and troll about new technologies. And also the ones who build the products millions of people use every day to do their non-technology related jobs. The booking systems, the CRM systems, the fiscal data tools, all the “boring” things that really run our lives.
We can moan and complain about all our great new innovations taking too long to be adopted. Or we could be open to feeding the people who talk to those who are afraid to try new things with the information they need.
Let’s send some love and data
I see Microsoft not as the evil empire any longer. I see them as a clearing house to graduate experimental cool web technology into something that is used in the whole market. Chances are that people who use Microsoft technologies are also audited and have to adhere to standard procedures. There is no space for wild technology goose chases there. Of course, you could see this as fundamentally broken – and I do to a degree as well – but you can’t deny that these practices exist. And that they are not going to go away any time soon.
With this in mind, I’d rather have Microsoft as a partner in crime with an open sympathetic ear than someone who doesn’t bother playing with experimental open technology of competitors because these don’t show any respect to begin with.
If we want IT to innovate and embrace new technologies and make them industrial strength we need an ally on the inside. That can be Microsoft.
I upgraded to a new MacBook about a week ago, and thought I’d use the opportunity to try living without Flash for a while. I had previously done this two years ago (for my last laptop upgrade), and I lasted about a week before breaking down and installing it. In part because I ran into too many sites that needed Flash, but the main reason was that the adoption and experience of HTML5 video wasn’t great. In particular, the HTML5 mode on YouTube was awful — videos often stalled or froze. (I suspect that was an issue on YouTube’s end, but the exact cause didn’t really matter.) So now that the Web has had a few additional years to shift away from Flash, I wanted to see if the experience was any better.
The short answer is that I’m pleased (with a few caveats). The most common Flash usage for me had been the major video sites (YouTube and Vimeo), and they now have HTML5 video support that’s good. YouTube previously had issues where they still required the use of Flash for some popular videos (for ads?), but either they stopped or AdBlock avoids the problem.
I was previously using Flash in click-to-play mode, which I found tedious. On the whole, the experience is better now — instead of clicking a permission prompt, I find myself just happy to not be bothered at all. Most of the random Flash-only videos I encountered (generally news sites) were not worth the time anyway, and on the rare occasion I do want to see one it’s easy to find an equivalent on YouTube. I’m also pleased to have run across very few Flash-only sites this time around. I suspect we can thank the rise of mobile (thanks iPad!) for helping push that shift.
There are a few problem sites, though, which so far I’m just living with.
Ironically, the first site I needed Flash for was our own Air Mozilla. We originally tried HTML5, but streaming at scale is (was?) a hard problem, so we needed a solution that worked. Which meant Flash. It’s unfortunate, but that’s Mozilla pragmatism. In the meantime, I just cheat and use Chrome (!) which comes with a private copy of Flash. Facebook (and specifically the videos people post/share) were the next big thing I noticed, but… I can honestly live without that too. Sorry if I didn’t watch your recent funny video.
I will readily admit that my Web usage is probably atypical. I’ve rarely play online Flash games, which are probably close to video usage. And I’m willing to put up with at least a little bit of pain to avoid Flash, which isn’t something fair to expect of most users.
But so far, so good!
[Coincidental aside: Last month I removed the Plugin Finder Service from Firefox. So now Firefox won't even offer to install a plugin (like Flash) that you don't have installed.]
Practical screen reader support by browser and OS
When testing aspects of support for new HTML5, WAI-ARIA features and HTML features in general, I often test browsers that do not have practical support for screen readers on a particular operating system. I find they have support for feature X, but lack support for feature Y that is required to enable practical support to web content for screen reader users. While it is useful to test and find successful implementations of discrete features, it needs to be viewed in the broader context of which browsers can be considered usable with popular OS level screen readers.
I found it difficult to get a complete understanding from the resources available on the web, but have put together a high level support table based on information I could glean.
If you have any further information or find any inaccuracies please comment.
Practical support for screen readers means that a browser can be successfully used to browse and interact with commonly encountered web content, using current versions of OS level screen readers such as, on Windows; JAWS, NVDA, Window Eyes. On Mac OSX and iOS; VoiceOver. On Linux; Orca and on Chrome OS; ChromeVox.
- “supported” means that the browser is usable in practice with a screen reader on the operating system (OS).
Note: in the case of Internet Explorer it lacks support for some important features, but due to its market share screen readers hack around its lack of support.
- “partial support” lacks support for some important features. For example, Chrome on Windows supports browsing using JAWS, but does not fully support accessible name calculation.
- “not applicable” means the browser does not run on the OS
- “not supported” means the browser does not have practical support for screen readers on the OS.
- “not known” means that accessibility support information is not publicly available.
- browsers recently added to OS’s, Early data indicates usable accessibility support.
- not known, but likely is unsupported.
Note: The table refers to the current (12/10/2014) versions of browsers and current versions of operating systems.
(built-in Android browser
Bringing HTML5 to the status of W3C Recommendation (in October 2014) is a defining moment in the development of the Open Web Platform (OWP), a set of technologies for developing distributed applications with the greatest interoperability in history. This year is also the 25th anniversary of the Web and 20th anniversary of W3C, making this an even more meaningful time to engage with the community about the Next Big Thing for the Web Platform.
My starting point for this discussion is that, now that HTML5 is done, W3C should focus on strengthening the parts of the Open Web Platform that developers most urgently need for success. I call this push for developers “Application Foundations.”
This is a new formulation, shaped in part by discussion at the September Extensible Web Summit in Berlin, as well as discussions within the W3C staff. I am planning further discussion at W3C’s TPAC 2014 meeting at the end of the month, and I welcome your feedback to this post and in the months ahead.
While this formulation is new, most of the work is not new. Rather, this represents a new way of looking at the considerable work that is already in the Web community, and placing some structure around the considerable work in front of us.
The Focus on Developers
As popular as the OWP is, it is still too challenging for developers to create some types of Web applications. Lack of broad interoperability for some features complicates development. Lack of standard features in the platform drives developers to create hybrid applications, implying a larger mix of tools, libraries, and interoperability issues. There is more work to meet growing expectations around privacy, security, and accessibility.
There are many ways to focus on developers. Many W3C activities outside of standards development are geared toward enabling developers, including tools (validator), documentation (Web Platform Docs), training (W3DevCampus, W3Conf), participation (Community Groups, draft Webizen program).
The question I want to get at in this post, however, relates to our open standards agenda: are we building the platform that developers need? How can we find out?
That is where the Application Foundations come in. They give us a way to think about the Open Web Platform that will make it easier for the W3C community to converge on the top priorities for developers.
What are Application Foundations?
Platforms mature predictably in the following way: at a given time, some capabilities are core and “applications” rely on the core. Invariably, there comes a time when certain features are so pervasively used as services by other applications, the “next generation” of the platform must subsume some of those features (via libraries, platform services, daemons, etc.).
Operating systems provide a familiar example. Typically, an operating system kernel provides the key lower layer functions that a computer needs for its programs (aka applications): program execution, memory management, support for devices, etc. In early versions of many operating systems, there are also higher layer functions (such as networking, security, GUIs, etc.). Often these functions have some manifestation in the kernel, but also some manifestation in applications. Over time, given experience with the higher layer functions, people recognize that some must mature into major subsystems (aka foundations) that are above the kernel, leveraged by many applications. Modular design of these subsystems allows experts in different areas (security, communications protocols, and so on) to deliver solutions that will best serve all the other parts of the platform.
We see this pattern with the Open Web Platform as well. There was a time that video would have been viewed as an application of the Web, but in HTML5, video has unquestionably been absorbed into the core infrastructure (e.g., via the HTML <video> element). An apt metaphor is to call the programmable Open Web Platform of today the first generation operating system of the Web. In the past couple of years, important subsystems have already started to emerge, and in this post I propose a taxonomy of eight Application Foundations to focus our discussion on the next generation:
- Security and Privacy
- Core Web Design and Development
- Device Interaction
- Application Lifecycle
- Media and Real-Time Communications
- Performance and Tuning
- Usability and Accessibility
Each Foundation represents collection of services and capabilities that should be available for all applications. For example, the Security and Privacy Foundation includes capabilities such as crypto, multi-factor authentication, and resource integrity.
We expect each Foundation to evolve independently, driven by experts in that topic. We also know that there will be interconnections, such as Security implications of Device Interactions, or Accessibility considerations of streaming Media.
Below I will begin to enumerate the capabilities we have associated with each Foundation, both long-standing and new or planned work that will substantially advance the capability of the OWP.
In our internal discussions there was quick consensus on the usefulness of an Application Foundations paradigm. There was also passionate debate about taxonomy itself. Did we come up with one that will speak to developers? Did we neglect some important piece of functionality? Should this or that second-level item be a top-level category or vice versa? To help structure the broader debate to come, I’d like to provide some background for the choices proposed here.
Principles for Thinking about these Foundations
Bearing in mind that we are looking for a best fit to structure discussion, not a perfect dissection, here are some key principles for thinking about these Foundations:
- Although this exercise is motivated by the desire to meet developer needs, we sought labels that would be meaningful for end users as well. We looked for terms we thought would speak to those audiences about both desirable qualities of the platform and current pain points that we need to address.
- These topics were derived by looking at W3C’s current priorities and discussions about upcoming work. W3C’s agenda is in constant motion, and this taxonomy will only be useful so long as it aligns with priorities. But the river bed shapes the river and vice versa.
- Because the focus is on current developer pain points, we do not attempt to fit all of W3C’s work into the eight categories. We are committed to our entire agenda, but this particular exercise is limited in scope. For the same reason, we do not attempt to represent all completed work in this categorization. While we might want to see how broadly we could apply this taxonomy, our priority project is to enable developers today and tomorrow.
Putting the Foundations to Use
Although this framework is meant initially only as a communications vehicle —a way of describing the substantial work we have to do to enhance the OWP— we may find other uses later. Once fleshed out and road-tested, for example, the W3C Technical Architecture Group (TAG) might use this model for architectural discussions about the Open Web Platform.
Ultimately, with such a framework, it becomes easier to identify what is missing from the platform, because we will think more cohesively about its key components. And where there are similar capabilities (e.g. different functions that show up in the same Foundation), it will make it easier to identify where synergies can simplify or improve the platform.
By definition, Foundations are common subsystems useful not only for “horizontal applications”, but also for a variety of industries such as digital publishing, automotive, or entertainment. In a separate exercise we plan to work with those industries to create a view of the Foundations specific to what they need from the Open Web Platform.
So let’s get started. In each paragraph below, I outline why we think this area deserves to be a Foundation. I list some absolutely critical problems the community is currently addressing. This will help motivate why each Foundation was chosen, and the technology development required to give rise to the next generation Web.
Security and Privacy
The Web is an indispensable infrastructure for sharing and for commerce. As we have created the OWP, we have become increasingly sensitive to making this a secure infrastructure. See, for example, our 2013 “Montevideo” statement calling for greater Internet security.
The vulnerabilities have become increasingly prominent. They vary in range and style. There are vulnerabilities that result from criminal exploitation of security holes for financial gain. There are numerous situations where information and communications that was intended to be private has found its way into unauthorized hands.
From a pure technical point of view, there is a tremendous amount of security research and there is knowledge on how to make an infrastructure secure. Many security advances are available in devices that are connected to the Web today. Nonetheless, security exposures abound: because it is too difficult for applications to leverage the security that is available; because new security techniques are not yet in place; and because users are not encouraged to rely on strong security.
To strengthen this Foundation, we are working closely with a number of organizations, including the IETF, FIDO Alliance, and Smartcard Alliance.
Core Web Design and Development
Developers use many widely deployed front end technologies for structure, style, layout, animations, graphics, interactivity, and typography of pages and apps. HTML5 brought native support for audio and video, canvas, and more. Dozens of CSS modules are used for advanced layout, transformations, transitions, filters, writing modes, and more. SVG is now widely supported for scalable graphics and animations, and WOFF is beautifying the Web and making it easier to read.
Still, the work is not complete. Much new work will be driven by the adoption of the Web on a broader set of devices, including mobile phones, tablets and e-book readers, televisions, and automobiles. The responsive design paradigm helps us think about how we need to enhance HTML, CSS, and other APIs to enable presentation across this wider set of devices.
One exciting direction for this Foundation is Web Components, which will make it easier for developers to carry out common tasks with reusable templates and code modules, all leveraging standards under the hood.
Another area of anticipated of work will be driven by a more complete integration of digital publishing into the Web. In the past, advanced styling and layout for magazines has remained an area where special purpose systems were required. In this Foundation, we will ensure that we have the primitives for advanced styling and layout so that all publishing can be done interoperably on all Web devices.
Our Test the Web Forward activity, though relevant across the Foundations, has been particularly influential for Core Web Design and Development, and we invite the community to contribute to that active testing effort.
Closely related to the Core Foundation is the Device Interaction Foundation, which describes the ways that devices are used to control or provide data to applications. New Web APIs are proposed weekly to give access to all of the features offered by supporting devices. For mobile phones, APIs exist or are in development for access to camera, microphone, orientation, GPS, vibration, ambient light, pointer lock, screen orientation, battery status, touch events, bluetooth, NFC, and more.
The next generation of Web attached devices will introduce new challenges. For instance, the Automotive and Web Platform Business Group is developing APIs to access information about vehicle speed, throttle position, interior lights, horn, and other car data that could help improve driving safety and convenience. We anticipate some of that work will advance to the standards track. In general, wearables, personal medical equipment devices, home energy management devices, and the Internet of Things will drive developer demand for data in applications, and for Web abstractions to simplify what will be new complexity in underlying networks. To achieve that simplicity for developers, the TAG, Device APIs Working Group, Web Apps Working Group, and Systems Applications Working Group all have a role to play in capturing good practices for API design.
The proliferation of environments —both mobile and non-mobile— in which an application may run has created new challenges for developers to satisfy user expectations. People expect their apps to be useful even when there is no network (“offline”), to do the right thing when the network returns (“sync”), to take into account location-specific information (“geofencing”), to be easy to launch on their device (“manifest”), to respond to notifications (from the local device or remote server), and so on. The Application Lifecycle Foundation deals with the range of context changes that may affect an application. For example, developers have made clear that that AppCache fails to meet important offline use cases. so we must come up with a superior solution.
The emerging approach (“Workers”) for addressing many these lifecycle requirements involves spawning important tasks as asynchronous processes outside of an application. For instance, a Worker can be used to manage a cache and update it according to network availability or receive server-sent notifications, even when an application is not actively running. Enhancing these Foundations these will enable developers to create superior user experiences.
Media and Real-Time Communications
A number of communications protocols and related APIs continue to serve developers well, from HTTP to XMLHttpRequest to Web Sockets. But to meet the growing demand for real-time communications and streaming media, we must add new capabilities, the focus of this Foundation.
The promise of WebRTC is to make every single connected device with a Web browser a potential communications end point. This turns the browser into a one-stop solution for voice, video, chat, and screen sharing. A sample use case driving interest in real-time in the browser is enabling “click-to-call” solutions for improved customer service. WebRTC has the potential to bring augmented reality to the Web and create a brand new class of user experiences – an exciting direction for this Foundation.
For audio and video, developers will have a variety of tools to manipulate media streams, edit audio input, and send output to multiple screens (“second screen”). This last capability is of particular interest to the entertainment industry. For example, in the US, a majority of people have a second device nearby while watching television, allowing for new interactive experiences such as social interactions or online commerce.
Performance and Tuning
Today we are working on APIs for performance profiling such as navigation timing and resource hints. In various discussions and Workshops, people have asked for a number of enhancements: for understanding load times, enabling automatic collection of performance data, providing hints to the server for content adaptation, improving performance diagnostics, managing memory and garbage collection, preserving frame rates, using the network efficiently, and much more.
The responsive design paradigm mentioned in the Core Web Design and Development Foundation also plays a role in the world of performance: we can make better use of the network and processing power if we can take into account screen size and other device characteristics.
Usability and Accessibility
The richness of the Open Web Platform has raised new challenges for some users. It is great to be able to create an app that runs on every device, but is it easy to use or klunky? It’s great to offer streaming media, but do developers have the standards to include captions to make the media accessible?
Designers have pioneered a number of approaches (responsive, mobile first), that can improve accessibility and usability, and W3C’s Web Accessibility Initiative has developed some standards (such as WCAG2 and WAI-ARIA) to enable developers to build accessible applications. But we have more work to do to make it easier to design user interfaces that scale to a wide array of devices and assistive technologies. We have confidence that designers and developers will come up with creative new ways to use standards for new contexts. For example, the vibration API used by some mobile applications might offer new ways to communicate safely with drivers through the steering wheel in some automotive apps, and could also be used to create more accessible experiences for people with certain types of disabilities.
Less than one third of current Web users speak English as their native language and that proportion will continue to decrease as the Web reaches more and more communities of limited English proficiency. If the Web is to live up to the “World Wide” portion of its name, it must support the needs of world-wide users at a basic level as they engage with content in the various languages. The W3C Internationalization Activity pursues this goal in various ways, including coordination with other organizations, creation of educational materials, coordination on the work of other W3C groups, and technical work itself on various topics.
Earlier I mentioned the pattern of widely used applications migrating “closer to the core.” While this is true for all the Foundations, it is especially clear in the Services Foundation, where today we are exploring the four most likely candidates for future inclusion.
The first is Web payments. Payments have been with us for decades, and e-commerce is thriving, predicted to reach $1.471 trillion this year, an increase of nearly 20% from last year. But usability issues, security issues, and lack of open standard APIs are slowing innovation around digital wallets and other ways to benefit payments on the Web. W3C is poised to launch a group to study the current gaps in Web technology for payments. The Payments group will recommend new work to fill those gaps, some of which will have an impact on other Foundations (e.g., Usability, Security and Privacy). Because a successful integration of payments into the Web requires extensive cooperation, the group will also liaise with other organizations in the payments industry that are using Web technology to foster alignment and interoperability on a global scale.
The second is annotations. People annotate the Web in many ways, commenting on photos or videos, when reading e-books, and when supporting social media posts. But there is no standard infrastructure for annotations. Comments are siloed in someone else’s blog system, or controlled by the publisher of an e-book. Our vision is that annotations on the Web should be more Web-like: linkable, sharable, discoverable, and decentralized. We need a standard annotation services layer.
The third is the Social Web. Consumer facing social Web services, combined with “bring your own device (BYOD)” and remote work policies in enterprise, have driven businesses to turn increasingly to social applications as a way to achieve scalable information integration. Businesses are now looking for open standards for status updates (e.g., Activity Streams) and other social data. These same standards will give users greater control over their own data and thus create new opportunities in the Security and Privacy Foundation as well.
The fourth is the Web of Data. The Semantic Web and Linked Data Platform already provide enhanced capabilities for publishing and linking data. These services have been used to enhance search engines and to address industry use cases in health care and life sciences, government, and elsewhere. But we know that more is necessary for developers to make use of the troves of data currently available. One upcoming activity will be to collect ontologies of how linked data should be organized for different applications (notably for search).
Web technology continues to expand by leaps and bounds. The core capability is growing, the application to industry is growing, and we continually find new devices for web technology and new use cases. To be able to focus on this expansion we need modular design, and a principle in modular design is to be able to clearly and succinctly talk about categories of function. Hopefully this post begins a healthy discussion about the framework for the Open Web Platform going forward.
I acknowledge extensive discussions within the W3C Team, but especially with Phil Archer, Robin Berjon, Dominique Hazaël-Massieux, Ivan Herman, Ian Jacobs, Philippe Le Hégaret, Dave Raggett, Wendy Seltzer, and Mike Smith. At the Extensible Web Summit, I received great input from Axel Rauschmayer, Benoit Marchant, and Alan Stearns.
Will HTML5 make the use of WAI-ARIA in HTML redundant? the short answer is definitely not. There are many ARIA roles and properties that are not provided by native elements and attributes in HTML5. Also developers still have the desire to roll their own interactive controls or web components even though they have been available in HTML as native elements for 15 years, why would this suddenly change with HTML5?
First rule of ARIA use (never forget):
If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Examples from real world web apps : a button and a link
Developers have had for 15 years a number of native elements they can use for buttons and the
a element for links, provided in HTML 4, all of which provide built in mouse and keyboard interaction and convey role, state and name properties to accessibility APIs:
But still in 2014 companies like Twitter and Google, choose to emulate a button with code (not to mention the associated scripting) such as this:
<a data-placement="bottom" class="js-tooltip global-dm-nav" href="#" role="button" data-original-title="Direct messages"> <span class="Icon Icon--dm Icon--large"></span> <span class="dm-new"><span class="count-inner"></span></span> <span class="visuallyhidden">Direct messages</span> </a>
<div tabindex="0" role="button" act="20" class="T-I J-J5-Ji nu T-I-ax7 L3" style="-moz-user-select: none;" data-tooltip="Refresh" aria-label="Refresh"> <div class="asa"> <div class="asf T-I-J3 J-J5-Ji"> </div></div></div>
and a link like this:
<div role="link" tabindex="0" idlink="" class="py pr" id=":i"> <h2 id=":k" class="pw">Quick Links</h2> <div class="qn"></div></div>
Note: First example from twitter, others are from Google’s Gmail application.
The reason is probably because they cannot apply the styles they want to native interactive elements, but who knows? What is important for accessibility is if developers choose to code in this way, they now have a method to provide the needed accessibility information. It would be preferable that they used the available native HTML elements, but if they do not, then ARIA provides what HTML alone cannot.
ARIA used in native HTML implementations (there goes the neighborhood):
<input type="week"> #shadow root (user agent) <div pseudo="-webkit-datetime-edit" id="date-time-edit" datetimeformat="'Week 'ww, yyyy"> <div pseudo="-webkit-datetime-edit-fields-wrapper"> <div pseudo="-webkit-datetime-edit-text">Week </div> <span <mark>role="spinbutton"</mark> <mark>aria-valuetext="blank"</mark> <mark>aria-valuemin="1"</mark> <mark>aria-valuemax="53"</mark> pseudo="-webkit-datetime-edit-week-field">--</span> <div pseudo="-webkit-datetime-edit-text">, </div> <span <mark>role="spinbutton"</mark> <mark>aria-valuetext="blank"</mark> <mark>aria-valuemin="1"</mark> <mark>aria-valuemax="275760"</mark> pseudo="-webkit-datetime-edit-year-field">----</span> </div></div></input>
Aria roles and properties not available in HTML5
Below are listed the ARIA roles and properties. not considered to be available natively in HTML5. It is clear that many roles and properties provided by ARIA which can be used to convey information to users are not available in HTML5.
ARIA States and Properties (aria-* attributes)
Stop adding ARIA cruft to your crappy markup. Just learn HTML. Keep it simple.
— Krijn Hoetmer (@krijnhoetmer) September 29, 2014
— Steve Faulkner (@stevefaulkner) October 1, 2014