SixtyFPS Becomes Slint | Hacker News Reader

SixtyFPS Becomes Slint

slint-ui.com

92 pointstronical58 comments

Hopefully this starts supporting accessibility tools before it gets too much traction and people start shipping inaccessible apps. The WebAssembley output demos on the homepage just render to a <canvas> and are completely inaccessible with any of the usual tools (screen reader, keyboard-only, voice dictation etc) but there's a GitHub issue (https://github.com/slint-ui/slint/issues/32) so fingers crossed.

Yeah, a UI toolkit that doesn’t have even basic accessibility bindings is basically illegal to use for commercial products in multiple major countries now. No specific shame on Slint (everyone has their own roadmaps) but when even big companies are failing* in this way it does seem like we’ve got a long way to go as an industry.

* Flutter has no accessibility bindings on the web and therefore falls under the same “illegal” category.

I’m surprised by how much progress we’ve made in this area. I used to make android apps circa 2013-15. Accessibility was an afterthought, a nice to have.

Reading the SwiftUI docs in 2022, it’s front and centre. They tutorial covers accessibility soon after “hello world”. Every module of the tutorial has a section on setting the right accessibility info, rather than a single, optional accessibility tutorial. It makes me happy that doing the right thing is the default.

I’m planning on making a small productivity app just for myself, but it’ll be 100% accessible simply because they’ve made it so easy.

Integrating accessibility into the tutorial is fantastic, but I’d also attribute it to Apple emphasizing accessibility in their developer documentation for a long time. I remember one of the early Interface Builder tutorials explaining accessibility pretty early on.

I wouldn’t attribute this to progress. iOS and macOS have always heavily prioritized accessibility. For Google, you can see in this example and in the flutter example that accessibility is an after thought.

The last time I spoke to a blind person it was quite a different picture, she was more or less forced to exclusively use apple products because nobody else took accessibility seriously enough.

> a UI toolkit that doesn’t have even basic accessibility bindings is basically illegal to use for commercial products in multiple major countries now

Any sources for that? I've never seen such a claim outside of Hacker News. A quick Google search i did about it only shows some court cases in U.S. (and in those cases it seems to be up to the judge with many failing). The closest is a requirement from EU in 2018 that web sites by the member states' government (ie. it is only for government web sites) has to be accessible. That makes sense, but it only covers government web sites specifically, not any other use for a toolkit (e.g. desktop apps) or even private sites.

Sure.

In the US is the ADA which stipulates “reasonable accomodations” to be made for users with disabilities. You could argue that providing e.g. a phone system as an alternative helps to satisfy this, but it’s debatable, and has been debated backwards and forwards in the US court system.

In Canada, from 2021-01-01 the AODA (Accessibility for Ontarians with Disabilities Act) specifically calls out WCAG 2.0 double-AA (with a few, very minor, changes around closed captioning) as the minimum for both public and private sector businesses.

Israel also has a minimum requirement of WCAG 2.0 double-AA codified into law.

Norway, while not specifically mentioning a standard or guideline, has accessibility requirements interpreted by their regulator to meet WCAG 2.1 double-AA.

And the whole of the EU will gain a minimum requirement of WCAG 2.1 double-AA for the private sector from 2025-06-28 (that’s already the case for the EU public sector). Something to be aware of if you’re purchasing software / white-label systems now.

While it’s a little out of date now, a good starting point is https://www.w3.org/WAI/policies/.

US FE engineer here. I have worked with major online retailers for accessibility remediation after they were successfully sued for WCAG failures.

The biggest thing, folks, is your navigation. If you run a large site and users can’t control your navigation with a keyboard at minimum, you’re really leaving people out in the cold - and asking for a lawsuit, depending on the industry and your country. I'm looking at you, dropdowns.

Full WCAG compliance is expensive and requires vigilance, but getting your navigation right should be priority 0.

Hoes do all those translate to UI toolkits not having accessibility functionality being illegal though?

It is largely a legalese infodump that makes it very hard to parse, but i skimmed through the EU proposal (most of its requirements being at the annex) and it largely seems to be for websites or for very specific uses where it'd make sense (Check-in stations, ticket stations, ATMs, E-commerce sites, etc). The closest to a more general requirement would be the requirement for operating systems to provide functionality like text-to-speech (it mentions "more than one sensory channel" so i assume that would fit), zooming, etc but the wording on that seems to be about the complete package - so i guess if that proposal passes, a store wouldn't be able to sell, e.g., a computer with Linux and IceWM preinstalled as the only desktop (no text to speech there).

When you wrote that UI toolkits without accessibility functionality being illegal was there anything more clear and specific or is it this just more of a "just in case" scenario?

An inaccessible toolkit itself wouldn’t be illegal in the EU, but producing an end-user facing interface under the scope of the EU directive[1] (which as you mentioned is rambling but pretty wide ranging – “consumer terminal equipment with interactive computing capability, used for electronic communications services” could apply to most things that HN people work on) using that inaccessible toolkit would be.

But that’s just the EU. In the AODA[2] for example (which is already law), “barrier” is defined as “anything that prevents a person with a disability from fully participating in all aspects of society because of his or her disability, including a physical barrier, an architectural barrier, an information or communications barrier, an attitudinal barrier, a technological barrier, a policy or a practice” and sets out a process for the development / adoption of standards (the aforementioned WCAG 2.0 double-AA) and binds public and private sector to meet those standards to remove the barriers. Use of an inaccessible toolkit would certainly constitute “a technological barrier”.

[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%...

[2] https://www.ontario.ca/laws/statute/05a11

I think even in those the application would matter. For example i don't see how something like an image editor (which was the original application for Gtk, for example, even if nowadays Gtk has some accessibility support) or a specialized tool like [0] would be illegal (i don't know if it has accessibility support but for the sake of argument lets assume it doesn't).

I can see there being an issue with something like a chat program though (i wonder if XChat will now be illegal to sell :-P).

[0] https://shadermap.com/home/

Note: this is all specific to the US.

https://equidox.co/blog/robles-v-dominos-pizza-explained-no-...

Domino's was sued by a man who is blind who was unable to order a pizza online.

Unfortunately, requirements for websites to be considered "accessible" in a legal sense are essentially undefined in the US. Here's how the site above summarizes, emphasis theirs:

> Title III of the ADA mandates that all places of public accommodation and their services must not discriminate against those with disabilities. According to the 9th Circuit Court of Appeals, that includes making websites equally accessible for people who use assistive technology.

Lacking precise guidelines, the thinking in the web community generally is that if your site adheres to WCAG 2.0 or higher, there will be little purchase for folks to sue. Adherence to that standard has also been mandated in the past by courts in settlements.

> How do all those translate to UI toolkits not having accessibility functionality being illegal though?

You put up a non-conforming website using one of these UI toolkits, someone sues you (there are lawyers who specialize in this), you lose and have to pay lots of money. And then you still have to make your site conforming.

Flutter does handle accessibility on the web, but not very well. You need to press a button hidden from non-screenreader users and then Flutter will make a tree of dummy elements with aria attributes that let you use the app. You can see this if you use a screenreader or your browser of choice's accessibility tree inspector on the demo app.

Ah, OK, looks like they’ve progressed a bit since I evaluated it. Thanks for the update.

I don't think tools like this should be used to make websites / webapps, period; good enough for demo purposes, but just because you can, doesn't mean you should. Just make a good website / webapp, you get a lot of accessibility for free if you use semantically correct HTML and sprinkle in accessibility hints where needed.

Likewise, if you're building apps, prefer to build them using native toolkits if you value accessibility. The major platforms have it built in. When building an app, did you ever consider VoiceOver gestures [1]? Providing a readable text for the text-to-speech engine as an alternative to a UI element?

https://support.apple.com/guide/iphone/learn-voiceover-gestu...

To be clear, using canvas elements for UI is not inherently inaccessible so long as some accessible content on the page is also available to screen readers. Slint could in theory additionally render a kind of keyboard accessible overlay with invisible page elements, for example.

Edit: accessible -> inaccessible

Sure - that's the approach Google have taken with Docs, which switched to canvas-based rendering last year (https://thenewstack.io/google-docs-switches-to-canvas-render...). It's definitely not for the faint of heart though.

The thing that (the generally excellent) MS UI Automation API has taught me is that making the UI accessible makes it testable and vice versa. Since any serious software projects needs tests, having a good accessibility story is paramount to delivering high-quality applications.

It should be possible with a good screen reader. It can read to the icons and text on the page to you. It might be hard to know which boxes are clickable, but that applies to using it normally too.

A screenreader doesn’t literally read the screen, it reads the accessibility tree that apps build for their interfaces. If your user interface kit doesn’t create an accessibility tree then your users’ screenreaders are completely lost at sea.

>A screenreader doesn’t literally read the screen

Why not? The approach of creating an accessibility tree can take extra work from developers instead of it just working. It's convenient to be able to just use an image without writing alt text for it. For example in a group chat.

An image on its own: sure, our tech is getting pretty good at recognising the contents. An image in context? Almost impossible to tell whether it’s meant to be decorative, inspirational, factual, or to be OCRed for text without some sort of hint.

Or what about a chart, or an assembly or measurement diagram? Can current image recognition reliably reproduce that information?

At the end of the day, the extra work by developers is part of what it means to be a developer. If you’re not doing that work then is the end product really meeting your users’ needs?

A screen reader could be made to describe those things. Even if it failed I don't see how it could be worse than it just saying that there is an image there.

> The approach of creating an accessibility tree can take extra work from developers instead of it just working.

Because this isn’t true unless you’re using a nonnative framework like Flutter. If you write your apps in HTML or native frameworks, the tree is built automatically. You only have to fiddle with it if you’re doing really custom stuff (which almost no one is).

The project that is being linked to renders everything into a canvas. It's extra work to create a separate tree for another program to digest.

You asked why not. That's the answer -- why should platforms create an overcomplicated ML-based solution to try to screen read (assuming such a thing is even possible, which I don't believe it is), when existing solutions using standard frameworks work fine and _don't_ require devs to spend extra time?

Considering year old mobiles are able to perform on-the-fly language translations in photos even via awful cameras, i find it weird that screenreaders still rely on such hints.

Delete every CSS declaration (both inline or stylesheets) from every website and see how easy it is to read them. Not very, huh? Same deal with accessibility.

You can't "just OCR stuff" without losing all the visual meaning in a page. Just like we use borders and paddings and colors to hierarchize information, screenreaders use an information hierarchy too so users can conveniently navigate around.

I wasn't referring to just OCR stuff (or even just web stuff) though, my point was that there is enough information in the screen to make out detail - computer vision is more a broad subject than just scanning text. ~12 years ago i was working on getting a computer figure out where 2D boxes were in a feed from a camera (for augmented reality, not accessibility) and my algorithm was quite naive and primitive, but also the source was some awful web camera, not something "pristine" like a screen's content.

Of course i don't know that it is possible, it could be impossible, i'm just having the impression that there hasn't been much effort towards that approach. And TBH it kinda feels like it'd be much better to have a solution that works with "everything" without that "everything" knowing about it (or at least with very little participation from that).

Also FWIW i often use a "simple" web browser like Dillo or Elinks to read articles since it bypasses all the cruft and the usual suspect for making things unreadable isn't CSS but JavaScript.

OCR is relatively easy, but the accessibility information is not only that. There are the types of elements, the possible interactions and the changes on the screen. Also, it gives the ability to skip unnecessary information. Using ml for all of that is taxing and probably not very practical until the invention of AGI.

I wasn't referring to just OCR, check my other comment.

This is an important factor. Accessibility only gets harder to integrate with time and is fundamental to any serious general long-term usage.

The need to rebrand is unfortunate. High framerate is not nearly as important as low standard deviation in the framerate. Naughty dog has blogged on the topic, but it was well known decades earlier in the demo scene. Getting smooth animations on old hardware was not trivial, but people discovered that the way the brain and eye work in conjunction, you could create marquees that looked flawlessly smooth at 8 fps provided you always redrew the pixels with very precise timing.

I’ve sort of known this for a while, but I got to see a demo a few years ago. A friend set up an old amiga demo on a modern fpga, and I saw him get all the timings right for it to finally look smooth as silk on the monitor he had. Then he attached the original signal to a second monitor and the difference was night and day side by side. One was smooth, the other jerky. Both the same fps.

The requirements state "If you're using C++, a compiler that supports C++ 20" and All I'm thinkin' is it must be nice to be able to choose a modern compiler like that. Some of us are lucky to get C++14.

I'm not saying we should be stuck on old compilers forever, but in C++ land, especially when I have to integrate with other frameworks or game engines, the assumption that I can choose my compiler or will always be on latest kinda irks me. Even Qt has versions for the last few MSVC releases (though thankfully the ABI stopped changing every release after VS2015).

That being said, this still looks pretty new, and by the time it's a mature framework C++20 itself may be more available.

I think that's a deliberate decision. They know that by the time it gains adoption even C++20 will be "old". By pinning the requirement high now, while there will mostly be early-adopters, startups, open source projects etc there's less of a cost.

On the Rust side they require a compiler released 10 weeks ago, and it is actually reasonable, thanks to Rust's strong backwards compatibility and painless auto-update.

Yeah the problem isn't nearly as pronounced for rust, since rustup exists and rust itself isn't really available on any platforms you can't just update the toolchain yourself.

C++ has a lot more tangled dependencies going on especially when you're stuck with a vendor's compiler.

Make no mistake: the problem here isn't necessarily technological.

I don't understand what would be an environment where you could fetch the latest rust from internet but not the latest clang. I do my builds on centos:8 (well, rockylinux now) and it has access to the latest GCC 11. On Debian derivatives llvm itself provides up to date repos and on Windows, llvm-mingw works perfectly.

Generally, an environment where you can't use clang /at all/. There are many C++ compilers.

but this does not make sense. If you can't even change the C++ compiler you use you can't write non-C++ code (e.g. Rust) either.

Otherwise let me just fork Clang into the "Gnalc" compiler for the "Sulpsulpees" language which happens to be exactly compatible with the programming language that the clang++-13 binary supports. Takes me a whole 15 minutes, most of which will be taken by forking the LLVM repo on github, and I can guarantee than porting to it will be less effort than porting to Rust. I can even provide the backing of a proper non-profit foundation established on two continents for your legal team's needs.

The reason you can't use clang is not a technical one, but that you are /required/ to use the platform's provided C++ compiler.

And yes, you are making my point. We are in violent agreement.

You can't write Rust either, which is why C++ support would be initially exciting, until you learn you can't use just any C++ compiler and the one you can use is excluded.

Who has such stupid requirements ? What's the "platform" compiler for something that provides GCC up to 11, like centos ?

Embedded stuff usually, game consoles. Also if you have an Enterprise SKU of Visual Studio it costs real money to upgrade. Maybe your company has purchased a compiler suite you have to use. Maybe you have to link against proprietary libs that were only provided for a certain MSVC ABI.

But you originally said: "Yeah the problem isn't nearly as pronounced for rust,"

It does not make sense: the problem is even worse for rust in that case, since you cannot even use it ?

Exactly, that's why one would get excited for C++ support.

However, I realise the point is moot since there would be no way to compile the library. I've been living too long in "Compiles to C" languages this month I guess.

C++ the language also has pretty strong backwards compatibility. It's also trivial to install a new Clang version on most systems. But it certain spaces that's not what matters. Maybe you are only allowed to use That One Certified Compiler from 15 years ago and getting a certification for a newer compiler is not feasible. Or maybe you're on a system where the C++ standard library is part of the system and so you cannot use newer language features because that would require raising the minimum required OS version (I remember that some parts of the C++ standard library are not available if you compile for older macOS versions, for example).

It's usually very old projects that are stuck with old C++ versions, no? I mostly work in embedded, and even there, new GCC or Clang versions are rarely hard to pull in.

Any other frameworks that name overlap with a band?

To name a few:

SDL: https://www.discogs.com/artist/707518-SDL

DirectX: https://www.discogs.com/artist/4506329-Direct-X-2

Vulkan: https://www.discogs.com/artist/1464296-Vulk%C3%A1n

the "Direct X" one looks like an artist picking a "high-tech" name from a software framework.

Slint is the other way around, if anything.

https://en.wikipedia.org/wiki/OSI_model / https://en.wikipedia.org/wiki/OSI_(band)

The biggest problem to me with the old SixtyFPS brand was that it was always just aspirational thing and not really describing any property of the framework. As such it oversold the product and muddled the message as it was easy to point out that it in fact did not always hit 60fps. So while Slint as a brand might be less ambitious, at least it feels bit more honest

Slint sounds to me like a linter for Swift or something like that. A variation on "slick" would be better IMO.

I loved their 1991 album, "Spiderland"

https://www.theguardian.com/music/2014/may/01/spiderland-sli...

It's a classic.

In the kitchensink demo, the keyboard doesn't show when clicking the input, on mobile.

Reply on news.ycombinator.com