[komon]

> it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days

A userscript hammered out in a few days is not really that comparable to incorporating accessibility in a flexible and sound way across a codebase.

Where one is dependent on the current representation and types of features in the app, the other touches pretty much everywhere in a code base that might be split across different people or teams that have other business goals to accomplish.

The scale of work is not really as comparable as they may seem at first glance.

So, contrary to what you said about lack of priority and disrespect, I think it's admirable that they take the time to add these necessary accommodations in a way that ensures that they'll be appropriately maintained and present with future iterations.

[s73v3r_]

The scale of work would be a lot, lot, lot smaller if they had made native apps to start, and could use the built in accessibility stuff instead of having to reinvent the wheel.

[squeaky-clean]

Is there a reason Electron apps can't take advantage of the accessibility features built into Chromium? Having separate platform apps runs into the issue of the user settings page being accessible in the Windows app, but unusable with a screen-reader in the Mac app because of a bug, etc etc.

[Hello71]

assuming this claim is valid, that it took "few days" to implement what took them "months", then they could rewrite the entire user script from scratch every time a change is made, and this could be repeated dozens of times, which, assuming major UI changes are made once every few months, would take several years.

[milesvp]

But, but, but, then I'd have to touch the same code twice... /s

There is definitely a poison in our profession, I definitely have to fight the urge to make sure no future changes will break something, instead of just budgeting time to fix breaking changes later. Especially since no one seems to remember when we all agree something doesn't need to be bullet proof. Just today there was an expression of disbelief when I reminded people I'd built a tempermental UI for some internal tool. Never mind that it was a conscious decision to prioritize a better UI later if we found the tool useful and found the UI was causing problems.

[amarkov]

These are not unrelated observations! The same people who expressed disbelief that your UI is temperamental will react the same way if Slack releases a temperamental UI.

The difference is that they don't work in the same office as Slack. They'll never hear about all the important, completely justified reasons Slack decided to release a bad UI. They'll just notice it happened, and conclude that Slack must hire incompetent UI developers who didn't realize it was bad. Any product with a large customer base has to be pathologically averse to things like this.

[bringtheaction]

What is a temperamental UI? It must have something with UX to do I am sure but can’t find anything on the first page of Google about it aside from one page that mention avoiding UIs to be temperamental but firstly that was all that was said it seems and secondly the forum is was posted on was, ironically, completely broken on mobile such that the text could not be seen. The page had a mobile navigation bar and the zoom set to mobil unchangeable but the content is wide like on a regular monitor and cannot be scrolled into view and additionally there is a sidebar so only the first few letters are visible of each line of text. It was about the worst thing I have ever seen on mobile. Obviously they have wrapped a forum solution in their own templates and their templates are responsive but the forum content is not. So I guess the people that run that site don’t browse their own forum in a mobile browser. Anyway I digress.

[fouc]

Here it's not a named concept, it's just "temperamental" + "UI". In this case, temperamental means "something that does not behave or work reliably."

[bringtheaction]

PS: Here is the link https://www.lean.org/FuseTalk/Forum/messageview.cfm?catid=49...

[taneq]

Any extra engineering time spent on something beyond that required to make sure it fulfils its purpose is wasted. It's like the old quote about Formula 1 cars: The perfect Formula 1 car crosses the finish line in first place, then falls apart. If it doesn't cross the finish line in first place, it's too light. If it doesn't fall apart the moment it crosses the finish line, it's too heavy.

(Note that 'purpose' might be 'allow us to process this one batch of files' or it might be 'provide a stable, maintainable infrastructure for our product for the next 20 years'. It's just important not to lose sight of that purpose either way!)