Hacker News Reader

Comment by nine_k | Hacker News Reader

The usual problems are caused by the non-native controls: no built-in affordances like spell checking and all the OS-specific behaviors, no easy way to plug in accessibility, and the non-native look and feel.

All this is totally fine for a game UI, and is a much harder sell for productivity software.

View on HN

Thats a little bit unfair, even the W3C's web-agency has a hard time building an accessible website and needed spend two weeks (of billable time) reviewing different web frameworks because of it:

https://w3c.studio24.net/updates/on-not-choosing-wordpress/

Not that many people need accessibility. About 100% of people need spell-checking, though.

Certain types of automation and testing are often built on top of accessibility features. Accessibility doesn't just mean accessible to the disabled. It also means accessible to your code.

Exactly. And people forget that depending on the UI libraries you use, you might get a mostly accessible app by default. All of core Windows widget classes, and WinForms and WFP, support accessibility features. Worst case you have a somewhat broken object tree without good labels, but that's already a start.

Dealing with something that believed it only needs a canvas to draw on is PITA.

> Not that many people need accessibility.

100% will require accessibility in some form if your timeframe is long enough. We aren't young forever, you know.

> All this is totally fine for a game UI, and is a much harder sell for productivity software.

Is it? Web and electron applications have the same issue, and they seem to be doing fine.

Reply on news.ycombinator.com