Archive for the 'accessibility web standards' Category

Reading List 285

Farewell, 2021

Not much happened in 2021, for obvious reasons. One surprising event was that I took a permanent job for the first time since Opera went tits-up in 2016. I had been contracting for Babylon Health for 6 months, helping them on their mission to make “high-quality healthcare accessible and affordable for everyone on Earth” and I liked them (even more surprisingly, they liked me) so when they offered me fripperies like paid time off and sick leave during a pandemic, I said yes.

Conferences didn’t really happen. I came to dislike speaking at Zoomferences, but did manage to harangue people in person at Front Conference Zurich, which was brilliantly organised by volunteers. Hopefully I can shout at people in real-life after Spring 2022 (and stay tuned for an exciting announcement about this).

Instead of conferences, I put my rabble-rousing urges into ending the Apple browser Ban, twice invited to brief the UK Competition and Marketing Authority about their investigation into Apple’s iOS browser monopoly and Progressive Web Apps. The final report will come out in June.

In personal news, I gained a few kilos due to an even more sedentary pandemic lifestyle, and didn’t smoke all year. And I managed to sell an Evil demonic spirit, captured in a box. Genuine ghost. Do NOT open the box! on eBay.

However, by the end of the year, I was feeling burned out and depressed, so decided to spend Christmas in Thailand, where I have a little rural holiday home. I felt a bit irresponsible travelling during Covid (and had to pay through the nose –pun intended– on 4 PCR tests for each family member), but it was absolutely worth it. It was such a tonic to get some sun, speak another language, eat different food and just see different surroundings after 2 years of the pandemic.

On return, however, I’m not feeling optimistic for the winter. In Thailand, everyone –and I mean, everyone– wears a mask outside their home, even in 30+ centigrade heat. No whining about “muzzles” or “liberty”, just social responsibility and a sense of shared endeavour. Yesterday, after my Day 2 PCR test came back negative, I could go to the supermarket to restock after my holiday. I reckon 50% of shoppers wore masks. Today my son returns to college. Given multiple sclerosis is my own immune system attacking my nervous system, I’m fully expecting to get sick. Hopefully, my vaccinations and booster will save me from serious illness.

Let’s hope 2022 brings better times for all.

On the CMA’s interim report on mobile ecosystems

You might remember that I was part of a small group of 3 UK web developers invited to brief the UK Competition and Markets Authority (i.e., our monopoly regulator) about Apple’s iOS browser monopoly and Progressive Web Apps. Yesterday, the very large interim report was published.

The CMA tweeted

Apple and Google have developed a vice-like grip over how we use mobile phones and we're concerned that it's causing millions of people across the UK to lose out.

Our provisional findings suggest Apple and Google’s substantial market power across mobile operating systems, apps stores and browsers could be negatively affecting consumers. People aren’t seeing the full benefit of innovative new products and services such as cloud gaming and web apps. Our provisional findings also suggest customers could be facing higher prices than they would in a more competitive market. Apple and Google take many decisions on behalf of their users to protect their security and privacy online – in some cases this has an impact on a user’s ability to make their own choices.

The report is gargantuan, and I haven’t read it all yet. It also deals with App/Play Store approval processes, and advertising, but these are aspects of the industry that concern me less than Progressive Web Apps. On PWAs, it’s pretty damning. Here are some choice quotes; emphasis is CMA’s.

Page 226-7:

Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.

we have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition and users from Apple’s WebKit restriction is justified on security grounds

We further consider that the limitation on the feature support that browsers on iOS can offer is likely to be significant. This appears to be particularly the case with respect to supporting web apps.

In addition to potentially harming the functionality of competing browsers within Apple’s ecosystem, we consider that the WebKit restriction may also serve to support Apple’s highly profitable position in the distribution of native apps through its App Store, and in parallel the market power of its operating system… web apps could in principle also serve to undermine the indirect network effects of native app distribution

Page 378-9:

We concluded in Chapter 5 that a significant contributing factor to the market power of Apple and Google in relation to mobile browsers is the restrictions that they – and in particular Apple – are able to place on rival browsers. We have therefore identified a number of potential interventions aimed at removing these restrictions. These interventions are summarised below:

  • Apple does not permit the use of third-party browser engines within its mobile ecosystem – all browsers are required to use its browser engine, WebKit. We have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition or consumers from Apple’s WebKit restriction are justified on security grounds. We are therefore seeking to assess the merits of a requirement for Apple to allow alternative browser engines on iOS, at least for dedicated browser apps. This could be implemented by requiring Apple to permit third-party browser engines to interoperate with its iOS operating system, subject to those browser engines meeting conditions that would address any risks that might arise from a greater choice of browser engines (for example, complying with appropriate quality and security standards).
  • Restrictions on the functionality of all browsers on iOS: as a possible alternative to requiring Apple to allow alternative browser engines, Apple could be required to enable access to specific features for browsers using WebKit on iOS, including supporting web app functionality. This could bring benefits from web apps providing a stronger competitive constraint on the App Store and the Play Store, while also reducing barriers to entry in the supply of new operating systems. We agree that, without appropriate safeguards, there are potential security and privacy risks associated with greater third-party interoperability with the iOS ecosystem.612 We are initially of the view that the costs and security risks associated with requiring access to core functions on the phone, such as push notifications, screen rotation and full screen capability should not be disproportionate.
  • API access for rival browsers: we also have concerns regarding the differences in APIs that are available to Safari and Chrome by comparison with third-party browsers. This could be rectified by a requirement for Apple and Google to ensure that all browsers within a particular mobile ecosystem have access to directly comparable features and functionality through APIs. To the extent that some of the APIs and other functionality may be proprietary or increase costs for Apple and Google, such an intervention would also need to mandate the terms of such interoperability in a way that provides for access on fair and reasonable terms, potentially with guidance about how this would work in practice.

In its responses to our questions, Apple raised a number of concerns that introducing third-party browser engines, or increasing the interoperability of WebKit, could introduce privacy and security risks. Apple submitted that Webkit offers the best level of security, and has cautioned that ‘mandating use of third-party rendering engines on iOS would break the integrated privacy, security, and performance model of iOS devices’. Apple considers that by requiring apps to use WebKit, it is able to address security and privacy issues across all browsers on the iPhone for all iPhone users, quickly and effectively, and that ‘this is especially true when it comes to security vulnerabilities that have to be fixed as soon as possible in order to mitigate potential exploits by bad actors’.

7.73 However, as discussed in Chapter 5, the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines. Further, and as discussed in Chapter 5, other parties have suggested that the impact of a browser engine on overall device security can, to a certain extent be limited.

Digital Markets Unit

The CMA is going to set up a permanent regulatory body called the Digital Markets Unit (DMU). This will have broad powers to enforce a code of conduct and apply interventions on activities by firms that have been given Strategic Market Status (SMS) in relation to activities in the scope of the CMAs Market Study. The DMU is currently operating on a non-statutory basis but it is intended that the government will introduce legislation to put the regime on a statutory basis when legislative time permits.

It is expected that while the DMU can only apply these regulations in the UK that they will cooperate with other regulators and the impacts will be global. Manchester has been picked as the head office of the DMU and they expect to hire 200 full time employees.

Strategic Market Status

In order to be regulated by the DMU a firm must be designated Strategic Market Status (SMS) in at least one digital activity. The test for SMS has three components:

  • The activity must be at its core digital
  • The firm must have substantial and entrenched Market Power arising from this activity that is unlikely to be removed by competition in the short or medium term
  • Must have a strategic position meaning the use of this market power will be particularly widespread or significant

Both iOS and iOS Safari are recommended by the CMA as being designated strategic market status.

What’s next?

If you have opinions or comments, you’re invited to send them by 7 Feb. And, as I’ve seen, they will be listened to: mine were, and I’m no cleverer than you. The final report is due to be published in June 2022.

Afterword

I just wanted to point out that I’m not an evil shill for Google, Soros or even the Illuminati. I just bought a new Macbook Pro, I greatly respect the Apple WebKit engineers and standards experts I’ve met over the years, and think Apple’s accessibility team is second to none. I just want Apple’s management to set Safari free.

Other news reports and opinions

Reading List 284

Component libraries, accessibility and transparency

A couple of weeks ago, Manuel Matuzović wrote

UI component libraries are using the term “accessible” too freely. Adding focus styles and copy-pasting some ARIA roles doesn’t make your library accessible, neither does adding an “accessibility” page where you claim to conform to WCAG just because you ran a Lighthouse test.

Mallory replied

I think right now today they could *all* switch to simply listing what they did and tested, without claims starting with “a”. Followed by a link to their gh tickets w the “accessibility” label. More useful tbh

By coincidence, my boss had asked to write up how to evaluate third party libraries (indeed, any third party software). Here’s some of what I wrote:

The first rule is: don’t unquestioningly believe vendors’ claims. This isn’t to say that they are lying (although some are); perhaps they made their components believing them to be accessible, but didn’t know how to test; perhaps they started off accessible but subsequent contributors/ maintainers let bad code into the product.

Nothing replaces thorough testing with actual devices, but that’s time-consuming, so it’s useful to draw up a shortlist, which is as much an art as it is a science.

  • Is the marketing website accessible? (Give it a quick test with the Tota11y tool. If yes, it doesn’t mean the components are, but if the site lacks alt text, can’t be used with keyboard and has bad contrast, can we really trust the components?)
  • Does the project website/ repo mention a11y prominently, e.g. is it featured?
  • If they do, do they indicate what they tested (WCAG 2.1 A, AA?), on what (JAWS, NVDA, VoiceOver? etc), and when (3 years ago, yet there have been 6 subsequent releases)?
  • Do they have a named person looking after a11y? (If “no”, this isn’t necessarily a problem; if yes, it’s a good sign)
  • Does a web search for the project name + “accessibility” come up with positive or negative results?
  • Do recent PRs suggest that code reviewers took a11y into account? (An original dev may have been a11y-minded, but moved on, so any a11y promises might be stale.)

Hidde de Vries (of W3C) recommends asking the following questions:

  • How did they test? (e.g, automated tests only? Against WCAG? With screen readers? If so, which ones?)
  • Who did they test with? (e.g., did real screen reader users test? Was a broad range of disabilities included?)
  • Are they open about pros and cons of their approach? (Do they claim to be a magical fix-all? Or is there an accessibility statement with known issues and planned fixes?)
  • Who created them? Is it a reputable org with a public service remit, eg GDS, BBC? Or well-respected a11y practitioners, eg Tenon, Tertralogical?

Today, Erik Kroes wrote

I wrote a quick blog for #LionComponents about accessibility in design systems, and specifically what it means in the context of Lion.

Lion is an open-source set of “white label” UI Web Components, developed and tested with assistive technologies on behalf of ING Bank. Erik’s blogpost The Accessibility of Lion is an excellent transparent statement of accessibility. It says what it does, doesn’t over-promise, and is transparent about what it doesn’t do:

Using Lion does not ensure an accessible outcome. Sorry, it doesn’t work like that. What it does provide is a solid base for you to build your own design systems and/or components with. It covers things like keyboard accessibility, UX design and semantics but a bad visual design can still ruin a lot.

It also tells me what testing has been done, and with what assistive technology (although not which browsers and operating systems; for example, is Talkback on Android tested?):

It’s thoroughly design, built and tested for you to meet (and exceed) WCAG 2.1 AA. Components are based on the theoretic ARIA Design Pattern Examples but made practical by automated testing, extended manual testing, heavy scrutiny and testing across platforms with screen readers like VoiceOver, NVDA and JAWS.

It also transparently points to any accessibility-related Github issues, so I can see how quickly things get resolved, the rationale behind any decisions, and whether there are any issues that might prohibit my adoption of it.

More of this stuff, please, component library creators!

(Update 8 Dec 2021):

Reading List 283

Reading List 282

Set Safari free!

As you may know, every browser on iOS is actually just a branded re-skin of WebKit, the engine that Safari uses, because Apple won’t allow other engines on iOS.

Fred from Scooby Doo with a masked figure and text 'Firefox on iPhone'. Fred removes the mask to reveal the villain headed 'Apple's Safari'. Then the same with Edge on iPhone and Chrome on iPhone.

Supporters of the Apple Browser Ban tend to give one of three reasons (listed here from most ridiculous to most credible):

The web shouldn’t be “app-like”, it’s for documents only

Whatever. (See A Brief History of Web Apps for more on why this is nonsense.)

Privacy and security are protected by not allowing non-Apple code on devices

This doesn’t really make sense when non-Apple apps are allowed on iOS, which can leak data so valuable that Amazon and eBay will pay you to use their apps rather than web. Apple’s most recent zero-day vulnerability was exploited along with a flaw in WebKit, and so left all users exposed because users of other “browsers” are forced to use WebKit. Stuart Langridge has a great post going deeper into Browser choice on Apple’s iOS: privacy and security aspects.

Updated 9 Feb 2022: And, of course, Apple kept quiet about a WebKit bug that leaks user’s data, leaving it unpatched for almost two months.

Project Zero’s analysis of 2021 bugs shows that WebKit was by far the slowest to patch security vulnerabilities:

WebKit is the outlier in this analysis, with the longest number of days to release a patch at 73 days. Their time to land the fix publicly is in the middle between Chrome and Firefox, but unfortunately this leaves a very long amount of time for opportunistic attackers to find the patch and exploit it prior to the fix being made available to users. This can be seen by the Apple (red) bars of the second histogram mostly being on the right side of the graph, and every one of them except one being past the 30-day mark.

Allowing other rendering engines leads to Chromium taking over the world

This one kind of makes sense. After all, Opera abandoned its Presto engine and Microsoft abandoned Trident, and both went to Chromium. Firefox risks sliding into irrelevance due to inept lack of leadership. If Apple were forced to allow Chrome onto iOS, then domination would be complete!

The interesting predicate of this argument is that Apple intend to keep Safari as the sad, buggy app that they’ve allowed it to wither to, because it has no competition. I emphatically do not want Chromium to win. Quite the opposite: I want Apple to allow the WebKit team to raise its game so there is an *excellent* competitor to Chromium.

WebKit is available on Windows, Linux and more. Safari was once available on Windows, but Apple silently withdrew it. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

There is browser choice on MacOS, and 63% of MacOS users remain with Safari (24% use Chrome, 5.6% use Firefox). As everyone who works on browsers knows, a capable browser made by the Operating System’s manufacturer and pre-installed greatly deters users from seeking and installing another. There is no reason to believe it would be different on iOS. (Internet Explorer on Windows isn’t a counter-example; there were much better alternatives, long before Edge came along.)

But let’s set out aspirations higher. Imagine a fantastic Safari on iOS, Mac, Android, Windows and Linux, giving Chrome a run for its money. If anyone can take on Google, Apple can. It has talented WebKit engineers, excellent Standards experts, a colossal marketing budget, and great brand recognition.

If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!

(You could also read my Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps.)