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

31–40 of 61 posts

Re: SixtyFPS Becomes Slint

#31

Post by gostsamo »

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.

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.

Re: SixtyFPS Becomes Slint

#32

Post by robin_reala »

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…

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

Re: SixtyFPS Becomes Slint

#33

Post by charcircuit »

robin_reala wrote: post #24
charcircuit wrote: post #22

Earlier quoted context omitted.

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.

Re: SixtyFPS Becomes Slint

#34

Post by robin_reala »

charcircuit wrote: post #33
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.

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

Re: SixtyFPS Becomes Slint

#35

Post by carapace »

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…

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

Re: SixtyFPS Becomes Slint

#36

Post by mirashii »

nindalf wrote: post #13
robin_reala wrote: post #11

Earlier quoted context omitted.

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 “il…

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…

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.

Re: SixtyFPS Becomes Slint

#37

Post by marcellus23 »

charcircuit wrote: post #33
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.

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

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

Re: SixtyFPS Becomes Slint

#38

Post by charcircuit »

robin_reala wrote: post #34
charcircuit wrote: post #33

Earlier quoted context omitted.

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

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.

Re: SixtyFPS Becomes Slint

#39

Post by charcircuit »

marcellus23 wrote: post #37
charcircuit wrote: post #33

Earlier quoted context omitted.

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

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

Re: SixtyFPS Becomes Slint

#40

Post by [deleted] »

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…

[deleted]
Post reply on HN