- eyeo wins landmark copyright court decision; protects digital rights and sets important legal precedent for who ‘owns’ HTML – Media org Axel Springer (German gutter press, not the science publisher) lost its court case against Eyeo (Adblock Plus). They were sad at its sites’ ads being blocked, and claimed that the HTML of their sites is copyright, so blocking or changing any of it is copyright infringement. Herr Judge said “Keine Chance, du kolossaler Schweinehund. Verpiss dich.”
- Defensive CSS – “a collection of snippets that can help you in writing CSS that is protected. In other words, you will have fewer issues in the future” by Ahmad Shadeed
- Add a Service Worker to Your Site by Chris Ferdinandi
- A Complete Guide To Accessible Front-End Components by Vitaly Friedman
- Which accessibility settings do the Dutch really use on their phone? – Survey of 1 million people: “43% use one or more accessibility settings on their phone. 14% uses 2 or more accessibility settings”
- Chromium has started experimental implementation of <selectmenu> – it’s like
selectbut you can style all the constituent parts, instead of twatting about with billions of divs and wiring up keyboard and ARIA yourself (or hoping a framework will)
- Boolean attributes in HTML and ARIA: what’s the difference? asks Hidde de Vries. And then, as a bonus, tells you the answer.
- A New Container Query Polyfill That Just Works by Coy Chrisier
- Full accessibility tree in Chrome DevTools
- Accessibility monitoring of public sector websites and mobile apps 2020-2021 – gov.uk
- Emojis and Accessibility: The Dos and Don’ts of Including Emojis in Texts and Emails – “A friend sent me a text the other day … I never got to the part where I was supposed to give them a call. The emojis got in the way.”
- RFC 3339 vs ISO 8601 – a handy venn diagram and table
- CEOs are hugely expensive – why not automate them? – “If a single role is as expensive as thousands of workers, it is surely the prime candidate for robot-induced redundancy.”
- Web3 is going just great
Archive for the 'accessibility web standards' Category
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.)
And “jar” is some Java shit.
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).
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.
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
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.
Other news reports and opinions
- Benedict Evans’ twitter thread
- UK calls out Google and Apple for limiting competition, asks for better ways to move between iOS & Android, more
- UK’s antitrust watchdog is very angry and has written a letter telling Apple and Google how angry it is with them
- Apple’s cloud gaming restrictions may be biggest news in CMA interim report
- Responsive Layouts, Fewer Media Queries
- Accessible Toggles by @MicheBarks
- taba11y – Chromium extension calculates the tab order of all elements and displays it visually
- Consultation on modified commitments in respect of Google’s ‘Privacy Sandbox’ browser changes “CMA is inviting observations and evidence on modified commitments offered by Google in relation to the CMA’s investigation into Google’s proposals to remove third party cookies and other functionalities from its Chrome browser.” Deadline: 5pm, 17 Dec.
- 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/
- Improving The Performance Of Wix Websites (Case Study) – my chum @DanShappir, the Panjandrum of Performance at @WixEng, on improving the speed of millions of sites hosted at Wix.
- Windows 11 blocks Edge browser competitors from opening links
- :has pseudo class prototyping status – your friends a Eeyo (Adblock Plus) are funding your friends at Igalia to implement the long wished-for
:haspseudoclass (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)
- ‘Buy the Constitution’ Aftermath: Everyone Very Mad, Confused, Losing Lots of Money, Fighting, Crying, Etc – “ConstitutionDAO tried to buy the Constitution. Now it has a $40 million mess on its hands and entire refunds are being wiped out by high fees. Once cryptobro is quoted as saying “We have educated an entire cohort of people about the possibilities of web3”. Indeed.
- Thinking of uses for BlockChains – sagacious Uncle Tel does some thoughts
- Why are hyperlinks blue? and should they be underlined still?
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.
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):
- Also see glamorous Adrian Roselli’s post Be Wary of Accessibility Guarantees from Vendors which is 4 years old, because he’s so far ahead of the curve, he’s like sultry yankee tachyon.
- The Business Disability Forum created an Accessibility Request for Proposal that you can use within your organisation.
- Disability:IN has an Accessible Technology Procurement Toolkit
- Google’s special Android for India revealed – Partnership with Jio brings 5.45 in touchscreen, 2GB RAM & 32GB storage, in-built translation into 10 Indian languages & read aloud, voice activation. 6,500 rupees (£64, $87) or instalment plan. Gamechanger? (Marketing site)
- Photoshop’s journey to the web – Next time someone says “web isn’t powerful enough for my app”, show them Photoshop in the browser, or the Clipchamp video editor PWA
- The ADA lawsuit settlement involving an accessibility overlay: using an accessibility overlay is NOT a valid substitute for a real and valid accessibility strategy.
- Less Absolute Positioning With Modern CSS – an interesting article by Ahmad Shadeed
- Making data visualizations more accessible – “Researchers find blind and sighted readers have sharply different takes on what content is most useful to include in a chart caption.”
- Let’s Talk about Native HTML Tabs – Spicy Sections! I approve both name and concept.
- Line length revisited: following the research – Longer line lengths on screens no longer considered harmful
- Enhancing the Manifest – Aaron Gustafson on some ideas for making PWAs almost as groovy as he is with some proposed additions to the Manifest
- Accessible Writing with Ashley Bischoff – 1 hr video on writing accessible content
- The State Of Web Scraping in 2021 – a look at some utilities available for scraping data out of HTML for processing in a structured way
- AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives: as Bobo Berjon writes, a clear and dispassionate overview of the damage wreaked by AMP and the reason why it’s become very difficult to treat Google-led initiatives with anything other than intense suspicion.
- Apple, Its Control Over the iPhone, and The Internet – “There is no open web on the iPhone, either — only the “iPhone web.””
- Lena – a very thought-provoking short story in the form of a “wikipedia” article about the earliest executable image of a human brain.
- Link o’ the week: The Future of CSS: Cascade Layers is a jolly useful guide by @bramus that’s helped me understand the syntax and subtleties
- Apple to face EU antitrust charge over NFC chip – Only Apple Pay can use it because (checks notes) “privacy and security, absolutely not monopolistic behaviour. Who, us? Ha ha! Never!”
- New study reveals iPhones aren’t as private as you think – “Android phones collect more data by volume, but iPhones collect more types of data, a study finds”
- Make your PWAs Look and Launch Beautifully a presentation a by Önder Ceylan at PWA summit on the new developments on cross-platform icons, splash screens etc.
- Making the whole web better, one canvas at a time – Uncle Brian on
- In Quest of Search – “On why I think adding a new HTML sectioning element for search is a good idea” by Sara Soueidan
- Datasette Desktop – “Datasette was originally designed as a tool for data journalists, to help report on data-driven stories, crunch through large datasets and publish the results…Datasette can be used to power dynamic-static websites: sites that run on serverless hosting while providing dynamic data-backed functionality.”
- Google found guilty of restricting Android forks in South Korea, fined $177 million
- Me Me Me! corner: The F-Word Episode 13 – Does the iOS browser ban harm or help the web? Now with added Stuart Langridge!
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.
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.)