Steve Faulkner et alRough Guide: browsers, operating systems and screen reader support – Updated

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

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.

Table legend

  • supported “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 “not applicable” means the browser does not run on the OS
  • not supported “not supported” means the browser does not have practical support for screen readers on the OS.
  • not known “not known” means that accessibility support information is not publicly available.
  • supported, but limited support data.browsers recently added to OS’s, Early data indicates usable accessibility support.
  • not knownlikely, not supported 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.

Practical screen reader support by browser and OS (24/11/2014)
Chrome Firefox Internet Explorer Opera Safari
Windows supported supported supported note partial support not supported
OSX supported partial support not applicable partial support supported
Linux not supported supported not applicable not knownlikely, not supported not applicable
IOS supported, but limited support data not applicable not applicable not knownlikely, not supported supported
Android supported supported not applicable not knownlikely, not supported partial support
(built-in Android browser
webkit  based)
Chrome OS supported not applicable not applicable not applicable not applicable
Firefox OS not applicable partial support not applicable not applicable not applicable

References:

Steve Faulkner et alSlow Week in Web Standards

Scanning through my twitter timeline, realized that it had been another week in web standards devoid of progress, passion and humour…

 

 

 

<script async="" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

 

<script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

Planet MozillaPushing Hybrid Mobile Apps to the Forefront

Mozilla Festival 2014 was held in London in October.

At Mozilla Festival 2014, I facilitated a session on Pushing Hybrid Mobile Apps to the Forefront. Before, I had been building a poker app to keep track of my poker winning statistics, record notes on opponents, and crunch poker math. I used the web as a platform, but having an iPhone, wanted this app to be on iOS. Thus, the solution was hybrid mobile apps, apps written in HTML5 technologies that are wrapped to run "natively" on all platforms (e.g., iOS, Android, FirefoxOS).

I stumbled upon the Ionic hybrid mobile app framework. This made app development so easy. IT fulfills the promise of the web: write once, run everywhere. In being with Mozilla for over two years, I've read so little hype for hybrid mobile apps. Hybrid mobile apps have potential to convert much more native developers over to the web platform, but hybrid mobile apps aren't getting the ad-time they deserve.

What is a Hybrid Mobile App?

Hybrid mobile apps, well explained in this article from Telerik, are apps written in HTML5 technologies that are enabled to run within a native container. They use the device's browser engine to render the app. And then web-to-native polyfill can be injected, prominently Cordova, in order to access device APIs.

The Current Lack of Exposure for Hybrid Mobile Apps

In all of the Mozilla Developer Network (MDN), there are around three articles on hybrid mobile apps, which aren't really fully fleshed and in need of technical review. There's been a good amount of work from James Longster in the form of Cordova Firefox OS support. There could be more to be done on the documentation side.

Cross-platform capability on mobile should be flaunted more. In MDN's main article on Open Web Apps, there's a list of advantages on open web apps. This article is important since it is a good entry point to into developing web apps. The advantages listed shouldn't really be considered advantages relative to native apps:

  • Local installation and offline storage: to a developer, these should be inherent to an app, not an explicit advantage. Apps are expected to be installable and have offline storage.
  • Hardware access: also should be inherent to an app and not an explicit advantage. Apps are expected to be able to communicate with its device APIs.
  • Breaking the walled gardens: there are no "walls" being broken if these web apps only run in the browser and FirefoxOS. They should be able to live inside the App Store and Play Store to really have any effect.
  • Open Web App stores: well, that is prety cool actually. I built a personal app that I didn't want to be distributed except with me and antoher. So I simply built a page that had the ability to install the app. However, pure web apps alone can't be submitted it to App Store or Play Store so that should be addressed first.

What's missing here is the biggest advantage of all: being able to run cross-platform (e.g., iOS, Android, FirefoxOS, Windows). That's the promise the web, and that's what attracts most developers to the web in the first place. Write it once, run anywhere, no need to port between languages or frameworks, and still be able to submit to the App Store/Play Store duopoly for to gain the most users. For many developers, the web is an appropriate platform, saving time and maintenance.

Additionally, most developers also prefer the traditional idea of apps, that they are packaged up and uploaded to the storefront, rather than self-hosted on a server. On the Firefox Marketplace, the majority of apps are packaged over hosted (4800 to 4100).

There's plenty of bark touting the cross-platform capability of the web, but there's little bite on how to actually achieve that on mobile. Hybrid mobile apps have huge potential to attact more developers to the web platform. But with its lack of exposure, it's wasted potential.

So what can we do? The presence of hybrid mobile apps on MDN could be buffed. I've talked to Chris Mills of the MDN team at Mozfest, and he mentioned it was a goal for 2015. FirefoxOS Cordova plugins may welcome contributors. And I think the biggest way would be to help add official FirefoxOS support to Ionic, a popular hybrid mobile app framework which currently has over 11k stars. They've mentioned they have FirefoxOS on the roadmap.

Building with Ionic

Ionic Framework is a hybrid mobile app framework It has a beautifully designed set of native-like icons and CSS components, pretty UI transitions, web components (through Angular directives for now), build tools, and an easy-to-use command-line interface.

With Ionic, I built my poker app I initially mentioned. It installs on my phone, and I can use it at the tables:

Poker app

Poker app built with Ionic.

For the Mozfest session, I generated a sample app with Ionic (that simply just makes use of the camera), and put it on Github with instructions. To get started with a hybrid mobile app:

  • npm install -g ionic cordova
  • ionic start myApp tabs - creates a template app
  • cordova plugin add org.apache.cordova.camera - installs the Cordova camera plugin (there are many to choose from)
  • ionic platform add <PLATFORM> - where could be ios, android, or firefoxos. This enables the platforms
  • ionic platform build <PLATFORM> - builds the project

To emulate it for iOS or Android:

  • ionic emulate <PLATFORM> - will open the app in XCode for ios or adbtools for android

To simulate it for FirefoxOS, open the project with WebIDE inside platforms/firefoxos/www.

How the Mozfest Session Went

It was difficult to plan since Mozfest is more of a hands-on unconference, where everything is meant to be hands-on and accessible. Mozfest wasn't a deeply technical conference so I tried to cater to those who don't have much development experience and to those who don't bring a laptop.

Thus I set up three laptops: my Macbook, a Thinkpad, and a Vaio. And had three devices: my iPhone, a Nexus 7, and a FirefoxOS Flame. My Macbook would help to demonstrate the iOS side. Whereas the other machines had Linux Mint within a VirtualBox. These VMs had adbtools and Firefox with WebIDE set up. All the mobile devices had the demo apps pre-installed so people could try it out.

I was prepared as a boy scout. Well, until my iPhone was pickpocketed in London, stripping me of the iOS demonstration. Lugging around three laptops in my bag that probably amounted to 20 pounds back and forth between the hotel, subway, and venue wasn't fun. I didn't even know what day I was going to present at Mozfest. Then I didn't even use those meticulously prepared laptops at the session. Everyone who showed up was pretty knowledgable, had a laptop, and had an internet connection.

The session went well nonetheless. After a bit of speech about pushing hybrid mobile apps to the forefront, my Nexus 7 and Flame were passed around to demo the sample hybrid mobile app running. It just had a simple camera button. That morning, everyone had received a free Firefox Flame for attending Mozfest so it turned more into WebIDE session on how to get an app on the Flame. My coworker who attended was able to get the accelerometer working with a "Shake Me / I was shaken." app, and I was able to get geolocation working with an app that displays longitude and latitude coordinates with the GPS.

What I Thought About Mozfest

There was a lot of energy in the building. Unfortunately, the energy didn't reach me, especially since I was heavily aircraft-latencied. Maybe conferences aren't my thing. The place was hectic. Hard to find out what was where. I tried to go to a session that was labeled as "The 6th Floor Hub", which turned out to be a small area of a big open room labelled with a hard-to-spot sign that said "The Hub". When I got there, there was no session being held despite the schedule saying so as the facilitator was MIA.

The sessions didn't connect with me. Perhaps I wanted something more technical and concrete that I could takeaway and use, but most sessions were abstract. There was a big push for Mozilla Webmaker and Appmaker, though those aren't something I use often. They're great teaching tools, but I usually direct to Codecademy for those who want to learn to build stuff.

There was a lot of what I call "the web kool-aid". Don't get me wrong, I love the web, I've drank a lot of the kool-aid, but there was a lot of championing of the web in the keynotes. I guess "agency" is the new buzzword now. Promoting the web is great, though I've just heard it all before.

However, I was glad to add value to those who found it more inspiring and motivating than me. I believe my session went well and attendees took away something hard and practical. As for me, I was just happy to get back home after a long day of travel and go replace my phone.

Bruce LawsonReading List

W3C Team blogThis week: Chrome HTML5 features, Service Workers, Net neutrality, etc.

This is the 14-21 November 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

Net Neutrality

W3C in the Press (or blogs)

8 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.

Planet MozillaNative apps, the open web, and web literacy

In a recent blog post, John Gruber argues that native apps are part of the web. This was in response to a WSJ article in which Christopher Mims stated his belief that the web is dying; apps are killing it. In this post, I want to explore the relationship between native apps and web literacy. This is important as we work towards a new version of Mozilla’s Web Literacy Map. It’s something that I explored preliminarily in a post earlier this year entitled What exactly is ‘the mobile web’? (and what does it mean for web literacy?). This, again, was in response to Gruber.

Native app

This blog focuses on new literacies, so I’ll not be diving too much into technical specifications, etc. I’m defining web literacy in the same way as we do with the Web Literacy Map v1.1: ‘the skills and competencies required to read, write and participate on the web’. If the main question we’re considering is are native apps part of the web? then the follow-up question is and what does this mean for web literacy?

Defining our terms

First of all, let’s make sure we’re clear about what we’re talking about here. It’s worth saying right away that 'app’ is almost always used as a shorthand for 'mobile app’. These apps are usually divided into three categories:

  1. Native app
  2. Hybrid app
  3. Web app

From this list, it’s probably easiest to describe a web app:

A web application or web app is any software that runs in a web browser. It is created in a browser-supported programming language (such as the combination of JavaScript, HTML and CSS) and relies on a web browser to render the application. ( Wikipedia)

It’s trickier to define a native app, but the essence can be seen most concretely through Apple’s ecosystem that include iOS and the App Store. Developers use a specific programming language and work within constraints set by the owner of the ecosystem. By doing so, native apps get privileged access to all of the features of the mobile device.

A hybrid app is a native app that serves as a 'shell’ or 'wrapper’ for a web app. This is usually done for the sake of convenience and, in some cases, speed.

The boundary between a native app and a web app used to be much more clear and distinct. However, the lines are increasingly blurred. For example:

  • APK files (i.e. native apps) can be downloaded from the web and installed on Android devices.
  • Developments as part of Firefox OS mean that web technologies can securely access low-level functionality of mobile devices (e.g. camera, GPS, accelerometer).
  • The specifications for HTML5 and CSS3 allow beautiful and engaging web apps to be used offline.

Web literacy and native apps

As a result of all this, it’s probably easier these days to differentiate between a native app and a web app by talking about ecosystems and silos. Understanding it this way, a native app is one that is built specifically using the technologies and is subject to the constraints of a particular ecosystem. So a developer creating an app for Apple’s App Store would have to go through a different process and use a different programming language than if they were creating one for Google’s Play Store. And so on.

Does this mean that we need to talk of a separate 'literacy’ for each ecosystem? Should we define 'Google literacy’ as the skills and competencies required to read, write and participate in Google’s ecosystem? I don’t think so. While there may be variations in the way things are done within the different ecosystems, these procedural elements do not constitute 'literacy’.

What we’re aiming for with the Web Literacy Map is a holistic overview of the skills and competencies people require when using the web. I think at this juncture we’ve got a couple of options. The first would be define 'the web’ more loosely to really mean 'the internet’.

This is John Gruber’s preferred option. He thinks we should focus less on web browsers (i.e. HTML) and more on the connections (i.e. HTTP). For example, in a 2010 talk he pointed out a difference between 'web apps’ and 'browser apps’. His argument rested on a technical point, which he illustrated with an example. When a user scrolls through their timeline using the Twitter app for iPhone, they’re not using a web browser, but they are using HTTP technologies. This, said Gruber, means that ecosystems such as Apple’s and the web are not in opposition to one another.

While this is technically correct, it’s a red herring. HTML does matter because the important thing here is the open web. Check out Gruber’s sleight of hand in this closing paragraph:

Arguments about “open” and “closed” often devolve into unresolvable cross-talk where the two sides have different definitions of what open and closed really mean. But the weird thing about a truly open platform is that its openness allows closed things to be built on top of it. In broad strokes, that’s why GNU/GPL software isn’t “open” in the way that BSD software is (and why Richard Stallman outright rejects the term “open source”). If you expand your view of “the web” from merely that which renders inside the confines of a web browser to instead encompass all network traffic sent over HTTP/S, the explosive growth of native mobile apps is just another stage in the growth of the web. Far from killing it, native apps have made the open web even stronger.

I think Gruber needs to read up on enclosure and the Commons. To use a 16th-century English agricultural metaphor, the important thing isn’t that the grass is growing in the field, it’s that it’s been fenced off and people are excluded.

A way forward

A second approach is to double-down on what makes the web different and unique. Mozilla’s mission is to promote openness, innovation & opportunity on the web and the Web Literacy Map is a platform for doing this. Even if we don’t tie development of the Web Literacy Map explicitly to the Mozilla manifesto it’s still a key consideration. Therefore, when we’re talking about 'web literacy’ it’s probably more accurate to define it as 'the skills and competencies required to read, write and participate on the open web.

What do we mean by the 'open web’? While Tantek Çelik approaches it from a technical standpoint, I like Brad Neuberg’s (2008) focus on the open web as a series of philosophies:

Decentralization - Rather than controlled by one entity or centralized, the web is decentralized – anyone can create a web site or web service. Browsers can work with millions of entities, rather than tying into one location. It’s not the Google or Microsoft Web, but rather simply the web, an open system that anyone can plug into and create information at the end-points.
Transparency - An Open Web should have transparency at all levels. This includes being able to view the source of web pages; having human-readable network identifiers, such as URLs; and having clear network entry points, such as HTTP and REST exposes.
Hackability - It should be easy to lash together and script the different portions of this web. MySpace, for example, allows users to embed components from all over the web; Google’s AdSense, another example, allows ads to be integrated onto arbitrary web pages. What would you like to hack together, using the web as a base?
Openness - Whether the protocols used are de facto or de-jure, they should either be documented with open specifications or open code. Any entity should be able to implement these standards or use this code to hook into the system, without penalty of patents, copyright of standards, etc.
From Gift Economies to Free Markets - The Open Web should support extreme gift economies, such as open source and Wikis, all the way to traditional free market entities, such as Amazon.com and Google. I call this Freedom of Social Forms; the tent is big enough to support many forms of social and economic organization, including ones we haven’t imagined yet. Third-Party Integration - At all layers of the system third-parties should be able to hook into the system, whether creating web browsers, web servers, web services, etc.
Third-Party Innovation - Parties should be able to innovate and create without asking the powers-that-be for permission.
Civil Society and Discourse - An open web promotes both many-to-many and one-to-many communication, allowing for millions of conversations by millions of people, across a range of conversation modalities.
Two-Way Communication - An Open Web should allow anyone to assume three different roles: Readers, Writers, and Code Hackers. Readers read content, Writers write content, and Code Hackers hack new network services that empower the first two roles.
End-User Usability and Integration - One of the original insights of the web was to bind all of this together with an easy to use web browser that was integrated for ease of use, despite the highly decentralized nature of the web. The Open Web should continue to empower the mainstream rather than the tech elite with easy to use next generation browsers that are highly usable and integrated despite having an open infrastructure. Open should not mean hard to use. Why can’t we have the design brilliance of Steve Jobs coupled with the geek openness of Steve Wozniak? Making them an either/or is a false dichotomy.

Conclusion

The Web Literacy Map describes the skills and competencies required to read, write and participate on the open web. But it’s also prescriptive. It’s a way to develop an open attitude towards the world:

Open is a willingness to share, not only resources, but processes, ideas, thoughts, ways of thinking and operating. Open means working in spaces and places that are transparent and allow others to see what you are doing and how you are doing it, giving rise to opportunities for people who could help you to connect with you, jump in and offer that help. And where you can reciprocate and do the same.

Native apps can mitigate against the kind of reciprocity required for an open web. In many ways, it’s the 21st century enclosure of the commons. I believe that web literacy, as defined and promoted through the Web Literacy Map, should not consider native apps part of the open web. Such apps may be built on top of web technologies, they may link to the open web, but native apps are something qualitatively different. Those who want to explore what reading, writing and participating means in closed ecosystems have other vocabularies – provided by media literacy, information literacy, and digital literacy – with which to do so.


Comments? Questions? Direct them here: doug@mozillafoundation.org or discuss this post in the #TeachTheWeb discussion forum

Planet MozillaFirefox and Cisco’s Project Squared

Yesterday I was at Cisco’s Collaboration Summit where Cisco’s CTO for Collaboration Jonathan Rosenberg and I showed Cisco’s new WebRTC-based Project Squared collaboration service running in Firefox, talking to a Cisco Collaboration Desktop endpoint without requiring transcoding.

This demo is the culmination of a year long collaboration between Cisco and Mozilla in the WebRTC space. WebRTC enables voice and video communication directly from within the browser. This means that anyone can build a video conferencing service just using WebRTC and HTML5 standards, without the need for the user to download a plugin or a native application.

Cisco is not only developing WebRTC-based services that run on the Web. They have  also joined a growing number of organizations and companies helping Mozilla to build a better Web. Over the last year Cisco has contributed numerous technical improvements to Mozilla’s WebRTC implementation, including support for screen sharing and the H.264 video codec. These features are now shipping in Firefox. We intend to use them in the future in Mozilla’s own Hello communication service that we are bringing to Firefox.

Cisco’s contributions to the Web go beyond just advancing Firefox. For the last three years the IETF, the standards body defining the networking protocols for WebRTC, has been unable to agree on a mandatory video codec for WebRTC, putting ubiquitous interoperability in doubt.

One of the major blockers to coming to a consensus was that H.264 is subject to royalty-bearing patents, which made it problematic for open source projects such as Firefox to deploy it. To break this logjam, Cisco open-sourced its H.264 code base and made it available in plugin form. Any product  — not just Firefox — can download the plugin and use it to enable H.264 without paying any royalties.

This collaboration between Mozilla and Cisco enabled Firefox to add support for H.264 in WebRTC, and also played a significant role in the compromise reached at the last IETF meeting to adopt both H.264 and VP8 as mandatory video codecs for WebRTC in browsers. As a result of this compromise, in the future all browsers should match the capabilities already available in Firefox.

Mozilla will continue to work on advancing Firefox and the Web, and we are excited to have strong partners like Cisco who share our commitment to the open Web as a shared technology platform.


Filed under: Mozilla Tagged: Mozilla, WebRTC

Planet MozillaAnother 100K bug reports… and nobody noticed

Bugzilla bug report #1,100,000

We used to have a little cheering for every 100,000 bug reports filing.  Bugzilla hasn’t keeled over yet!

But somehow, in the aftermath of the megabug, I think we forgot to plan for this one.  Oops!

It looks like it took us about 19 months to get here from the previous one.  I’ll leave it to Gervase Markham to dig up the appropriate statistics.

Steve Faulkner et alHTML5 Accessibility analysis

HTML5Accessibility.com was updated last week to include the latest results for HTML5 accessibility support in Windows browsers. What do these results mean?

HTML5 Accessibility support: where are we at?

The aim of HTML5Accessibility.com is to track the implementation of accessibility support in browsers for a range of  User Interface (UI) features introduced in HTML5. Accessibility support is assessed in terms of the implementation in browsers of mappings for the features to accessibility APIs which Assistive Technology can make use of to convey HTML semantics and UI behavior to users, and the implemented keyboard interaction support for interactive controls. Consistent exposure of the accessibility information and keyboard support across browsers is a cornerstone of an accessible interoperable web.

Overview of HTML5 accessibility support in Windows browsers

HTML5 Accessibility Support Score

Firefox <meter max="100" min="0" value="85.5"></meter>
85.5/100

Chrome <meter max="100" min="0" value="83.3"></meter>
83.5/100

Internet Explorer<meter max="100" min="0" value="37"></meter>
37/100

Firefox have consistently lead the pack in providing accessibility support for new features as they are implemented. This is a great achievement by the Mozilla Accessibility Engineers and really important work, as it allows user with disabilities, who require assistive technology to participate on the web, the opportunity to do so.

Chrome support has improved markedly since the last update, and is now on par with Firefox. This is due to the efforts of members of the chromium project working hard to resolve a large number of  bugs. Kudos to these chromium project members!

Internet Explorer continues to perform poorly in implementing accessibility support overall. It must be noted that IE support for interactive UI features is on par with Chrome and Firefox, but Internet Explorer continues to be particularly poor in providing accessibility support for non interactive HTML elements. Good news is we can expect improvements from IE soon:

<script async="" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

Opera in theory, now Opera has switched to the Blink rendering engine, should have similar support to Chrome, but as Opera provides no accessibility documentation or assistive technology support claims (none that I could find) for any of its browsers, it is considered an unknown entity.

What about browsers on other operating systems?

Apologies for not providing detailed information on OSX/iOS, Linux and Android etc. I simply don’t have the time to do so at present. The Rough Guide: browsers, operating systems and screen reader support provides an overview of the best OS/browser combinations for accessibility support. In brief: Safari and Chrome both have very good support on OSX/iOS. Firefox has very good support on Linux.

Detailed accessibility support information for Windows browsers is available at HTML5Accessibility.com

Note: Browser implementation bugs have been filed where applicable and are listed in the ‘notes’ column of the HTML5 accessibility support tables.

Bruce LawsonReading List

W3C Team blogThis week: wide-review signal list, President Obama on Net Neutrality, etc.

This is the 7-14 November 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

Net Neutrality & Open Web

W3C in the Press (or blogs)

3 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.

Planet MozillaCrypton: The Privacy Framework

Crypton Logo

Since I left Mozilla last year, I have been working on Crypton ( https://crypton.io ), an HTML5 application framework that places privacy above all else. Last month, my team was invited to the ‘Hack In The Box’, Malaysia security conference to lead a Lab Session on Crypton.

We were required to write a whitepaper for HiTB to publish, which was a great exercise, as my team has been meaning to write a paper for some time. It was a long trip, but worth it. We led a group of engineers through most of the Crypton API in about 2 hours.

I lived-coded the ‘skeleton’ of a messaging application in 74 lines of JavaScript. The coolest thing about this session was using Firefox’s Scratchpad for all of the live-coding. It worked so well, we plan on doing more sessions like this.

Crypton is intended for use inside of mobile and desktop applications (FirefoxOS, too). Our initial target for development is via Cordova and node-webkit. The API hides all of the complexity of cryptography from the developer. Developers use APIs that look like any other hosted API, for instance, account creation looks something like this:

var myAccount; 
crypton.generateAccount('alice', 'password', function callback(error, successResult){
  if (error) { console.error(err); return;}
  myAccount = successResult;
});

Beneath this elegant, every-day-looking API call, a set of encryption keys are generated for encryption, signing and HMAC as well as a stretched key via the password that wraps all other keys. This keyring is then stored on the server making multiple-device operations easy.

As we move forward with the Crypton framework, we are building a “private backend service” which will make using Crypton trivially easy to use and require no system administration. More on this in a future post.


Steve Faulkner et alDesign like we give a damn! Accessibility @W3C

Lots of things happened at the W3C TPAC 2104 conference. It was a busy week in web standards.

HTML5 became an official W3C Recommendation, the W3C turned 20, and the web itself celebrated its 25th anniversary. In amongst all these momentous events there was still time for the assembled W3C participants to explore new ideas through a series of lightning talks, and now the lightning talks are starting to be made available for everyone to share.

A highlight of TPAC, for me, was to be in the audience for the lightning talks and hear my dear friend and colleague Léonie Watson, in just 4 minutes, say so much about what we as participants in the development of web standards at the W3C could do, to re-invigorate and broaden our approach, to fulfill the promise of an accessible web.

Léonie Watson: Design like we give a damn!

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="375" src="http://player.vimeo.com/video/110965713" width="500"></iframe>

Léonie Watson: Design like we give a damn! from W3C on Vimeo.

IEBlogLiving on the Edge – our next step in helping the web just work

Today we are rolling out a new Windows 10 preview build with significant Internet Explorer interoperability updates. In line with our commitment to interoperability and compatibility, this update includes over 2000 fixes for interoperability issues, support for 20 new platform features, and our new architecture for advancing interoperability and compatibility. We’re excited to be sharing this work at such an early stage in our development process and we look forward to hearing your feedback. We're also rolling out this preview build to users of our new RemoteIE service, available for Windows, Mac OS X, and other platforms.

Introducing the “living” Edge document mode

The cornerstone of this update to IE is the “Edge” mode platform—a new document mode designed with interoperability at its core. With this mode, we’re applying the highly successful interoperability strategy of Windows Phone 8.1 Update to Windows 10.

As we announced in August 2013, we are deprecating document modes as of IE11. With our latest platform updates, the need for legacy document modes is primarily limited to Enterprise legacy web apps. With new architectural changes, these legacy document modes will be isolated from changes in the “living” Edge mode, which will help to guarantee a much higher level of compatibility for customers who depend on those modes and help us move even faster on improvements in Edge. The next major version of IE will still honor document modes served by intranet sites, sites on the Compatibility View list, and when used with Enterprise Mode only.

Public Internet sites will be rendered with the new Edge mode platform (ignoring X-UA-Compatible).  It is our goal that Edge is the "living" document mode from here out and no further document modes will be introduced going forward. We need your help in testing this new mode so we are enabling it on by default for a small percentage of the Windows Insider user base and those of you that manually select the mode (see below).

Edge mode introduces an interoperable UA string designed to get today’s modern Web content, and to avoid old IE-only content. We’ve also spent a lot of time ensuring that the IE platform behaves like modern Web content expects.

In cases where these changes necessarily differ from standards, we’re following through with standards bodies and other browsers to update specs and implementations to reflect the interoperable behavior.

New features in preview

Also in Edge mode are early implementations of several in development features (we’ll blog more about these in depth soon):

CSS Preserve-3D – A popular developer request, this feature enables CSS transforms on multiple elements to be composed as a part of a 3D scene rather than flattened together.

Without preserve-3d  With preserve-3d

 

Content Security Policy 1.0 CSP is the next step forward since HTML5 Sandbox in preventing cross-site scripting. Pages provide a policy via the Content-Security-Policy header. This policy defines the origins from which resources on the page (JS, CSS, plugins, images, etc) are allowed to be loaded. This adds a defense-in-depth mechanism for preventing malicious content from being injected into the page. Resources blocked by CSP are reported through F12 tools and, optionally, as a report back to the server.

CSP violations reported in F12 Tools

CSS Interaction Media Queries (Level 4) – A key component in responsive design is responsive input handling. We’ve talked before about adapting UX for input types, and this feature gives Web developers a new tool to do just that. Stylesheets can now use pointer and hover media queries to adapt UI based on the general precision of the user’s input (fine/coarse) and whether the device supports hover.

<script src="https://gist.github.com/jacobrossi/85ab1772c392b57ac131.js" type="text/javascript"></script>

Gamepad API First previewed earlier this year, Gamepad API is now in the preview for Windows 10. Plug in an Xbox One or Xbox 360 controller and check out our demo code on GitHub.

WAV Audio This audio format uses PCM audio for lossless quality. With this release, WAV is supported in the <audio> element and will eventually be supported with Web Audio in a future release.

Selection API– We've improved our interoperability for the Selection object by implementing APIs like Selection.extend(), containsNode(),and setBaseAndExtent(). We have also helped get the W3C Selection API specification to First Public Working Draft and ensured it covers all of these interoperable APIs.

ECMAScript 6 Features – New language features from the latest ES6 “Harmony” draft specification:

Classes – syntax for declaring classes in ES6.

Promises – allows easier and cleaner asynchronous coding. Adds the Promise constructor, along with the 'all' and 'race' utility methods to the language itself.

Iterators – enables iteration over iterable objects (including arrays, array-like objects, iterators and generators), invoking a custom iteration hook with statements to be executed for the value of each distinct property.

Arrow Function – the arrow (=>) provides a shorthand for the function keyword with lexical 'this' binding.

Math, Number, Object, String Built-ins – dozens of new utility functions and properties for manipulating and inspecting data.

Object Literal Enhancements – adds computed properties, concise method definitions, and short-hand for properties whose value is initialized to a same-named variable.

Spread – the spread operator expands iterable expressions into individual arguments. For example, a.b(…array) is roughly the same as a.b.apply(a, array).

Template Strings – string literals that allow for expressions to be evaluated and concatenated with the string literal.

Symbols – allows properties to be added to existing objects without the possibility of interference with the existing properties, unintended visibility, or with other uncoordinated additions by any other code.

Proxies – enables JavaScript programmers to implement objects with new kinds of custom behavior.

Weak Set – a set of objects such that those objects will be collected if they are not referenced anywhere else.

 

Experimental Features

Also in this release is the introduction of a new experimental features dashboard, accessed by browsing to about:flags. Here you’ll find new platform experiments that you can enable to try out the very bleeding edge of what we’re working on. Future experiments may include new standards we’re working on, interoperability fixes we’re trying out, new performance or security architectures, and more.

Given the sheer volume of changes in Edge mode, we’re going to progressively roll out the new mode by choosing a random set of Windows Insiders to get Edge while the rest remain in 11 document mode. Our data science and quality engineering teams will leverage user feedback and anonymous telemetry to guide the roll out while we make tweaks to the platform in future preview builds accordingly.

If you’re a developer coding against new features or testing for compatibility, you can head over to about:flags and choose Edge mode explicitly by setting “Enable Experimental Web Platform Features” to “Enabled” (“Automatic” restores you to the default roll out and “Disabled” lets you compare with 11 mode).

New about:flags page for enabling experimental features

At any time, developers can identify the mode a page is in via F12 tools. Note that dynamically switching between Edge and other document modes from F12 isn’t yet supported (we told you these experiments may bite!). For now, use about:flags for switching when developing and testing.

Giving Feedback

We’re sharing our changes earlier in the process than ever so we can collect your feedback to help shape the product. Last month, we introduced the IE Platform Suggestion Box on UserVoice where developers can suggest and vote on improvements to the platform. In this release, we’re adding a feedback tool right in the top-level UI. Just click the smiley face icon to “send a frown” such as reporting a problem on a site. If the page is running in Edge mode, you can also try reloading in the “compatibility mode” (IE11 behavior). As always, you can also report issues through Connect or the Windows Feedback app in the Windows 10 Tech Preview.

Click the smiley to report a web site problem

We’re excited to share with you an early look at what we’ve been working on. Join our engineering team on Twitter at 11am PST Friday November 14 where we'll be answering your #AskIE questions, and follow along with some of the other work we’re planning at status.modern.IE.

Jacob Rossi (@jacobrossi) - Senior Program Manager, Internet Explorer


Update 11/12/2014 : Added ES6 Proxies and WeakSet to the list of features in this preview build, removed RegExp built-ins (still in development)

W3C Team blogA Productive TPAC 2014 and W3C Highlights

tpac-250

TPAC 2014, W3C’s annual organization-wide meeting, was a milestone for W3C and the Web community on several levels. Thirty-four groups met face-to-face and held joint meetings the last week of October. Participants organized 30 breakout sessions on telecommunications, privacy, Web of things, payments, APIs, testing, robotics, W3C agility, and more. With that many meetings and so many attendees, I can’t speak to all the highlights of the week. But here were a few for me:

  • Nearly 550 people attended TPAC meetings, a record, and a great indicator of the vitality of our agenda. Several groups met for the first time face-to-face: the Social Web Working Group, Payments Interest Group, Web Annotations Working Group, and the RDF Data Shapes Working Group.
  • We celebrated the 20th anniversary of W3C, with an all-star slate of speakers and panelists. We live-streamed the event and have published some photos as well. Many thanks to our sponsors Intel, Ford Foundation, ICANN, Knight Foundation, Rakuten, and Tata Communications.
  • We announced the HTML5 Recommendation, emphasizing the work of the last two years to build a test suite of more than 100,000 tests to drive interoperability, and the Royalty-Free licensing commitments from more than 60 Members that make this the premiere platform for innovation. As part of the announcement, we released a video on the value of standards that was viewed 65,000 times in less than a week.
  • With the completion of HTML5, and while so many people were gathered in Santa Clara, it was a great opportunity to reflect on what the community has accomplished and what lies ahead. The HTML Working Group spent some time at its face-to-face meeting planning next steps. There were also spirited discussions of developer needs, framed through the Application Foundations taxonomy.

The week was busy, and from all signs, productive. One Advisory Committee Representative expressed his appreciation for “an excellent week loaded with events,” and I hope that long-time and new Members alike found it a valuable opportunity to connect.

As part of preparation for TPAC we published for the Membership “W3C Highlights – October 2014,” now public, which I invite you to read.

We are already looking forward to TPAC 2015, 26-30 October in Sapporo, Japan (just prior to the IETF meeting 1-6 November in Yokohama).

Planet MozillaAnnouncing Quaxe, native desktop and mobile apps from html5 and Haxe

My technical world changed a bit recently with a few events that directly impacted me or the activities of my company, Disruptive Innovations:

  1. Mozilla shows increasing signals that the future of XUL as a platform for embedders like my company is not bright. XULRunner has many users around the world but it's not part of the roadmap any more, unfortunately. I won't discuss here their corporate strategy. My applications BlueGriffon and BlueGriffon EPUB Edition being based on XULRunner and my business being largely based on them, it would be a bit foolish to avoid looking for an alternative...
  2. I have not found a single solution allowing me the flexibility of XUL+JavaScript in native desktop and/or mobile cross-platform apps; there are hybrid solutions for mobile, almost nothing for desktop in a cross-platform fashion.
  3. the two only potential solutions, Qt on one hand and AdobeAir on the other, do not satisfy me for the following reasons:
    1. Adobe Air is nothing near native,
    2. Qt is a big and powerful beast, hard to learn and master.
  4. Apple's Swift looks nice and powerful but cross-platform is not a word available in the Apple ecosystem.
  5. I have discovered Haxe. Haxe is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a complete cross-platform standard library and ways to access each platform's native capabilities. If you know ECMAScript and/or Java, you'll find Haxe fun and easy to master. I started playing with it and fell in love with its beauty, simplicity, and the large numbers of packages available.

In such cases, I take a few sheets of paper and start writing ideas. I have put a lot of ink on a dozen of originally blank pages and tested a few designs. I want, I need a very simple, flat learning curve way of writing standalone cross-platform native apps. And if the existing ecosystem can't give me such a tool, well, I do what I always do in such cases: I write my own... So I started writing my own environment for native desktop and mobile applications.

My requirements were the following ones:

  • all UI specified in html5, of course, with the help of role attributes... Maybe I'll add a XUL-like language too just for migration purposes.
  • UI styled by CSS, eh what did you expect? :-)
  • resulting native UI
  • code in Haxe of course compiled to native!!! Assets not trivially readable like with JS...
  • trivial embedding of Haxe-based gaming frameworks
  • trivial embedding of a browser instance (Blink, Servo, etc...). When I say trivial, I really mean it. If you've played with CEF, you probably understand that this is not what I mean.
  • no ugly hacks to deal with OSX menus or Windows icons.
  • dynamic UI changes based on DOM manipulation just like in XUL
  • very simple localization
  • a "Hello world" button in a native window should be a one-minute thing. No big environment to install, no complex setup, no new IDE to learn. You know html5? Just put a <button> inside a new document's <body> in your favorite code editor, open a terminal and type "quaxebuild". Done, you have a native app in hands, ready for distribution.

The result will be Quaxe. Native desktop and mobile applications with native UI from html5 and Haxe.

I am glad to share with you the first demo screenshot below. The app was launched through a open bin/mac/MyFirstTest.app command line on OSX. Just to be very clear, there is NO BROWSER WINDOW in the screenshot below. The app is only a native resizable main frame containing a native button. It's specified in html5, you can access and modify its DOM but it's not your regular browser, there is no Blink, Gecko, Servo or any Web rendering engine inside. There is no common runtime either, à la Adobe Air. It's very, very lightweight despite of having to implement a xml parser, DOM4, a CSS parser, the whole CSS cascade and an OM for the widgetry.

First test screenshot

As you can see above, it's already taking shape. If you're an investor and you're interested, please do not hesitate to contact me at your convenience. Writing native apps is going to be way cooler and simpler than it is now, that's a promise.

Bruce LawsonReading List

W3C Team blogThis week: HTML5 is a Recommendation, #w3c20, Winamp in HTML5+JS, etc.

This is the 28 October – 7 November 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

W3C in the Press (or blogs)

57 articles since the last Digest, including 26 about HTML5 to Rec; a selection follows. You may read all articles in our Press Clippings page.

Bruce LawsonNotes on draft CSS “alt” property

A while ago, there was discussion in CSS Working Group about an alt property to be added to CSS. Its purpose is to let assistive technology know the meaning of unicode characters inserted into a visual rendering of a document with CSS generated content. The problem is described by James Craig, Apple’s nice accessibility chappie.

It’s been shipping as -webkit-alt for a year now, and has just been added to the draft CSS Pseudo-Elements Module Level 4 spec. Let’s say you’re using a star glyph to show something is “new”, by generating CSS content using a class of .new as your selector:

.new::before { 
  content: url(./img/star.png);
  alt: "New!"; 
}

The alt gives information to assistive technology.

The alt string can be blank. Assume you’re generating “►” to show that a widget is expandable. Because you’re a lovely human being and a responsible developer, you’re using aria-expanded="false" in the HTML. Therefore, you’d use empty alt in the CSS that generates the glyph to prevent assistive technology “helpfully” reading out “Black right-pointing pointer” after the AT has relayed the ARIA information to the user:

.expandable::before {
  content: "\25BA"; /* a.k.a. ► */
  alt: ""; 
  /* aria-expanded="false" already in DOM, 
     so this pseudo-element is decorative */
}

Update 17:05 GMT fantasai of the CSS WG has mailed the CSS Working Group protesting against the syntax above. I don’t have any horse in the syntax race; my aim with this post is to show that we need some mechanism to give alternate content to assistive technology given that we allow non-textual content to be generated via CSS.

When I tweeted about this earlier, a few people objected to the concept because it adds content to CSS. But that ship has long sailed, with the content property that people have been using for ages. If you say “adding non-decorative content to a page is a misuse of CSS that merits the author 100,000 years in purgatory with Tim Berners-Mephistopholee pouring hot Ovaltine over their dingle-dangles whenever they try to sleep”, I will vehemently nod my agreement.

But sometimes, for organisational reasons, or because you inherited code, or you’re refactoring code from before you saw the light, you’re working with CSS that generates icons. This new property at least allows an author to make that content more accessible.

Years ago, I joined a web team a week after their brand new website had been delivered, months late and squillions over budget, by Big London Agency PLC. The site was a vile splodge of nested layout table cells and spacer GIFs with “click here” links pointing to PDFs. Of course, I could have instantly resigned my job and let the bank repossess my house.

Instead, I gently pointed out to any who would listen the inadequacies of the site and made plans about how it could be refactored. But while biding my time, I was also making small tweaks here and there to make it better and incrementally more accessible; removing duplicate link text from title attributes, changing “click here”s, putting blank alt text on spacer GIFs in the small parts of the template I controlled.

This was before the days of ARIA but I would have jumped at the chance of adding role="button" to the horrible mess of nested <div>s that the CMS spat out. Yes, it’s much better to spend a fortune getting the external CMS provider in to change the templates, the retest every single form on every single browser – but that simply wasn’t possible.

Two years later, when the senior manager who commissioned the terrible site left and we could jettison it, we did. And then we did it right. But for those who needed the content and were unable to wait nearly three years (that is, everyone), I’m glad I applied sticking plasters and polished turds.

It’s often said that if a job’s worth doing, it’s worth doing well. But it’s also wise to remember: sometimes, if a job’s worth doing, it’s worth doing badly than not at all. If you must have meaningful content generated by CSS, at least now you can make it accessible.

Planet MozillaTaking a break

sleeping-red-panda

Four years ago I announced that I will join Mozilla as principal evangelist and I was the happiest person alive. I exclaimed that I want Mozilla to be the “Switzerland of HTML5” and an independent player in the great browser wars around the early days of this new technology revolution. I also announced that I am excited to use my flat more as I can work from home.

Now I am here and I have hardly had the chance to do so as I was busy getting from event to event, training to training and meetup to meetup. And whilst this is exciting it is also superbly taxing. It is time to lean back a bit, relax and have some me time.

I feel the first signs of burnout and I think it is very important to not let a fast and seemingly glamourous lifestyle on the road as an official spokesperson get in the way of finding peace and tranquility. I spoke in my last TEDx talk about getting too excited about one’s own online personality and living for that one and how dangerous that is.

And here I am finding myself being excited about Chris on the road and forgot about Chris who just lets go and leaves things to sort themselves out.

This is why I am taking a break from Mozilla. I am going on a sabbatical for a while and be a spectator watching the rewards of all the work we put in the last years. Firefox’s 10th anniversary is coming and great things are afoot.

I think we’ve shown that we can be the “Switzerland of HTML5” and it is time for me to have some time for myself and see what my colleagues can do. That’s why I am stepping down as “the Mozilla guy” and be plain Chris for a while.

I want to thank all my colleagues over the years for the great time I had. It is amazing to see how many dedicated and gifted people can work together and create something open and beautiful – even in traditionally very closed environments like the mobile space.

I will of course be around and you will be able to meet me at selected events and online. People in London and Stockholm will also see more of me. I will only take it slower from now on until the new year and represent myself and not the large, amazing and wonderful world that is Mozilla. As it stated on one of our summits: it is one Mozilla and many voices. And I will lean back, listen, and enjoy.

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>