The reason that the Star Wars character Jar Jar Binks is so reviled is that “binks” are things that are actually links, but styled to look like buttons and so don’t respond as expected for keyboard users. (Buttons are actionable with the space bar, links are not.)
I’d rather have a tiger come to tea
Than read more crap about Web 3.
Better have a walrus jizz in the butter
than meet another crypto nutter.
I’d sooner Melania Trump haunt my dreams
Than hear more batshit blockchain Ponzi schemes.
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).
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.
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.
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
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.
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.
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.
The UI fund – Announcing the UI fund from Chrome, designed to provide grants for people who work on design tools, CSS, and HTML.
Exploiting CSP in Webkit to Break Authentication & Authorization – “there was a vulnerability that we reported to Safari that Apple didn’t consider severe enough to fix quickly… after waiting for almost a year, we decided to explore the potential of vulnerability by targeting bug bounty programs”. And, of course, because of the Apple browser ban, all iOS browsers were vulnerable/
:has pseudo class prototyping status – your friends a Eeyo (Adblock Plus) are funding your friends at Igalia to implement the long wished-for :has pseudoclass (aka ‘parent selector’). Implementor Byungwoo Lee discusses problems of it, prototyping progress, current status and steps forward at BlinkOn 15 (captioned YouTube video, 25 mins)
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.
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.)
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!
I can’t reveal my sources, but this letter from two years ago today recently came into my possession while I was doing some research prompted by Eve Fullard, a highly-trained virologist/ epidemiologist/ political commentator and legal scholar who finds time in her busy schedule to post lots of spelling mistakes on GB News.
Bill Gate’s office
11 November 2019
I was recently contacted by Zogmuffin, King of the Reptilians. He confirms that they have finished kidnapping humans, whisking them away in UFOs and sticking probes up their bums, and have decided to move onto Phase 2 of their plan to take over the world.
At our last meeting at the Bilderberg Illuminati Group, you mentioned that you and a cabal of Chinese Jews have a secret lab in Wuhan. Do you think you could release a virus (make it look like an accident, like we did with Chernobyl!), so I can co-ordinate all the world’s governments, scientists and academics in a secret plan to inject the world with a “vaccine” filled with 5G nanobots that will change everyone’s DNA and make them willing fodder for the Reptilians to eat?
Have a think and let me know at Epstein’s Xmas Pizza ’n’ Pedophilia party.
Here’s a song I wrote many years ago when I lived in Turkey. “Laleli” is actually a rather drab suburb of Istanbul, but I’m using it here as a woman’s name purely because it sounds nice and rolls off the tongue!