Archive for the 'call to arms' Category

Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps

On 4 March this year, the UK Competition and Markets Authority announced that it is

investigating Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

Submissions from the public were invited, so I replied and was invited, with “Clark Kent” (a UK iOS Web-Apps developer who wishes to be anonymous) and Stuart Langridge to brief the CMA in more detail. We were asked to attend for 2 hours, so spoke for one hour, and then took questions.

CMA are happy for our presentations to be published (they’re eager to be seen to be engaging with developers) but asked that the questions be kept private. Suffice it to say that the questioning went over the allocated time, and showed a level of technical understanding of the issues that surpasses many engineers. (The lawyers and economists knew, for example, that iOS browsers are all compelled to use WebKit under the hood, so Chrome/ Firefox/ Edge on iOS share only a name and a UI with their fully-fledged real versions on all other Operating Systems).

Clark’s presentation

Clark talked of how Steve Jobs’ 2007 announcement of apps for iPhone inspired him to use his webdev skills to make iOS web-apps.

you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services … And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today.

Unfortunately, Safari’s bugs made development much more expensive by breaking Indexed DB; breaking scrolling etc. Also, Apple refuses to support Web Bluetooth, so his customers had to purchase expensive iOS-compatible printers for printing receipts, at 11 times the cost of Bluetooth printers. iOS apps can integrate with Bluetooth, however.

He can’t ask his customers to jettison their iPads and buy Android tablets. Neither can he ask them to use an alternative browser, because there isn’t any meaningful choice on iOS. Clark simply wants to be able to make “amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone”, as Jobs promised. He summed up:

All these business costs inevitably get passed onto consumers. Or worse applications simply never get built, due to the increased cost.

From the perspective of software developers there is no browser competition on iOS.

Apple has banned all the other browser engines and Safari’s bugs and missing features means that web-apps struggle to compete with the AppStore. If third party browsers were allowed, with full access to all the APIs that Apple gives Safari, this would provide Apple the incentive to keep pace with the other browsers and give consumers a means of voting with their feet by moving to a competing browser if they fail to do so.

This would then lead to a universal open app development and distribution platform which would substantially reduce development and maintenance costs for a wide range of business and consumer applications. The open web offers an alternative future where the control from corporate intermediaries along with their fees are replaced with consumer choice and the freedom to easily shift from one platform to another. Instead of having to write multiple separate applications for every device, it allows developers to build their application once and have it work on all consumer devices be it desktop, laptop, tablet or phone.

Write once, deploy everywhere, no gatekeepers, no fees. just as Steve Jobs originally promised.

Stuart’s presentation

Stuart examined whether Apple’s assertion that lack of real browser diversity is actually better for consumers’ privacy and security.

My presentation

Here’s my captioned video. Below is the marked-up transcript with links. Note: this submission is my personal opinion and does not represent the opinion of any of my past or present clients or employers.

Transcript and Links

Hi, I’m Bruce Lawson, and I’m here to talk about Progressive Web Apps and iOS. I’ve been mucking around on the web since about 2002, mostly as a consultant working on expanding people’s websites to be truly worldwide, so they’re performant and work with constrained devices and networks in emerging markets. I’m also involved with making websites that are accessible for people with disabilities. And I was on the committee with the British Standards Institution writing BS8878, the British standard for commissioning accessible websites that last year got a rolled into the ISO. And before that, I was deputy for the chief technical officer at Opera software that makes a popular web browser used by about 250 million people worldwide, predominantly in emerging markets.

Most of my customers are in the UK, USA, or Israel, and they’re largely focused on UK and US markets. In the month of June this year, stats counter showed that 30% of all US web traffic was on iOS, 28% windows, 22% Android. And to drill that into just mobile browsers, 57% were iOS and 42% were Android.

In the UK, 30% of people use Windows to browse the web, 27% iOS, 25% Android. And that jells pretty well with stats from the GDS, the government digital services. Their head of front-end, Matt Hobbs, every month tweets some stats. He said that in June, iOS accounted for 44% of traffic, Android 28%. (Although he does note that because you have to opt in to be tracked, it tends to over-represent the mobile browsers). But we can see that in the UK, 50% of traffic is on iOS and 49% is Android.

So, we obviously have to be concerned with iOS as well as Android, Windows, et cetera, and all the different browsers that are available on every non-iOS operating system. And so, I always recommend to my customers that they use the web. After all, that’s what it’s for.

The principle of universality allows the web to work no matter what hardware, software, network connection or language you use, and to handle information of all types and qualities. This principle guides Web technology design

And that was said by Sir Tim Berners-Lee, and his parents were both from Birmingham, as am I. So he’s practically a relative. And with my work in web standards, those principles still hold true for the web standards we make today. So, I wanted to use the web and I wanted to use what’s called a Progressive Web App, which is basically a website plus. It’s a website and it’s web pages, each of which has a URL. It’s built with web technology, but in modern browsers, conforming browsers, it can look and feel more app-like.

In fact, the UK government itself recommends these. Our government writes,

advances in browser technology have made it possible to do things on the mobile web that you could previously only do with native apps. Services that take advantage of these modern browser enhancements are often called mobile web apps or Progressive Web Apps. The user experience of PWAs and a handset is almost identical to a native app, but unlike native apps, PWAs have a single code base that works on the web, like any normal website. A benefit of PWAs over native apps for the government is that there is no need to maintain lots of different operating system versions of the same app. This makes them relatively inexpensive to develop compared to native apps.

And just like government, business likes to reduce costs, and therefore can reduce costs to the end user. Our government goes on to say,

users can choose to install PWAs on any device that supports technology. If a user chooses to install a PWA, they typically take up less space than the equivalent native app.

And this is very important in emerging markets where lower priced phones have lower specifications and less storage space. The government continues,

PWAs cost less than native apps since they need to be only developed once for different platforms. They are also forward compatible with future upgrades to operating systems

And then it lists browsers that do support PWAs, and it lists Apple, Safari and iOS, but this is only partially true. Apple themselves make this claim in their February 2021 submission to the Australian investigation into monopolies. Apple said of PWAs,

Web browsers are used not only as a distribution portal, but also as platforms themselves, hosting progressive web applications that eliminate the need to download a developer’s app through the app store or other means at all

Therefore, Apple is suggesting that PWAs are a viable alternative to the app store. Apple continues,

PWAs are increasingly available for and through mobile based browsers and devices, including on iOs [my emphasis]. PWAs are apps that are built using common web technology like HTML 5, but have the look feel and functionality of a native app

But, as we will see this, isn’t true. PWAs do not have the same functionality as a native app.

Let’s recap about what a PWA actually is. It’s a bit of an umbrella term, but fundamentally it’s a website, but it can install to the home screen of your mobile device, just like a native app. And it can have its own icon defined by the web developer, launch full screen, portrait or landscape, depending up on what the developer chooses, but it lives on the web.

And this is a really important. It’s important for several reasons. Firstly, because it lives on the web, you’re not downloading everything in one go. A native app is like downloading a whole website all at once. A PWA, you download just the shell, and as you navigate around it, it will get any content it doesn’t already have stored from the web server. Another advantage is that means that you have instant publication. The moment you press the button and it goes on your web server, the next person who opens your app on their device will see the new version. Great for security updates and also great for time-sensitive material.

Another great thing is, of course, is that because there’s no app store, no gatekeeper. Smaller shops don’t have to pay the 15 to 30% tax to Google and Apple. And also, for industries that are not compatible with the app stores, such as adult entertainment, gambling, et cetera, it’s a mechanism of giving an app because they can’t use the app store. And PWAs can work offline.

Let’s briefly look at one. I’m here speaking in a personal capacity. I don’t represent any of my clients or employers, so I can’t show you one of their apps, but I took 15 minutes to convert my WordPress blog into a PWA.

Okay, here, I’m using Firefox on Android. Android, unlike iOS, allows not only different badged browsers, but it actually allows that full browser on, so Firefox on Android is using Firefox’s own Gecko engine. Here, Firefox and Android are collaborating and they can tell when a user goes to my website that it is a PWA, and it offers the opportunity to the visitor to add it to the home screen. You can see it says “you can easily add this website to your device’s home screen to have instant access and browse faster with an app-like experience”. As a developer, I didn’t make this and the user doesn’t have to know anything because the operating system and the browser just show this. If the user chooses, they can add to home screen, they can click on the icon, and it will add automatically or else they can drag it themselves to where they want it.

And here, as you can see, it’s now on my Android home screen. There’s a little Firefox icon at the bottom of my logo to tell the user it’s a PWA. Chrome doesn’t do this, but it does also detect that it’s a PWA and offer to add it to the home screen. And as you can see from the screenshot on the right, when they tickle that icon into life, up pops my website full screen, without an address bar, looking like a native app. If however, a user goes to my website in a browser that doesn’t support PWAs, such as UC Web here, they don’t get offered the add to homescreen thing, they just see my website and navigate it as normal. So people with capable browsers get an app like experience, everybody else just gets the website and nobody loses out.

On iOS it’s subtly, but importantly, different.

So on iOS, if you go to my website, you’re not told anything about this being installable. You have to know to click that icon in the bottom bar that I’ve circled in red. And once you’ve done that, then you get the screen on the right. And you just have to know as a user to scroll down, whereupon you’ll see add to home screen there with no instructions or explanation of what’s going to happen. Anyway, once you click that, then you confirm, and finally it’s on the homescreen. And when you press it, it launches full screen without an address bar. But it still, even though it’s much harder to discover this, it still can’t do everything that a native app could do.

This is Echo Pharmacy. It’s a service that I’ve been using during the pandemic. It’s nothing to do with my employers or clients. I’m just a customer. I use it to get my repeat prescriptions, and I used it and it worked really well. And on the confirmation screen, after I’d ordered some more medication, it said, “Hey, why not use our app?” And I thought, well, why would I need an app, because this website has worked perfectly well for me. So I asked on Twitter, I said, “Why does it need me to download the app?” The website allows me to place and track my meds, why clog up my device, because it’s a download, right? Is it for push notifications, because on iOS websites and PWAs cannot send push notifications. And for a pharmacy like this, it’s important for them to say, “It’s 8:00 PM, have you taken this tablet?” Or, “We notice in four days time, you’re going to run out of this medication. Please come back and order.”

And I got a reply from the CTO of Echo Pharmacy saying,

Hey Bruce, you’re right about push notifications, which for some people are preferable to email or SMS reminders. Beyond that our app and website have feature parity,so it’s really just about what you prefer.

In other words, these people at Echo Pharmacy, not only have they got a really great website, but they also have to build an app for iOS just because they want to send push notifications. And, perhaps ironically, given Apple’s insistence that they do all of this for security and privacy, is that if I did choose to install this app, I would also be giving it permission to access my health and fitness data, my contact info, my identifiers sensitive info, financial info, user content, user data and diagnostics. Whereas, if I had push notifications and I were using a PWA, I’d be leaking none of this data.

So, we can see that despite Apple’s claims, I cannot recommend a PWA as being an equal experience an iOS simply here because of push notifications. But it’s not just hurting current business, it’s also holding back future business. A lot of my clients are looking to expand into new markets. The UN has said by the end of this century, 50% of the population of the world will live in these 10 countries. And as you can see, only one of them is a traditional market for a UK business, the US. And it’s obvious why people want to do this. Whereas, the population of the “west”is not increasing, it’s increasing a lot in new markets.

“The Southeast Asian internet economy is expected to reach $200 billion by 2025“, for example, but all countries are not equal in the technological stakes. Here, for example, is the percentage of monthly income that it takes to buy one gigabyte of mobile data. In the UK, for a gigabyte, (not actually that much [data]), it costs me 0.16% of my monthly income. In India, it’s a little bit more at 0.05%. In the states, 0.1%. In Rwanda, where one of my customers is doing great business, it’s 0.5% of monthly income. In Yemen, where I was born, it’s very nearly 16% of monthly income. So, big downloads cost a lot of money, particularly for something like a medication tracking system, which I might use only once every quarter. It’s a heck of a lot to download at these prices.

VisualCapitalist.com say worldwide, the highest average costs for one gigabyte of data is 30,000% more than the cheapest average price. And it’s not just about data costs either. It’s about data speed. Here, for example, in the UK, the average or the median UK speed is 28.51 megabits per second, in the States, it’s 55. In Hong Kong, it’s 112. In Rwanda, it’s 0.81. In Cambodia, it’s 1.29. In India, it’s 4. In Indonesia, it’s 1.88.

So, a big download not only costs potential customers more, but it takes a lot longer. Facebook recognized this when they released their Facebook Lite app. Facebook said

downloading a typical app with 20 megabyte APK can take more than 30 minutes on a 2G network, and the download is likely to fail before completion due to the flaky nature of the network

Twitter released something called Twitter Lite, which is now just everybody’s Twitter. The Lite’s a PWA, and Twitter said

Twitter Lite is network resilient. To reach every person on the planet, we need to reach people on slow and unreliable networks. Twitter Lite is interactive in under five seconds over 3G on most devices. Most of the world is using 2G or 3G networks. A fast initial experience is essential

So, if we could offer PWAs, we would have a competitive advantage over other people, have much faster installation and a much cheaper installation. Penny McLachlan, who works as a product manager at Google said,

A typical Android app size [a native app, in other words], is about 11 megabytes. Web APKs, TWAs, [this is technical speak for a Progressive Web App], are usually in the range of seven to 900 kilobytes

So, only about 10% of the size of an Android app. So, we can see that PWAs is a competitive advantage for people trying to do business in the wider world, because at post-Brexit, global Britain, et cetera.

It’s no coincidence that the majority of the early PWAs that we saw coming out in 2016, 2017 came out of Asia and Africa, and that’s because when people who make websites and web apps use the same devices and the same networks as their consumers, they absolutely understand why PWAs are great.

But, we can’t make a PWA because we have to care about Safari, which is more than 50% of our traffic in our home market. So, what can I advise my clients to do? Well, a lot of them have settled on something called React Native. They can’t afford to have one developer team for Android, one developer team for iOS, and one developer team for web.

If you’re a massive organization such as Google or Amazon, of course you can afford that, but developers ain’t cheap. And three teams is prohibitively expensive for a smaller organization. React Native, which is open source (but stewarded by Facebook), promises that you write once and it works across platforms, where you’re writing in a language called React, and it compiles down to native applications. So you write in React, you press a button, and it squirts out a native Android app and a native iOS app. And it’s pretty good, I guess.

There’s pros and cons, of course. The pros we write just once. Great. The cons. Well, it still emits a native app, so we still have to submit to app stores, and the timing of that is at the whim of the whoever’s moderating the app store, et cetera. It’s still a big download because it’s a native app.

It’s a more complex built process. There’s not a great deal of build to the web. React Native requires lots of moving parts, internally. It’s harder for us to test the functionality because although we write it once, we have to test it on iOS and we had to test it on Android, and Android testing isn’t as simple as iOS because there’s a massive difference between a top-of-the-range Google Pixel device, or the expensive Samsung devices and the kind of no name cheap Android devices you can get in street markets in Bangkok and Jakarta and Mumbai.

And a problem for me, and for one of my clients, is accessibility. Accessibility is making sure that your app or your site can be used by people with disabilities. Apple and Google have done great jobs making iOS and Android accessible, but React Native has some quirks under the hood, which make it much trickier.

One of the reasons for this is that React Native is quite a new technology and the web is a mature technology, and accessibility on the web is pretty much a solved problem. It isn’t solved if developers don’t do the right thing, but Chrome is 98.5% compliant with the W3C guidelines for accessibility. Microsoft Edge is a 100%. Firefox is 94%. Safari is 97%.

But because we’re writing in React and it’s doing magic tricks under the hood, there are holes in its accessibility. Facebook themselves say,

we found that React Native APIs provide strong support for accessibility. However, we also found many core components do not yet fully utilize platform accessibility APIs. Support is missing for some platform specific features.

They say it’s true, that support is missing. But for example, if you have an external keyboard plugged into an Android device, perhaps because you have Parkinson’s, or (like me) you have multiple sclerosis and you prefer to use a keyboard than the tiny little software keyboards. But if you have an external keyboard, you cannot use that keyboard to focus in to enter any information in any input field that’s made with React Native [on Android]. This of, course, is a huge problem.

Facebook has done some effort into writing up all of their accessibility problems. Here, for example, we can see this is a GitHub board with all the issues and I scroll, scroll, scroll, scroll, scroll through them. There is apparently a fix for the inability to focus into any input fields with Android and a keyboard, but we are at the mercy of Facebook’s release schedules here.

So, what could I advise my clients to do? I tend to advise them, go PWA and let’s hope that the CMA make Apple do the right thing. What I would really like to do is say to them, “Okay, just put this notice on your web app. Say: ‘we’d like to send you push notifications, if that’s okay by you. Please download Microsoft Edge, Mozilla Firefox, or Google Chrome on iOS’.”

However, if they do download Edge for iOS, Firefox for iOS, or Chrome for iOS, that’s no help at all because Apple prohibits those browsers using their own more capable engines and they have to use the Safari engine under the hood. So, consumers get no choice at all.

Should you use HTML5 header and footer?

Matt Wilcox asked “I still don’t bother with <header> <footer> etc. I assume all widely used browsers support them now. But, do they do anything more than div?”.

It’s a good question. The answer I gave is “yes”. These two elements (and <nav> and <main>) give value to users of some assistive technologies on some browsers.

In the HTML5 spec, HTML elements are mapped to ARIA information. Some of those may be over-ridden by authors, but if they aren’t, they have default implicit ARIA semantics. A <header> element that is not a descendant of an article or section element maps to ARIA role=banner, for example. You don’t need to add any ARIA information; it’s included, free, in the HTML element.

These aren’t necessarily implemented everywhere; Steve Faulkner’s excellent html5accessibility.com keeps tabs of implementation. As an example, <footer> causes Chrome to expose the element with a footer role in IA2, and Firefox to exposes as ARIA landmark role=”contentinfo” (when not a child of article or section elements).

These are useful to people, as we can see in WebAIM’s 5th annual screenreader users’s survey (which encouragingly tells us “For the first time in 5 years of surveys, respondents are more positive about web accessibility progress than in the previous survey”).

When asked “How often do you navigate by landmarks/regions in your screen reader?” (such as “contentinfo”, “banner”, “main”, “navigation”), 26% said “whenever they are present”.

20% thought 1-3 landmarks/regions per page is optimal; 29% thought 4-6 is the right number.

So my advice is: yes, use them – especially the main <header>, <footer>, <nav> and (once per page) <main>. On browsers/ ATs that don’t support them they do no harm. But don’t use billions.

TL;DR

Added 13 May to clear up confusion:

  • Use <header>, <footer> as often as your content requires – only the main header and footer carry implicit banner and contentinfo roles. At a minimum, use them once (assuming you have a page header and footer, that is).
  • Always use <nav> for the primary navigation.
  • Use <main>, but only once per page.
Added 3 September 2015: The 6th Screenreader Survey tells us that 63% of screenreader users sometimes/ often/ always use landmarks/ regions. So definitely use them. Kiss.

Future friendly, or Forward to Yesterday?

chinese propagada poster, with 'Happy Productive Web Developers! Stamp out bourgeoise competition! Let us  march  together on the Single Path to a Glorious Yesterday!' added

Last week saw some interesting blogposts that neatly summarise the opposing world views that we’re seeing at the moment regarding the “problem” of the Web.

Alex Russell (of Google Chrome) wrote a considered blog post called Things the W3C Should Stop Doing in which he suggested

the W3C needs to find a ways to re-focus on the needs of the constituencies that give it credibility; namely web developers and browser vendors.

…it should be agreed that the W3C will divest itself of any and all Semantic Web, RDF, XML, Web Services, and Java related activities.

…What would that leave us with? CSS, DOM & JS APIs, HTML, a11y, i18n, and all the other stuff that has legs out on the public web.

…The time has come for the W3C to grab the mantle of the web, shake off its self-doubt, and move to a place where doing good isn’t measured by numbers of specs and activities, but by impact for web developers.

I found myself nodding frequently while reading it. I wrote two years ago about my belief that XML makes no sense on the Web. And there are no shortage of vital specifications to work on – just look at David Storey’s list The Open Web 1 stack: the HTML5 application age (even after removing EcmaScript and WebGL which arent’t W3C).

I fervently hope that the W3C continues to be the place where new Standards get hammered out. I worry that, because it dropped the ball so calamitously with XHTML 2 and left the WHATWG to begin work on HTML5, there is a feeling that other specs should be developed outside the W3C. We see this with Widget specifications, where organisations haven’t liked the W3C work but instead of participating in that group, they’ve developed their own variants in isolation.

Developer Joe Hewitt has nothing but scorn for the W3C or any standards body:

To thrive, HTML and company need what those other platforms have: a single source repository and a good owner to drive it. A standards body is not suited to perform this role. Browser vendors are innovating in some areas, but they are stalled by the standards process.

He similarly scorns diversity of user agents, wishing for a monoculture:

It would help if all the rendering engines but one were to die, but even that would not be enough. Even if WebKit was the only game in town, it would still be crucial for it to have competent, sympathetic, benevolent leaders. The closest thing we have to that today is Chromium…

Obviously, I’m hardly likely to agree with this (I work for Opera, but this post is personal opinion yada yada). I’ve written before about how the IE6 monoculture grew because people believed it was the finest browser (In praise of Internet Explorer 6) and you can read about the cost of a browser monoculture in Korea.

I’m with Uncle Timbo who dreamed of the Web as universal: independent of hardware platform, software platform (operating system), Application Software, Network access, Language and culture or disability. These are features not bugs. This universality is the strength of the Web, not a problem to be solved by a Strong Benevolent Leader and single user agent.

Web veteran John Allsopp writes

The web is a different problem. It makes little if any sense to compare innovation of the web ecosystem with that of iOS, Android or other platforms. The web faces challenges far far greater (and has goals far more important). A platform such as iOS can abandon legacy applications, content and hardware, (along with their users) with little compunction. It can (and does) make developers and content creators wishing to participate jump through any number of hoops. It has a single dictatorial decision maker, beholden to no one, and nothing other than itself. And it generates extraordinary revenues, which can be reinvested into the ongoing development of the platform.

The web is different. It values interoperablity, backwards compatibility. It’s goal is to bring access to the same information to billions across the world, on all manner of devices. Its custodians are, in my opinion, scandalously under-​​resourced, given just how much wealth the web has created for so many, perhaps above all Google and Apple.

Robert Nyman (of Mozilla) agrees:

The web is the true form of democracy: people from any part of the world – with any background, gender, social status or skin color – can take part in and build the future. Some things can take longer to reach consensus about than in a closed company-controlled environment, but I would have open and democratic standards every day over that.

Not all developers agree with Hewitt. This month’s poster child for responsive/ adaptive/ HTML5 design is the redesign of The Boston Globe newspaper. It has rich markup. It looks great across different devices and screensizes. It looks great on devices that can’t deal with much JavaScript such as Opera Mini.

In an interview I did (for .net magazine, unpublished) Scott Jehl (of the Filament Group who worked on Boston Globe) said

I find Opera Mini tends to be pretty easy to support if you build with Progressive Enhancement – it’s a great browser with lots of performance optimizations included, and of course it’s incredibly popular around the world so supporting it is a no-brainer. Our experience [at Filament] leading the jQuery Mobile project led some familiarity to a lot of platforms that aren’t commonly tested, but are quite popular throughout the world.

The baseline browser we were regularly testing was BlackBerry 4.6, which receives a basic, JS-free experience like most other non-media-query-supporting browsers. Somebody sent us a screenshot of the Globe site running on a Newton recently!

It’s not the case that to make sophisticated websites you need to abandon universality, creativity, and progressive enhancement.

Scott is one of those behind a manifesto site called Future Friendly that argues:

We want to make things that are future friendly. By anticipating what’s next, we can react to today’s concerns but also build long-term value for people and businesses…To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services…An ecosystem of devices demands to be interoperable, and robust data exchange is the easiest way to get going.

Once you remove the fluffiness from the manifesto, it boils down to a useful reminder to design with progressive enhancement; to use structured, semantic markup; to test across software and hardware platforms and to understand that things won’t look the same everywhere.

Future friendly or Forward to Yesterday? I know which I choose.

Government guidelines, ARIA, microformats

Not so much a blog post but a collection of links.

UK government browser guidelines: good sense prevails

The Web Standards community changed some guidelines for government webmasters that would encourage designing to browsers into something that requires valid code, web standards and progressive enhancement. UK government browser guidelines: good sense prevails.

Talking of guidelines, I’m doing a short talk on Wednesday about BS 8878: Web accessibility – Building accessible experiences for disabled people at the Oxford Geek Night. See you there?

How Can I Validate (X)HTML + ARIA?

A while ago I speculated that the lack of a validator for ARIA might slow adoption. Steve Faulkner has written a proof-of-concept HTML4+ARIA Checker and hopes, as I do, that “the W3C validator adds support for (X)HTML +ARIA documents so I when check a document and it contains no errors in the HTML (except for the use of ARIA) and ARIA code, I see a message like this: this document was successfully checked. Passed (1 Warning)”

Should you think that ARIA is just w3c vapourware, there’s a podcast on ARIA by Freedom Scientific (the manufacturers of the JAWS screenreader) available:

Freedom Scientific’s Chief Technical Officer Glen Gordon explains ARIA and its benefits. Jonathan Mosen then demonstrates some applications with ARIA enabled for improved accessibility.

Didn’t see a transcript anywhere, surprise surprise.

More bandaids for microformats

Pat “Herb” Lauke wonders “if we should have an official anniversary each year where the same microformat/accessibility issue is rehashed” and links to an experiment by Andy Clarke. It’s a nice idea, but I think it’s a bandaid. I agree with Isofarro’s diagnosis:

It boils down to this: the title attribute is meant for human consumable content, just the same as the inner text of most of the HTML elements.

Everytime you put machine-formatted data into a container that is for human consumption, then you run the risk of it being exposed to a human being. In microformats this a ‘feature’, in accessibility this a ‘bug’.

I think that’s throwing the baby out with the bathwater to say “the easiest approach right now is to say Microformats are inaccessible, and move along”; it’s just this pattern that’s inaccessible.

Patrick suggests, “why not make a ‘title attribute’ pattern that allows for the use of the most semantically appropriate element? span with title in cases like datetime, abbr when it is actually an abbreviation.”

That makes sense to me. How would those plugins that make use of microformats cope if I marked up hCalendar dates with a span. Anyone know?

IE 6 mobile standards compliance tests

So, I was challenged on my assertion that the new Internet Explorer for mobile that is going to be unleashed in China next year is based on the web developer’s mortal enemy and the virus-writer’s best friend, IE 6 for desktop.

I was wrong, people said: IE 6 mobile isn’t IE 6 desktop back from the dead and dripping goo and pus like a George Romero zombie; it’s an accident, a coincidence of the numbering system. Microsoft are good guys now, they said, committed to web standards.

After all, look at the claims for it:

Internet Explorer Mobile 6 [is] a full-featured browser for Windows Mobile devices that brings the same high-quality browsing experience to the user as desktop browsers. Internet Explorer Mobile 6 supports desktop-quality rendering and has the best compliance support of all versions of Internet Explorer on a Windows Mobile device to date.

So I downloaded the emulator and ran a few tests.

Conditional comments and * html

Firstly, I tested a simple page to see if it picked up Conditional Comments targetted at IE 6, and whether it picked up CSS rules aimed at the valid, but nonsensical * html elements.

The test page is

p {color:red}
* html p {color:blue;}
<!--[if lte IE 6]>
<h1>Conditional comments think I'm IE6!</h1>
<![endif]-->
<p>Red for non-IE6, blue for IE 6</p>

So, IE 6 (or below) will show a heading, and a paragraph in blue. A modern browser will have no heading and the text will be red. The screenshot shows that IE 6 mobile believes it to be the same as IE 6 desktop on both counts.

screenshot showing heading and blue text

IE 6 mobile and the Acid tests

29% of all internet users in China only ever use a mobile phone to acess the Web. But Microsoft’s “new” mobile browser doesn’t quite have the standards-compliance that Chinese people deserve.

The Acid 2 test:

a very bad attempt at rendering acid 2

and the Acid 3 test:

a very bad attempt at rendering acid 2

IE 6 mobile and CSS support

A big problem for web developers was IE 6 lamentable support for CSS, so I ran the CSS selectors test. The results say “from the 43 selectors, 10 have passed. 1 are buggy and 32 are unsupported”.

selectors test result

Even IE 7 passes 13 of the 43 selectors (“4 are buggy and 26 are unsupported”).

So what IS IE 6 mobile?

Well, it appears that the heart of it is chucklesome old IE 6 desktop, with a few extra bits grafted on from IE 7 and IE 8’s JavaScript engine. So it’s cross between a zombie and a Frankenbrowser.

To verify, I opened up the back of my mobile and hiding behind the battery, clinging onto the SIM, I found the true face of IE 6 mobile, its lips mouthing “Ni hao” in anticipation of its imminent Beijing exhumation.

zombie

Joking aside, this is a terrible situation. 20% of the world’s population are being offered an ancient, discredited browser. Who knows whether we’ll imminently see China’s phones paralysed by viruses—after all, the U.S. government’s Computer Emergency Readiness Team advised

there are a number of significant vulnerabilities in technologies relating to the IE domain. It is possible to reduce exposure to these vulnerabilities by using a different web browser.

We need web standards. And China deserves them, too.

Public consultation on browser standards for public sector Web sites: Opera’s response

Introduction

This is Opera Software’s response to the Public consultation on browser standards for public sector Web sites by Central Office of Information (COI).

Opera Software ASA is a company headquartered in Norway. Noway is a signatory to the European Economic Area Agreement, which guarantees free trade with all EU states and cooperation in such matters as consumer protection, culture, education, and information services (see http://www.eu-norway.org/about/eeaforside.htm).

Many of our users are within the United Kingdom and the European Union, and we feel that the draft guidelines (“the guidelines”) potentially disadvantage them.

We support the aim of the COI to ensure inclusion by testing public authority Web sites on a range of browsers. It is also laudable that the COI requires that Web sites be made accessible to people with disabilities and across multiple operating systems.

However, we feel that there are some aspects of the browser guidelines that need re-drafting. We request that our concerns be considered and give permission for them to be quoted with attribution in any report on this consultation.

Executive summary

Opera believes that the current guidelines attempt to reinvent a wheel that has already been satisfactorily invented and refined over time by other large organizations, both public and private. Reusing their work reduces costs to taxpayers.

Also, Opera believes that the guidelines in their current form

Recommendations

The guidelines should recommend using Web standards and a best-practice development methodology called “progressive enhancement”. This will help ensure compatibility across browsers, rather than aiming at different browsers as if they are completely separate targets.

For testing, the guidelines should recommend adoption of browser support matrices such as the one provided at http://www.bbc.co.uk/guidelines/futuremedia/technical/browser_support.shtml/ by the BBC, which is a well-respected Web brand with a public-service duty and a huge, diverse audience.

This would support

  • greater competition in the browser market

  • greater value for money for taxpayers

  • more consistency for Web visitors and developers, and

  • savings on Web development costs by promoting Web standards and proven methodologies.

These benefits are also noted in the BBC’s Objectives of Web browser support, which gives the methodology by which their browser-support matrix was devised at Appendix 2.

Guidelines restrict choice

Guidelines confuse popularity with capability

Paragraph 15 says “There may be specific browsers that you choose not to fully support because they are either old or unpopular.”

It is legitimate to choose not to support old browsers fully that are not capable of rendering sites made with Web standards and progressive enhancement.

However, it is wrong to decide not to support a browser purely because it is “unpopular”. If it is capable of rendering the site, it should be supported.

The guidelines’ introduction states, "It is important to declare which browsers your website has been tested on. This demonstrates a clear commitment to your audience. Users will want to know whether or not your website works with their browser."

We disagree. By naming the browsers on which a Web site has been tested (simply because they are more “popular”), the impression is given that browsers that were not mentioned are somehow “second class”, and its users are not worthy of attention, which demonstrates a clear lack of commitment to audience needs.

We recommend adopting a testing statement such as that used by the Solicitors Regulation Authority:

Browser compatibility

It doesn’t matter how old your browser is—you can use this website. It looks different in some older browsers, and is mostly text in very old browsers (like Netscape 4, or Internet Explorer for Macintosh). But the information is the same, and so are the things you can do.

Guidelines inconvenience users

This erroneous impression of less “popular” browsers as being inferior is reinforced in the sample “browser support statement” in paragraph 12.

Webmasters are advised to list browsers they have tested in as “supported”. The example browser support policy statement includes the message "We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above".

There are also many reasons why a user may not be able to change their browser easily – for example, they

  • may not be using their own computer and be on a shared computer; therefore, they are unable to change or update the browser,

  • may use a particular browser because of security or privacy settings,

  • may use a particular browser due to features that help them access and are unable to use another browser comfortably,

  • may not know how to change their browser.

Many users of the most “popular browser” made no conscious choice to use that browser. On the other hand, we know that many Opera users choose Opera because of features such as excellent keyboard support, the built-in voice browser, intelligent zoom, and fit-to-width display, which are very useful for people with disabilities. It is unreasonable and unfair to suggest that they upgrade because a Webmaster has elected not to test in Opera.

Potentially anti-competitive

Not only does this inconvenience the user, but we strongly believe that this is anti-competitive.

The guideines help perpetuate current market shares by encouraging users of “unsupported” (in reality, “untested”) browsers to replace their current browser with another.

(Disclosure: The EU Commission are opening an investigation into an anti-trust complaint filed by Opera on 12 December 2007, regarding Microsoft bundling Internet Explorer in the Operating System and not implementing Web standards.)

Guidelines do not promote best practices

The guidelines are published because it is “impractical and inefficient” to test in all browsers. Presumably this should be interpreted as the COI suggesting that it is not cost-effective to do so. However, it is unnecessary to do so if best-practice Web development is followed.

Best practices should be central to guidelines

The section “out of scope” notes, “How to code for browser compatibility [and] Development methodologies such as graceful degradation and progressive enhancement,” are out of scope.

Additionally, paragraph 40 notes “These guidelines do not advocate specific development methodologies, for example, graceful degradation or progressive enhancement. However, it is widely accepted that sites conforming to open Web standards such as XHTML and CSS are more likely to work well across a wide range of browsers. The importance of working to technical standards is highlighted in Minimum technical standards”.

Opera believes that the guidelines must recommend the development methodology known as “progressive enhancement” which, when based on Web standards, would reduce inconsistencies between browsers resulting in greater interoperability.

When this methodology is employed, users of the most capable browsers automatically receive the highest quality user experience, while users of less capable browsers will receive content and be able to access basic functionality. Therefore, no-one will be “locked out", whereas being "locked out" is much more likely if you choose consciously to test only in/support specific browsers.

Guidelines erroneously treat Web as a visual medium

The guidelines treat the Web as if it were a visual medium such as print, in which designers specify pixel-perfect layout and can rely on that being delivered to the consumer.

This is not true and is inappropriate for public-service websites, where the emphasis is on content rather than aesthetics.

Paragraph 41 says, “A browser is semi-supported if the content and navigation works but the website does not display as intended”.

It is incorrect to judge a Web site on whether it displays “as intended”. A Webmaster cannot mark a browser “down” as semi-supported because it does not have curved borders, opacity, or the same fonts as those on a designer’s machine.

By emphasizing “intention”, the guidelines legitimize preservation of design as a goal. In the past, this has led many bad design decisions such as fonts being expressed in pixel sizes which cannot be resized in Internet Explorer, for example.

The Web site should be judged on whether the recipient can use it in a format that (s)he wishes. If, for example, a browser mis-renders a site built with Web standards, such that content is obscured or is illegible, then that browser is unsupported.

If a browser renders the content as legible, the navigation usable and functionality operable, then that browser is fully supported in the context of a public-service site.

Best practices lead to cost-savings

Recommending best practices whereby developers code to internationally-agreed standards rather than to circumvent the quirks of today’s market leaders leads to cost savings throughout the life-cycle of a Web site:

  • It is more cost-effective to build right than to correct during testing, so explicitly advocating progressive enhancement results in more efficient development and Web sites being quicker to market.

  • Reducing inconsistencies through smarter development ensures that the “testing” phase is shorter and, in the case of static pages of content, it should be possible to reduce testing to a quicker “verification” stage that quickly checks across a range of browsers that there are no significant inconsistencies.

  • Once deployed, Web sites built using valid, semantic (X)HTML and CSS are more maintainable because they are in accordance with international standards.

Guidelines are too fragmented

The guidelines mention design methodology and minimum technical standards in paragraph 40, but it is a leap of faith to assume that everyone else will read the second document.

The guidelines are written “for all website managers, web developers and web testers delivering public sector websites”, so we recommend that all the guidance relevant to these groups be amalgamated —or developers will naturally assume this supersedes all other guidance and start developing to browsers.

Additionally, the “Minimum Technical Standards” document is dated May 2002 and is obsolete; it mentions CSS 2 as the latest version, allows HTML tables for layout, and does not mention Scalable Vector Graphics (SVG).

Opera recommends modernizing this document and incorporating the updated guidelines into a comprehensive document aimed at the target audiences named on the cover.

Guidelines do not address mobile and other devices

Paragraph 39 notes that Guidance on support for mobile platforms will be the subject of future guidance. Other devices are described are similarly “out of scope”. (Paragraph 37 also notes, “Guidance on support for mobile platforms will be the subject of future guidance”; we assume this is an editorial error.)

This further fragments the guidelines, as readers will have another set of guidelines to check.

Different guidelines are unnecessary. Recommending a progressive enhancement methodology ensures that Web pages work across all browsers and devices.

Guidelines ignore plug-ins which are independent of browsers

The guidelines ignore the subject of browser plug-ins, such as those that allow readers to access PDF, MP3, video, and Flash content. These plug into a browser but are independent of it. Therefore, a group of users running the same version of a browser may have different versions of plug-ins and receive markedly different experiences.

For example, a visitor running Opera 9.5 with Flash Player 6 would not be able to take advantage of any accessibility features built into a Flash movie, while a visitor running Opera 8 with Flash Player 7 would be able to use those accessibility features, because the plug-in has a higher specification, even though the browser is less capable.

The guidelines should address plug-ins, independently from browsers.

Opera also suggests that the guidelines for Web developers require the use of open standards wherever possible, while allowing content that requires plug-ins as a secondary delivery method.

Guidelines should recommend testing by disabled users

Opera welcomes the guidelines’ inclusion of a requirement that Web sites be tested with assistive technologies.

However, the guidelines currently legitimize a sighted developer using a trial version of a screenreader and comparing the synthesized speech with the words on a screen, which is inadequate testing; a sighted user cannot have the same experience or knowledge of the tool as a real user.

Therefore, we believe that it should incorporate guidance from the British Standards Institution’s Publicly Available Specification (PAS) 78, Guide to good practice in commissioning accessible websites:

  • “All organizations, regardless of size, should ensure that those testing the website are different from those developing it.”

  • “Website commissioners should conduct user testing with disabled participants to ensure that their websites are accessible and usable by disabled people”

  • User testing should include users from a range of disabilities and preferences, including a mix of beginners and experienced web users using a range of assistive technologies.

Inadequate definitions/ ambiguities

  • Paragraph 46 suggests testing “ability to bookmark” as part of testing a Web site. That is a browser feature, not a developer-authored feature and thus out-of-scope.

  • Why are Rich Internet Applications separated out? The requirement for sites to work with scripting turned off, etc., is not solely related to RIAs.

Too many trademarks used in examples

We would prefer it if more than one trademark were used as illustrative examples, or none at all, as currently the guidelines erroneously give the impression that only one browser exhibits the qualities being discussed.

For example, we would prefer it if paragraph 50 were redrafted to read, “Certain browsers (e.g., Firefox and Opera) are developed using cross-platform technology (e.g., Java) and, therefore, behave similarly on different operating systems,” or “Certain browsers are developed using cross-platform technology …”.

Contact details

These comments were written by Bruce Lawson, a Web Evangelist representing Opera Software ASA. Bruce may be contacted via brucel@opera.com for any clarification of these comments.


Comments on the Opera developers’ network, please; no login required.

Jottings, a hello, releases, apologies

A mixed bag of a post as I rush to get a plane to Amsterdam for the Fronteers conference that starts tomorrow (I’m speaking—come along!).

UK government draft browser guidance is daft browser guidance

I’ve written a piece for the Web Standards Project about a new government consulation on proposed guidelines on browser testing. Sounds yawnorama, I know, but please read it and respond to the government: if it goes unchallenged, it will reduce choice, inconvenience users of government websites and lock smaller browsers (like Opera, who I work for) out of the market. It looks like we struck a chord; Adam, who wrote the draft guidelines, says that they’ve had approximately 400 responses already. In three days!

Accessiblity in suit and tie

I’ve written a piece for thinkVitamin called Accessibilty in suit and tie about how to “sell” accessibility inside a corporate organisation, with crap technology and the like. It’s a more generic version of my long long article Standards-based corporate web development.

Hello Henny!

When I started at Opera, the top guys said to each other “Why do we only have one übergroovy kickboxing accessibility-lovin’ glamorous web evangelist? We need two! And make the other one a dame!”. Three months and an executive notice period later, in comes Henny Swann fresh from the RNIB and WaSP. (Note to Nate Koechley: Yes, Henny is a girl.)

What a great team of good-looking guys and gals I work with.

New Opera releases

Want to build your own browser in a device?

Then use the Opera 9.6 SDK to build an Opera browser in your TV, picture frame, tablet etc. This new version comes with the same compression used for Opera Mini on mobile phones, so it’s pretty jolly fast. (Developer documentation)

Opera 9.6 beta released

We’ve also released a beta version of Opera 9.6 desktop. This adds some privacy settings I like (so bookmarked URLs don’t appear in the autocomplete address bar, which can be embarrassing at presentations) and adds a low-bandwidth mode for the Opera mail client, plus some useful UI tweaks. Download it but please be aware it’s beta software, so please install it separately from your current 9.5 install

Multipack meeting on Saturday

For West Midlands web developers, and those who care for them, there’s the regular multipack meeting at The Old Joint Stock in Birmingham, to catch up with all the goss from Geek in the Park and dConstruct. Wish I could be there (but will be flying in from Amsterdam) as it’s always a pleasure and a warm welcome.

Tell the CSS WG what you want from CSS3

With all the tizzy about the CSS Working Group not listening to what designers really need, no-one noticed that in December, an invited expert to the group asked for such a steer from web professionals:

The CSSWG plans to discuss its charter at our next face-to-face meeting in March. If groups like CSS3.info, the CSS Eleven, and the WaSP and/or individuals like Jeffrey Zeldman and Eric Meyer could organize a collectively-written list of priorities and submit it to us before then, we could take that into account when writing our charter for 2008+.

So at the Web Standards Project we’re collecting such a list of priorities. Thinking caps on, if you please, and comments there.

DTI responds to questions about their accessibility.

Regular readers will know that Dan Champion and I have asked questions of the Department of Trade and Industry over spending a quarter of a million pounds of taxpayer’s money on a new website that failed to meet the accessibility standards required in their own spec.

The questions were asked twenty days ago under the Freedom of Information Act. On the last possible day the law allows for them to delay before responding, they have answered our questions.

Continue reading DTI responds to questions about their accessibility.

Fresh01’s redesign: more questions for the DTI

Dan Champion and I remain unhappy with the Department of Trade and Industry’s answers to why they spent a quarter of a million pounds on a Clarkian failed redesign.

Our unhappiness is due to their wasting public money on a site that does not meet the level of accessibility required in their own spec, and the fact that the DTI have said that “if further changes are to be made to the website the cost will be met by DTI”, so presumably, Fresh01 (the suppliers) will not be required to put their mistakes right at their own expense (if indeed, the DTI’s answers show that it’s the supplier’s fault).

We want to know why this shoddy procurement, development and supplier monitoring happened, and what will be done to prevent it reoccurring. Therefore, we’ve sent further questions to the DTI as a request under the Freedom of Information Act.

Continue reading Fresh01’s redesign: more questions for the DTI