Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SixtyFPS Becomes Slint

slint-ui.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: SixtyFPS Becomes Slint

#41

Post by lelandfe »

badsectoracula wrote: post #26
robin_reala wrote: post #21

Earlier quoted context omitted.

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…

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 close…

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.

Re: SixtyFPS Becomes Slint

#42

Post by kroltan »

badsectoracula wrote: post #29
robin_reala wrote: post #24

Earlier quoted context omitted.

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.

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.

Re: SixtyFPS Becomes Slint

#43

Post by milesvp »

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.

Re: SixtyFPS Becomes Slint

#44

Post by whylo »

cnity wrote: post #23
whylo wrote: post #5

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 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.

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.

Re: SixtyFPS Becomes Slint

#45

Post by badsectoracula »

kroltan wrote: post #42
badsectoracula wrote: post #29

Earlier quoted context omitted.

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.

Re: SixtyFPS Becomes Slint

#46

Post by badsectoracula »

gostsamo wrote: post #31
badsectoracula wrote: post #29

Earlier quoted context omitted.

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.

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.

Re: SixtyFPS Becomes Slint

#47

Post by badsectoracula »

robin_reala wrote: post #32
badsectoracula wrote: post #26

Earlier quoted context omitted.

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 close…

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…

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/

Re: SixtyFPS Becomes Slint

#49

Post by zokier »

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

Re: SixtyFPS Becomes Slint

#50

Post by marcellus23 »

charcircuit wrote: post #39
marcellus23 wrote: post #37

Earlier quoted context omitted.

> 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?
Post reply on HN