[miki123211]

The annoying and counterintuitive part of accessibility work is that there are some architectural decisions that are very hard to undo, don't seem that significant, but will absolutely bite you when you need to implement accessibility.

If you decide on a GUI framework which doesn't communicate semantics to the underlying APIs properly, you have no good options. Either you rewrite your entire project in a different framework just to deliver one feature, dive deep into framework guts to fix the issue (which may be written in an entirely different language and outside your area of expertise), or do some ugly hack on top to sort-of make it work.

A lot of accessibility issues, especially historically, essentially boiled down to "developer chose the wrong approach and didn't know how to get themselves out of the situation later."

It's better now because we went from desktop frameworks drawing their own pixels on screen to web frameworks creating div soup, and div soup is much easier to fix than having pixels instead of native OS controls, but it still happens occasionally. The most recent one I personally ran into was WindScribe, who made a desktop GUI framework of their own for no good reason, and now they can't fix accessibility without a whole lot of work.

[zersiax]

The solution, that accessibility advocates have been clamoring for for decades now, is to s"shift left".

If you know you're going to add accessibility, which ... we have had WCAG since 2005, not knowing that at this point is negligence imho, just make sure you work with frameworks and libraries that won't require overhauling all the things when the PO or management finally get sued into letting devs actually implement it properly. If that kind of functionality takes a backseat to "stunning" and "beaituful" designs that a bunch of people can't use, we take the user out of user interface.

[ryandrake]

We should stop thinking about accessibility as if it's some kind of feature that you "add" into the product later in development. This "add it later" mentality doesn't work for security, and it definitely doesn't work for accessibility. Like security, accessibility should be baked into the product's design from the very beginning. It should be part of the product's basic requirements.

[zersiax]

Doesn't work for security, not for accessibility, not usually for localization and internationalization, it doesn't work for bandwidth optimization... yet we all keep making UIs that really only work on 300 inch Apple Studio displays and screw anyone who isn't Murrican, rich, in a place with good internet, able-bodied and preferably willing to fork over all their personal data, voluntarily or involuntarily. There's a reason people burn out doing accessibility work, it's incredibly draining to have to swim against the current as much as we do, and actually HAVING a disability compounds that problem. We know how to do it best because we live this life, yes, but we also take the brunt when someone up top decides forking out a 3000000 dollar bonus to the CEO is more important than actually enabling users to use the product.

[TimByte]

The web has its own problems, but at least bad HTML is often still visible enough to repair. A custom canvas-like desktop UI can be basically a black box to assistive tech

[zersiax]

Very true :)

I had this exact issue with the Elgato StreamDeck user interface, which renders the macro buttons as one big canvas only drag-and-drop interacts with.

It's rare that I outright cannot figure out a way to make a UI accessible, but that one managed to break everything I tossed at it. I eventually switched my effforts to an open-source third party client which had a web UI, which is now accessible to screen reader users.

As for repairing HTML, my last few engagements have clearly shown me that while HTML CAN be repaired, many devs these days wouldn't know where to even begin to do that. The amount of hand-holding I've had to do has made me suggest, several times, to just give me git access as it'd be faster if I just fix it myself.